The MOD’s 2023 Secure by Design shift was deliberately more than a change of paperwork. It moved accountability for cyber risk toward senior responsible owners, capability owners and delivery teams, and replaced a late accreditation event with assurance through the lifecycle. Public MOD guidance describes security as a shared responsibility, supported by independent assessment at key stages rather than a final gate bolted onto delivery.[1][2]
That changes what “good” looks like. Assurance teams do not primarily need a large document set. They need confidence that the programme understands its mission, architecture, threat and risk; has made deliberate design choices; has implemented and tested the resulting controls; and has put residual risk in front of the person authorised to own it.
The evidence chain
| Link | Question it must answer | Typical evidence |
|---|---|---|
| Mission and context | What must the capability achieve, protect and survive? | Service outcomes; critical functions; impact tolerances; data and safety context |
| Threat | Who might act, with what capability, against which paths? | Threat assessment; abuse cases; attack paths; intelligence assumptions |
| Risk | What could happen, why does it matter and who owns it? | Risk scenarios; likelihood/impact rationale; named owners; treatment decisions |
| Architecture | Where are trust boundaries, dependencies and failure modes? | Current and target diagrams; data flows; identity and admin paths; dependency map |
| Controls | Which measures reduce each material risk? | Control design; requirements traceability; configuration standards; supplier obligations |
| Verification | Did the controls work in the real build? | Test results; code/configuration evidence; vulnerability findings; exercise outcomes |
| Decision and operation | What remains, who accepted it and how is it maintained? | Residual-risk decision; operating model; monitoring; change and incident records |
Artefacts that create confidence
A concise security case
The security case should make a structured argument: the capability is acceptably secure for a defined context because stated claims are supported by evidence. It should acknowledge uncertainty and exceptions. A clear twenty-page argument with live evidence is more useful than two hundred pages of generic control text.
Architecture that matches the deployed service
Assurers need more than a high-level solution diagram. Useful views show data movement, trust boundaries, administrative paths, external dependencies, identity flows, logging, key management, backup and recovery. The names in the diagrams should reconcile with inventories, tests and operating procedures. If the diagram and the build disagree, the build wins.
Threat and risk that drive engineering
Threat assessments should be specific enough to change a design choice. Risk statements should describe cause, event and consequence, identify the affected mission or asset, and have accountable owners. A register of generic cyber risks, all scored “medium”, rarely demonstrates understanding.
Traceable security requirements
Each important security requirement should be traceable backwards to a risk, policy or operational need and forwards to design, implementation and test evidence. This does not require a perfect toolchain. It requires stable identifiers and disciplined links. Traceability allows an assurer to sample a claim and follow it without guesswork.
Evidence from the delivery pipeline
The strongest programmes make evidence a by-product of engineering: reviewed code, signed builds, configuration scans, infrastructure-as-code checks, component inventories, test outputs, privileged-access logs and release approvals. Evidence is dated, attributable and tied to the version that will operate. Screenshots without provenance are weak; repeatable results are strong.
An operating model, not just a launch position
Security at entry to service is temporary. Assurance needs to see how vulnerabilities, changes, suppliers, identities, keys, logs, incidents, backups and recovery will be managed. It should be obvious which team acts, within what time, using which authority and information.
The gaps that stall programmes
| Gap | Why it stalls assurance | Practical correction |
|---|---|---|
| Security starts after architecture | Material trust and dependency choices are already expensive to change | Embed security architecture and threat work in discovery and option selection |
| Documents describe an ideal build | Assurers cannot rely on evidence that does not match deployment | Generate diagrams and evidence from authoritative inventories and pipelines |
| Risk has no empowered owner | Treatment and residual-risk decisions cannot be made | Name owners early; define escalation and acceptance thresholds |
| Supplier assurance stops at a certificate | Service-specific dependencies and privileged paths remain untested | Obtain architecture, control and incident evidence for the actual service |
| Testing proves presence, not effectiveness | A control can exist yet fail against the threat scenario | Use misuse cases, attack paths, recovery tests and adversarial validation |
| Temporary exceptions become permanent | The live risk position diverges from the approved position | Time-box waivers; fund remediation; report ageing and expiry |
| Operational teams arrive late | Controls cannot be sustained after go-live | Bring operators into design, exercises, handover and acceptance |
Build the evidence as you go
- Define the mission, critical functions, data and impact tolerances before selecting controls.
- Create an architecture baseline and record material decisions, alternatives and assumptions.
- Model credible threats and express risks in operational language that owners can decide.
- Map risks and obligations to security requirements with stable identifiers.
- Attach implementation and verification evidence to each requirement during delivery.
- Run assurance reviews at decision points while change remains affordable.
- Transfer the evidence chain into operations and keep it alive through change, incidents and testing.
Ten-minute assurance test
Choose one material risk at random. Ask the programme to show the threat or failure scenario, affected mission outcome, owner, design response, implemented control, latest test result, outstanding finding and residual-risk decision. If this chain cannot be followed in ten minutes, the programme has an evidence-management problem even if every expected document exists.
About TIS Global
TIS Global helps organisations design, assure and deliver secure digital transformation in complex and regulated environments. We bring together strategy, enterprise architecture, cyber security, cloud and operational delivery to turn policy into services that work in the real world.
References and further reading
[1] Ministry of Defence, “Secure by Design - a new way to manage cyber risk in capabilities” (30 May 2023).
[2] Ministry of Defence, “Secure by Design: User-centred guidance on Digital MOD.UK” (10 February 2025).
[3] Ministry of Defence, “Secure by Design: Two Years of Building a More Resilient MOD” (13 August 2025).
[4] National Cyber Security Centre, “Zero Trust” collection, reviewed 16 January 2026.
[5] National Cyber Security Centre, “Secure connectivity principles for operational technology (OT)”.
[6] National Cyber Security Centre, “Cyber Assessment Framework”.
© TIS Global 2026 | These papers provide general guidance and does not replace legal, safety or system-specific assurance advice.