Secure by Design in Defence: A Practical Guide to Delivering SbD Programmes
In this ongoing series, Defended Solutions and Ntegra explore the friction between high-speed digital delivery and the rigorous governance required in regulated environments, such as defence.
Written by Daniel Mulliss, with contributions from Andy Halkerston.
Executive Summary: Secure by Design (SbD) is a framework developed in partnership with the National Cyber Security Centre (NCSC) that requires security to be embedded into systems from the outset, rather than applied retrospectively. In defence, the MOD has adopted and formalised these principles into its own SbD framework, which governs how digital programmes are designed, delivered, and operated. Unlike legacy accreditation models, MOD SbD is evergreen: a continuous discipline that travels with a system throughout its entire lifecycle, from the first architectural decision to post-live operational governance. This article provides a practical guide to delivering SbD programmes in a defence context, drawing on direct experience of how the framework operates in practice.
Why Secure by Design Demands a Different Mindset in Defence
Most governance frameworks have an end date. A project completes its assurance activities, an accreditor signs off, and the compliance clock resets. MOD Secure by Design is deliberately different.
SbD is evergreen. It does not conclude at delivery. It travels with the system through its life; every change, every upgrade, and every operational iteration. For delivery teams used to treating security as a gate to pass through, this represents a fundamental shift in how risk and assurance are managed.
The consequence of not making that shift is predictable: projects stall at the build and test, high-level risks accumulate at senior leadership level, and services are brought into operation carrying residual exposure that should have been resolved at design stage. This is due to no vehicle in place to work on any residual risk associated with the delivery. In environments where a security failure carries financial, operational, and reputational consequences, that outcome is unacceptable.
The organisations making the strongest progress are the ones that treat SbD as a delivery disciplineto embed, rather than a framework to satisfy.
Stage 1: Assessment and Interpretation: Getting the Right People in the Room First
When a new project lands, the first SbD decision is a resourcing one. The technical questions come later.
Every MOD programme needs a Delivery Technical Security Lead (DTSL). Their role is to ensure the project is actively thinking about its approach to SbD from the outset, rather than discovering its obligations halfway through design. In practice, many programmes engage their DTSL too late, often after architectural decisions have already been made. That sequencing error creates delays that are entirely avoidable.
With the right person in place early, the next step is to determine how SbD principles map to the specific technical environment in question. This is a substantive exercise that requires genuine judgement. A single cloud platform, and the applications that reside on it, built top to bottom, follows a relatively straightforward assurance path. A multi-cloud environment is a different proposition entirely. In that scenario, you need to define the service layer and assure it through SbD, then separately address the inherited controls within each underlying platform and its associated applications.
Both approaches require an agreed security assurance strategy, signed off with the key stakeholders before delivery begins. That agreement is a foundational document. It prevents your assurance approach from being disputed six months into the build.
Stage 2: Technical Integration: From Principle to Design Decision
Translating a written SbD principle into a specific technical decision is where many programmes lose coherence. The process requires a structured design hierarchy, each stage mapped explicitly back to the controls it is intended to satisfy.
The starting point is a threat model at high-level design stage. This generates the evidence requirements for the assurance process as well as identifying risks in the abstract. A component exposed to the internet, for example, creates an obligation to demonstrate that protective measures are in place. The threat model makes that obligation explicit and traceable.
From there, the design process follows a disciplined sequence:
● A high-level design that maps directly to the relevant NIST 800-53 controls (specifically, the extract used to evidence compliance against the SbD framework) as well as to the project's functional and non-functional security requirements.
● A test plan that defines how each control will be evidenced. This includes IT health checks, penetration testing, and any user acceptance testing with a security dimension.
● A low-level design that maps back to the high-level design and to the applicable policies and standards, ensuring no gap opens between what was intended and what is built.
Running alongside all of this is the SbD assessment itself: a continuous measurement of risk and mitigation that evolves as the project progresses. SbD is a continuous activity with risk assessed, mitigated, and reassessed throughout delivery, rather than a waterfall exercise with a single compliance verdict at the end. At some points, stakeholders may decide to accept residual risk in order to meet cost or time constraints. That is a legitimate decision, but it must be made consciously and documented within the SbD assessment, rather than absorbed quietly into the delivery backlog.
For a practical illustration of how architectural design choices connect to SbD obligations at the prototype stage, see our earlier article on Secure by Design prototypes.
Ntegra’s Perspective
The pressure that pushes security work into “next sprint” usually begins before sprint planning. If security requirements are not identified during refinement, delivery teams are left trying to absorb them inside a fixed timebox, which is where risk starts to accumulate.
Our approach is to move security left. High-level design and Secure by Design considerations are established during Discovery and refined throughout delivery, with Architects working alongside the Scrum team to maintain technical direction rather than reviewing from a distance.
Security requirements are treated as part of delivery rather than parallel to it. Relevant controls are reflected in backlog items, acceptance criteria and, where appropriate, supporting assurance activity. Stories that do not meet the agreed Definition of Ready return to refinement.
This matters because sprint pressure is real. The most effective safeguard against security drift is not additional governance at the end of delivery, but ensuring security expectations are visible, estimated and prioritised in the same backlog as functional work. Drift is surfaced early through refinement, sprint reviews and continuous technical oversight.
Stage 3: Evidence and Assurance: Proving What You've Built
Evidence in a modern SbD environment is a continuously updated record of how risk is being managed throughout the delivery lifecycle, rather than a folder of documents produced at the end of a project.
In practice, evidence takes several forms. Test results from penetration testing and IT health checks provide point-in-time assurance against specific controls. Architecture documentation, including high-level and low-level designs with their explicit control mappings, provides the audit trail that shows how each decision was made and why. The SbD assessment itself provides the running record of risk posture: what was identified, what was mitigated, what was accepted, and by whom.
The relationship between the delivery team and the assurance body is critical here. Security assurance is an active participant throughout delivery, rather than a review function that appears at the end of a phase. Teams that treat their accreditor as an external examiner to be satisfied at milestone reviews consistently produce weaker evidence packages than teams that maintain an ongoing dialogue with assurance throughout the build.
This is one of the clearest markers of delivery maturity in an SbD environment. A programme that has produced the right documents but maintains a transactional relationship with its assurance body will consistently underperform against one where delivery and assurance work collaboratively throughout.
Stage 4: Operational Governance: SbD Continues After Go-Live
One of the most consequential misunderstandings about Secure by Design is the assumption that once a system is live, the SbD obligations are discharged. They are not.
Operational governance under SbD is, in many ways, where the framework shows its real intent. The controls that were designed in must be operated in. For example, administrators must operate under least privilege, consistently and verifiably. Vulnerability management must be performed on a defined cadence. Service reviews should occur at least quarterly (every 3 months) or sooner if there are significant changes, providing a structured checkpoint for risk posture, operational compliance and emerging threats. Service reviews must run against problem management processes. The system must be monitored in a way that provides evidence of continued compliance as well as continued availability. The in-life service will track against its security risks, ensuring the landscape is always improving whilst always checking for new threats.
Any significant change to the system after go-live is treated as a new project from an SbD perspective, with its own assessment cycle. This is by design. Treating post-live changes as minor configuration activity exempt from assurance is precisely how previously secure systems accumulate the kind of unmanaged risk that SbD was created to prevent.
At the portfolio level, this creates a genuine governance obligation for CIOs and programme stakeholders. SbD compliance is a live position that must be actively managed, reported against, and maintained as systems evolve, rather than a project-level artifact to be filed and forgotten.
Ntegra’s Perspective
The most reliable predictor of a poor handover is a delivery team that treats operational running as someone else’s problem from sprint 1. Where transitions succeed, operational obligations are designed into delivery from the outset, with the people responsible for running the service involved early enough to shape them.
That means least privilege administration, vulnerability management, monitoring, service reviews and operational responsibilities are considered alongside functional capability rather than retrofitted after go-live.
A mature handover unfolds over time rather than through a single transition meeting. Architects and technical leads remain engaged during early live operation, documentation evolves alongside delivery and operational teams gain ownership through structured shadowing and joint working. Secure by Design remains active after go-live, so significant changes return through the same refinement and assurance process rather than bypassing it.
What a Mature SbD Framework Looks Like
The clearest indicator of SbD maturity is what happens when things do not go according to plan, rather than how a programme describes its approach.
In an immature environment, you see programmes stalling at the SbD bar without a clear path through. You see high-level risks being signed off at senior leadership level not because leadership has made an informed risk decision, but because the programme has run out of road and needs to move. You see security and delivery operating as adversaries rather than partners.
In a mature environment, SbD is mapped out into a framework that is easy to understand and follow. Expectations are clear. RACIs are defined. Projects and programmes can navigate the process without constant escalation, because the process itself is designed to enable delivery, not obstruct it.
The key word is framework. SbD works best when it is experienced as a shared organisational standard, rather than a bespoke negotiation on every new programme. The controls, the design stages, the evidence requirements, and the assurance relationships should all be established at the organisational level, so that individual programmes can focus on applying them rather than reinventing them.
Ntegra’s Perspective
The organisations where Secure by Design operates as an enabler rather than a constraint tend to share a small number of structural characteristics. Security responsibilities are clear, decision-making authority is understood and assurance expectations are established early enough to shape delivery rather than react to it. Technical security leads, architects and key business stakeholders are engaged before delivery begins, enabling an agreed approach to assurance from the outset.
In mature environments, security is treated as part of delivery rather than adjacent to it. Relevant controls are reflected in backlog refinement, acceptance criteria and delivery governance, while assurance activity remains engaged throughout the lifecycle rather than concentrated at milestones. Residual risk decisions are made consciously, documented transparently and managed as part of delivery rather than absorbed implicitly through time pressure or backlog compromise.
Where Secure by Design feels obstructive, the pattern is often the reverse: security roles engaged too late, assurance expectations still evolving once delivery has started and governance structured around milestone approvals rather than continuous collaboration. The strongest delivery environments treat Secure by Design as a shared organisational discipline, giving teams enough clarity to move quickly without losing control.
Summary: The SbD Implementation Roadmap
For organisations looking to move from compliance anxiety to delivery confidence, the path through SbD is a practical one:
Appoint your Delivery Technical Security Lead (DTSL) at the start of every programme, before the design is underway.
Agree your security assurance strategy with key stakeholders before delivery begins, including how you will approach multi-platform or inherited-control environments.
Build your design hierarchy explicitly: threat model, high-level design with control mappings, test plan, low-level design.
Treat the SbD assessment as a live document, updated continuously throughout delivery, not produced once at milestone.
Maintain an active, collaborative relationship with your assurance body throughout the build.
Design your operational governance model before go-live, not after. Least privilege, vulnerability management, and service reviews must be operational from day one.
Treat post-live changes as new SbD projects. Evergreen means every change.
SbD done well does not slow delivery. It removes the ambiguity and late-stage surprises that slow delivery. The programmes that invest in the framework upfront are the ones that reach operational service without the accumulated technical and assurance debt that has come to characterise too many defence digital programmes.
If your organisation is delivering under Secure by Design and needs the framework built into the Agile cadence itself, from HLD and backlog refinement through to operational handover, contact Defended Solutions to discuss how we work alongside delivery teams in defence and other regulated environments.
Frequently Asked Questions
What is the role of the Delivery Technical Security Lead (DTSL) in a Secure by Design programme? The DTSL is responsible for ensuring the project has a clear approach to achieving SbD from the outset. Engaging them early, before architectural decisions are made, is one of the most effective ways to avoid delays later in the lifecycle.
What does "evergreen" mean in the context of MOD Secure by Design? Unlike legacy accreditation models, SbD does not have a fixed end date. The framework travels with the system throughout its life. Any change to the system after go-live must be assessed against SbD requirements as a new project, ensuring that security posture is maintained continuously rather than validated once.
What does evidence look like in a modern SbD delivery environment? Evidence includes penetration test and IT health check results, architecture documentation with explicit control mappings, and a continuously updated SbD assessment recording risk identification, mitigation, and acceptance decisions throughout the delivery lifecycle.
How does SbD change the relationship between delivery teams and accreditors? At its best, SbD transforms the accreditor relationship from a transactional review at the end of phases into an ongoing collaborative dialogue throughout delivery. Programmes that maintain this engagement consistently produce stronger evidence and encounter fewer late-stage surprises.
What are the warning signs of an immature SbD approach? The most visible indicators are programmes stalling at the SbD bar without a clear resolution path, and high-level risks being signed off at senior leadership level not through informed risk appetite decisions, but because the programme lacks the framework to manage them at the right level.
