# Risk Appetite vs Risk Tolerance 

*// @18xBan · GRC Series · Chapter 14*

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/c51aa594-ddc9-4f3b-b2e8-c17088270428.png align="center")

Capacity, appetite, tolerance, trigger. Only one of them is a number.

* * *

## Tuesday, 10:40 AM: "Is that OK?"

Priya's team wants to ship a product analytics SDK. It's a good tool, the integration takes a day, and it would answer questions the company has been guessing at for a year.

It also sends event data to the vendor, and the event payload includes customer email addresses.

Dan asks the question that should be easy: "Is that OK?"

Everyone looks at you. And the honest answer is that you don't know, because Wayne has never written down how much risk it's willing to carry. Every decision like this has been settled by whoever felt most strongly in the room.

You say you'll come back by end of day. Then you open the file you were supposed to draft for the March management review, and find one sentence in it:

> *Wayne Industries has a low appetite for information security risk.*

Read it against Priya's question. It answers nothing. Is a third-party SDK with customer emails inside appetite or not? Does "low" mean never, or means-tested? Who decides?

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/d2c0a612-78fb-43b6-81d1-120b15aee893.png align="center")

A real question, and a document that can't answer it.

**The unpopular truth:** "we have a low appetite for risk" is not a risk appetite statement. It's a mood, and moods can't be delegated, tested or audited. If your statement can't settle a specific decision, it isn't one.

* * *

## Four words people use interchangeably

Getting these apart is most of the work.

| Term | What it means | Who sets it | Wayne example |
| --- | --- | --- | --- |
| Risk capacity | The maximum risk you could absorb before the business is in real trouble | Reality, not preference | A customer-data breach during the Gotham deal would end the deal and possibly the company |
| Risk appetite | The broad amount and type of risk you're willing to accept in pursuit of the mission | Top management | No appetite for unauthorised access to customer data; moderate appetite for short-lived control gaps that let us ship |
| Risk tolerance | The acceptable variation in performance against a specific objective | Management, per objective | Unplanned downtime ≤ 0.1% a quarter; no single outage over 4 hours |
| Threshold / trigger | The point where a defined action fires | Whoever owns the control | MFA below 90% → escalate to the CEO with a costed fix |

Two relationships matter.

**Appetite can never exceed capacity.** If you'd be finished by a single event, a "moderate appetite" for it is fiction.

**Tolerance is always more specific than appetite.** NIST puts it well: appetite statements define the overarching guidance, tolerance statements define how that guidance applies to a specific objective. Or, in the classic example: "email should be available for the large majority of a 24-hour period" is appetite. "Email shall not be interrupted for more than 5 minutes during core hours" is tolerance.

One naming note that saves confusion in an ISO audit: ISO 27001 doesn't use the phrase "risk appetite" much. Clause 6.1.2 asks you to establish and maintain **risk criteria**, including **risk acceptance criteria**. Your appetite statement is where those criteria come from, and the acceptance criteria are the part the auditor will ask to see.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/225bde95-502c-4455-b7b4-c5cd76899d66.png align="center")

Capacity bounds appetite. Appetite drives tolerance. Tolerance sets the triggers.

* * *

## The published guidance: NIST IR 8286 and 8286A

You don't have to invent the format. NIST's **IR 8286** series on integrating cybersecurity and enterprise risk management deals with appetite and tolerance directly, and **IR 8286A** carries a table of notional appetite statements paired with the tolerance statements derived from them.

https://csrc.nist.gov/pubs/ir/8286/a/r1/final

NIST CSF 2.0 makes the same point as an outcome: **GV.RM-02** asks that risk appetite and risk tolerance statements are established, communicated and maintained, and its implementation examples say to translate appetite statements into specific, measurable, broadly understandable tolerance statements.

That's the whole recipe:

1.  Write the appetite in plain sentences, per risk category.
    
2.  Translate each into at least one measurable tolerance.
    
