How to Write a Risk Appetite Statement (With Examples for SMB and HealthTech Teams)

Short answer: A risk appetite statement is a short, leadership-approved document that says how much information security risk your organization will accept in pursuit of its goals. A usable one names risk categories, gives a plain-language stance for each, adds measurable thresholds, assigns owners and sets a review date, so teams can decide without escalating every risk.

Related guides:

• Risk appetite vs risk tolerance
• How to build and maintain a risk register
• Risk acceptance: when and how to accept a risk

Key takeaways

• A risk appetite statement turns "how careful should we be?" into written decisions leadership has signed off on.
• Each category needs two layers: a qualitative statement (the stance) and measurable thresholds (the numbers that tell you when you are outside it).
• Keep it short. We recommend five to eight categories on one or two pages for most SMBs.
• The statement only works when it is wired into your risk register, your risk acceptance process and your key risk indicators.
• If you run an ISO 27001 ISMS, your appetite statement is a natural source for the risk acceptance criteria the standard asks you to define.

---

What is a risk appetite statement?

A risk appetite statement is a written declaration, approved by leadership, of the types and amount of risk the organization is willing to accept to reach its objectives. It is a governance document, not a technical one.

NIST describes the relationship in its guidance on integrating cybersecurity with enterprise risk management, NIST IR 8286r1: senior leaders set risk appetite at a broad level, and that appetite is then translated into more specific, measurable risk tolerance for particular risks and systems. The NIST Cybersecurity Framework 2.0 also places this in its Govern function, with an outcome (GV.RM-02) for establishing, communicating and maintaining risk appetite and risk tolerance statements.

This guide is about writing the document itself. If you want the conceptual difference between the two terms, read our risk appetite vs risk tolerance comparison, linked above, first.

What goes into a usable risk appetite statement?

A usable statement has five parts: categories, a stance per category, measurable thresholds, an owner and a review cadence. Leave out any one of them and the document stops guiding decisions.

Component	What it answers	Example
Risk category	Which area of risk are we talking about?	Patient data (PHI) confidentiality
Qualitative statement	What is our stance, in plain language?	"We have a very low appetite for unauthorized disclosure of PHI."
Appetite level	How would we rate that stance on a common scale?	Averse, Minimal, Cautious, Open
Tolerances and thresholds	At what measurable point are we outside appetite?	Zero known PHI exposures; critical vulnerabilities on PHI systems fixed within 14 days
Owner	Who monitors this and escalates breaches of tolerance?	CTO, with the security lead as delegate
Review cadence	When do we revisit it?	Annually, and after any major incident or product change

Two practical notes on these parts:

• Use a small appetite scale. Four levels such as Averse, Minimal, Cautious and Open are easier to apply consistently than a 10-point scale. Define each level in one sentence at the top of the document.
• Thresholds are where the value is. "Low appetite" means different things to a founder and an engineer. "No production database reachable from the public internet" means one thing to everyone.

How do you write a risk appetite statement, step by step?

Start from business objectives, not from your control list, then work down to numbers your tools can actually measure.

1. List what the business is trying to achieve this year. For example: close two enterprise health system deals, launch an AI feature, expand to the UK. Appetite only makes sense relative to goals.
2. Choose five to eight risk categories. Pull them from your risk register and group them. Typical categories for HealthTech: patient data, availability, third parties, regulatory compliance, AI use, and change or delivery risk.
3. Draft a one-sentence stance for each. Use the appetite scale. Be honest: a startup that ships daily usually has a higher appetite for delivery risk than for data risk, and the document should say so.
4. Add two or three measurable thresholds per category. Prefer metrics you already collect, such as patch times, uptime, vendor review status or open high-severity findings. These become your key risk indicators.
5. Name an owner and an escalation path. State who must be told when a threshold is breached, and how fast.
6. Pressure-test it against real decisions. Take three recent decisions, such as adopting a new vendor or delaying a patch, and check whether the draft would have given a clear answer. If not, tighten the wording.
7. Get it approved and published. Leadership signs it, and it goes somewhere people will find it, next to your risk management policy.

A simple risk appetite template for each category looks like this:

Category: [name]
Appetite level: [Averse / Minimal / Cautious / Open]
Statement: We [accept / do not accept] [type of risk] in pursuit of [objective], because [reason].
Tolerances: [metric 1 and threshold]; [metric 2 and threshold]
Owner: [role] | Escalate to: [role or committee] within [time]
Last approved: [date] | Next review: [date]

Risk appetite statement examples for HealthTech and SMB teams

The examples below are illustrative statements written by SecureSlate for this guide. They are not drawn from any real company, regulator or standard, and the thresholds are placeholders to adapt to your own context and obligations.

1. Patient data (PHI) confidentiality: Averse
"We do not accept risks that could lead to unauthorized access to or disclosure of patient data. We will delay a release or decline a deal rather than handle PHI outside approved systems." Tolerances: zero PHI in non-production environments; 100% of PHI systems behind MFA; critical vulnerabilities on PHI systems remediated within 14 days.

2. Service availability: Cautious
"Our customers rely on us for clinical workflows, so we accept limited availability risk for planned change but not for prolonged unplanned outages." Tolerances: monthly uptime at or above the commitment in customer contracts; no unplanned outage longer than four hours; backups restore-tested every quarter.

