Introduction
Risk tolerance is the measurable boundary that turns a board's risk appetite into a decision rule people can actually operate. Appetite says how much risk the organization is willing to pursue; tolerance says how far actual outcomes may drift before someone must act.
Most governance programs write an appetite statement and stop there. The result is a document that sounds good in the board pack but cannot tell a SOC manager, a CISO or an auditor whether 14 days of unpatched critical exposure is acceptable or a breach. Tolerance closes that gap.
This article explains what risk tolerance is under the main standards, how it differs from capacity, appetite and limits, how to set and express it, and how regulators and auditors expect it to be governed.
What the standards say
The standards agree that tolerance is narrower and more measurable than appetite, but they frame it in two different ways. Definitions below are paraphrased; see References for the source texts.
Source | How it frames risk tolerance | Lens |
|---|---|---|
ISO Guide 73:2009 (vocabulary used by ISO 31000:2018 and ISO/IEC 27005:2022) | The readiness of an organization or stakeholder to bear risk after treatment in order to achieve objectives; may be shaped by legal or regulatory requirements | Residual risk accepted |
COSO ERM, Integrating with Strategy and Performance (2017) | Renamed simply "tolerance": the boundaries of acceptable variation in performance around a business objective | Variation band |
NIST SP 800-39 (2011) | The level of risk or degree of uncertainty acceptable to the organization; set during risk framing and passed down through all tiers | Organizational frame |
NIST IR 8286 series (8286, 8286A r1 2025) | Appetite is broad; tolerance is the specific, measurable expression of it applied to a given objective or asset | Cyber-to-ERM bridge |
NIST CSF 2.0, GV.RM-02 | Appetite and tolerance statements must be established, communicated and maintained; appetite is translated into specific, measurable, broadly understood tolerance statements | Governance outcome |
ISACA Risk IT Framework, 2nd ed. (2020) | The acceptable deviation from the level set by risk appetite | Variation band |
FSB Principles for an Effective RAF (2013) | Deliberately avoids the term; uses risk appetite plus quantitative risk limits to keep the vocabulary simple | Limits |
The practical synthesis. Treat tolerance as two things at once: the maximum residual risk you will accept for a specific objective (ISO/NIST view), and the band of variation around a target before escalation is mandatory (COSO/ISACA view). A good tolerance statement names both the target and the boundary.
Consistency rule. Pick one vocabulary and publish it in your risk management policy glossary. Mixing "tolerance", "threshold" and "limit" loosely across the policy, the RCSA and the board pack is one of the most common audit observations in this area.
The risk boundary hierarchy
Tolerance sits between appetite and capacity: appetite is the target zone, tolerance is the buffer before escalation becomes mandatory, and capacity is the hard edge the organization cannot cross and survive.
Limits and KRI thresholds then cascade these boundaries to individual business units, systems and vendors.
Level | What it means | Set or owned by | Typical form |
|---|---|---|---|
Risk capacity | Maximum risk the organization can absorb before insolvency, regulatory breach or loss of critical services | Board, informed by finance and risk | Capital and liquidity buffers, RTO / MTPD, regulatory minimums |
Risk appetite | Amount and type of risk the organization is willing to pursue for its objectives | Board | Qualitative statement per risk category |
Risk tolerance | Acceptable residual risk, or variation around appetite, for a specific objective | Senior management, approved by the board | Measurable statements with KRIs |
Risk limits / thresholds | Hard ceilings cascaded to units, systems and vendors | Risk owners within delegated authority | Numeric limits and KRI triggers |
Risk profile | The current, actual exposure | Measured and reported by the second line | Dashboard values against the boundaries above |
Expressing tolerance: qualitative, semi-quantitative, quantitative
Tolerance only works if it can be measured and compared against the current risk profile. There are three common ways to express it, and mature programs use all three at different layers.
Approach | Example | Strength | Weakness |
|---|---|---|---|
Qualitative | No residual risk rated "High" on critical customer-facing systems | Easy for the board to approve | Depends on a consistent rating methodology; hard to aggregate |
Semi-quantitative (heat-map scores) | Residual score must stay at or below 12 on a 5x5 matrix | Ties directly to the risk register | Ordinal scores cannot be added or averaged meaningfully |
Quantitative, operational (KRIs) | 95% of critical vulnerabilities remediated within 15 days | Directly monitorable; drives behaviour | Measures control performance, not loss exposure |
Quantitative, financial (FAIR / loss exceedance) | Less than 10% probability of a cyber loss above AED 20 million in 12 months | Comparable with capital, credit and market risk | Needs data, modelling skill and calibrated estimates |
Key Risk Indicators are how tolerance is watched. Each KRI needs a green zone (within appetite), an amber zone (within tolerance but drifting) and a red zone (tolerance breached). The amber trigger is the early warning; the red trigger is the escalation event.
Quantification closes the loop with the board. Open FAIR (The Open Group O-RA/O-RT) expresses exposure as annualized loss distributions. A loss exceedance curve can then be overlaid with a board-approved tolerance curve: any point where modelled exposure sits above the tolerance curve is a breach, regardless of how the heat map looks.
The figures in the table are illustrative only; each organization must calibrate them to its own capacity and objectives.
How to set risk tolerance
Tolerance is derived top-down from strategy and capacity, then tested bottom-up against what operations can actually measure. The sequence below aligns with COSO ERM, NIST IR 8286 and NIST CSF 2.0 GV.RM.
Anchor to objectives. List the business objectives and the critical services, data and assets that support them (NIST CSF GV.OC, ISO 31000 context establishment). Tolerance without an objective has nothing to vary from.
Establish risk capacity. Determine the maximum loss or disruption the organization can absorb: capital and liquidity buffers, regulatory minimums, contractual SLAs, recovery time objectives, reputational and life-safety limits.
Confirm the appetite statement. The board approves, per risk category, how much risk it is willing to pursue (for example: low appetite for regulatory non-compliance, moderate appetite for technology change risk).
Translate appetite into tolerance statements. For each category, write a specific, measurable statement with a metric, a target, a boundary and a time window (CSF 2.0 GV.RM-02 Ex2).
Define KRIs and thresholds. Assign each tolerance at least one leading and one lagging KRI, with green, amber and red trigger values and a data source.
Cascade into limits. Break enterprise tolerances down into business-unit, system or vendor limits that individual owners can control.
Validate feasibility. Back-test the thresholds against 12 to 24 months of historical data and current control performance. A tolerance that is breached every month, or never comes close, is mis-calibrated.
Approve and communicate. Board or board risk committee approves; the CRO or CISO publishes the statements in policy, the risk register and the dashboard.
Monitor, escalate and review. Report the risk profile against tolerance at a fixed cadence, escalate breaches under a defined protocol, and recalibrate at least annually or after a material change in strategy, threat or regulation (CSF 2.0 GV.RM-02 Ex3).
Writing a good tolerance statement. Use the pattern: for [objective or asset], [metric] must stay [within boundary] over [period]; breach triggers [escalation] to [owner].
Cybersecurity and IT examples
Each row pairs a board-level appetite with the tolerance and KRI that make it operable. Values are illustrative and must be calibrated to the organization.
Risk category | Appetite (board level) | Tolerance statement | KRI and red trigger |
|---|---|---|---|
Vulnerability management | Low appetite for exploitable weaknesses on internet-facing systems | Critical vulnerabilities on internet-facing assets remediated or mitigated within 15 days | Count of critical findings older than 15 days; red at 1 or more on a KEV-listed CVE |
Service availability | Low appetite for disruption of payment services | Core payment platform unplanned downtime no more than 4 hours per quarter; no single outage beyond the RTO | Cumulative quarterly downtime; red at 4 hours or any RTO breach |
Data protection | Zero appetite for unauthorized disclosure of customer personal data | No confirmed breach of customer PII; DLP high-severity alerts triaged within 24 hours | Confirmed PII incidents; red at 1 |
Detection and response | Low appetite for undetected intrusions | Mean time to detect a high-severity incident at most 24 hours; mean time to contain at most 72 hours | Rolling 90-day MTTD and MTTC; red above target for 2 consecutive months |
Identity and access | Low appetite for excessive privileged access | 100% of privileged accounts reviewed quarterly; orphan accounts disabled within 5 days of exit | Overdue reviews and orphan accounts; red at any overdue privileged review |
Third-party risk | Moderate appetite for outsourcing, low for unassessed critical vendors | No critical vendor onboarded or renewed without a completed security assessment | Critical vendors with expired or missing assessments; red at 1 |
Regulatory compliance | Zero appetite for wilful non-compliance | High-rated regulatory or audit findings closed within agreed dates; no more than 5% overdue | Percentage of overdue high findings; red above 5% |
Notice the asymmetry. Zero-appetite categories still need a tolerance: it describes what happens on the first event, who is told, and how fast. "Zero tolerance" written as a slogan without a response protocol is not a control.
Governance, escalation and breach handling
Tolerance has value only if a breach reliably reaches someone with the authority to act. Ownership should follow the three lines model (IIA, 2020).
Role | Responsibility for tolerance |
|---|---|
Board / Board Risk Committee | Approves appetite and enterprise tolerances; receives red breaches and remediation plans |
Senior management (CEO, ExCo) | Proposes appetite; owns tolerances for their objectives; decides on remediation or formal acceptance |
Second line (CRO, CISO, Compliance) | Designs the framework, calibrates thresholds, monitors KRIs, independently challenges and escalates |
First line (business and IT owners) | Operates within limits, reports KRI data, executes corrective actions |
Third line (Internal Audit) | Gives independent assurance that tolerances are set, monitored and escalated as designed |
A workable escalation protocol:
Amber (within tolerance, outside appetite): risk owner notified; corrective plan logged in the risk register within an agreed period, for example 10 business days.
Red (tolerance breached): CRO or CISO informed immediately; senior management decision within a set window; board risk committee informed at the next meeting or sooner for material breaches.
Persistent breach: the board must choose explicitly: fund remediation, transfer the risk, change the business activity, or formally raise the tolerance with documented rationale.
Risk acceptance is not a workaround. Accepting a risk above tolerance should require a higher approval level than accepting one within it, carry an expiry date, and be visible in board reporting. Otherwise, exceptions quietly become the real tolerance.
Regulatory perspective: banking and the UAE
Regulators rarely use the word "tolerance" consistently, but they all expect a board-approved appetite cascaded into measurable boundaries that are monitored and escalated. Map your tolerance framework to whichever term your regulator uses.
Regulation or framework | What it expects | Equivalent of tolerance |
|---|---|---|
FSB, Principles for an Effective Risk Appetite Framework (2013) | A risk appetite framework covering capacity, appetite, limits and risk profile, by business line and legal entity | Risk limits |
Basel Committee, Corporate Governance Principles for Banks (2015) | Board oversees the RAF; a written risk appetite statement covering the aggregate level and types of risk the bank will accept or avoid; a board risk committee | Risk limits within the RAS |
CBUAE Risk Management Regulation and Standards (Circular 153/2018) | The board must approve and oversee the risk governance framework, including the risk appetite statement and risk limits by legal entity, business line or unit consistent with it | Risk limits |
CBUAE Credit Risk Management Regulation and Standards (effective 30 Nov 2024) | The board reviews and approves credit risk tolerances/limits consistent with the risk appetite and capital strength | Tolerances / limits |
ISO/IEC 27001:2022, clause 6.1.2 | Information security risk criteria, including risk acceptance criteria, are established and maintained | Risk acceptance criteria |
NIST CSF 2.0, GV.RM-02 | Appetite and tolerance statements established, communicated and maintained | Risk tolerance statements |
Healthcare (e.g., ADHICS in Abu Dhabi) | A risk-based information security program with defined risk assessment and treatment decisions | Risk acceptance criteria and treatment thresholds |
Practical implication for a UAE bank. Tolerance and limits for technology and cyber risk should sit inside the same board-approved RAF used for credit, market and liquidity risk, not in a separate CISO document. The CBUAE Information Security Regulation and the operational risk framework then consume those limits as the basis for control design and reporting.
Practical implication for an auditee. When an auditor asks for "risk acceptance criteria" under ISO 27001 or a healthcare standard, the expected evidence is the same artefact: an approved, measurable boundary, applied consistently in the risk register.
Common pitfalls and how auditors test them
Most tolerance frameworks fail in operation, not in design. The pitfalls below are the ones an IT auditor or regulator is most likely to find.
Pitfall | Why it matters | What an auditor will test |
|---|---|---|
Appetite and tolerance used interchangeably | No measurable boundary exists, so nothing can be breached | Glossary in the risk policy; whether each appetite statement has at least one measurable tolerance |
Tolerance with no data source | Thresholds exist on paper but are never measured | Trace each KRI to its system of record and last reported value |
Thresholds never breached, or always breached | Calibration is wrong; the framework adds no signal | 12-month KRI trend against amber and red triggers |
Breaches not escalated | Governance failure; board unaware of real exposure | Sample red breaches; check committee minutes and decision records |
Risk acceptance used to bypass tolerance | Exceptions become the de facto tolerance | Acceptance register: approval level, expiry, rationale, visibility to the board |
Static tolerance | Does not reflect new strategy, threats or regulation | Evidence of annual review and event-driven recalibration |
Cyber tolerance outside the enterprise RAF | Technology risk is invisible in capital and strategy decisions | Whether cyber KRIs appear in the board risk dashboard with other risk types |
Heat-map arithmetic | Ordinal scores are averaged or summed, distorting aggregate exposure | Method used to aggregate residual risk across the register |
A one-line audit test. Pick any tolerance statement and ask: what is the current value, where does it come from, when was it last breached, and what did the board decide? If any answer is missing, the tolerance is not yet operating effectively.
Conclusion
Risk tolerance is where risk governance becomes measurable. Appetite expresses intent; tolerance defines the boundary, the metric and the escalation path that prove the organization is living within that intent.
Three tests separate a working framework from a paper one: every appetite statement has a measurable tolerance, every tolerance has a live KRI with an owner, and every breach produces a recorded board-level decision. Build to those tests and the framework will satisfy NIST CSF 2.0 GV.RM-02, ISO 27001 risk acceptance criteria and CBUAE risk-limit expectations with the same evidence.
References
ISO 31000:2018, Risk management — Guidelines, and ISO Guide 73:2009, Risk management — Vocabulary. International Organization for Standardization.
ISO/IEC 27001:2022 (clause 6.1.2) and ISO/IEC 27005:2022, Guidance on managing information security risks.
COSO (2017), Enterprise Risk Management — Integrating with Strategy and Performance.
NIST SP 800-39 (2011), Managing Information Security Risk: Organization, Mission, and Information System View.
NIST IR 8286A Rev. 1 (2025), Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management; see also the NIST glossary entry for risk appetite and NIST IR 8286B.
NIST Cybersecurity Framework 2.0 Implementation Examples (GV.RM-02), NIST, 2024.
ISACA (2020), Risk IT Framework, 2nd edition.
Financial Stability Board (2013), Principles for an Effective Risk Appetite Framework.
Basel Committee on Banking Supervision (2015), Corporate governance principles for banks.
Central Bank of the UAE, Risk Management Standards, Circular 153/2018.
Central Bank of the UAE, Credit Risk Management Standards (effective 30 Nov 2024); overview by KPMG Lower Gulf.
The Open Group, Risk Taxonomy (O-RT) and Risk Analysis (O-RA) standards (Open FAIR).
The Institute of Internal Auditors (2020), The IIA's Three Lines Model.
Department of Health Abu Dhabi, Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS).