3.  Attach the trigger and the action.
    
4.  Say who can accept a breach, and for how long.
    

* * *

## Start with capacity, not appetite

Before writing what Wayne *wants* to accept, you write down what Wayne *could survive*. Half a page, agreed with Dan:

*   **A two-day delay to a feature:** annoying. Absorbable.
    
*   **A four-hour outage in business hours:** painful, recoverable, one or two angry customers.
    
*   **A week-long outage:** loss of the Gotham deal and probably two existing accounts.
    
*   **A breach of customer personal data:** PIPEDA notification, disclosure to every customer, the Gotham deal gone, and a company with one security person explaining itself.
    
*   **A 5 figure incident cost:** survivable.
    
*   **A 6 figure one:** eats the engineering hires Dan has been promising for a year.
    

That list does something the appetite statement can't do on its own. It makes "no appetite" honest in the places where it's genuinely true, and stops you claiming zero appetite for everything, which is the other failure mode.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/025534e6-3058-43b7-b977-b3fea90d9bb5.png align="center")

Write down what would end the company before writing what you'll accept.

**The unpopular truth:** a statement that says "zero appetite" for every category is as useless as the one-line version. Everything becomes an exception, the exceptions become the process, and the statement quietly stops being read.

* * *

## Wayne's risk appetite statement

6 categories. One appetite sentence each, one or more measurable tolerances, and what happens at the boundary.

| Category | Appetite | Tolerance (measurable) | At the boundary |
| --- | --- | --- | --- |
| Customer data confidentiality | None for unauthorised access to or disclosure of customer data | Zero publicly accessible storage. Zero customer personal data to a vendor without a completed security review | Treated as an incident. CEO informed same day |
| Identity and access | Very low. Access is granted narrowly and removed on departure | MFA ≥ 95% of people accounts, 100% for admin and remote access. Zero shared admin credentials. Leavers disabled by end of last working day | Below 90% MFA, or any leaver exception → escalate at the next leadership meeting |
| Service availability | Low. Short, rare disruptions are acceptable; sustained ones are not | Unplanned downtime ≤ 0.1% per quarter. No single outage over 4 hours. RPO ≤ 15 minutes | Incident review within 5 working days; a standing item at the management review |
| Regulatory and contractual | None for knowingly unmet obligations | Zero missed breach-notification deadlines. Zero security commitments made to customers without a named owner | Disclosed to the affected customer within 5 working days |
| Delivery speed vs controls | Moderate. Wayne will accept short-lived, bounded control gaps in order to ship | No more than 3 open exceptions at once. None older than 90 days. None touching customer data or admin access | Ship pauses until the count is back inside the limit |
| Third parties | Low, but pragmatic | No new data sharing with an unreviewed vendor. Tier-1 vendors reviewed annually. No more than 2 overdue reviews | New sharing blocked until the review completes |

Look at row 5. That's the one that makes the document real, because it's the only row where the answer is sometimes "yes, take the risk." An appetite statement that only ever says no gets routed around within a month.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/33d94133-8852-4f99-bb4c-f9974d77c32d.png align="center")

6 categories. Every appetite sentence has a number underneath it.

* * *

## Who can accept what

A statement without delegation just moves every decision to the CEO. Wayne's acceptance criteria, approved as part of the risk methodology under Clause 6.1.2:

| Level | Rough exposure | Who can accept | Maximum duration |
| --- | --- | --- | --- |
| Low | Under $25k estimated annual loss, no customer data | You (Head of Security) | 90 days |
| Medium | $25k–$250k, or internal data, or one customer affected | Dan (CTO) | 60 days |
| High | Over $250k, customer personal data, or a regulatory obligation | Maya (CEO) | 30 days, with a fix plan |
| Outside appetite | Anything in a "none" category | Nobody accepts it standing. Requires a documented plan, an expiry and a management review item | — |

3 rules that come with it:

