Almost every board will tell you it has a cyber risk appetite. Far fewer could tell you what it actually changed last quarter. Which system was built differently because of it? Which investment was approved, or refused, because of it? Which risk did someone decline to accept on their own authority, because the appetite said it belonged to the board?
If the honest answer is “none”, the appetite is not doing its job. When talking about cyber resilience, we consistently argue that surviving a serious incident starts with defining your Minimum Viable Business (MVB) and the scenarios that would threaten it. This article puts that principle into practice. It sets out why most risk appetite statements deliver so little, what a good one looks like, and a practical two-step approach to building one that the business will recognise, the delivery teams can act on, and the board will sign.
Why most risk appetites deliver limited value, or are never signed off
The problem is rarely a lack of effort. Security teams invest weeks drafting appetite statements, only to watch them stall in committee or sit on a shelf once approved. Three failings come up time and again.
They speak the language of security, not the language of the business. “We have a low appetite for ransomware” is a typical example. It is technically coherent, but no finance director or operations lead would recognise it as their problem. Ransomware is a method, not an outcome. What the business cares about is whether it can still take orders, ship stock, pay suppliers and protect its customers. When the appetite is not written in those terms, the board cannot meaningfully agree or disagree with it, so it either nods it through or quietly parks it.
They cannot be calibrated, so they cannot drive action. “Low”, “medium” and “high” sound like thresholds, but they are not. Low compared with what? How much control is enough to be within a “low” appetite? When the answer is unbounded, every project team interprets it differently, every exception becomes a negotiation, and the security function is cast as the department of “no”. An appetite that cannot tell a delivery team whether it has done enough is not a constraint. It is an opinion.
They chase the risk matrix rather than the consequences. Many appetites are framed around the familiar five-by-five grid: get every risk to within a certain distance of the bottom-left corner and it is deemed acceptable. But a catastrophic scenario rated “unlikely” is still catastrophic if it happens. As the attacks on M&S, Jaguar Land Rover and KNP Logistics showed, the question is not just how probable an event is. It is whether the business can absorb it, keep operating and recover when it lands. A residual risk is still a hazard even if it is considered unlikely.
What does a good risk appetite look like?
A good risk appetite serves three audiences at once. If it fails any one of them, it will not stick.
It should be recognisable and understandable by the business. A non-technical reader, whether a buyer, a store manager or a non-executive director, should be able to read it, understand what it means for them, and challenge it if they think it is wrong. If the CFO reads it and says “actually, we could survive three weeks of lost online sales, not two”, that is the appetite working. Challenge is a sign of ownership.
It should be executable by the delivery function. The people building, buying and running systems should be able to read the appetite and work out where their system sits and what is expected of them. A team deploying a new warehouse management system should not need a workshop with the security team to discover that it is in scope of the most stringent controls. The appetite should tell them, and tell them what “enough” looks like.
It should be verifiable by the oversight function. Whoever provides assurance, whether the security function, the second or third line of defence, or external auditors, should be able to judge whether a system, or the business as a whole, is within appetite. That judgement may sometimes be subjective, but it must be possible. “Has this system had a restore test in the last twelve months?” can be checked. “Is this system low risk?” cannot.
These three tests are a useful lens for reviewing any existing appetite statement. Most fall at the first hurdle.
How do you go about creating one?
An effective appetite is built in two steps. The first defines what the business cannot tolerate, in its own language. The second defines what that means, in practice, for the systems and people that support it.
Step one: develop the Risk Appetite Scenarios
Define the Minimum Viable Business. Imagine everything else has been burnt to the ground. Which capabilities and systems would need to remain for the business to stay viable? For a physical product vendor which sells direct to customers and runs a lean operation with limited liquidity in working capital, the answer might be four things: the ERP that runs stock, fulfilment and finance; the warehouse management system; the digital platform that carries online sales; and the point-of-sale systems in stores. Everything else, such as product lifecycle management (PLM) and manufacturing, matters, but its loss would hurt over weeks rather than threaten survival within days. That distinction is the foundation of everything that follows.
Develop a set of scenarios that are specific and relevant to the business. Each should describe an outcome the business would recognise, not a technical attack. “The MVB is halted for more than two weeks” is a scenario a board can debate. “Malware on the network” is not. Some scenarios will be existential; others will be painful but survivable. All should be credible, even if unlikely. A good guideline is between five and nine scenarios. Miller’s law suggests that is about as many as people can hold in mind at once, and an appetite the board cannot remember is one it will not apply. Typical categories include financial distress, operational disruption, brand and reputation, regulatory exposure and intellectual property.
Define how far the business can tolerate each scenario. This is where calibration comes in. For each scenario, set the threshold at which the appetite changes, in terms the business already uses: pounds, weeks, percentage of sales, number of customer records. Three or four tiers are enough to stay manageable. For example:
| Scenario | Near to Zero | Averse | Moderate |
|---|---|---|---|
| Financial loss (direct, ransom or lost revenue) | Above £x million | Between £y and £x million | Below £y million |
| Operational disruption to the MVB | MVB halted for more than x weeks | Sales down more than xx% for more than x weeks | Anything less |
| Loss of customer personal data | — | High-profile customer data, or thousands of records made public | Below threshold |
| Loss or tampering of product designs | — | Irrecoverable loss, or undetected modification | Theft by a competitor |
Notice what this does. A non-specialist can read every line and argue with the numbers. And it says nothing about ransomware, phishing or denial of service, because those are routes to an outcome, not the outcome itself.
Step two: develop the Posture policies
The scenarios tell the business what it cannot tolerate. The posture policies tell delivery teams what to do about it. For each appetite tier, write two things.
A simple statement of intent. One or two sentences anyone can understand. For Near to Zero, it might read: “Risks that cannot be accepted outright. All reasonable means should be applied to reduce the likelihood, and deliberate steps must be taken in advance to limit the impact and enable recovery.” For Moderate: “Standard controls balance these risks with business flexibility and agility.”
A detailed set of requirements and obligations. These are what systems and capabilities in that tier must meet. They should be specific enough to test. This is where the appetite becomes executable and verifiable:
| Requirement | Near to Zero | Averse | Moderate |
|---|---|---|---|
| Maximum data loss on recovery | 10 minutes | 60 minutes | Standard controls |
| Maximum time to restore | 48 hours | 7 days | Standard controls |
| Attack and recovery testing | At least annually and on major change | On major change | 20% of systems sampled annually |
| Supplier assurance | Evidenced annually, or diverse alternative supplier | Evidenced every two years | At onboarding and at least every 5 years |
| Crisis exercise | Annual table-top for a high-impact scenario | Documented procedures for likely scenarios | — |
| Who can accept the residual risk | The board | The COO | The CTO (for exceptions to standard controls) |
The Near to Zero tier deserves particular attention. Here, the mitigation is not a technical control alone. It is a whole-business solution: reversionary modes of operation, using the diversity between stores and online channels, graceful degradation built in by design, and staff who know they may be redeployed to run manual processes. That is the resilience thinking of BS 65000 turned into obligations someone can be held to.
The last row may be the most powerful. By tying each tier to a named level of authority, the appetite makes clear who owns the decision. Risks that could destroy the business are not accepted by a project manager or the security team. They are accepted, explicitly, by the board.
Three questions for the board to answer
Could a non-executive director read your current risk appetite and explain what it means for the business? Could a project team use it to decide what controls their new system needs? And if your Minimum Viable Business were halted tomorrow, does your appetite say who would have accepted that risk, and what they agreed would happen next?
If the answer to any of these is no, the appetite is an aspiration, not a tool.
A risk appetite built in the way described in this article does more than satisfy a governance checklist. It gives the board a set of scenarios it recognises and can own. It gives delivery teams a clear answer to “how much is enough?” before they start building, not after. It gives assurance functions something they can actually test. And it directs investment to where failure would hurt most, rather than spreading it evenly across a risk register.
It also tends to get signed off, because the people signing it can see what they are agreeing to. The good news is that getting there is a business conversation, not a technical one, and it is a conversation the board should be leading.
You can find an illustrative example of a risk appetite developed in this way here
