"The organisation has a low appetite for cyber risk." The sentence is approved in the minutes, goes into the policy, appears in the annual report — and changes absolutely nothing about what the team does on Monday morning. Appetite that does not become a number does not become a decision.
The problem is not the sentence. Every appetite statement starts that way, and has to: it is the board saying what its comfort level is. The problem is stopping there. Between the statement and the analyst who has to decide whether to accept or escalate a risk there are two translations, and almost nobody makes them.
Appetite, tolerance and limit
The three terms get used as synonyms and are not. Separating them is the first step:
| Term | What it is | Who sets it |
|---|---|---|
| Appetite | How much risk the organisation is willing to take on to meet its objectives. Directional. | Board or executive team |
| Tolerance | The acceptable variation around the appetite, by risk category. Numerical. | Executive team, by category |
| Limit | The value beyond which something has to happen: escalate, stop, notify. | Process owner |
The appetite statement answers "how much risk do we want". Tolerance answers "how far, in this category". The limit answers "and when I go past it, what happens". Only the third is operable.
The two translations
From sentence to limit. Take the statement and ask, for each relevant risk category, which number makes it verifiable. "Low appetite for unavailability of customer-facing services" becomes something like: no service classified as critical may have unplanned downtime above X hours per quarter. "Low appetite for exposure of personal data" becomes: no risk whose consequence is a customer database leak may remain in a residual state above Y.
The initial number will be arbitrary. That is fine — it is a hypothesis, and a wrong, explicit hypothesis is infinitely better than an adjective. By the first review you already have data to adjust it.
From limit to acceptance criteria. This is the translation that closes the loop, and it is exactly what ISO 27001 requires when it asks for risk acceptance criteria defined before the assessment. The criterion has to say three things, without ambiguity:
- Below what value the risk is accepted without escalation — and by whom.
- Between which values it requires a treatment plan with a deadline.
- Above what value it cannot be accepted by anyone below a set level — and the activity does not start without that acceptance.
The lone analyst test
There is a cheap way to find out whether your appetite is really defined. Take a real risk, hand it to an analyst who was not part of the discussion and ask: do you accept or escalate?
If they have to ask someone, the appetite is not defined — it is delegated. And informal delegation is what makes the same risk accepted in one area and escalated in another, with nobody noticing the inconsistency until the audit.
Why the unit matters here. A limit expressed on an ordinal scale — "nothing above high risk" — reintroduces the problem of the heat map: two "high" risks that differ by two orders of magnitude get the same treatment. A limit in money and in probability is what makes the criterion comparable across areas.
Where this touches NIST CSF 2.0
The Govern function, added in version 2.0 of NIST CSF, exists in good part because of this. It covers strategy, roles, policy and oversight — and the risk management category within it asks precisely that appetite and tolerance be established, communicated and maintained.
It is no coincidence that the new function is the governance one. The implicit reading is that the problem organisations face has stopped being to identify or to protect, and has become to decide — and deciding without a stated criterion is what eats committee time.
A first step that takes one meeting
No project is needed. Take the five risks that came up most often in committee over the last year and ask, for each one, which number would have made the discussion unnecessary. The answers are the draft of your table of limits.
Take that draft to the executive team with a single question: is this the level at which you want to be involved? It is a short conversation, and it produces in an hour what the generic statement did not produce in a year.
This article describes principles for defining risk appetite, with reference to the Govern function of the NIST Cybersecurity Framework 2.0 and to the risk acceptance criteria requirements of ISO/IEC 27001:2022. Consult the official texts before formalising your policy.