*   **Every acceptance has an expiry.** Nothing is accepted "indefinitely." An expired acceptance reopens automatically.
    
*   **Every acceptance is written**, with the risk, the reason, the compensating controls and the date.
    
*   **The exception register is one of the 6 board measures** from now on. What gets counted gets closed.
    

The dollar bands are Wayne's, sized to Wayne. A 20-person company might put the top band at $50k. What matters is that the bands exist and match what the business could actually absorb.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/cd0c7837-8f2f-47ca-b7a9-3a6533ec4448.png align="center")

3 levels, 3 names, 3 expiry dates.

* * *

## Back to Tuesday

With the draft in hand, Priya's question takes 2 minutes instead of a week.

Customer email addresses going to a vendor with no completed security review lands in row one a category with **no** appetite. So the answer isn't "no, never." It's 3 options, in order of how fast they unblock her:

1.  **Strip the personal data.** Send hashed identifiers instead of emails. Inside appetite, ship today.
    
2.  **Complete the vendor review first.** 2 days for a tier-2 vendor using the questionnaire. Inside appetite on Thursday.
    
3.  **Accept a bounded exception.** Not available here, because the category is "none" and only Maya could weigh in and the fix is a day's work, so asking the CEO to carry the risk would be absurd.
    

Priya picks option one before lunch, because the hashed identifier answers her actual question anyway. Nobody negotiated. The document did the arguing.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/1054d077-8b39-4fa9-9a41-e580f9244be4.png align="center")

3 options, ranked by how fast they unblock the release.

2 weeks later it does the opposite job. An engineer needs a temporary debug endpoint on staging, with no customer data behind it, for 4 days.

Row 5: internal data, short-lived, no customer data, no admin access, and only one other exception open. You approve it yourself, in writing, with a 4-day expiry, and nobody escalates anything.

That's the test of a working statement: it says yes quickly as often as it says no.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/9ef3b2b3-788c-4c8d-91d0-39904d18ae37.png align="center")

A statement that only ever says no gets routed around by February.

* * *

## Checking where you actually are

The statement is only useful if someone compares it to reality on a schedule. Same idea as the board pack: same query, same month-end cut.

```python
# appetite-check.py — current measures against the tolerance bands
TOLERANCES = [
    # name,                       current, limit, direction, category
    ("MFA, people accounts",        0.71,  0.95, "min", "Identity and access"),
    ("MFA, admin and remote",       1.00,  1.00, "min", "Identity and access"),
    ("Leaver exceptions (90d)",     0,     0,    "max", "Identity and access"),
    ("Public storage",              0,     0,    "max", "Customer data"),
    ("Unreviewed vendors sharing",  0,     0,    "max", "Third parties"),
    ("Overdue vendor reviews",      12,    2,    "max", "Third parties"),
    ("Open exceptions",             2,     3,    "max", "Delivery vs controls"),
    ("Oldest exception (days)",     41,    90,   "max", "Delivery vs controls"),
]

for name, current, limit, direction, category in TOLERANCES:
    inside = current >= limit if direction == "min" else current <= limit
    print(f"{name:<28} {current:>6} / {limit:<6} {'within' if inside else 'OUTSIDE':<8} {category}")
```

```text
MFA, people accounts           0.71 / 0.95   OUTSIDE  Identity and access
MFA, admin and remote           1.0 / 1.0    within   Identity and access
Leaver exceptions (90d)           0 / 0      within   Identity and access
Public storage                    0 / 0      within   Customer data
Unreviewed vendors sharing        0 / 0      within   Third parties
Overdue vendor reviews           12 / 2      OUTSIDE  Third parties
Open exceptions                   2 / 3      within   Delivery vs controls
Oldest exception (days)          41 / 90     within   Delivery vs controls
```

*Sample output (illustrative). Wayne Industries is fictional.*

Two rows outside appetite, both already owned with dates from the December review. That's the correct state for a young programme: knowingly outside, with a plan, rather than accidentally outside with nobody watching.

