skip to content

Under NIST CSF 2.0's GV.RM-02, how do risk appetite and risk tolerance differ, and what should happen when a residual risk exceeds tolerance?

level: seniorimportance: should knowfreq 30%

answer

  1. set at the top, measured below
  2. broad stance versus measurable limit
  3. acceptance authority follows the limit
  4. escalate, re-treat, or accept higher up

basics

~20 s

Risk appetite is the broad amount and type of risk leadership is willing to take in pursuit of objectives; risk tolerance turns it into measurable limits. A residual risk beyond tolerance is escalated to whoever owns the appetite, to re-treat or explicitly accept.

solid answer

~50 s

CSF 2.0 `GV.RM-02` requires risk appetite and risk tolerance statements to be "established, communicated, and maintained". **Appetite** is the broad statement from executives and the board: for example, low appetite for anything that interrupts customer payments, moderate for internal analytics. **Tolerance** turns it into measurable limits per objective or risk: no more than four hours of settlement outage per incident, or a 1-in-10-year loss below a stated amount. NIST SP 800-37 Rev. 2 says organizations determine acceptable residual risk based on tolerance, so tolerance sets who may accept what. A residual risk above tolerance is not the local owner's to accept. It goes up the chain to be re-treated, avoided, or explicitly accepted by the level that owns the appetite, recorded with rationale and a review date, and possibly prompting a review of the tolerance itself.

go deeper

for a junior

Recall that appetite is the broad stance set by leadership and tolerance is the measurable limit, and that CSF 2.0 places both under Govern.

for a middle

Explain how tolerance decides who may accept a residual risk, and give an example of a measurable tolerance for a specific business objective.

for a senior

Show how you handle an acceptance request above tolerance: escalation, options to re-treat or avoid, an explicit exception with conditions, and a review trigger.

for a principal

Discuss how you would draft and calibrate appetite and tolerance with executives so they are testable, and when repeated exceptions should change the statements.

## Where the terms come from NIST CSF 2.0 puts risk appetite and tolerance in the **Govern** function, under **Risk Management Strategy (GV.RM)**: "The organization's priorities, constraints, risk tolerance and appetite statements, and assumptions are established, communicated, and used to support operational risk decisions." The subcategories that matter here: - `GV.RM-02`: risk appetite and risk tolerance statements are established, communicated, and maintained. - `GV.RM-04`: strategic direction describing appropriate risk response options is established and communicated. - `GV.RM-06`: a standardized method for calculating, documenting, categorizing and prioritizing cybersecurity risks is established and communicated. NIST SP 800-53 Rev. 5 echoes this in the programme management family: `PM-9` (risk management strategy) includes "an expression of the security and privacy risk tolerance for the organization", and `PM-28` (risk framing) requires the organization to identify and document its risk tolerance. SP 800-30 Rev. 1 says tolerance is "determined as part of the organizational risk management strategy to ensure consistency across the organization". ## Appetite versus tolerance CSF 2.0 uses the two terms side by side without formal definitions; the distinction in common enterprise risk management usage is: | | Risk appetite | Risk tolerance | |---|---|---| | **Nature** | Broad stance: how much and what kind of risk to pursue | Measurable limit around a specific objective or risk | | **Set by** | Board and executives | Executives and risk function, cascaded to business units | | **Form** | Qualitative statements by risk category | Thresholds, metrics, loss figures | | **Example** | "Low appetite for risks that interrupt customer payments" | "No incident may stop settlement for more than four hours" | | **Used for** | Setting direction and priorities | Deciding whether a residual risk is acceptable, and by whom | Appetite without tolerance cannot be tested against a register row; tolerance without appetite is a set of numbers with no rationale. ## How tolerance governs acceptance SP 800-37 Rev. 2: "regardless of the risk response, there remains a degree of residual risk. Organizations determine acceptable degrees of residual risk based on organizational risk tolerance." In practice: 1. **Within tolerance** — the risk owner may accept the residual risk, with rationale and a review date. 2. **Above tolerance** — the owner may not accept it alone. The row is escalated to the level that set the appetite (an executive risk committee, or in the NIST model the risk executive function and the authorizing official). 3. **At that level**, the choices are to fund further treatment, avoid the activity, or explicitly accept the risk as an exception, recorded with its rationale, conditions and review date. 4. **Repeated exceptions** in the same category are a signal to revisit the tolerance statement, which `GV.RM-02` says must be *maintained*, not written once. ## A fintech scenario A fintech's tolerance says no single scenario may carry a 1-in-10-year loss above a set amount. A FAIR analysis of a new instant-payments integration shows the tail above that figure until transaction-monitoring rules are built, eight weeks after launch. - The product owner wants to launch now and accept the risk. That acceptance is above their authority because the residual exceeds tolerance. - The risk committee sees three options: delay launch (avoid), launch with a lower transaction limit (mitigate by reducing magnitude), or accept for eight weeks with daily manual review. - It chooses the lower limit plus manual review, and records the residual as accepted at committee level, reviewed when the rules go live. ## Pitfalls - Using the two words as synonyms, so nobody can say whether a risk is acceptable. - Appetite statements so vague ("we take security seriously") that no decision can be tested against them. - Tolerance defined but never cascaded, leaving acceptance authority unclear. - Moving the tolerance to fit an inconvenient risk instead of escalating it.

  • What makes a risk tolerance statement usable in day-to-day decisions?
    It is measurable and tied to an objective someone can check: a maximum outage duration, a maximum records exposed, a loss figure at a stated percentile. It names the category of risk it applies to and who may accept risk inside it. A statement like "low tolerance for data breaches" cannot be tested against a register row, so every acceptance becomes an argument.
  • Should an organization change its tolerance when a valuable project keeps exceeding it?
    Possibly, but as a deliberate governance decision by the level that owns the appetite, not as a quiet edit by the project. Repeated exceptions are evidence that either the tolerance is miscalibrated for the business or the project carries more risk than leadership wants; `GV.RM-02` expects the statements to be maintained, so the review should happen openly and be recorded.

saying these in an interview costs you the question

  • Risk appetite and risk tolerance mean the same thing.
  • The security team sets the appetite from its vulnerability backlog.
  • A risk above tolerance can never be accepted by anyone.
  • Tolerance statements are only needed by regulated companies.
  • Once written, the appetite statement never needs revisiting.