What is Secure by Design?
Secure by Design is the UK government’s cross‑government approach to building security into digital services from the outset, replacing point‑in‑time assurance with continuous, risk‑driven practices. It was cemented in the Government Cyber Security Strategy in 2022 and the recently published 2026 Government Cyber Action Plan reinforces accountability by positioning Secure by Design as the default operating model.
Who is Impacted by Secure by Design?
Secure by Design is mandatory for central government departments and arm’s‑length bodies for new or significantly changed services going through Cabinet Office digital & technology spend controls. It is also an advisory for the wider public sector and is expected of suppliers via procurement, so their products and processes align with Secure by Design outcomes.
For a practical overview of Secure by Design – it’s evolution, purpose, and why it matters – watch Bridewell’s webinar: Secure by Design: Transforming Public Sector Cyber Security
Secure by Design Core Principles
Firstly, let’s recap on the intent of Secure by Design by looking at its ten core principles:
| Principle | Intent |
Create responsibility for cyber security risk | Assign accountable senior risk owners with authority and resources across the service lifecycle. |
Source secure technology products | Continuously assess third‑party platforms/code; mitigate findings and drive supplier improvements. |
Adopt a risk‑driven approach | Set risk appetite, run threat‑modelling, and select proportionate controls; keep assessments current. |
Design usable security controls | Make controls clear and low‑friction through user research to prevent workarounds. |
Build in detect‑and‑respond | Design logging, monitoring, alerting and rehearsed incident response from the outset. |
Design flexible architectures | Architect for secure change so new/updated controls can be integrated quickly without instability. |
Minimise the attack surface | Only run what’s necessary; retire/disable the rest to reduce exposure and cost. |
Defend in depth | Layer controls so a single failure doesn’t lead to full compromise; contain impact by design. |
Embed continuous assurance | Continuously evidence that controls operate as intended throughout delivery and operations. |
Make changes securely | Assess and test the security impact of design, development and deployment changes before release. |
Mapping Secure by Design Activities into Agile Project Delivery
For project delivery teams, it is essential to embed Secure by Design requirements and activities within a formal delivery methodology. The UK Government overlays Secure by Design across the GOV.UK Agile framework which comprises the following phases:
- Discovery – Understand users, the problem, constraints and options; decide whether to proceed and what to test.
- Alpha – Prototype and test ideas with users to validate approaches and reduce risk before building for real.
- Beta – Build a working service, test with real users (often private beta first, then public beta), iterate and ready the service for scale
- Live – Run the service in production, continuously improve, monitor performance and support users.
The table below maps Secure by Design requirements and activities to each project phase and lists example artefacts you should document for every activity. Where available, we’ve linked activities and artefacts to official government resources, including downloadable templates you can reuse in your projects.
Note that activities usually span multiple Agile phases. This is because both agile delivery and the Secure by Design approach are designed to be iterative and continuous across the entire service lifecycle, so the same security concerns (risk, obligations, assurance, suppliers, logging/response) must be started early and refined repeatedly as the product or service moves through Discovery → Alpha → Beta → Live.
| Secure by Design Activity | Agile Phase (s) | Action Summary | Artefacts | |
| Prepare a secure service | Consider security within the business case Identify security resources Agree roles and responsibilities Track Secure by Design progress Agree risk appetite | Discovery → Alpha | Embed Secure by Design requirements in strategic/outline/full cases. Secure budget, time, and skills. Document people/tooling needs per phase. Establish clear ownership and governance aligned to Secure by Design policy. | Discovery: Strategic Outline Case; Alpha: Outline Business Case; RACI Security resources plan Secure by Design Tracker Risk appetite statement |
| Understand the security landscape | Manage 3rd party product security risks Understand cyber security obligations Understand business objectives and user needs | Discovery → Alpha | Establish service context, constraints and obligations. Co-design usable controls aligned to user needs and initial architecture. | Conceptual architecture diagram; Security obligations register; Stakeholder map & user needs summary; Initial security requirements list 3rd party risk report |
| Understand the security landscape | Document service assets Assess the importance of service assets Source a threat assessment Perform threat modelling Perform a security risk assessment Agree a set of security controls Mitigate security risks Assess control effectiveness | Alpha → Beta → Live | Identify threats/abuse cases Assess risks Choose controls and supplier requirements proportionate to risk appetite Refine continuously | Service Asset Register Asset Evaluation Business Impact Assessment Data Privacy Impact Assessment Initial threat assessment Threat model CAF assessment Risk register Risk treatment plan Security controls matrix mapped to architecture |
| Anticipate and respond to vulnerabilities | Implement a vulnerability management process Discover vulnerabilities Manage observability | Beta → Live | Put proactive and reactive processes in place for findings and misconfigurations Plan for rapid response and recovery | Vulnerability register & reports Change/patch runbook Incident response playbooks Disaster Recovery Plan |
| Maintain continuous assurance | Evaluate the security impact of changes Retire service components securely | All phases (Discovery→Live); emphasised at Beta/Live | Treat assurance as continuous Automate checks Track confidence Show evidence at phase gates/spend controls | Security assessments Security testing process Security assurance report System retirement plan Service asset register (updated) |
Integrating Secure by Design into the Gate Review Lifecycle
Those readers working in Government departments will be familiar with the concept of delivery gates. UK government programmes and projects are typically expected to pass a sequence of formal decision points or gates (Gate 0 – Gate 5) which provides assurance they can progress successfully to the next stage.
A core part of this process is the requirement to submit the following business cases at key points:
- Strategic Outline Case (SOC)
- Outline Business Case (OBC)
- Full Business Case (FBC)
By capturing Secure by Design plans and outcomes in business cases at key gates, you demonstrate compliance and next‑phase readiness.
To help project teams determine which Secure by Design artefacts to present at each gate, the Infrastructure and Projects Authority (IPA) set out how agile delivery aligns with the gate lifecycle through their GovS 002: Project Delivery Standard. The table below provides a quick reference:
| Gate | Purpose | Secure by Design Actions | Gate pack Secure by Design artefacts |
| Gate 0 - Strategic assessment (Discovery) | Confirm strategic fit and intent | • Appoint SRO • Set risk appetite • Start SbD self-assessment • Plan security resourcing • Include security in the Strategic Outline Case (SOC) | • RACI • Security resources plan • Initial SbD self-assessment • SOC security inputs |
| Gate 1 - Business justification (Discovery) | Define context and justify | • Record security obligations (policy/regulatory) • Map business objectives and user needs • Produce conceptual architecture • Source preliminary threat assessment • Update Outline Business Case (OBC) with security effort/costs | • Security obligations register • Conceptual architecture diagram • Preliminary threat assessment • OBC security inputs |
| Gate 2 - Delivery strategy (Discovery → Alpha) | Set delivery model and security assurance approach | • Initial threat-modelling • Select controls mapped to architecture • Plan assurance-as-code (e.g., secure defaults, vuln checks, SBOM) • Outline logging/monitoring, alerting, incident approach • Embed SbD requirements in procurement | • Initial threat model • Security controls matrix • Incident Response outline • Procurement contract clauses set • Supplier evidence checklist |
| Gate 3 - Investment decision (Alpha → Beta) | Approve investment with testable plan | • Finalise Full Business Case (FBC) security annex and control costs • Confirm pipelines and supplier evidence model • Update risk register | • FBC security annex • Pipeline control list • Risk register • Architecture Decision Records • Supplier evidence checklist (e.g., Software Bill of Materials, hardening, disclosure) |
| Gate 4 - Readiness for service (Beta → Live) | Prove readiness to go live | • Provide current SbD confidence profile (High or credible Medium) • Show CI/CD logs and assurance results (incl. pen tests) • Finalise vulnerability management Standard Operating Procedure (SOP), incident runbooks • Confirm SOC integrations and observability | • SbD self-assessment • CI reports & pen-test findings • Vulnerability management SOP • Incident response playbooks • Observability checks |
| Gate 5 - Operations review & benefits realisation. (Live → Retirement) | Review outcomes; execute secure transition. | • Report CAF-aligned KPIs (e.g., time-to-fix, gate pass-rates, threat-model cadence) • Capture lessons learned • Execute secure retirement/decommission plan | • KPI dashboard (mapped to CAF) • Lessons-learned report • Retirement/decommission plan & evidence |
Secure by Design Responsibilities
Clear accountability for Secure by Design activities is critical to project success. Define these responsibilities in your RACI. They are typically appointed as follows:
Project/program ownership (delivery level)
- Senior Responsible Owner (SRO) / Service Owner - risk owner for the service’s cyber risk through life; ensure resources and authority to manage it.
- Delivery Manager - coordinates the Secure by Design self‑assessment tracker and keeps the confidence profile current across phases.
- Product Manager & Business Analyst - embed Secure by Design in vision, user needs and business cases; ensure security is a delivery constraint from the start.
- User Researcher & Service Designer - make security controls usable and low‑friction via research and prototyping (Discovery/Alpha phases).
- Technical Architect & Security Architect - define conceptual architecture, lead threat‑modelling, control selection and mapping to the design.
- Developers/DevOps/Platform - implement secure defaults, logging/monitoring, vulnerability management and pipeline checks.
Commercial & suppliers
- Commercial/Procurement teams - embed Secure by Design in contracts and procurements (e.g., require secure‑by‑default configs, Software Bill of Materials, hardening guides, vulnerability disclosure).
- Third‑party suppliers - align product security and artefacts to organisational requirements and Secure by Design principles; liaise with security contacts.
Operations & assurance
- Security Operations Centre (SOC)/Operations - agree logging, monitoring, alerting and incident response; run and improve vulnerability and incident workflows in Beta/Live.
- Project teams (all roles) - maintain continuous assurance, retain evidence, and submit the Secure by Design confidence profile at spend controls and phase gates.
How Can Bridewell Help?
To implement Secure by Design effectively, project teams must be actively supported by trained security advisors, from discovery through to live operations. Secure by Design is iterative and multidisciplinary by design, it requires early framing of obligations and risk appetite, threat‑modelling and control selection, continuous assurance, and supplier due‑diligence, work that cannot sit solely with delivery managers or product leads.
Embedding security advisors alongside delivery ensures clear ownership, strong security governance, and subject matter expertise, helping to turn policy into repeatable practice and faster delivery. In short, close partnership between delivery and security is the difference between “secure on paper” and resilient services proven continuously.
Nick Selby
Principal Security Consultant
