Risk Appetite and Tolerance for Cyber Guide: Setting and Using Risk Limits

A cyber risk appetite that says only "we have a low appetite for cyber risk" cannot tell anyone whether to patch tonight, accept an exception or delay a product launch. Appetite becomes useful only when it is cascaded into tolerances that a security team can measure, key risk indicators (KRIs) that warn before a limit is crossed, and escalation rules that put the right decision in front of the right person. This guide explains the vocabulary (appetite, tolerance, capacity, limits) as ISO 31000, COSO ERM, the FSB and NIST IR 8286 Rev. 1 use it, how to write cyber appetite statements that survive contact with operations, how to set KRI thresholds, and how to report against them to a board. It is written for CISOs, risk managers and GRC teams. The ready-to-use policy wording lives in the separate Cyber Risk Appetite Statement Template; this guide covers the method behind it.

Key takeaways

• Appetite is direction, tolerance is a boundary. NIST IR 8286 Rev. 1 treats appetite as the amount and type of risk an organisation is willing to take to meet its objectives, and tolerance as the narrower, measurable limit that applies it to a specific objective or system.
• Capacity sets the ceiling. Appetite must sit inside risk capacity, the maximum loss or disruption the organisation could absorb before breaching financial, regulatory or operational constraints.
• Every tolerance needs a KRI and a threshold. Use green, amber and red zones, with amber set early enough to act, and name who is told at each zone and how fast.
• Cascade from board to system. A board statement becomes category statements, then tolerances per category, then operational limits such as "no KEV-listed internet-facing vulnerability open beyond 7 days" or "no production NHI without a named owner".
• Use it to decide, not to decorate. A statement earns its keep when exceptions, investment cases and risk acceptances are tested against it, and when a breach of tolerance triggers a decision rather than a revised threshold.

Appetite, tolerance, capacity and limits defined

The terms are used loosely in practice, and the confusion causes real problems: a board approves "tolerance" when it meant appetite, or a security team sets a "limit" nobody above them agreed. The table aligns the main sources.

• A note on older NIST usage: NIST SP 800-39 used "risk tolerance" for both ideas; IR 8286 Rev. 1 says explicitly that it separates them. When reading older federal documents, check which meaning applies.
• A note on COSO: COSO ERM 2017 (Integrating with Strategy and Performance, updating the 2004 framework) frames tolerance as acceptable variation in performance, which is why "minutes of outage" or "days to remediate" work better than "risk score below 12".
• A note on ISO 31000:2018: the standard (edition 2, confirmed in 2023, guidelines rather than a certifiable standard) expects risk criteria to be defined in context setting; appetite and tolerance statements are the board-level part of those criteria. ISO/IEC 27001 clause 6.1.2 risk acceptance criteria should derive from the same statement.

Why cyber appetite is hard to write

• Cyber risk is mostly downside: organisations do not seek it for return, so the real question is how much residual exposure to accept in exchange for speed, cost or functionality, such as running a legacy system past end of support.
• Impacts cross categories: ransomware is an availability, financial, regulatory and reputational event at once, so write appetite by impact type, not one appetite for "cyber".
• Likelihood is hard to observe: breach probability cannot be measured monthly, so tolerances sit on leading indicators (exposure, coverage, time to fix) and lagging outcomes (incidents, outage minutes, losses).
• Regulators now expect it: NIST CSF 2.0 subcategory GV.RM-02 expects risk appetite and risk tolerance statements to be established, communicated and maintained. The UK Cyber Governance Code of Practice (launched 8 April 2025) asks boards to set out the cyber risk appetite, communicate it and confirm there is a plan to meet it (action A.3), and to require at least quarterly reporting with agreed tolerances for each metric (action E.2). US registrants describe board oversight of cyber risk and management's processes under Regulation S-K Item 106.

Writing cyber appetite statements

Write appetite in words a board can debate, and tolerance in numbers a team can measure. A workable structure has three layers.

1. Overall statement: two or three sentences linking cyber risk to strategy, for example: willing to take measured risk to adopt cloud and AI where it supports growth, minimal appetite for harm to customers, loss of regulated data or extended disruption of critical services, and no appetite for breaching legal obligations.
2. Category statements: one line per category using a fixed scale (averse, minimal, cautious, open). Categories should match the enterprise risk taxonomy so cyber risk rolls up rather than sitting in a separate report. NIST IR 8286C Rev. 1 describes this staging of cyber risk register entries into the enterprise risk register and profile.
3. Tolerances: for each category, two to four measurable boundaries with a named KRI, a data source, an owner and a review frequency.