3. Third-party and vendor risk: Minimal
"We use third parties to move fast, but we do not share sensitive data with a vendor before it has been reviewed and contractually bound to protect it." Tolerances: no vendor receives PHI without a signed business associate agreement; 100% of critical vendors reviewed in the last 12 months; no critical vendor with an open high-severity finding older than 90 days.

4. Regulatory and compliance risk: Averse
"We do not knowingly operate outside the laws and contractual security commitments that apply to us. Where requirements are unclear, we take the more conservative interpretation until advised otherwise." Tolerances: zero overdue regulatory notifications; zero audit findings past their agreed remediation date.

5. AI use: Cautious
"We want to use AI to improve our product and productivity, and we accept experimentation risk, but not with patient data or in ways that bypass human review of clinical outputs." Tolerances: no PHI entered into AI tools without an approved data agreement; every production AI feature has a named owner and a documented risk assessment; zero unapproved AI tools with access to company data.

6. Product delivery speed: Open
"We accept higher risk of minor defects to ship quickly, provided changes are reversible and do not touch the controls above." Tolerances: rollback available for every production deploy; security review required only for changes to authentication, data flows or PHI handling.

Notice how the levels differ. A good appetite statement is not uniformly cautious. Saying "low" for everything gives teams no way to prioritize and usually means the document gets ignored.

How does it connect to your risk register and ISO 27001?

The appetite statement sets the line, and the risk register shows which risks sit above it. Every risk in the register should be tagged to an appetite category, scored, and compared with that category's thresholds.

Register outcome	What the appetite statement tells you
Residual risk within appetite	The risk owner can accept it and record the decision
Residual risk above appetite, below a hard limit	Treat it, or escalate for formal risk acceptance with an expiry date
Residual risk breaching an "Averse" category	Treat it. Acceptance requires leadership sign-off, if it is allowed at all
A key risk indicator crosses a threshold	Owner escalates within the agreed time, and the register entry is rescored

If you run an information security management system, ISO/IEC 27001:2022 asks you, in clause 6.1.2, to establish and maintain information security risk criteria, and those criteria include risk acceptance criteria. The standard does not use the phrase "risk appetite statement" or require one. In practice, though, an appetite statement with measurable thresholds is a clear way to document what risk levels you will accept, and auditors will typically look for consistency between your stated criteria and the acceptance decisions in your register and risk treatment plan.

For how appetite feeds into wider planning, see our guide on what a risk management strategy is.

Who approves it, and how often should it be reviewed?

Leadership approves it, at board level if you have an active board, and it should be reviewed at least once a year and after any major change.

In a small company, the approver is often the CEO with the founding team, or the board for venture-backed companies with formal governance. What matters is that the people who carry accountability for the business sign it, not only the security lead. A statement written and approved by the security team alone is a security preference, not organizational appetite.

Trigger an out-of-cycle review when:

• you enter a new market or regulated segment, such as starting to process PHI
• you launch a significantly new product, such as an AI feature
• a serious incident or audit finding shows a threshold was wrong
• a major customer contract changes your commitments, such as a new uptime SLA

Record each approval with a date and version number. It is useful evidence for auditors and customers asking how leadership oversees security risk.

What mistakes make a risk appetite statement useless?

The most common failure is a statement so vague that no decision could ever be checked against it.

• Everything is "low". If every category has the same appetite, the document cannot help you choose between risks.
• No numbers. Without thresholds, nobody can tell when the organization is outside appetite.
• Thresholds you cannot measure. If no tool or report produces the metric, it will never be checked.
• Written once for an audit. A statement nobody has reopened since certification is not guiding anything.
• Disconnected from the register. If register entries are not tagged to appetite categories, acceptance decisions drift.
• Copied from a large enterprise. A bank's appetite statement will not fit a 40-person HealthTech company. Write for your own objectives and size.
• No owner. A threshold breach that nobody is responsible for escalating will not be escalated.

How SecureSlate helps

SecureSlate's risk management module gives you a central risk register where each risk can be scored, assigned an owner and tracked through treatment or acceptance, so your appetite thresholds are applied to real entries rather than living in a separate document. Multi-framework control mapping across SOC 2, ISO 27001, HIPAA, HITRUST and NIST CSF links risks to the controls that treat them, and vendor risk management keeps third-party reviews on the schedule your appetite statement sets. Agentless read-only cloud integrations and the device agent help supply the evidence behind thresholds such as MFA coverage, and audit management keeps approvals and review records ready for your auditor.

Start your free SecureSlate trial

FAQ

How long should a risk appetite statement be?

For most SMBs we recommend one to two pages: five to eight categories, each with a one-sentence stance and two or three thresholds. Longer documents tend to go unread.

Is a risk appetite statement required for ISO 27001 or SOC 2?

Neither framework requires a document with that exact name. ISO 27001 does require defined risk acceptance criteria, and many teams use an appetite statement to set them. For SOC 2, a documented appetite statement is useful evidence of how leadership oversees risk.

What is the difference between a risk appetite statement and a risk management policy?

The policy describes how you manage risk: the process, roles and methodology. The appetite statement describes how much risk you are willing to take. The policy usually references the statement.

Can a startup have a high risk appetite?

Yes, for some categories. Startups often accept more delivery and market risk. In regulated areas such as patient data, appetite should usually be low regardless of company stage, because the obligations do not scale down with headcount.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.