Skip to content
← All perspectives
UK Government

UK Secure by Design: ten principles on a SABSA spine

The UK government's Secure by Design policy is mandatory for central government departments and arm's length bodies. Read through SABSA, its ten principles stop being a compliance list and start looking like an architecture.

"Secure by design" gets used so loosely that it's worth being precise. In UK government it isn't a slogan. It's a published policy, owned by the Government Cyber Unit, with ten principles, named accountabilities and a compliance route. And it lines up remarkably well with SABSA.

What the policy actually requires

The policy statement is short: all central government departments and arm's length bodies (ALBs) "shall incorporate effective security practices based on the common government Secure by Design principles when delivering and building digital services and technical infrastructure". It's optional for the rest of the public sector, and suppliers are told to check with their security contacts which requirements apply to them.

The scope is deliberately about change, not the whole estate: it covers new services and significant changes — for example those needing a Treasury business case or significantly changing the cyber risk profile — that fall under digital and technology spend controls. Services already in operation or routine maintenance are out of scope, with the expectation that over time everything will either be retired or come into scope.

The ten principles are:

  1. Create responsibility for cyber security risk
  2. Source secure technology products
  3. Adopt a risk-driven approach
  4. Design usable security controls
  5. Build in detect and respond security
  6. Design flexible architectures
  7. Minimise the attack surface
  8. Defend in depth
  9. Embed continuous assurance
  10. Make changes securely

Compliance is reviewed through the spend control approval process, and is demonstrated by reaching a "high" security confidence profile in the Secure by Design self-assessment tracker.

Why SABSA fits so naturally

Secure by Design is risk-driven and accountability-driven, and it expects evidence to flow back to the people who own the risk. That is SABSA's two-way traceability in all but name. Here's how the principles sit on SABSA's layers.

Contextual layer — the business view

Principle 1 names the people: an executive role such as the CDIO accountable for adopting Secure by Design, and a senior role such as the SRO or service owner accountable for the cyber risks of each service. Principle 3 starts with the business: agree a security risk appetite and document the legal, regulatory and contractual requirements the service must meet. Both belong at SABSA's contextual layer — the who and the why. The policy even wants security considered in the business case, which is where I'd run the attributes profiling workshop.

Conceptual layer — what "secure" means here

Principle 3 continues with threat modelling and risk assessment, and principle 4 makes usability a security requirement, asking teams to design controls that remove the incentive for workarounds. In SABSA terms, "usable" is simply another business attribute, weighed against "confidential" or "available" rather than ignored. Principle 6 asks for flexible, risk-based architectures, citing zero trust as an example.

Logical, physical and component layers — how it's built

Principles 2, 5, 7 and 8 are the engineering: due diligence on third-party products, logging and monitoring with incident response built in, a minimal attack surface through segmentation, least privilege and secure coding, and layered controls so one failure doesn't mean compromise. This is where frameworks like NIST SP 800-53 or the CIS Controls supply the specific controls.

Operational layer — keeping it true

Principles 9 and 10 keep the architecture honest over time: test controls regularly, reassess them as the service and threats change, give risk owners "regular evidence that security controls and capabilities are operating as intended", assess the security impact of changes, and record any residual risk in the risk register.

Secure by Design asks for accountable owners, a risk appetite, and evidence flowing back to them. That is SABSA's traceability, written as policy.

The link to the CAF

The policy states that meeting its requirements helps government organisations achieve the required outcomes in the NCSC's Cyber Assessment Framework — with four exceptions: B1 (service protection policies, processes and procedures), B6 (staff awareness and training), D1 (response and recovery planning) and D2 (lessons learned).

Plan the gap explicitly

If your organisation is also assessed against the CAF, those four are largely organisation-wide rather than specific to one service, so Secure by Design won't produce the evidence for them. Treat them as separate workstreams from day one rather than discovering the gap at assessment time.

I cover the CAF itself, and its EU counterpart NIS2, in The CAF and NIS2: one architecture, two regulatory regimes.

How I'd run it on a new service

  1. Business case: name the accountable senior role, agree the risk appetite, and list the obligations the service must meet.
  2. Attributes profile: a short workshop turning those into a dozen or so business attributes, each with a definition and a measure.
  3. Threat model and risk assessment against those attributes.
  4. Agree the control set, with each control traced to the risk it treats.
  5. Plan the evidence at the same time — what will show risk owners each control is working, and how it's collected automatically.
  6. Build change and retirement into the process, so principle 10 happens by default.

Done that way, the self-assessment tracker becomes a report you generate rather than a questionnaire you dread.


Secure by Design is one of the better pieces of security policy the UK government has produced precisely because it's about accountability and risk, not a control list. Put it on a SABSA spine and it's also something rarer: a policy you can trace from a senior owner's decision all the way down to the evidence. There's more on that foundation in SABSA as the foundation.

Sources

JV

JV · Security Architect

I design secure-by-design, zero-trust and well-architected cloud systems — and write about the trade-offs behind them. This site is my portfolio.