Secure by Design in UK Government what good actually looks like in delivery

James Bruckel·CEO, Wuluf

Secure by Design works when leaders back it, delivery teams expect it and security is involved in everyday decisions.

The principles are easy to support.

Programme leaders want to understand risk early, choose proportionate controls and maintain assurance throughout the life of a service. The harder part is making that happen alongside delivery pressures, existing governance and complex supply chains.

Without changes to the way the programme works, Secure by Design can become another set of documents attached to the old process.

A programme completes the self assessment. Security activities appear in the plan. A RACI is produced and evidence is collected before a gateway. All the expected material exists, but commercial, architectural and delivery decisions still happen without useful security input.

The process has been followed, but the service has not been designed more securely.

UK Government guidance describes Secure by Design as a journey of continuous improvement rather than a compliance exercise. That distinction only matters if the organisation changes how it governs, funds, buys, designs, builds and operates a service.

Where Secure by Design applies

The ten Secure by Design principles apply to UK central Government departments and arm’s length bodies delivering new or significantly changed digital services and technical infrastructure. Suppliers do not receive a separate Secure by Design certification. Departments can, and should, put the required outcomes, responsibilities and evidence expectations into procurement and delivery contracts.

Secure by Design does not provide any of the following.

• A certification or accreditation
• A single assessment that a programme passes or fails
• A score that proves a service is secure
• Another name for GovAssure
• A replacement for the NCSC Cyber Assessment Framework

Each mechanism has a different job. Secure by Design shapes how a service is conceived, delivered, changed and operated. GovAssure assesses Government systems within its scope against the NCSC Cyber Assessment Framework. Evidence from Secure by Design delivery can support that assurance. Completing the self assessment does not produce a GovAssure result or certify the service as secure.

There is no Secure by Design badge to obtain. The programme needs justified confidence in the service as it changes.

The principles are also useful outside Government. Private sector organisations can use them to improve ownership, delivery and ongoing assurance. Government suppliers may have to support Secure by Design outcomes through their contracts. The exact obligation depends on the customer, service and procurement.

Executive sponsorship comes first

In our practitioners’ experience, Secure by Design needs support from the highest levels of the organisation. Subject matter experts can explain the approach and shape how it is introduced. They cannot be expected to change the whole organisation from the middle of its hierarchy.

A bottom up approach asks too much of those specialists. They have to persuade each layer of leadership until they reach the executive team, then depend on the message travelling back down through every function. Existing budgets, priorities and working practices remain in place while they do it.

The executive team needs to understand why Secure by Design matters. Policy compliance alone will not change the organisation. Support has to appear in expectations, resources and decisions across commercial, finance, delivery, technology and operations.

Senior Responsible Owners need the same commitment, particularly when they sit outside the executive team. They should expect security to be present in the programmes they oversee and ask why when it is absent.

The answer matters. A security team that lacks capacity has a resourcing problem. A team that was never invited has a different problem. Security is still outside the way delivery decisions are made.

How Secure by Design CAF and NIS2 connect

They overlap in places, but they are not equivalent requirements.

The practical overlap includes leadership ownership, controls based on risk, supplier security and evidence that the arrangements work. Secure by Design can produce evidence that is useful for CAF assessments and relevant regulatory duties.

This is a chance to reuse sound practice, not evidence that the requirements are equivalent. Secure by Design and CAF outcomes do not automatically demonstrate NIS2 compliance. NIS2 is an EU directive and is not a blanket UK requirement. An organisation needs to check its activities, jurisdiction and the national law that applies. European Commission NIS2

Secure by Design should change decisions

The clearest test is what the programme does with the security information it receives. A useful process changes decisions while there is still time to influence them.

That could include the following decisions.

• Changing a proposed architecture after threat modelling exposes an unacceptable concentration of risk
• Putting security requirements and evidence obligations into a procurement before contracts are signed
• Funding monitoring, recovery or specialist assurance through the business case instead of treating it as an unplanned delivery cost
• Rejecting a supplier response that cannot show how important controls will operate
• Changing a release because the programme cannot support an important security claim with current evidence
• Reassessing risk when a service, dependency or threat changes in operation

In each case, security has influenced the decision while the programme can still act.

The Government framework provides principles, recommended activities and implementation support. Those foundations are useful. Templates cannot make up for unclear ownership, weak governance or a delivery model that brings security in too late.

What organisations often misunderstand

A completed tracker does not mean a programme has passed

The self assessment tracker helps a team understand and communicate its progress against the principles. It is not a pass mark, an accreditation or a security outcome.

A programme can mark an activity as complete while the risk remains poorly understood. It can produce a threat model that nobody revisits, assign work to people without enough authority or record controls whose effectiveness has not been evidenced.

The tracker should expose uncertainty and prompt action. Pressure to improve its status before a review can create confidence that the programme has not earned.

A useful self assessment is a current view of delivery. Evidence supports it and people can challenge it. When the service changes, the assessment changes too.

Security cannot own Secure by Design alone

Security professionals have an important part to play, but the process cannot sit within the security team.

Decisions across the programme create or reduce risk. The Senior Responsible Owner influences priorities and risk appetite. Product and delivery teams shape scope. Architects and engineers decide how the service works. Commercial teams set supplier obligations. Finance affects what can be funded. Operations determine whether controls keep working after launch.

Government guidance reflects this shared model. The practical problem begins when everyone is said to be responsible and nobody has been told what they must do.

A programme needs clear answers to these questions.

• Who is accountable for the service’s cyber risk
• Who owns each significant risk and security outcome
• Who provides specialist advice and assurance
• Which decisions the delivery team can make
• What must be escalated, to whom and by when
• Who must produce and maintain the necessary evidence

