Working out the project’s security risk appetite

Creating a project risk appetite statement will allow you to:

• determine acceptable and unacceptable risks
• create a risk culture and set risk expectations to be shared across the delivery team
• make informed, timely and effective risk management decisions

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.

Who is involved

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.

How to work out your project’s security risk appetite

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.

Step 1: Summarise your project scope

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.

Step 2: Align with the organisation’s risk appetite

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:

• data breaches
• not adhering to security laws and regulations
• allowing the service to be a victim of a denial-of-service attack

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.

Step 3: Determine relevant security threats

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.

Examples of malicious security threats

• deliberate phishing attempts
• software supply chain attacks
• account hacking

Examples of unintentional or accidental security threats

• mishandling of data
• security controls not being properly implemented on a service
• loss of a device containing personal information

Step 4: Determine the required constraints

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.

Step 5: Communicate the security risk appetite

The project scope, unacceptable risks and risk appetite statement should be signed off by the SRO and shared with:

• people responsible for deciding on appropriate strategies for mitigating security risks, such as service owners
• people responsible for managing service delivery and ensuring cyber security risks are considered within plans, such as project, programme and delivery managers
• people responsible for assessing cyber security risks and implementing relevant controls, such as technical architects, security architects and developers

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.