Are you hungry? A two-part blog about risk appetites

| This content was last reviewed on 05/03/2025 |
The basics and characteristics of useful risk appetites
When the NCSC talks to people about risk appetites, we sometimes get asked: what are they? What’s their purpose? How do we go about defining them? And how can they support boards with their decision making process? So, I thought I’d write a blog about this.
As Mat P mentioned in his blog, common vocabulary is useful when we want to achieve understanding through agreed terms, so we can have more meaningful discussions about security. I couldn’t agree more, and risk appetites can really help with this.
Okay, so let’s start with the basics: what are risk appetites, and what’s their purpose?
Starting with the basics
First and foremost, risk appetites help to scope and direct decision making, they are not the preserve of cyber security, and accordingly, there are a number of different definitions out there. However, they all generally agree that they are a means of defining a ‘level’ of risk an organisation, project, operation or system will manage when pursuing its objectives. Sometimes (unfortunately and unhelpfully), they are defined as “low”, “hungry” etc., but what does this actually mean, and how can they help to direct decision making?
Risk appetites are the means by which we can articulate risk red lines; what for example, is an organisation, project, operation or system owner absolutely unwilling to accept risk on? This could be fulfilling its legal/regulatory obligations, such as the protection of personal information, or continued plant operations. Equally, it is also a definition of business or operational opportunity such as digital transformation; it needs to articulate what business or operational context these risk red lines exist in. What business or operational activities necessitate these risk red lines? Remember, businesses are in the business of business, so risk appetites should also be the means by which we define what is trying to be achieved, as well as the opportunities and ultimately benefits this provides.
So, risk appetites are the means by which we can define the risk red lines associated with business or operational opportunities. However, importantly these risk red lines must be communicated to those who need to work with them, in a way that is accessible and understood. This may sound obvious, but I would say most members of staff who need to work with them, would find it difficult to locate applicable risk appetites, let alone recall what they say.
Why is this? Well, risk appetites also have to resonate with those that need to work with them. Abstraction doesn’t help, for example a risk appetite defined as: “the organisation is averse to cyber security risk but hungry for business opportunities”, will not resonate with staff because it doesn’t tangibly mean anything in their day-to-day jobs. However, if risk appetites are effectively communicated, and resonate with people, then they can be a useful extension of governance that can help to direct security decisions ‘on the ground’ – that is their utility and purpose. Effectively communicated risk appetites will help people align with the organisation’s view of risk, and can contribute to an effective security culture.
The characteristics of useful risk appetites
The NCSC often talks about the need for practitioners to work with a range of different complementary techniques, to manage cyber security risk as effectively as possible – the definition of risk appetites is no different. There are a number of ways in which they can be defined; risk appetites can be as detailed as they need to be, and they can be expressed in different ways, for example economically or more qualitatively; it doesn’t really matter so long as they are useful and help to direct decision making.
Jack Jones, the Chairman of the Fair Institute summarises this nicely by presenting five characteristics of useful risk appetites, they should:
- be realistic and actionable
- provide clarity in expectations
- improve focus in risk management efforts
- improve communication with stakeholders
- reduce the potential for unacceptable loss
You could call this the ‘Jones test’ for risk appetites; they should possess all of these characteristics. Applying the ‘Jones test’ to my earlier example risk appetite, “the organisation is averse to cyber security risk but hungry for business opportunities”, it is clear that it doesn’t really meet any of these characteristics.
So, how can we define useful risk appetites? Ones which can define risk red lines, business or operational opportunities, and resonate with staff so that risk management activities are directed ‘on the ground’. And how can this be done in an informed, consistent, and semi-formal way, as well as satisfying the ‘Jones test’?
In Part 2, I will attempt to answer these questions by presenting a qualitative approach to defining risk appetites, based on the first stage of Systems-Theoretic Process Analysis (STPA).
A qualitative approach to defining risk appetites using STPA
In Part 1, I talked about the basics and characteristics of useful risk appetites. In Part 2, I will be presenting a qualitative approach to defining risk appetites using Systems-Theoretic Process Analysis (STPA). Don’t worry, you don’t need to be an expert in STPA to be able to benefit from this approach – and I don’t propose to go into any detail here – any organisation can follow these steps, with very little understanding of STPA.
Step 1: Determination and scoping
Before defining risk appetites, a scope of the agreed organisation, project, operation or system, which it is associated with, needs to be agreed so that the boundaries are clearly articulated, and any assumptions and/or exclusions are made explicit. The scoping exercise needs to convey understanding primarily for those who are charged with risk managing the organisation, operation or system. Those who are accountable/responsible for this, need to be identified so that they can understand and agree the scope before beginning to define risk appetites. The scope could be very large: an organisation, its people, and technology, or it could be more specific: a web service. Either way, everyone should understand what it is, before defining the associated risk appetites. In my example the scope is a national payment system which is operated and managed by a financial institution.
Step 2: Define purpose
Once the scope has been been agreed, stakeholders need to define purpose. The purpose of an organisation, project, operation or system, does not need to be understood in any great detail; however, the articulation needs to be sufficient so this is reflected in the risk appetite. This can be represented semi-formally as follows: (name of project, operation or system) does x, by means of y, in order to contribute to z, (x is the goal; y is the statement of how the goal will be met; and z is the larger problem that this goal contributes to).
An example might be: “The purpose of the national payment system (name) provides electronic settlement (x), in real time by means of holding accounts, provision of reserves and payment services (y), in order to contribute to the delivery of an efficient and more resilient payment and settlement system for the nation (z)".
By defining purpose in this way, we not only beginning to articulate the associated business and operational opportunities, and using this to begin defining the risk appetite, but we are also providing an overarching goal that everyone can refer to.
Step 3: Define unacceptable losses
The next step is to define and agree unacceptable losses. This can be anything that is unacceptable to stakeholders - the things that keep them awake at night - which must be prevented. For example: harm to people, a financial loss, exposure or loss of sensitive information, etc. Some example unacceptable losses for the national payment system might be: legislative requirements not being met, a funding or accounting liquidity crisis, etc. Once these have been defined, they can be used in conjunction with the purpose, to further reinforce and communicate the organisation’s goals, which begins to articulate the risk appetite in a more meaningful way, using our example from earlier:
“The purpose of the national payment system is to provide electronic settlement, in real time by means of holding accounts, provision of reserves and payment services, in order to contribute to the delivery of an efficient and more resilient payment and settlement system for the nation.
It is unacceptable if: (1) legislative requirements are not met; (2) there is a funding or (3) accounting liquidity crisis; (4) there is a mission loss; (5) reputation/trust in the organisations is lost; or (6) financial and monetary stability in the country cannot be maintained.”
The organisation has now articulated the things which are unacceptable that must be prevented in the context of its business and operational opportunities.
Step 4: Define hazards
Next, define the hazards which give rise to the unacceptable losses defined in the previous step, these are the states which if true, could lead to their occurrence. These are high-level factors that could lead to unacceptable losses in the context of the scope we determined in Step 1 - these are things which we can control through design. In our earlier example of the national payment system this could be: "the national payment system allowing unauthorised access", "authorised changes that have an adverse effect on the national payment system", etc. Causes should be described as concisely and unambiguously as possible, – remember the risk appetite needs to be practically useful and resonate with staff who will be working with it.
Step 5: Define constraints
The next step is to begin determining the constraints that are needed to prevent the hazards, and ultimately the unacceptable losses we defined in the previous steps. Constraints are states intended to limit or prevent this. Specifically, constraints determine what is not allowed, or what shall be enforced through for example, design and policy, to help realise, in our case, security. They are rules or laws of behaviour that are ‘codified’ at the upper layers of the organisation, project, operation or system, and imposed through for example, requirements, processes and procedures at the lower layers. This is an important step when defining a risk appetite as it articulates the management direction for decisions ‘on the ground’.
Constraints can be arrived at by simply inverting the hazards that were identified in Step 4. For example, if we consider the first hazard associated with the national payment system: "allows unauthorised access", this can be inverted to arrive at the corresponding system constraint: the "national payment system will not allow unauthorised access".
Once constraints have been agreed, they can be used, in conjunction with the purpose and unacceptable losses, to complete the definition of the risk appetite:
“The purpose of the national payment system is to provide electronic settlement, in real time by means of holding accounts, provision of reserves and payment services, in order to contribute to the delivery of an efficient and more resilient payment and settlement system for the nation.
It is unacceptable if: (1) legislative requirements are not met; (2) there is a funding or (3) accounting liquidity crisis; (4) there is a mission loss; (5) reputation/trust in the organisations is lost; or (6) financial and monetary stability in the country cannot be maintained.
The national payment system will: (1) not allow unauthorised access; (2) authorise all changes to messages and workflow; (3) not allow authorised changes to have an adverse effect; (4) only process payments from sending participants; (5) process payments as instructed by sending participants (6) settle payments within their agreed provided parameters; (7) always be available within stated parameters; (8) maintain the privacy of PII; and (9) balance and close all transactions in the ledger accurately and within stated parameters.”
As you can now hopefully appreciate, without needing an expert in STPA, or indeed a risk management specialist, we have defined a risk appetite which: defines the risk red lines associated with the organisation’s business or operational opportunities; helps direct activities ‘on the ground’; and hopefully resonates with staff who need to work with it, as it tangibly means something to them in their day-to-day jobs.
So, does our risk appetite meet the ‘Jones test’? Well yes, I think it does; it is realistic and actionable, it certainly provides clarity in expectations, and will improve focus in risk management efforts. Further, the definition clearly articulates what is unacceptable and what the national payment system must do, it can be easily understood by stakeholders and will improve their communication. Finally, and ultimately its definition can help to reduce the potential for unacceptable loss to the national payment system.
Working with the risk appetite definition
Once you have defined a risk appetite using STPA, then what? Well we need to put it to ‘work’, – people need to get aligned and stay aligned with it. Getting aligned basically means evaluating where current or proposed activities exceed the appetite definition, and where this is the case, identifying and implementing options for aligning with it. Staying aligned is the more difficult part of this, with stakeholders needing to set decision making boundaries and identify and correct 'appetite violations'. Now I recognise this is far easier said than done, and that there may be some difficult, in this case, non-security trade-offs to work through, but a risk appetite definition has no value unless it is worked with in the same way as other aspects of governance.
Why stop there?
You can define multiple risk appetites; ones which are maybe more applicable to the organisation as a whole, supported by ones which are maybe more applicable to specific technology services. You can also refine and improve the risk appetite you have defined by iterating the steps presented, in both approaches above, to reflect changing levels of maturity. You could also include threat context as described in Mat P’s blog, or conduct further analysis of vulnerabilities and constraints. It really doesn’t matter provided that the risk appetite is useful and meets the ‘Jones test’. Risk appetite definitions can be an effective vehicle for governance, provided they make sense, and they are understood by those who have to work with them.
Defining useful cyber security risk appetites that meet the 'Jones test', which can help to direct decision making, and then aligning and staying aligned with them, requires an ongoing set of activities, – it takes buy-in and commitment from a range of different stakeholders. So, next time someone says they’re hungry, you might want to correct them!