Shared responsibility without named accountability usually becomes unowned work.

One early workshop is not continuous involvement

An early workshop is useful. It does not keep security involved as the service changes.

Requirements change. Architects revise assumptions, suppliers introduce dependencies and operational experience changes the picture. A threat model produced once at the start can soon describe a service that no longer exists.

Government guidance says that threat modelling should be repeated when a relevant design change occurs or a new threat emerges. The same principle applies to the wider security case. Evidence and risk decisions need to follow the service as it changes.

Set clear triggers for reassessment. A material design change, new data flow, new supplier, significant vulnerability or revised operating model should prompt the relevant security work.

A gateway is too late to begin assurance

Traditional delivery often concentrates security work immediately before an approval, accreditation or service transition. Teams then discover that evidence is missing, requirements were interpreted differently or a control cannot work as intended.

Secure by Design moves assurance into delivery.

This does not require a constant flow of reports. It requires enough evidence to show that security claims remain valid as the work progresses. Normal delivery should produce that evidence wherever possible. Teams should not have to reconstruct it shortly before a board meeting.

In practice, this means the following.

• Security requirements are traceable to designs, controls and tests
• Architecture decisions record their security implications
• Supplier evidence is reviewed as it becomes available
• Control owners understand how effectiveness will be demonstrated
• Vulnerabilities, exceptions and risk decisions remain visible
• Changes trigger proportionate reassessment
• Operational monitoring provides evidence that controls continue to work

A gateway should confirm assurance that the programme has already built. It should not begin the search for evidence.

Controls need a reason

A catalogue of controls cannot replace an understanding of risk.

The right control depends on the service, its users, information, dependencies and threats. Applying a standard set without that context can consume a great deal of effort while leaving the main exposure untreated.

Start by understanding what needs protection, who might threaten it and what the consequences could be. Threat modelling then informs architecture and the choice of controls. Assurance tests whether those controls support credible security claims.

A programme should be able to explain why each control is needed, which risk it addresses and what evidence shows it is working. That explanation starts with the service and the consequences of an incident. Starting with a control catalogue can leave teams with plenty of documents and no clear account of why the controls are sufficient.

Supplier responsibility needs to be explicit

Government services often depend on several delivery partners, platforms and specialist suppliers. Contracting out the work does not remove the programme’s exposure.

Secure by Design needs to cross organisational and contractual boundaries. Requirements must be clear enough to procure against. Suppliers need to know which evidence they must provide, when it is due and how changes or vulnerabilities will be handled. The contract also needs to settle responsibility for risks created where systems and suppliers meet.

If these expectations appear after contract award, important work may sit outside scope. Evidence may be unavailable, and remediation may require a commercial renegotiation.

Commercial engagement is part of security. Early involvement gives the programme more control over supplier behaviour and reduces the risk of paying later for requirements it assumed were included.

What good looks like through delivery

Secure by Design should be visible in every phase of delivery.

Programmes do not need to follow an identical process. Government guidance allows organisations to tailor the recommended activities to their structure, processes and resources. Tailoring should make the work proportionate. It should not remove an activity because it is inconvenient.

Security needs to be visible

The change also affects who knows the security team and how people work with it. Security cannot remain a specialist group known only within IT. Commercial, finance, operations and programme teams need to know who to approach, when to involve them and what help they can expect.

Our practitioners have found that the strongest implementations make security a trusted adviser. Teams raise questions early because the conversation helps. Problems become known while there is time to deal with them, rather than appearing as unwelcome surprises at a gateway.

It should be simple to ask security for help. The technical work may still be complex, but involving the team should be part of everyday conversations and should not create another obstacle to delivery.

A practical operating rhythm

Secure by Design lasts when it becomes part of existing delivery rather than a separate security project.

A practical rhythm could include the following.

• A named senior owner for cyber risk and an agreed escalation path
• Security representation in relevant design, commercial and delivery decisions
• A maintained service context, threat model and view of critical dependencies
• Security requirements linked to delivery work and acceptance criteria
• Regular review of material risks, assumptions, exceptions and evidence gaps
• Defined change triggers that cause reassessment
• Supplier security obligations tracked alongside other contractual deliverables
• Assurance activity planned with the delivery roadmap rather than immediately before gateways
• Operational feedback, including incidents, vulnerabilities and monitoring, used to update the security position

The aim is not to create more meetings. Put the right security information into the forums where decisions are already made.

How to tell whether it is working

Completion percentages say little on their own. Programme leaders should look for changes in delivery behaviour.

Ask these questions.

1. Can the programme explain its most important security risks in service and mission terms?
2. Has security evidence changed an architectural, commercial or delivery decision?
3. Are significant risks owned by people with authority and budget?
4. Can security requirements be traced to implementation and current evidence?
5. Are suppliers clear about the security outcomes and evidence expected from them?
6. Does assurance activity happen throughout delivery?
7. Are threat models, assumptions and risk assessments updated when the service changes?
8. Can operational teams explain how they will detect, respond to and recover from incidents?
9. Are exceptions explicit, limited in time and accepted by an authorised owner?
10. Does the programme know where evidence is missing, rather than assuming that no reported problem means no risk?

If a completed tracker is the only convincing evidence of progress, Secure by Design has become another compliance exercise, whatever level of confidence the tracker reports.

Good Secure by Design can be quiet

Mature implementation does not have to produce the largest security workstream or the most documentation.

It produces timely decisions, clearer ownership and fewer late surprises. Security requirements arrive before procurement and threats influence architecture. Evidence comes from delivery. Risks reach people who can act, and operational lessons feed back into the service.

Security becomes part of the programme’s normal work.