NIST IR 8286 Rev. 1 illustrates the difference with email: the appetite is that the service is available for the large majority of each day; the tolerance is that it is not interrupted for more than five minutes during core hours. The first tells leaders what matters, the second tells the service owner when to escalate.

Tests for a good statement

• Decision test: pick three recent decisions (an exception, a supplier onboarding, a delayed patch) and check whether the statement would have given a clear answer. If not, it is too vague.
• Measurability test: every tolerance names a data source that exists today.
• Capacity test: the worst outcome allowed by the tolerances should be well inside capacity. If a tolerance permits a 48 hour outage but the business would breach contracts after 24, the tolerance is wrong.

Cascading appetite into tolerances and limits

IR 8286 Rev. 1 describes senior executives passing risk direction, including appetite and tolerance, to the organisational level, where it is interpreted and applied at system level by those who own the systems. The table shows a worked cascade. Values are illustrative and must be set from your own business impact analysis and loss estimates.

• KEV timing: CISA Binding Operational Directive 22-01 sets due dates for US federal agencies (generally two weeks for CVEs assigned from 2021 onwards and six months for older ones), recorded per entry as dueDate in the catalog. See the Risk-Based Vulnerability Management Guide.
• NHI ownership: an unowned service account or API key cannot be rotated, reviewed or decommissioned safely, which is why the ownership percentage is one of the most useful NHI tolerances. See the NHI Ownership Guide.
• Limits below tolerances: teams may set tighter limits (3 days for KEV on payment systems) that roll up to the board tolerance; limits can change without board approval, tolerances should not.

KRIs and threshold design

IR 8286 Rev. 1 says KPIs and KRIs should be created to warn when tolerance boundaries are being approached, and that KRIs show where tolerances have been exceeded. Design choices matter more than the number of indicators.

• Leading and lagging: pair each outcome measure (incidents, outage minutes) with one or two leading exposure measures (KEV age, MFA coverage, unowned NHIs). Boards need both: leading indicators to act, lagging ones to calibrate.
• Amber with lead time: set amber where the team can still recover inside the reporting period. An amber triggered on day 6 of a 7 day tolerance gives no warning.
• Ratios and counts: percentages hide absolute exposure (1% of 200,000 NHIs is 2,000 identities); use counts for high-impact items.
• Population definition: fix the denominator ("production NHIs in the inventory") and report inventory coverage separately, otherwise a shrinking inventory improves the KRI.
• Data quality flag: report when a KRI could not be measured or its source changed.
• Few per category: two to four KRIs per category, 15 to 25 in total at board level. Move the rest to management dashboards. See the Identity Security Metrics Guide and the Security Operations Metrics Guide for candidate measures.

Qualitative and quantitative appetite

Mature programmes combine all four. For the trade-offs see the Quantitative vs Qualitative Cyber Risk Guide, and for FAIR modelling and loss exceedance curves the Cyber Risk Quantification Guide.

• Small organisations: start with five to seven categories, a four-level scale and one or two control tolerances each. Review annually.
• Large or regulated organisations: align with the ERM taxonomy, quantify loss for the top 10 scenarios, link to insurance limits and capital, and have internal audit test KRI accuracy.

Using appetite in decisions

• Risk acceptance: tie approval authority to appetite level. A residual risk in an "averse" category goes to the board risk committee; in a "cautious" category the CISO or risk owner may accept it. NIST SP 800-53 RA-7 (Risk Response) and PM-9 (Risk Management Strategy) expect responses consistent with organisational risk tolerance.
• Exceptions: each request states which tolerance it breaches, by how much, for how long, the compensating control and an expiry date.
• Investment: fund categories that are amber or red, or forecast to be; where loss is quantified, compare modelled loss reduction with control cost.
• Change: business cases for new systems, suppliers and AI name the categories affected and confirm residual risk stays within tolerance.

Board reporting against appetite

A board report answers three questions: are we inside appetite, where are we not and what is being done, and is the appetite still right.

1. Summary page: one row per category with appetite level, KRI status (green, amber, red), trend versus last quarter and a one-line commentary.
2. Breach reports: for each red KRI: cause, residual exposure, remediation owner and date, and whether the tolerance itself remains appropriate.
3. Scenario view: top scenarios (ransomware, NHI credential theft, supplier compromise) with exposure against capacity.
4. Accepted risks and exceptions: count and age by category, with any expired items.
5. Appetite review: at least annually, or after a major incident, acquisition or strategy change, propose changes with reasons.

Quarterly reporting, as in UK Code action E.2, is a sensible default elsewhere too. For report structure see the Board Cyber Risk Reporting Guide and the Board Cyber Report Template; for who owns what across the first, second and third lines see the Three Lines Model for Cyber Risk Guide.

