Guidance

Secure by Design - Cultivating a Culture of Information Security

Published 11 November 2025

1. Briefing Summary

This document provides a comprehensive overview of the ‘Secure By Design’ (SbD) approach, which aims to embed cyber security principles throughout the lifecycle of digital services. It outlines the rationale behind SbD, the key principles, roles and responsibilities, and practical implementation steps. The approach emphasizes continual risk assessment, proactive security planning, and the involvement of all stakeholders in managing cyber risks. This briefing is intended for professionals involved in digital service delivery, including technical, security, and project management roles.

2. Introduction

• This presentation will cover what ‘Secure by Design’ means, why it’s essential, and how it can be effectively implemented in projects.​

• Let’s begin by defining ‘Secure by Design’ and understanding why it’s a fundamental practice in today’s security landscape​

• This will also cover details on the processes required to follow SbD procedure

3. What is Secure by Design?

• Secure by Design emphasises the integration of security measures and considerations into the entire project lifecycle.​

• It’s about making security a priority from the beginning, rather than treating it as an afterthought or a box to check at the end.

4. What’s changing?

‘The current approach to security risk management in the MOD does not work and is increasingly unsuitable for modern threats to the UK’– Audit in 2020

The change:

• Phasing out accreditation, phasing in continual assessment

• Capabilities will be inherently protected from the outset throughout their lifecycle, resilient against cyber-attacks, with pre-planned recovery processes in place.

• The scale and complexity of security challenges can be identified early, so that suitable resources can be allocated within the project lifecycle to address it.

• We’ll get a better understanding of risks and more effective management of them

5. The Secure by Design mandate

“All central government departments and arms-length bodies (ALBs) shall incorporate effective security practices based on the common government Secure by Design principles when delivering and building digital services and technical infrastructure.”

Secure by Design Policy

Outcome 9 of the Government Cyber Security Strategy

“…ensure that appropriate and proportionate cyber security measures are embedded within the technology government uses, and that the security of digital services is continually assured throughout their lifecycle.” 

Commitment 11 of the Roadmap for digital and data, 2022 to 2025

“All new services shall comply with the common approach to Secure By Design”

6. Who does Secure by Design affect?

It encourages everyone to collectively manage cyber security risks related to the delivery of digital services.

6.1 Digital & Data

• CDIO

• CTO

• Service owners

• Product managers

• Delivery managers

• Developers / DevSecOps

• IT operations

• User researchers

• Technical architects

6.2 Project Delivery

• Senior Responsible Owners

• Programme and project management

• Business analysts

6.3 Security

• CISO

• Security advisers

• Security risk managers

• Security architects

• Security assurance experts

6.4 Other

• Commercial / Procurement

• Enterprise risk and operations

• Finance

All shall be made aware!

7. The Importance of Secure by Design

7.1 The Human Side

• Saves time and costs in the long run by reducing the number of large updates needed to security software. ​

• Builds trust with customers and stakeholders. If their data can be safer and more secure, the more trust they will have in our teams and products ​

• A clear and easy-to-follow security framework means that all levels of management and staff will be able to understand security requirements. ​

• If cyber security stops being considered purely digital, and becomes a business risk in the open, everyone can work to make systems safer.

7.2 The Digital Side

• Secure by design also involves decentralising the security infrastructure. Centralised infrastructure means that successful attacks can access other parts of the system easily. ​

• Minimises potential security breaches and mitigate long term risks. If a program has consistently up to date security, that’s been integrated from design, it can recognise and fight threats more efficiently. ​

• The cloud world is constantly changing. The sheer volume of data means automated, integrated security must keep up with human interaction.

8. The Principles

Read more on security.gov.uk

1. Source secure technology products

2. Adopt a risk-driven approach

3. Design usable security controls

4. Build in detect and respond security

5. Design flexible architectures

6. Minimise the attack surface

7. Defend in depth

8. Embed continuous assurance

9. Make changes securely

10. Create responsibility for cyber security risk

9. Understanding Risk Is Crucial

• The Discovery Phase encourages projects to consider security risks at the conceptual level.​

• This provides a basis for understanding the key security risks of a project from the outset.​

• Further decisions should be informed by the results of this process so a secure and cost-effective product can be delivered.

10. Risk Assessment

• When delivering a digital service, you need to identify, analyse and evaluate the potential cyber security risks. It is important to embed risk analysis and evaluation into digital delivery processes to continuously be aware of the highest priority risks.

• For more context into risk management from UK Government, read The Orange Book – Management of Risk – Principles and Concepts

• The gov.uk portal lists multiple frameworks including ISO, NCSC, and NIST. As a standard, the MoD uses the NIST framework, specifically ‘NIST 800-30: Guide for Conducting Risk Assessments’, amongst others.

