How to integrate Secure by Design into the government gate review life cycle
Aligning activities to your organisation’s delivery process.
The Secure by Design approach aims to help teams deliver effective cyber security from the initial concept through every stage of a project delivering a digital service.
This guidance aims to help project delivery professionals effectively incorporate Secure by Design activities into the gate review process for agile delivery. We recommend tailoring it to reflect your organisation’s structure, processes and resources, since:
- agile phases do not always align exactly with gates
- the point at which business cases are submitted may vary for different departments
- some teams use a waterfall or hybrid delivery method
- smaller projects may not need to submit all the business case types we’ve listed
Projects that are already underway and digital services which are in public beta or live will not pass through each of the gates or phases listed on this page. The Questions about Secure by Design guidance explains how the Secure by Design approach applies in these scenarios (see the questions and answers in the ‘When it needs to be done’ section).
Overview of gates, business cases and agile phases
Gate review points
To promote consistent ways of working across government, the Government Functional Standard (GovS 002) sets a series of gate review points, also known as decision points or stage gates. These exist so business cases can be reviewed at key stages of the end-to-end life cycle. When teams show they’re meeting the necessary objectives, they can get approval to move to the next stage of the project.
The gate review points are:
- gate 0: strategic assessment
- gate 1: business justification
- gate 2: delivery strategy
- gate 3: investment decision
- gate 4: readiness for services
- gate 5: operations review and benefit realisation
Business cases
As outlined in the latest agile digital and IT projects guidance, you will submit the following business cases or equivalent at key points during this process:
- Strategic Outline Case (SOC)
- Outline Business Case (OBC)
- Full Business Case (FBC)
By including details of planned and completed Secure by Design activities within business cases at key delivery points, you’ll be able to demonstrate that you’re achieving security requirements and are suitably prepared for the next delivery phase.
Agile phases
As part of projects, teams following agile delivery methods use the following phases:
These phases run in parallel to the gate review life cycle, with business cases being submitted at key delivery points. For example, the SOC might be submitted at the end of discovery, the OBC during alpha and the FBC at the end of private beta, although this can differ from project to project.
How activities align to gates and agile phases
Gates 0 and 1: discovery
It’s never too soon to think about cyber security considerations, and it’s sensible to include security-related topics during initial discussions about an idea for a digital service.
At the earliest available opportunity, look to get answers to questions like:
- does providing this service create any obvious risks to users or the organisation?
- have any similar services been developed that we can take a security steer from?
- do we have the necessary resources available to make this type of service secure?
If you can establish elements like the project’s risk appetite and who will have responsibility for cyber security at the concept stage, it will be easier to show that you’re meeting the necessary requirements during later phases. It will also help to reduce the chances of a project being rejected or delayed due to security risks.
At the end of your discovery phase, you may have to submit a Strategic Outline Case (SOC) so the project can proceed. Completing the following recommended activities by this point will help you meet the required Secure by Design principles:
- Considering security within the business case (if a case was submitted)
- Identifying security resources
- Agreeing roles and responsibilities
- Tracking Secure by Design progress
- Working out the project’s security risk appetite
- Managing third-party product security risks
- Understanding cyber security obligations
- Understanding business objectives and user needs
- Documenting service assets
- Assessing the importance of service assets
- Sourcing a threat assessment
Until there’s something concrete to develop, much of this will remain theoretical rather than specific. Provide as much detail as possible, and use resources or expertise available from elsewhere in your organisation to cover areas of uncertainty.
Gates 2 and 3: alpha
When the first building blocks of your service are being put together, the security implications of what you’re planning to build will start to become clearer.
The size and complexity of alpha projects vary wildly, but in general they will be experimental solutions that cover core parts of the intended user journey. They are likely to rely on existing tools or environments, and be designed to be disposable.
The GOV.UK Service Manual guidance on how the alpha phase works says that “a crucial part of alpha is identifying your riskiest assumptions and testing them.”
Each of your tests and experiments should also have information on the:
- types of cyber threats that may be relevant
- vulnerabilities that may exist
- data and other assets that will need to be protected
- security controls that could be put in place to mitigate threats
Details may still be vague or unknown at this stage, but by consulting with cyber security advisors, you can work out what you need to do to provide more in-depth information. By collating this, along with a high-level security risk assessment in an Outline Business Case (OBC), the alpha phase project can progress, either to a further experimental stage or to a private beta.
At this point you should properly evaluate prototypes based on their security credentials and alignment with Secure by Design principles. By this stage, a delivery team should:
- be including details of how they’re meeting security requirements within project plans
- be including security resources within their budgets
- have thorough processes for conducting risk assessments and developing mitigation strategies
With a clearer understanding of the technical architecture of the project forming, this is also the point where you should consider risks related to third-party products. Security requirements need to be embedded in procurement processes and supplier contracts with documented information on how vendors will meet obligations.
At the end of the alpha phase, you’ll submit an updated OBC. Completing the following recommended activities by this point will help you meet the required Secure by Design principles:
- Considering security within the business case (if a case was submitted)
- Identifying security resources
- Agreeing roles and responsibilities
- Tracking Secure by Design progress
- Working out the project’s security risk appetite
- Managing third-party product security risks
- Documenting service assets
- Assessing the importance of service assets
- Sourcing a threat assessment
- Performing threat modelling
- Performing a security risk assessment
- Agreeing a security controls set for your service
- Responding to and mitigating security risks
- Assessing the effectiveness of security controls
- Implementing a vulnerability management process
- Discovering vulnerabilities
- Managing observability
- Evaluating the security impact of changes
- Retiring service components securely
Gate 4: private beta
The gate 4 review approximately aligns with the end of the private beta phase. You’ll submit a Full Business Case (FBC). This needs to provide conclusive evidence that you’ve addressed cyber security risks and put suitable mitigations in place to counteract them.
At the end of the beta phase, you’ll submit an FBC. Completing the following recommended activities by this point will help you meet the required Secure by Design principles:
- Considering security within the business case (if a case was submitted)
- Identifying security resources
- Agreeing roles and responsibilities
- Tracking Secure by Design progress
- Managing third-party product security risks
- Documenting service assets
- Assessing the importance of service assets
- Performing threat modelling
- Performing a security risk assessment
- Agreeing a security controls set for your service
- Responding to and mitigating security risks
- Assessing the effectiveness of security controls
- Implementing a vulnerability management process
- Discovering vulnerabilities
- Managing observability
- Evaluating the security impact of changes
- Retiring service components securely
Gate 4 and 5: public beta and live
By the time your service is released to the public, you should continue to mitigate cyber security risks through change management processes and business as usual security risk management processes.
At the stage when your service is ready to move from public beta to live, you’ll submit an updated FBC. It should contain details of how you are meeting Secure by Design principles during operation and performing ongoing security monitoring and vulnerability assessments.
Completing the following recommended activities by this point will help you meet the required Secure by Design principles:
- Considering security within the business case (if a case was submitted)
- Tracking Secure by Design progress
- Responding to and mitigating security risks
- Assessing the effectiveness of security controls
- Discovering vulnerabilities
- Evaluating the security impact of changes
- Retiring service components securely
Because the security landscape is always evolving, regular security reviews need to take place to check that assumptions made about threats and risks are still accurate.
It’s likely that your live service will still go through a series of iterations and updates to address any emerging security threats. When making any changes to your live service, the testing of any components with security implications should be conducted in development environments and fully assured before going live.
As part of lessons learned and project closure process, you should assess whether you’ve met the expected cyber security requirements of the project.
Identify areas where Secure by Design principles were successfully implemented and where improvements could be made for future projects.
Tables showing how activities align
These 5 tables show each group of Secure by Design activities and their corresponding agile phases. An activity appearing in more than one phase means we recommend you revisit it and iterate accordingly.
Prepare a secure service
For the first activity, Considering security within the business case, note that some projects may not submit a business case at each phase.
| Activities | Discovery | Alpha | Private beta | Public beta and live |
|---|---|---|---|---|
| Considering security within the business case | Yes | Yes | Yes | Yes |
| Identifying security resources | Yes | Yes | Yes | No |
| Agreeing roles and responsibilities | Yes | Yes | Yes | No |
| Tracking Secure by Design progress | Yes | Yes | Yes | Yes |
| Working out the project’s security risk appetite | Yes | Yes | No | No |
Understand the security landscape
| Activities | Discovery | Alpha | Private beta | Public beta and live |
|---|---|---|---|---|
| Managing third-party product security risks | Yes | Yes | Yes | No |
| Understanding cyber security obligations | Yes | No | No | No |
| Understanding business objectives and user needs | Yes | No | No | No |
Manage cyber security risks
| Discovery | Alpha | Private beta | Public beta and live | |
|---|---|---|---|---|
| Documenting service assets | Yes | Yes | Yes | No |
| Assessing the importance of service assets | Yes | Yes | Yes | No |
| Sourcing a threat assessment | Yes | Yes | No | No |
| Performing threat modelling | No | Yes | Yes | No |
| Performing a security risk assessment | No | Yes | Yes | No |
| Agreeing a security controls set for your service | No | Yes | Yes | No |
| Responding to and mitigating security risks | No | Yes | Yes | Yes |
| Assessing the effectiveness of security controls | No | Yes | Yes | Yes |
Anticipate and respond to vulnerabilities
| Activities | Discovery | Alpha | Private beta | Public beta and live |
|---|---|---|---|---|
| Implementing a vulnerability management process | No | Yes | Yes | No |
| Discovering vulnerabilities | No | Yes | Yes | Yes |
| Managing observability | No | Yes | Yes | No |
Maintain continuous assurance
| Activities | Discovery | Alpha | Private beta | Public beta and live |
|---|---|---|---|---|
| Evaluating the security impact of changes | No | Yes | Yes | Yes |
| Retiring service components securely | No | Yes | Yes | Yes |
Life cycle visualisations
Here you can view or download a series of visualisations which show how the Home Office has adapted Secure by Design activities to match delivery life cycles for 3 different delivery methodologies (programme, waterfall and agile). You may find the visuals useful to adapt for your organisation's own needs.
