Secure by Design in Practice: More Than a Checklist at the End

Illustration for: Secure by Design in Practice: More Than a Checklist at the End

The UK Government and the Ministry of Defence have replaced accreditation with Secure by Design, and plenty of programmes are still treating it as the old process with a new letterhead. That misreads what changed. This article covers what the shift actually asks of a delivery team, and the failure mode that wastes the opportunity.

What changed and why

For years, government systems were accredited: a delivery team built the thing, an accreditor reviewed a pile of documents (typically an RMADS, a Risk Management and Accreditation Document Set), and at some point a certificate said the system was acceptable to operate. The MOD formally moved away from this in July 2023, and the wider government Secure by Design policy followed for central departments and arm’s length bodies.

The old model failed in predictable ways. Accreditation was a point-in-time event, so a system accredited in March could be materially different, and materially weaker, by September. The accreditor owned the judgement, so delivery teams optimised for passing the review rather than securing the system. And the documentation was produced at the end, describing decisions already made, which meant security findings arrived when they were most expensive to fix.

Secure by Design replaces the certificate with continuous through-life assurance. There is no final sign-off to aim at. Security is assessed continuously, from concept through disposal, and the accountability sits with the people delivering and operating the capability, not with an external gatekeeper.

Two stacked delivery timelines comparing a single accreditation certificate gate with continuous Secure by Design assurance markers from concept to disposal

One gate versus continuous assurance: accreditation stops at a certificate while Secure by Design assesses across the whole lifecycle.

The principles that actually matter

Strip away the guidance documents and three ideas carry the weight:

• Risk-driven, not compliance-driven. The question is not “have we done the 20 mandated things” but “what could compromise this capability, and what are we doing about it”. Controls follow from an understanding of threat and impact. A logistics system and a targeting system should not have identical control sets, even if both sit at OFFICIAL.
• Delivery team ownership. The Senior Responsible Owner carries the risk. The delivery team makes the security decisions and holds the evidence for them. Security professionals advise, challenge and assure, but they no longer own the outcome. This is the hardest cultural shift, because for two decades teams learned that security was somebody else’s signature.
• Continuous assurance. Assurance activity happens throughout: threat modelling at design, security testing in each increment, monitoring in live, reassessment when the system or the threat changes. The MOD’s self-assessment expects an honest, current view at any point, not a dossier assembled for a gate.

What it means day to day for a delivery team

The principles sound abstract. In practice, a team doing this well looks like this:

• Security requirements sit in the same backlog as everything else, prioritised against features, with acceptance criteria a tester can verify. Not a separate 40-page requirements annex nobody opens.
• Threat modelling happens when architecture changes, not once at the start. A one-hour session when you add a new integration or data flow, with the outputs recorded as risks or backlog items.
• The risk register is a working document the team actually uses in planning, reviewed at least each increment, with named owners and dates. If the register was last touched four months ago, you are not doing Secure by Design.
• Pipelines carry part of the assurance load: dependency scanning, static analysis, infrastructure-as-code checks, with failures triaged like any other defect.
• Someone on the team, often called a security lead or workstream lead, owns keeping the self-assessment current, but the decisions are made in ordinary team ceremonies.
• Risk decisions are written down when they are made. Two paragraphs, dated, with the rationale and who agreed it. That is the evidence base.

None of this requires a big security team. It requires the delivery team to treat security work as delivery work.

Evidence as you build, not audit at the end

The evidential shift is the practical heart of the policy. Under accreditation, evidence was manufactured retrospectively: a technical author interviewed the team and wrote up what had supposedly happened. Under Secure by Design, evidence is the natural exhaust of doing the work, captured at the time.

Concretely, that means the architecture decision record from April is the evidence that you considered the trade-off in April. The pipeline run showing the dependency scan passed is the evidence of scanning. The pull request approving the firewall rule change, the pen test report and the tickets tracking its findings to closure, the threat model diagram with a date on it: these are the artefacts. The discipline is small and constant, perhaps 30 minutes a week of tidying, rather than a three-month documentation sprint before a gate.

Evidence timeline from April to September with dated artefact cards and a green loop closing arrow

Dated artefacts pinned to the delivery timeline, with the loop visibly closing between pen test and retest.

Two rules keep it honest. First, evidence must be dated and attributable; an undated diagram proves nothing about when you knew something. Second, evidence must show the loop closing. A pen test report on its own is evidence you found problems. The report plus the fix tickets plus the retest is evidence you managed them.

The common failure: RMADS by another name

The most frequent way programmes get this wrong is to rename the old process and carry on. The accreditor becomes an “assurance coordinator”. The RMADS becomes a “Secure by Design evidence pack”, still written by a contractor in the last quarter before a milestone, still describing decisions post hoc, still reviewed by someone outside the team whose approval everyone privately treats as the real gate.

Two-column comparison of renamed accreditation practices against genuine Secure by Design behaviours

Row by row, the difference between renaming the old process and actually changing it.

You can spot this failure quickly. Ask a developer on the team who owns the top security risk. If the answer is a name in another building, it is accreditation in a lambswool jumper. Ask when the risk register last changed. Ask whether any security requirement has ever been prioritised above a feature. Ask whether the self-assessment answers changed between two consecutive returns; if they are static, nobody is looking at them.

The other version of the failure is drowning the team in the full weight of every guidance artefact at once, so Secure by Design becomes 200 questions answered badly rather than 20 risks managed well. Proportionality is in the policy for a reason. Use it.

Where to start on Monday

If your programme is mid-transition, do three things first. Put the current risk register in front of the delivery team and make one person per risk accountable by name. Start an architecture decision log this week, even if the backfill is thin. And book a recurring monthly hour to update the self-assessment as a team, so the current view stays current. The programmes that succeed at this are not the ones with the best documents. They are the ones where, when the threat changes, the backlog changes the same week.