Implementing an appetite framework

1. Prepare (weeks 1 to 4): collect the enterprise appetite statement, risk taxonomy, business impact analysis, insurance limits and risk register, and ask the CRO, CFO and business heads which outcomes they could not tolerate.
2. Draft (weeks 4 to 8): write the overall statement and category statements, then two to four tolerances per category with a named data source. Start from the Cyber Risk Appetite Statement Template rather than a blank page.
3. Baseline and pilot (weeks 8 to 14): measure every KRI for two reporting cycles before approval. Where a tolerance is red on day one, decide whether it reflects real exposure (fund remediation) or an unrealistic limit (adjust, with reasons recorded).
4. Approve: the board or its risk committee approves appetite levels; the committee approves tolerance values. The CISO drafts but does not approve.
5. Embed: wire tolerances into exception, risk acceptance, investment and change workflows, and the quarterly report.
6. Review and roll back: change an unworkable tolerance through the committee with a recorded rationale, and keep the previous version so trends stay comparable.

Measuring whether the framework works

• Decision coverage: % of risk acceptances and exceptions citing a specific tolerance.
• KRI measurability: % of board KRIs measured from automated sources in the period (target: above 90%).
• Time to escalate: median days from a KRI turning red to committee notification, against the documented rule.
• Breach resolution: % of red KRIs returned to green or amber within the committed date.
• Prediction check: whether related KRIs were amber or red before each significant incident.

Framework mapping

For the wider method see the Risk Management Guide, the ISO 31000 Risk Management Guide and the Risk Register Template.

Common failure patterns

• Appetite with no numbers: a statement of the form "low appetite for cyber risk" approved by the board and never cascaded. Nobody can show whether the organisation is inside it, so it never informs a decision.
• Tolerances moved to close breaches: a red KRI is "fixed" by relaxing the threshold. Require committee approval and a recorded reason for any tolerance change, and report the history.
• Measuring what is easy: KRIs built from whatever the tools report (blocked emails, scan counts) rather than from the exposures behind the top scenarios. Unpatched internet-facing systems and unowned or long-lived machine credentials are recurring entry points; the ShinyHunters FBI breach claim centres on a claimed entry through an internet-facing PeopleSoft server, and Mandiant reports the group exploiting a PeopleSoft flaw Oracle had patched months earlier: exactly the exposure a time-to-patch tolerance on external assets exists to surface.
• Appetite above capacity: tolerances permit outages or losses the business could not survive, because nobody compared them with contracts or insurance limits.
• Security approving its own appetite: the CISO writes and signs the statement, so it becomes a target rather than a business decision, and exceptions are accepted at the wrong level.
• Missing identity categories: statements that cover human MFA but say nothing about service accounts, API keys or AI agents, despite stolen credentials featuring heavily in incidents such as the Snowflake breach, where infostealer credentials, some valid for years without rotation and used without MFA, gave access to around 165 customer accounts.

Practitioner checklist

• Confirm which definitions of appetite, tolerance and capacity your organisation uses, and write them into the statement.
• Align cyber risk categories with the enterprise risk taxonomy so cyber KRIs roll up into the enterprise risk profile.
• Give every category an appetite level on a fixed scale and two to four tolerances with a KRI, data source, owner and frequency.
• Include non-human identity and AI agent tolerances, such as % production NHIs without an owner and maximum secret age.
• Set green, amber and red thresholds, with amber early enough to act inside the reporting period.
• Check that the worst outcome allowed by the tolerances sits inside risk capacity, including insurance limits.
• Measure every KRI for at least two cycles before approval, and record a reason for every change made during baselining.
• Link risk acceptance authority and exception approval to the category's appetite level.
• Report to the board at least quarterly, with breach reports that state cause, remediation date and whether the tolerance remains right.
• Review the whole statement at least annually and after any major incident, acquisition or strategy change.

Standards and references

• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management (ERM)
• NIST: IR 8286C Rev. 1, Staging Cybersecurity Risks for Enterprise Risk Management and Governance Oversight
• NIST: Cybersecurity Framework 2.0
• ISO: ISO 31000:2018 Risk management, Guidelines
• COSO: Enterprise Risk Management, Integrating with Strategy and Performance
• Financial Stability Board: Principles for an Effective Risk Appetite Framework
• UK Government: Cyber Governance Code of Practice
• US SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure rules

Related NHI Mgmt Group resources: Cyber Risk Appetite Statement Template · Cyber Risk Quantification Guide · Quantitative vs Qualitative Cyber Risk Guide · Board Cyber Risk Reporting Guide · Board Briefing: NHI Risk