RaptorGRC — Offline GRC

BLOG

What Is UK Secure by Design Government Assurance After Accreditation

Published 2 August 2026 · By P Larner

Regulation & Legislation#SbD

What Is UK Secure by Design: Government Assurance After Accreditation

Illustration for: What Is UK Secure by Design, Government Assurance After Accreditation

Illustration for: What Is UK Secure by Design, Government Assurance After Accreditation

For two decades a government system became secure the moment a letter said it was. An accreditor read a pile of documents, signed off the risk, and everyone moved on until the renewal date. That world has formally ended. The Ministry of Defence retired accreditation in July 2023, the rest of central government followed with a mandatory policy in early 2024, and the replacement is called Secure by Design. If you deliver digital services in or to government, it is now the frame your security work is judged in, so it is worth being precise about what it actually is, who it binds, and where it can quietly go wrong.

What Secure by Design actually is

Secure by Design is the UK Government’s policy for building security into digital services from the start and keeping it there for the life of the service. It is published on gov.uk, developed centrally with input from the National Cyber Security Centre, and it is not a product standard, not a certification scheme, and not a checklist you complete at the end. It consists of a set of principles and a longer set of delivery activities, running from discovery through to decommissioning, which delivery teams self-assess against continuously.

The reason it exists is that the old accreditation model failed in predictable ways. A certificate described a system as it stood on one day, issued by a reviewer outside the delivery team, based on documents written after the decisions were already made. An earlier post in this series looked at those failure modes in practice, and at what the shift demands of a delivery team day to day. This post stays at the primer level, because the framework itself is still widely misunderstood.

The one sentence version. Security stops being a gate someone else opens and becomes a risk the delivery team owns, manages and evidences for as long as the service runs.

Who it applies to

Central government departments and their arm’s length bodies have been required to follow Secure by Design since early 2024, for new digital services and for significant changes to existing ones. It arrived through the central digital and cyber functions rather than through legislation, which means the obligation is policy and spend-control pressure rather than statute.

The Ministry of Defence moved first and runs its own version, mandatory across defence programmes since July 2023. The intent is the same, though the artefacts and terminology differ, and defence suppliers meet it through contractual conditions rather than gov.uk guidance.

Everyone else feels it indirectly. Local government and the NHS have their own regimes, but the direction of travel is one way, and any supplier building or operating systems for a department in scope will find the framework’s expectations flowing into contracts. If government is your customer, Secure by Design is your problem too, whether or not your name is on the policy.

The principles, in plain terms

The framework rests on around ten principles. Stripped of policy language, they group into four demands:

  • Someone accountable owns the risk. A named senior owner carries the cyber risk for the service, and responsibility for security sits inside the delivery team, not in a review function at arm’s length.
  • Effort follows risk. Teams are expected to understand what they are protecting and from whom, and to size their controls to that answer rather than to a template. Sourcing decisions are part of this, because buying insecure technology is a risk decision like any other.
  • Security is designed in, not bolted on. Minimise the attack surface, defend in depth, make controls usable enough that people do not route around them, and build architectures that can change when the threat does.
  • The service can detect, respond and improve. Monitoring, incident response and secure change are delivery concerns from day one, and assurance continues for as long as the service is operated.

None of this is novel security thinking. What is novel, for government, is who has to do it and when. These duties belong to the programme, from discovery, with evidence expected as the work happens.

How assurance works now

The accreditation certificate has no successor. In its place sits continuous assurance, which means the delivery team assesses itself against the framework’s activities throughout delivery and operation, records the outcomes, and keeps its risk decisions current. The senior risk owner reviews and accepts risks as they change, not once at go-live. Documents that were once produced for a reviewer, then archived, are supposed to become living artefacts that the team actually steers by.

Comparison diagram of a straight path ending at a certificate stamp beside a continuous loop of design, build, operate and improve

Comparison diagram of a straight path ending at a certificate stamp beside a continuous loop of design, build, operate and improve

The old model ended at a stamp. The new model never ends, which is the point, and also the risk.

GovAssure sits above it. Secure by Design operates at the level of an individual service. GovAssure, the Cabinet Office assurance scheme built on the NCSC Cyber Assessment Framework, reviews a government organisation’s security posture as a whole, with independent review of the self-assessment. The two are complementary rather than competing. GovAssure asks whether the department manages cyber risk credibly across its estate, and Secure by Design asks whether this particular service is being built and run securely. A department can pass one conversation and fail the other, which is exactly why both exist. This series has covered the Cyber Assessment Framework separately if the organisational layer is your concern.

What it means for suppliers

If you build, host or operate systems for government, the practical effects arrive through procurement rather than policy documents.

  1. Contracts increasingly require evidence that security activities happened during delivery, not just a compliance statement at acceptance.
  2. Your customer’s delivery team now owns their risk, so expect earlier and more technical security conversations, and expect your architecture decisions to be challenged while they are still cheap to change.
  3. Defence suppliers see the same shift expressed through defence conditions and the evolving cyber requirements attached to contracts, with evidence expectations scaled to the sensitivity of the work.
  4. A supplier who can show threat modelling, secure design decisions and monitoring capability as standard outputs will find this regime a commercial advantage rather than a burden.

The honest counterpoints

Adoption is uneven. Departments interpret the activities differently, and a framework applied through policy rather than statute depends on the strength of each organisation’s digital and security functions. Two teams can both claim compliance and be doing very different things.

Continuous assurance can decay. A living risk record is only alive while someone reads it. Without a forcing function, the artefacts can rot into a spreadsheet updated the week before a review, which is accreditation’s worst habit reproduced without accreditation’s one virtue, the hard deadline.

Self-assessment needs teeth. The old gate was slow and often theatrical, but it forced a moment where someone independent looked. Where independent scrutiny is light, an optimistic team can mark its own homework for years. My own view is that the framework works precisely where a strong risk culture already exists, which is an uncomfortable property for a policy meant to create one.

Capability is the binding constraint. The model assumes every delivery team can reach real security expertise. Many cannot, and no principle document conjures a security architect into a team that has never had one.

A decision, not a certificate

Secure by Design gets the theory right. The people making daily decisions about a system are the only people who can actually secure it, and a certificate signed by someone else was always a comforting fiction. But the framework does not secure anything by itself. It works where risks have named owners, where decisions are written down while they are being made, and where the record is honest about what was accepted and why. That is the habit this whole series keeps returning to, because every regime eventually rests on it. The letter that once declared a system secure is gone, and nothing has replaced it. What replaces it is the delivery team’s own discipline, deliberately applied and documented, or nothing at all.

Run your GRC programme in your own network.

RaptorGRC Community Edition is free — every module, offline licence activation, nothing phones home.

Register / Download Contact us
An unhandled error has occurred. Reload 🗙

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.