• This is used to support the risk assessment process and provide an established process to follow.

• In addition to this material, a workshop on risk assessment and the NIST 800-30 process will be held, for those who need additional guidance.

10.1 The Discovery Phase

• The Discovery Phase is divided into enterprise and system level tasks​

• They are mainly Project Management focused so security or engineering specialists aren’t required​

• The outputs of the Discovery Phase help inform the scale of risk and complexity of the security programme required​

• The Discovery Phase Section of the SbD Self-Assessment Tracker (on SbD portal) should be completed​

• A Project Security Officer should review where needed​

• Information owners should be consulted and are responsible for this​

• Side note: with a lot of projects aiming to have lighter documentation, proportional document sets commensurate to the associated security risk will be produced

10.2 Continual self-assessments are key

• Self-assessments report on how well a project is managing and integrating security based on how well the reported risk is being managed.

• This allows for you to evaluate, progress and demonstrate the maturity of your projects risk management.

• Self-assessments must be reviewed at-least once every 3 months to ensure risk is being managed appropriately and to account for any changing circumstances.

• Keeping updated with regular self-assessments benefit projects and allow for more informed security decisions to be made.

11. SbD Implementation

11.1 This includes:

• Security Working Groups

• Self-assessment

• Security management plans

• SRO involvement

12. The Senior Responsible Officer (SRO)

12.1 The official description:

• As set out by JSP 440 Leaflet 5C, it is the duty or the SRO to ensure Delivery Teams (DTs) are following Secure by Design (SbD) policy, ensure cyber risk is defined and published for the DT, and ensure that cyber risks are actively managed throughout the capability life cycle. The SRO must ensure delivery is underpinned by formal risk management framework.

12.2 What this means:

• The SRO is the person responsible for signing off on risk

• The SRO should have an agreed risk appetite, and review if expected risk changes

• All Security Working Group (SyWG) decisions should be signed off by the SRO (or SRO representative)

• The SRO should be the last sign-off for security documentation

13. The activities

Read more on security.gov.uk

The items in bold below have a template on the SbD portal at ‘security.gov.uk’.

13.1 Prepare a secure service

• Considering security within the business case

• Identifying security resources

• Tracking Secure by Design progress

• Working out the project’s security risk appetite

• Agreeing roles and responsibilities

13.2 Understand the security landscape

• Managing third-party product security risks

• Understanding cyber security obligations

• Understanding business objectives and user needs

13.3 Manage your security risks

• Performing a security risk assessment

• Performing threat modelling

• Responding to and mitigating security risks

• Agreeing a security controls set for your service

• Assessing the effectiveness of security controls

• Assessing the importance of service assets

• Documenting service assets

• Sourcing a threat assessment

13.4 Anticipate and respond to vulnerabilities

• Discovering vulnerabilities

• Managing observability

• Implementing a vulnerability management process

13.5 Maintain continuous assurance

• Evaluating the security impact of changes

• Retiring service components securely

14. Supporting resources

14.1 Security Controls Taxonomy

• Aims to help project teams select appropriate security controls from recognised industry security standards and frameworks as part of risk mitigation activities.

• Mapped to Cyber Assessment Framework (CAF) outcomes in order to support organisations with demonstrating their achievement of their respective CAF profile (GovAssure).

• Example-Secure-by-Design-Controls-Taxonomy-ALPHA.xlsx

14.2 Self-Assessment Tracker

• Supports the project team to track its progress against the Secure by Design principles and activities to deliver appropriate security protections within new systems at each stage of the delivery cycle.

• Used to generate an overall SbD confidence profile that is used as input to the Digital and Technology spend control approval process.

• Secure_by_Design_Self_Assessment_Tracker_alpha.xlsx

14.3 RACI Matrix

• Provides a view of what roles should be involved in what activities and on what basis (Responsible, Accountable, Consulted, Informed).

• Delivery teams can use this template as a starting point for assigning roles and responsibilities to Secure by Design activities.

• Cyber-security-roles-and-responsibilities-RACI-matrix-EXAMPLE.xlsx

15. Self-Assessment - Security Working Groups

• A project Security Working Group (SyWG) should be established to oversee the management and co-ordination of project security activities and ensure the effective communication of project security and resilience risk to relevant stakeholders.​

• The SyWG should also be responsible for Information System Contingency Planning (ISCP) to establish thorough plans, procedures, and technical measures that can enable a system to be recovered as quickly and effectively as possible following a service disruption. ​

• A security consultant should also be employed to work within the SyWG. This ensures corners aren’t cut by a team assessing their own work.​

• This ensures that security and resilience risks are managed to a level acceptable to the Senior Responsible Officer and Programme Manager.

16. Security Management Plan (SyMP)

