A risk appetite statement is meant to answer one question before it comes up: how much risk is this organization willing to take to get what it wants? Most security teams do not have one. The ones that do often have a single sentence, "we have a low appetite for security risk", which answers nothing.
Without a usable statement, every risk decision becomes a negotiation. An engineer wants to ship, security wants a control first, and the answer depends on who escalates. With one, the decision has already been made at the right level, and the conversation is about whether the risk falls inside it.
This article covers what appetite means next to tolerance and acceptance criteria, which frameworks ask for it, a structure that works, sample wording, and the faults that make a statement decorative.
Appetite, tolerance and acceptance criteria
The three terms overlap, and teams use them interchangeably. Keeping them separate makes the document easier to write.
Risk appetite is the amount and type of risk the organization is willing to pursue or retain in pursuit of its objectives. ISO Guide 73, the ISO risk management vocabulary, defines it in roughly those terms. It is a leadership statement of direction.
Risk tolerance is the boundary around that appetite: the variation the organization will bear, usually expressed as something you can measure. "We are cautious about availability risk" is appetite. "No more than one customer-visible outage a quarter exceeding our recovery time objective" is tolerance.
Risk acceptance criteria are the operational rules your risk method applies: which risk levels can be accepted without further treatment, and by whom. They are where appetite meets the scoring matrix.
The statement covers the first two. Your risk method carries the third and should point back to the statement as its source.
Which frameworks ask for it
ISO/IEC 27001:2022 does not ask for a document called a risk appetite statement. Clause 6.1.2 a) requires risk acceptance criteria, and an auditor will ask how those criteria were set and who agreed them. A statement approved by top management is the cleanest answer, and it supports the leadership commitments in clause 5.1. Our article on ISO 27001 clause 6 covers the criteria requirement in detail.
NIST CSF 2.0 is more direct. Its Govern function includes an outcome, GV.RM-02, calling for risk appetite and risk tolerance statements to be established, communicated and maintained. If you report against the NIST Cybersecurity Framework, this is the outcome the statement satisfies. The overview of CSF 2.0's six functions places it in context.
SOC 2 does not require a statement by name, but the risk assessment criteria expect you to analyze risks as a basis for deciding how to manage them. A statement gives your auditor a reason behind each acceptance.
A structure that works
A useful statement is short, usually two to four pages. It has six parts.
Purpose and scope. What the statement governs: information security and privacy risk across the systems and data in your ISMS or SOC 2 scope.
Overall position. One paragraph on how security risk relates to the business strategy. A company selling to regulated buyers will write this differently from an early-stage company still finding its market.
Category statements. For each risk category that matters, a stance and one or more measurable tolerances. This is the bulk of the document.
Decision rules. How the categories map to your risk method's acceptance criteria, and which roles can accept which levels.
Escalation. What happens when a risk exceeds tolerance: who is told, within what time, and who decides.
Ownership and review. Who maintains the statement, who approves it, and when it is reviewed.
Choosing categories
Pick categories your leadership already thinks in. Typical ones for a SaaS company are customer data confidentiality, service availability, regulatory and contractual compliance, third parties, and change velocity. Five to eight categories is enough. More than that, and nobody reads to the end.
Stating a stance
A simple ordinal stance per category helps: averse, minimal, cautious, open. The label is less important than the sentence after it, which says what the stance means in practice.
Sample wording
The statements below are illustrative, written for a hypothetical B2B SaaS company that holds customer business data. Adapt the substance, not the words.
Customer data confidentiality: averse. We do not accept risks that could plausibly expose customer data to unauthorized parties where a reasonable control exists. Tolerances: no customer production data in non-production environments; no standing human access to production data stores outside approved break-glass procedures; every vendor with access to customer data has a completed review before go-live.
Service availability: cautious. We accept short degradations in exchange for the ability to ship changes frequently. Tolerances: recovery within the recovery time objective we publish to customers; tested restores of production backups at the frequency set in our backup policy.
Change velocity: open. We prefer fast, reversible changes over slow, heavily approved ones, provided every production change is peer reviewed and traceable. Tolerances: no direct changes to production outside the deployment pipeline except documented emergencies.
Third parties: cautious. We use third-party services to move faster, and we accept the dependence that brings for services that are not customer data processors. Tolerances: tier one vendors have a current independent assurance report or a completed security review, reassessed at least annually.
Notice what each statement does. It names what the organization will trade, draws a line someone can check, and says nothing a reader cannot test.
Connecting the statement to decisions
The statement earns its keep in three places.
Risk acceptance. Your method should say that a risk inside appetite can be accepted by the risk owner, and a risk outside appetite needs a higher authority, typically an executive or the leadership team. That keeps the statement from being overruled one exception at a time.
Scoring. If your likelihood and impact scales produce levels, the decision rules should name which levels fall inside appetite for each category. An averse category might treat anything above low as outside appetite. An open category might accept up to moderate.
Exceptions and vendors. When someone asks for a policy exception or wants to onboard a new vendor, the relevant category statement is the first thing to check. It turns "is this OK?" into "is this inside what leadership agreed?"
Faults that make a statement decorative
One stance for everything. "Low appetite for all security risk" contradicts how every company operates, and everyone knows it.
No measurable tolerances. Stances with nothing to check cannot be breached, so they never come up in a decision.
Approved by the security team alone. Appetite is a business decision. If the leadership team has not discussed and approved it, the statement carries no authority when it conflicts with a deadline.
Disconnected from the register. If no risk in the register is ever judged against the statement, the statement is not part of the process.
Never revisited. A statement written before a major funding round, a move into healthcare or a first enterprise contract is probably wrong after it. Review it at least annually and on major changes in strategy.
Getting it approved
Draft the statement in security, then take it to the leadership team as a set of decisions rather than a document for signature. Ask each question plainly: will we hold customer data in staging, yes or no? Record the answers, revise the draft, and bring it back for formal approval. Keep the minutes or the approval record; an auditor asking how acceptance criteria were set will want to see it.
The first version will be imperfect. That is acceptable. A short statement leadership has argued over is worth more than a long one nobody read.
How TrustLynce helps
TrustLynce's risk management module lets you set acceptance thresholds that reflect your appetite and records who accepted each risk and when. Approved statements can be versioned and tracked for acceptance through policy management.