How to write a cyber risk appetite statement
A cyber risk appetite statement says how much cyber risk the organization is willing to accept in pursuit of its goals, and sets measurable tolerances that show when a risk has crossed that line. A usable one fits on a page, is approved by the board, and is written in numbers you can check every quarter rather than in adjectives.
Risk appetite and risk tolerance, defined
Appetite is the direction: “we accept little risk to customer data, and more risk in trying new internal tools.” Tolerance is the number that makes it checkable: how many days a critical flaw may stay open, how many hours of data you can lose. You need both, and most statements we read have the first without the second.
Why cyber needs its own statement
An enterprise statement usually says something like “we have a low appetite for operational risk.” That sentence cannot tell an engineer whether a critical patch can wait for the next release window, or tell a manager whether a new vendor may hold customer data offshore.
Cyber decisions are made daily, by people far from the boardroom. A cyber statement translates the board’s intent into limits those people can apply without calling a meeting.
Frameworks expect it too. The Govern function of NIST Cybersecurity Framework 2.0 asks for risk appetite and risk tolerance statements that are established, communicated and maintained.
What a usable statement says
Each tolerance has four parts: the risk it covers, a limit you can measure, where the measurement comes from, and who acts when the limit is crossed.
Compare two versions. “We will maintain strong access controls” gives nobody anything to check. “No administrator account operates without phishing-resistant MFA for more than 30 days” can be checked against a directory export.
If a tolerance cannot be measured with data you already hold, either change the tolerance or start collecting the data. Do not keep it as decoration.
A worked example: three tolerance statements
These are illustrations for a mid-sized organization, not recommended values. Yours depend on what the business can absorb.
| Risk | Tolerance | Measured by |
|---|---|---|
| Exploitable internet-facing systems | No critical vulnerability on an internet-facing system stays open longer than 14 days | Scanner data, reported monthly |
| Loss of the finance system | Restored within 24 hours, with no more than 4 hours of data lost | A restore test each quarter |
| Privileged access | Every administrator account uses phishing-resistant MFA; no exception older than 30 days | Directory export, reviewed monthly |
Each row names an owner in the real document. A tolerance without an owner is a wish.
How it connects to the risk register and KRIs
Each tolerance becomes a key risk indicator: the measurement in the third column, tracked over time and reported to the board. Our note on cyber KRIs the board will read covers how to present them.
The register is where appetite does its work. Every risk is rated against the statement, and anything outside appetite needs a recorded decision: reduce it, transfer it, or have a named executive accept it with a review date. What a cyber risk register should contain sets out the fields.
The recovery tolerance in the example should come from a business impact analysis. That is where the 24 hours gets justified.
Questions we are asked
What is the difference between risk appetite and risk tolerance?
Risk appetite is the amount and type of risk an organization is willing to accept overall. Risk tolerance is the measurable limit for one specific risk, the point at which someone has to act or escalate.
Who should approve a cyber risk appetite statement?
The board, or the board committee that owns risk, approves it. Management drafts it, and the security lead proposes the tolerances, because they know what can actually be measured.
How often should it be reviewed?
Review it once a year, and again after anything that changes the business: an acquisition, a new regulated product, a serious incident, or a change in insurance terms.
Does a small organization need one?
Yes, but it can be three or four sentences. What matters is that someone with authority has written down which cyber risks are acceptable, so staff are not guessing.
Drafting yours
We draft appetite statements, registers and KRIs as part of cyber risk management and governance. Send the enterprise statement you have, if any, and the reply says what a cyber version would need. More writing is at writing.