When devising a service strategy and setting objectives, it’s important to establish what level of cyber-related risk the project is willing to take on.
Creating a project risk appetite statement will allow you to:
The project’s risk appetite should be established during the discovery or requirement gathering phase. It should be continually assessed against current threats and refreshed whenever there is a major change in the project scope.
Completing this activity will help you to achieve the outcomes included in the Secure by Design principles to adopt a risk-driven approach and embed continuous assurance.
A project’s risk appetite is the level of cyber security risk the Senior Responsible Owner (SRO) and service owner are willing to accept. They need to take responsibility for creating a statement they’re comfortable with.
This should be compiled using information from security professionals and product, programme, project and delivery managers who can advise on the different elements of a project that should be considered from a risk perspective.
Cyber security risk for your project must be managed with reference to your organisation’s risk appetite statement.
Before you begin creating a risk appetite specific to your service, talk to your risk management team to understand the overall organisation’s risk acceptance thresholds. This will determine what you must do to reduce cyber security risks to an acceptable level.
Before SROs or service owners can begin to work out the project’s security risk appetite, they will need an overview of the service. This should cover the purpose and scope, including any assumptions or exclusions, creating the boundaries where relevant security risks need to be assessed.
A project scope should have already been created as part of the business case detailing the project objectives, deliverables, exclusions, constraints and assumptions.
Using the project scope, make a list of any relevant elements from the organisation’s risk appetite statement and others you deem to be relevant to the service. This will create a baseline of what security risks the service must be resilient against and aim to prevent.
These statements could include:
Make these specific to your project so the risk appetite can be appropriately assessed. For example, include the types of data (such as personal or financial) that your service will collect and which users it relates to.
Making these relevant to the service is an important part of governance. The risk appetite will need to be communicated to and used by delivery teams to inform project plans and support risk management decision making. Make sure they are clear and can be put into action.
Example unacceptable risks for a fictitious government service
It is unacceptable if: (1) legislative and regulatory requirements relevant to the Grant Application Service are not met; (2) PCI-DSS requirements are not met; (3) An awarded grant is paid into the wrong account; (4) A grant seeker is able to see another grant seeker’s confidential information; or (5) Unauthenticated users are able to view or amend data stored on the system.
Review your list of unacceptable risks at the organisation level and outline the internal and external security threats that could lead to these within the context of the service. These should be threats that can be mitigated through effective service design and robust operational processes.
Using the unacceptable risks and potential cyber security threats as a guide, determine the rules that need to be put in place to prevent them.
This should be a series of statements outlining the project’s attitude to relevant cyber risks that management teams can use to make informed decisions. For example, if there is a desire to add a new feature to a live service, the schedule must include the appropriate time and resources required to ensure that it will not open the service up to any unacceptable risks.
These statements do not have to specify the security controls that will be put in place, but should be used by delivery teams when selecting which controls should be implemented.
Example risk appetite statement for a fictitious government service
The Grant Application Service will: (1) not allow unauthorised access to personal information; (2) prevent grant seekers from accessing confidential records of other grant seekers; (3) protect the integrity of card payment data; (4) protect the integrity of bank account details; (5) settle grant payments within their agreed provided parameters; and (6) always be available within stated parameters.
The project scope, unacceptable risks and risk appetite statement should be signed off by the SRO and shared with:
The risk appetite statement should be considered a working document that’s continually assessed against changes in the service or the threat landscape. Communicate any updates with those who may be affected so teams can factor the latest information into digital delivery and future plans.
This activity is part of the ‘Prepare a secure service’ stage of Secure by Design, which also includes:
Read the Secure by Design activities
The Secure by Design approach will evolve to reflect the needs of government digital services. Your feedback will help us to improve it.
Last update: 31 January 2024
OFFICIAL