• As before, a security management plan is required for any SbD project​

• It describes the approach a project will take to embed security so it can be deemed SbD​

• Sufficient detail is required to ensure individuals new to the project can understand the security strategy and scope​

• The SyMP should be reviewed by members outside the security team, including technical lead, project manager, and SRO

17. Security Self-Assessment Tracker

17.1 How to track Secure by Design progress

• Step 1: Understand what the self assessment tracker is for

• Step 2: Download the self assessment tracker

• Step 3: Understand how the self assessment tracker works

• Step 4: Provide a response to each required action

• Step 5: Keep the self assessment tracker current

• (note this tool is OFFICIAL so no info above this classification should be inputted)

18. More in depth into these steps…

18.1 Step One: Understand Purpose

• This tracker allows delivery teams within government departments and arm’s-length bodies (ALBs) to demonstrate how they are meeting the Secure by Design principles. ​

• It will provide a confidence profile (LOW, MEDIUM or HIGH) applicable to the phase you are at within the service lifecycle.​

• If the project is in scope for the digital and technology spend controls approval process, this tracker must be submitted to the Government Digital Service (GDS) with support from your internal assurance teams.

18.2 Step Two: Download

• This tool is a prototype that is currently being assessed and improved. Each digital service should have a separate self-assessment for each delivery stage.​

• The MS Excel download link: Secure_by_Design_Self_Assessment_Tracker_alpha.xlsx ​

• Populate the ‘Summary’ tab with the necessary information. Save it to an appropriate folder within your file management system. It should be treated as an asset and therefore only be accessible to those who need to view or contribute to it.

18.3 Step Three: Understand Functionality

• Use the dropdown tool in the ‘Summary’ tab to select the appropriate agile or waterfall delivery phase for your service.​

• In the ‘Self-Assessment Actions’ tab is a list of actions associated with recommended Secure by Design activities. Those marked as required will differ depending on the delivery phase selected. Complete the tracker during the course of delivery by providing a response to each action, selecting from “Yes”, “No” or “N/A” (not applicable).​

• Your total “Yes” responses will determine your security confidence profile. This will be shown on the ‘Summary’ tab as LOW, MEDIUM or HIGH. Weighting has been applied to certain actions during each delivery phase to indicate those which are particularly important to achieving the necessary security levels.​

• If you mark too many actions as “N/A”, your security confidence profile will be set as INVALID which indicates that not enough activities have been completed to achieve a sufficiently secure service.​

• A HIGH confidence profile is required to demonstrate that the digital service has been delivered in accordance with the Secure by Design principles

18.4 Steps Four and Five: Respond and Repeat

• Each action is associated with a Secure by Design activity that provides an explanation of why it is necessary, and the steps required to achieve the intended outcome. As part of your regular project delivery process, update your responses to each required action.​

• A ‘Notes or evidence’ column is provided where you can add supporting information, such as an explanation of how the security requirement has been met, or a reference to where activity outputs can be found.​

• It is not necessary to provide links to documents. If you do, you must ensure that access has been set appropriately to maintain the security of the information you are referencing.​

• Include the maintenance of the self assessment within your project delivery processes, updating the information to reflect new evidence or when there are significant changes in outputs already submitted. You may be required to change a response from a “Yes” to a “No” if the evidence supplied no longer meets the criteria of the self-assessment.​

• Share the information with your delivery team, business risk owners and your organisation’s security function so it can be factored into project planning and decision making.

19. In-Service Transition to SbD

There are many UK Gov systems that are already in-service and accredited. These systems all need to shift to SbD as per new Gov policy. Here are some basic steps that an in-service DT should complete to start their SbD process:

• Find out if/when they had SyWGs and how they have managed risk so far with accreditation.

• Find out what their security governance is, including who is SRO and what their risk appetite is.

• Is there a Project Security Engineer (PSyE) or Project Security Officer (PSyO)? If not, these roles need to be assigned.

• Complete self assessment tracker and submit (as explained in previous slides).

20. Conclusion

• Highlights importance of integrating security considerations from the outset

• Focuses on minimising vulnerabilities

• Increases awareness of continual risk management

• Improves governance and empowers the SRO

• Scale and complexity of security challenges can be matched to suitable resources

21. Useful Links

• Example-Secure-by-Design-Controls-Taxonomy-ALPHA.xlsx​

• Cyber-security-roles-and-responsibilities-RACI-matrix-EXAMPLE.xlsx​

• Secure_by_Design_Self_Assessment_Tracker_alpha.xlsx​

• About Secure by Design - UK Government Security - Beta​

• Secure by Design principles. ​

• The Orange Book – Management of Risk – Principles and Concepts​

• NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments​

• Digital and technology spend control version 6 - GOV.UK​

• Secure by Design (MoD)