* * *

## Evidence #14

Approved at the March management review, which is where Clause 6.1.2 criteria are supposed to get their authority:

*   The risk appetite statement: 6 categories, appetite sentences, measurable tolerances, triggers.
    
*   The capacity note behind it, so future readers know why the lines sit where they do.
    
*   The risk acceptance criteria and delegation table, approved by Maya.
    
*   The exception register, with the 3 rules and the current 2 entries.
    
*   The appetite check against current measures, dated, with the two out-of-appetite rows and their owners.
    

**Evidence #14:** documented risk criteria, approved by top management, and evidence they were applied to real decisions.

That last clause is the one auditors care about most. A statement in a folder proves intent. Two decisions traced back to it proves a system.

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/7ffb3d92-0f05-4c25-8a37-79f1bf3ce7b3.png align="center")

A statement in a folder proves intent. Decisions traced back to it prove a system.

* * *

## What an auditor accepts vs rejects

| Accepted | Rejected |
| --- | --- |
| Appetite per category, each with a measurable tolerance | "We have a low appetite for risk" |
| Acceptance criteria approved by top management | Criteria the security team wrote and nobody approved |
| Delegation bands with named roles | Every acceptance signed by the same person, regardless of size |
| Acceptances with expiry dates | "Accepted" with no end date |
| Decisions that reference the statement | A statement nobody has ever cited |
| A capacity note that explains the "none" categories | Zero appetite everywhere, and a pile of exceptions |
| Periodic comparison of reality to tolerance | An annual document with no monitoring behind it |

* * *

## What you actually do on Monday

1.  **Write the capacity note first.** Half a page: what would hurt, what would end you.
    
2.  **Pick 5 or 6 categories** that match how your business actually loses money or trust.
    
3.  **Write one appetite sentence per category,** in language your CEO would use.
    
4.  **Translate each into a number.** If you can't, the appetite sentence is still too vague.
    
5.  **Set the delegation bands** and the maximum duration for each.
    
6.  **Create the exception register** and put its count in your monthly pack.
    
7.  **Get it approved at a management review,** not over Slack.
    
8.  **Use it out loud** the next time someone asks "is that OK?" — that's what makes it real.
    

* * *

## Framework mapping

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/6f9477ca-01d2-4f45-9253-571d37821b83.png align="center")

Risk criteria, appetite and tolerance across the frameworks.

* * *

## Maturity ladder

| Stage | 20 people | 200 people | 2,000 people |
| --- | --- | --- | --- |
| The statement | Half a page, founder-approved | 5–8 categories with tolerances, reviewed annually | Board-approved, cascaded to business units |
| Tolerances | 2 or 3 numbers you already track | One per category, tied to reported measures | Modelled, with quantified loss bands |
| Acceptance | The founder signs, with a date | Delegation bands by exposure | Formal authority matrix, audited |
| Exceptions | A list in a shared doc | A register with expiry and reporting | Workflow-driven, with automatic reopening |
| The trap | Never writing it | Writing it and never citing it | So many categories that nobody can recall any |

At 20 people this is half a page and a signature. It still beats the one-line version, because half a page can answer a Tuesday question.

**Where Wayne sits:** 6 categories, measurable tolerances, delegation approved, two rows knowingly outside appetite with owners, and two real decisions on record that cite the statement.

* * *

## Cheatsheet

![](https://cdn.hashnode.com/uploads/covers/6aa9ab6f5e60cef18e9a8e9b/5438cde6-31f7-4dc4-bf73-f1ee7c2674e7.png align="center")

Appetite, tolerance and the words in between.

* * *

## The takeaway

Write capacity first. Appetite that exceeds capacity is fiction. One appetite sentence per category, and at least one number under each. Say who can accept what, for how long otherwise everything lands on the CEO or on nobody. The test isn't the document. It's whether the next "is that OK?" gets answered in two minutes.

* * *

> ⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.