Your Risk Appetite Statement Is a Slogan Until It Has Thresholds

Category: Enterprise Risk Author: Cody Swidler Tags: risk appetite, KRIs, risk tolerance, metrics, thresholds, board reporting

Almost every risk program I've walked into has a risk appetite statement. It's usually a page, sometimes a slide, approved by the board a year or two ago. It says something like: "The organization has a low appetite for risks that could materially impact customer trust, regulatory standing, or operational continuity."

That sentence cannot be violated. There is no number in it, no owner, and no condition under which anyone would be required to do anything differently. It's a slogan.

The test for a risk appetite statement is simple: can you point to a specific measurement that, if it crossed a specific line, would trigger a specific action by a specific person? If not, you don't have an appetite statement. You have a values statement about risk, and those are free.

Appetite, Tolerance, Threshold

Three words get used interchangeably and shouldn't be. The distinction is what makes the whole structure operable.

Appetite is the qualitative position: how much of this risk the organization is willing to take on in pursuit of its objectives. It's directional and it belongs to the board.

Tolerance is the quantitative boundary on that position, expressed in units the business already uses. Not "low appetite for outage risk" but "no more than 4 hours of cumulative unplanned downtime per quarter on tier-one services." Tolerance is where appetite becomes falsifiable.

Thresholds are the trigger points on the indicators that tell you where you are relative to tolerance, before you breach it. If tolerance is 4 hours per quarter, a threshold might be 2 hours — the point at which the risk owner has to report and act, while there's still quarter left to act in.

Most programs write the appetite layer and stop. The result is a statement that can only be assessed in hindsight, after the loss event, when someone asks whether this was within appetite and the honest answer is that nobody could have told you either way.

What Makes a KRI an Indicator

The "I" in KRI is doing real work and gets ignored constantly. An indicator points at something. Most metrics in risk dashboards don't point — they just count.

Count metrics tell you what already happened: number of incidents last quarter, number of overdue findings, number of failed controls. They're useful for trend and accountability, but they're lagging. By the time the count moves, the risk has already materialized.

A real indicator moves before the risk event does, because it measures a driver of the risk rather than the risk itself. If the risk is "critical vendor fails and disrupts service," the incident count is lagging. The leading indicators are things like: concentration of critical processes on single vendors, percentage of tier-one vendors without a tested exit plan, average age of vendor risk assessments, vendor financial-health signals. Those move first.

The practical filter I use on any proposed KRI is three questions:

Does it move before the loss? If it only moves after, it's a performance metric, not a risk indicator. Keep it, but don't let it carry threshold logic.

Can someone change it? An indicator nobody can influence is a weather report. If the threshold trips and the only available response is "note it," the metric isn't connected to a lever.

Is the data already produced by the business? KRIs that require a new manual collection process die within two reporting cycles. The durable ones are pulled from systems that run whether or not the risk team is watching — ticketing, HR, identity, procurement, monitoring.

Fewer Metrics, Actually Wired

The failure mode I see most often isn't too few metrics. It's forty of them, on a dashboard, all green, none load-bearing.

Forty metrics with no thresholds is a worse position than five metrics with thresholds, because the forty create the appearance of measurement. Someone built that dashboard. Someone reviews it monthly. It consumes real effort and produces no decisions.

A useful rule: every top-tier risk in your register gets one to three indicators, and every indicator has a named owner, a defined threshold, and a documented response. If you can't complete that row for a metric, the metric doesn't go on the dashboard. It goes in a supporting appendix or it goes away.

This forces a conversation most programs avoid, which is what the organization would actually do at each level. That conversation is the value. The dashboard is just where it gets recorded.

The Breach Protocol

A threshold without a defined response is a number that makes people uncomfortable in a meeting. What turns it into governance is the protocol attached to it — decided in advance, when nobody is under pressure.

For each threshold, three things need to be settled before it trips:

Who is notified, and how fast. Not "management is informed." A role, and a timeframe. The risk owner within two business days, the risk committee at its next scheduled session, the board if it stays breached through a second consecutive period.

What the required response is. Typically a documented analysis of cause, a remediation plan with dates, and an interim position — accept, mitigate, or escalate for a formal appetite exception.

Who can accept a continued breach, and for how long. This is the one that gets skipped, and it's the one that matters. If operating outside tolerance requires a named executive to sign a time-boxed exception that gets reported to the board, breaches get fixed. If it requires nothing, tolerance is decoration.

The exception register is the honest measure of a program here. A program with zero exceptions on file either has no thresholds that bind, or has thresholds people quietly ignore. A healthy program has a small number of active, dated, owned exceptions — evidence that the lines are real enough to occasionally get in the way.

Wiring It to the Register

Indicators shouldn't live in a separate deck from the risk register. They belong attached to the risks they indicate, which is what makes the register a live instrument instead of an annual artifact.

The connection runs in both directions. A sustained threshold breach is evidence that the residual risk score is wrong — either likelihood is higher than assessed, or the controls credited in the residual calculation aren't performing. When an indicator trips, the corresponding risk should be re-scored, not just noted. That's the mechanism that keeps the register honest between assessment cycles, and it's the same connected-model logic that ties incidents and issues back to control effectiveness.

Run the other direction too. When a new top risk is added to the register, part of accepting it is answering: how will we know if this is getting worse? A risk with no indicator is a risk you have agreed to discover late.

What the Board Should See

Board-level reporting on appetite is not a list of metrics. It's a position statement with evidence behind it.

The useful format is short: for each principal risk, where we sit relative to tolerance, direction of travel, and any active exceptions with their expiry dates. Green, amber, red is fine as a presentation layer — as long as the color is derived from a threshold rather than assigned by judgment before the meeting.

The question a board should be able to ask, and get a straight answer to, is: "which risks are we currently running outside of appetite, who approved that, and when does it expire?" A program that can answer that in one page has a functioning appetite framework. A program that has to go build the answer has a slogan.

Where to Start

If your appetite statement is currently qualitative, don't try to quantify all of it at once. Take your top three to five principal risks. For each, work the chain in order: what's the qualitative appetite, what's the measurable tolerance boundary, what indicators move ahead of that boundary, where do the thresholds sit, and what happens when they trip.

Five risks with a complete chain will do more for your program than twenty with a partial one, because the five prove the mechanism works. Once a threshold has tripped, triggered a response, and produced a visible decision, the rest of the organization stops treating the framework as a documentation exercise. That's the point at which appetite starts constraining behavior, which is the only thing it was ever supposed to do.

Cody Swidler is the founder of PivotRisk. He has built operational resilience and GRC programs at organizations operating under FFIEC, SEC, FCA, and DORA-aligned frameworks across fintech, asset management, and network infrastructure.