Risk Appetite vs Risk Tolerance vs Impact Tolerance

Risk appetite, risk tolerance, and impact tolerance are often used as if they mean the same thing.

They do not.

They are related, but they answer different questions.

Risk appetite asks:

How much risk are we willing to take in pursuit of our objectives?

Risk tolerance asks:

How much variation from our desired performance or risk level can we accept before action is needed?

Impact tolerance asks:

How much disruption to an important service can we tolerate before harm becomes unacceptable?

Those distinctions matter.

If the terms are confused, risk reporting becomes vague. Executives may approve risk appetite statements that never translate into operating thresholds. Risk owners may escalate issues inconsistently. Control owners may not know when a failed control becomes unacceptable. Resilience teams may set recovery expectations without connecting them to enterprise risk. Boards may see red, amber, and green dashboards without understanding what action is required.

A Connected GRC program should make these concepts practical.

Risk appetite should guide strategy and risk-taking.

Risk tolerance should turn appetite into measurable thresholds and escalation points.

Impact tolerance should define how much disruption the organization can absorb for important services.

Together, they help leaders decide when to accept, mitigate, escalate, remediate, invest, pause, or stop an activity.

The goal is not to create more risk terminology.

The goal is to make risk decisions clearer.

The simplest difference

A simple way to remember it:

• Risk appetite is strategic.
• Risk tolerance is measurable.
• Impact tolerance is disruption-focused.

Risk appetite is usually set at the enterprise or strategic level.

Risk tolerance usually applies to specific risks, objectives, metrics, thresholds, or operating conditions.

Impact tolerance usually applies to important or critical business services in operational resilience.

They should connect, but they should not be collapsed into one idea.

What is risk appetite?

Risk appetite is the amount and type of risk an organization is willing to take or retain in pursuit of its strategy, objectives, and value creation.

Risk appetite is usually expressed through statements such as:

• We have low appetite for risks that could compromise employee safety.
• We have limited appetite for regulatory noncompliance.
• We have moderate appetite for innovation risk in pursuit of growth.
• We have low appetite for cyber risk affecting customer data.
• We have no appetite for material weaknesses in financial reporting controls.
• We have moderate appetite for third-party dependency where appropriate controls exist.
• We have low appetite for disruption to critical customer-facing services.

COSO’s risk appetite guidance focuses on linking risk appetite with strategy and objectives and using appetite as part of decision-making.  

That is the right lens.

Risk appetite should not be a document created once a year.

It should help leaders make choices.

For example:

• Should we enter a new market?
• Should we use a new AI vendor?
• Should we accept a high-risk third party?
• Should we delay remediation of a vulnerability?
• Should we accept a policy exception?
• Should we invest in resilience?
• Should we launch before all controls are complete?

Risk appetite gives the organization a way to answer those questions consistently.

What is risk tolerance?

Risk tolerance is the acceptable level of variation or deviation from a specific objective, risk level, metric, threshold, or expected performance before action, escalation, or remediation is required.

Risk tolerance is usually more specific than risk appetite.

For example:

A helpful practical definition from the University of California’s ERM materials describes risk appetite as the amount of risk an entity is willing to accept in pursuit of value, while risk tolerance is the acceptable level of variation relative to achievement of a specific objective, often measured in the same units as the objective.  

That last point is important.

Risk tolerance should be measurable whenever possible.

If the tolerance cannot be measured, it becomes hard to govern.

What is impact tolerance?

Impact tolerance is the maximum tolerable level of disruption to an important or critical business service before the impact becomes unacceptable.

Impact tolerance is most often used in operational resilience.

The FCA describes impact tolerances as maximum tolerable levels of disruption for important business services and expects firms to identify important services, set tolerances, map the people, processes, technology, facilities, and information that support them, and take action to remain within tolerance through severe but plausible scenarios.  

Examples of impact tolerance might include:

• Customer payments must be restored within a defined maximum disruption period.
• Account access cannot be unavailable beyond a defined threshold.
• Customer support for critical services must continue at a minimum service level.
• A regulated reporting process must be restored before a required deadline.
• A service affecting market integrity must remain within a defined disruption window.
• A critical internal service must recover before downstream business harm becomes unacceptable.

Impact tolerance is different from a general risk tolerance because it is service-specific and disruption-focused.

It asks:

If this important service is disrupted, how much disruption can we tolerate before customers, markets, operations, safety, regulators, or the business experience unacceptable harm?

That is a practical resilience question.

Why these terms are confused

These terms are confused because they all describe boundaries.

Risk appetite sets the broad boundary for risk-taking.

Risk tolerance sets measurable boundaries for specific risks, objectives, or metrics.

Impact tolerance sets disruption boundaries for important services.

They are related.

But they operate at different levels.

The confusion happens when organizations use broad appetite language but never define measurable tolerances.

Or when they define impact tolerances but do not connect them to enterprise risk appetite.

Or when they use “tolerance” generally without clarifying whether they mean risk tolerance or impact tolerance.

Connected GRC helps by making each concept a record with owners, thresholds, evidence, issues, and reporting.

How the three concepts work together

The three concepts should cascade.

1. Risk appetite sets the direction

The board and executive team define how much risk the organization is willing to take.

Example:

We have low appetite for disruptions that materially affect customer access to core services.

2. Risk tolerance defines measurable thresholds

Risk teams translate appetite into measurable thresholds.

Example:

Customer-impacting service incidents above a defined severity must be escalated within a defined timeframe. Repeat incidents or open remediation beyond threshold require executive review.

3. Impact tolerance defines service disruption limits

Resilience teams define maximum tolerable disruption for the important service.

Example:

Customer account access must be restored within the approved disruption tolerance and tested through severe but plausible scenarios.

4. GRC workflows enforce and monitor the thresholds

Connected workflows link:

• service maps
• BIAs
• controls
• incidents
• vendors
• vulnerabilities
• issues
• remediation
• evidence
• dashboards

That is how risk language becomes operational.

A practical example: customer account access

Imagine a company provides customer account access through a digital platform.

Risk appetite

The board says:

We have low appetite for disruptions that materially impair customer access to core services.

This is broad and strategic.

Risk tolerance

Management defines thresholds such as:

• high-severity customer access incidents must be escalated immediately
• repeat incidents in the same service require root-cause review
• critical vulnerabilities on service-critical systems must be remediated within defined SLA
• unresolved high-severity issues affecting the service require executive review

These are measurable.

Impact tolerance

The operational resilience team defines the maximum tolerable disruption for customer account access.

This is service-specific.

Connected GRC workflow

The service record connects to:

• business processes
• applications
• identity systems
• vendors
• data stores
• cyber controls
• vulnerability records
• incident history
• continuity plans
• crisis playbooks
• open issues
• test evidence

The dashboard shows whether the service is within tolerance, which issues could breach tolerance, and what decisions are needed.

That is the full connection.

Risk appetite is not a metric by itself

Risk appetite is often expressed in words.

That is fine.

But words alone are not enough.

A risk appetite statement such as “low appetite for cyber risk” is too broad to manage unless it is translated into tolerances, limits, controls, and escalation rules.

A useful risk appetite statement should eventually connect to:

• risk category
• owner
• business objective
• tolerance thresholds
• KRIs
• controls
• issues
• escalation rules
• reporting cadence
• evidence
• decision authority

For example:

Risk appetite becomes useful when it guides decisions.

Risk tolerance should be measurable

Risk tolerance is most useful when it can be measured, monitored, and escalated.

Tolerances may use:

• counts
• percentages
• timeframes
• severity levels
• financial thresholds
• service levels
• deadlines
• backlog thresholds
• issue aging
• incident frequency
• vulnerability age
• evidence rejection rates
• control failure rates
• residual risk ratings

Examples:

• No high-severity regulatory issues overdue beyond 30 days.
• Critical vendors cannot renew with unresolved high-risk issues unless risk acceptance is approved.
• Key controls cannot remain untested past the testing cycle.
• Privacy incidents involving sensitive data must be reviewed within defined timeframe.
• Evidence rejection rate above threshold requires control-owner training.
• SOX deficiencies above severity threshold require audit committee visibility.
• Critical vulnerabilities on customer-facing systems cannot exceed remediation SLA.

A tolerance without measurement is hard to enforce.

A measurement without action is just reporting.

The best tolerances trigger workflow.

Impact tolerance should be service-specific

Impact tolerance should be tied to a specific important service.

A generic statement such as “we tolerate limited disruption” is not enough.

A useful impact tolerance should identify:

• important service
• service owner
• maximum tolerable disruption
• minimum service level
• customer or stakeholder harm threshold
• regulatory or market impact
• operational impact
• dependencies
• testing approach
• evidence
• escalation path
• remediation trigger

The FCA’s operational resilience policy materials emphasize identifying important business services, mapping the resources needed to deliver them, and testing the ability to remain within impact tolerances in severe or extreme but plausible scenarios.  

That is the practical operating model.

Impact tolerance is not just a number.

It is a commitment that must be tested against real dependencies.

Risk appetite vs risk limits

Risk appetite and risk tolerance are often connected to risk limits.

A simple way to distinguish them:

Example:

• Risk appetite: Low appetite for operational disruption to critical services.
• Risk tolerance: Important service disruption must remain below approved tolerance.
• Risk limit: If service outage exceeds defined threshold, crisis escalation is required.
• Trigger: If dependency failure threatens tolerance, issue escalation begins.

Limits and triggers make appetite and tolerance actionable.

Without them, risk appetite stays abstract.

Risk tolerance vs impact tolerance

Risk tolerance and impact tolerance can look similar because both define boundaries.

But they apply to different things.

Risk tolerance asks:

How much variation can we accept?

Impact tolerance asks:

How much service disruption can we absorb?

They can connect.

For example, if a critical service is approaching its impact tolerance during an incident, that may breach risk tolerance and require executive escalation.

Risk appetite vs impact tolerance

Risk appetite is broader than impact tolerance.

Risk appetite may say:

We have low appetite for disruption to critical customer services.

Impact tolerance defines what that means for each important service.

For example:

Risk appetite is the governance signal.

Impact tolerance is the service-level boundary.

Both are needed.

How KRIs fit into appetite and tolerance

KRIs help monitor whether risk is moving toward or beyond tolerance.

Examples:

A KRI should connect to:

• risk appetite
• tolerance threshold
• owner
• escalation rule
• issue creation
• remediation plan
• dashboard reporting

A KRI without a tolerance is a metric.

A KRI with a threshold and action rule becomes risk management.

How controls fit into appetite and tolerance

Controls are the operating mechanisms that help keep risk within appetite and tolerance.

For example:

• Access reviews help manage cyber and SOX risk.
• Vendor due diligence helps manage third-party risk.
• DPIAs help manage privacy risk.
• Vulnerability remediation helps manage cyber risk.
• Continuity testing helps manage resilience risk.
• AI use-case approval helps manage AI risk.
• Regulatory change impact assessment helps manage compliance risk.
• Management review controls help manage financial reporting risk.

A Connected GRC program should link:

• risk appetite statement
• tolerance threshold
• risk
• control
• evidence
• test result
• issue
• remediation
• dashboard

If controls fail, the organization may move outside tolerance.

If multiple controls fail, the organization may exceed appetite.

This is why control health belongs in risk appetite reporting.

How issues fit into appetite and tolerance

Issues are one of the clearest signals that risk may be moving beyond tolerance.

Examples:

• A high-severity control issue is overdue.
• A critical vendor has unresolved cyber gaps.
• A privacy incident root cause remains open.
• A vulnerability affecting a critical service exceeds SLA.
• A SOX deficiency remains unremediated.
• A BIA gap prevents recovery within impact tolerance.
• An AI governance issue remains open before deployment.
• A regulatory change implementation is delayed.

A Connected GRC program should show:

• which issues affect which appetite statements
• which issues affect which tolerances
• which issues threaten impact tolerance
• which owners are responsible
• which due dates are overdue
• which remediation is validated
• which risk acceptances exist
• which decisions are needed

Issue dashboards should not only show open and closed counts.

They should show whether open issues are pushing risk outside tolerance.

How incidents fit into appetite and tolerance

Incidents test whether risk appetite and tolerance are realistic.

A single incident may not change appetite.

But it may reveal that tolerances are too loose, controls are weak, dependencies are missing, or impact tolerances are unproven.

Incident examples:

• A cyber incident reveals a failed detection control.
• A vendor outage threatens a critical service impact tolerance.
• A privacy incident shows that escalation thresholds are unclear.
• A physical security incident affects a restricted area.
• A crisis event shows decision rights are not defined.
• A financial reporting incident triggers SOX control evaluation.

A connected incident record should show:

• affected risk appetite statement
• affected risk tolerance
• affected impact tolerance
• control failures
• root cause
• issues opened
• remediation actions
• residual risk update

Basel’s operational resilience principles emphasize that organizations should respond, adapt, recover, and learn from disruptive events.  

That learning should flow back into risk appetite, tolerances, impact tolerances, and controls.

Examples across GRC domains

Cyber & IT Risk

• Risk appetite: Low appetite for cyber risk that could compromise customer data or critical services.
• Risk tolerance: Critical vulnerabilities on internet-facing, service-critical systems must not exceed remediation SLA.
• Impact tolerance: Customer-facing digital service must remain within approved disruption tolerance.

Third-Party Risk

• Risk appetite: Moderate appetite for third-party dependency where controls and contractual protections exist.
• Risk tolerance: Critical vendors cannot have unresolved high-risk issues at renewal without approved risk acceptance.
• Impact tolerance: Vendor-supported critical services must remain within defined disruption tolerance.

Privacy

• Risk appetite: Low appetite for privacy incidents involving sensitive personal data.
• Risk tolerance: High-risk processing activities require approved privacy assessment before launch.
• Impact tolerance: Privacy request handling service must remain within required response timeframe during disruption.

SOX / Financial Reporting

• Risk appetite: No appetite for material weaknesses in ICFR.
• Risk tolerance: Key control failures require deficiency evaluation and remediation before closure.
• Impact tolerance: Financial close process must recover before reporting deadlines are threatened.

Operational Resilience

• Risk appetite: Low appetite for disruption to important customer services.
• Risk tolerance: Resilience issues affecting critical services cannot remain overdue beyond threshold.
• Impact tolerance: Each important service has a maximum tolerable disruption level tested through severe but plausible scenarios.

AI Governance

• Risk appetite: Low appetite for unapproved AI use involving sensitive data or regulated decisions.
• Risk tolerance: High-risk AI use cases must complete privacy, cyber, legal, and governance review before deployment.
• Impact tolerance: AI-supported critical workflows must have fallback or manual process when disruption would cause unacceptable harm.

These examples show why all three concepts matter.

Risk appetite sets direction.

Risk tolerance defines operating boundaries.

Impact tolerance defines service disruption boundaries.

The Connected GRC appetite and tolerance map

A Connected GRC program should link appetite and tolerance records to the workflows that make them real.

This map is how appetite becomes operational.

Without these connections, appetite and tolerance remain statements.

With these connections, they become a decision system.

1. Start with business objectives

Risk appetite should connect to business objectives.

Examples:

• grow in a new market
• launch AI-enabled product capabilities
• improve customer digital experience
• reduce operational cost through outsourcing
• maintain financial reporting integrity
• protect customer data
• maintain resilience of critical services
• satisfy regulatory obligations
• improve ESG disclosure readiness

Each objective involves risk.

The organization must decide how much risk it is willing to take to pursue the objective.

COSO’s guidance emphasizes that risk appetite should be linked to strategy and objectives.  

That means appetite should not be written in isolation.

It should support the choices the organization is trying to make.

2. Turn appetite into tolerances

Once appetite is defined, translate it into tolerances.

A broad appetite statement should become measurable thresholds.

Example:

Risk appetite: Low appetite for critical service disruption.

Possible tolerances:

• No critical service may have incomplete dependency mapping.
• Critical service scenario tests must be completed on schedule.
• Failed scenario tests must create issues with remediation plans.
• Critical vendors supporting important services must have current continuity evidence.
• High-severity resilience issues cannot exceed remediation deadline without escalation.
• Incidents threatening impact tolerance require crisis escalation.

This is where risk appetite becomes operational.

The tolerances define what “low appetite” means in daily work.

3. Define limits and triggers

Tolerances should create limits and triggers.

A limit defines the boundary.

A trigger defines the action point.

Example:

• Tolerance: Critical vulnerabilities on customer-facing systems must be remediated within SLA.
• Limit: SLA deadline cannot be exceeded without approved exception.
• Trigger: If vulnerability is 72 hours from SLA breach, notify owner and escalate to CISO.
• Action: Create issue, assign remediation, require closure evidence, escalate if overdue.

This makes the risk process proactive.

The goal is not to wait until appetite is exceeded.

The goal is to act before risk moves too far.

4. Assign owners

Every appetite statement and tolerance should have ownership.

Possible owners include:

• board
• executive committee
• CRO
• CISO
• CCO
• CFO
• general counsel
• business owner
• risk owner
• service owner
• control owner
• vendor owner
• policy owner
• resilience owner

Ownership should be clear at each level:

If ownership is unclear, tolerance breaches become reporting items instead of action items.

5. Connect appetite to dashboards

A risk appetite dashboard should show:

• risk appetite statements
• risks outside appetite
• tolerance breaches
• KRIs above thresholds
• failed key controls
• overdue high-severity issues
• incidents affecting appetite
• accepted risk
• impact tolerance breaches
• remediation status
• validation status
• decisions needed

A dashboard should not only show risk ratings.

It should show where appetite is being approached, exceeded, or accepted.

For example:

This is how GRC dashboards become decision-ready.

6. Connect appetite to risk acceptance

Risk acceptance should be tied to appetite and tolerance.

A risk acceptance should answer:

• What risk is being accepted?
• Which appetite statement applies?
• Which tolerance is being exceeded or waived?
• Why is remediation not occurring now?
• What compensating controls exist?
• Who approved the acceptance?
• How long is acceptance valid?
• When will it be reviewed?
• What evidence supports the decision?
• What would trigger reassessment?

Risk acceptance should not become a way to avoid remediation.

It should be governed, time-bound where appropriate, and visible.

If risk acceptance repeatedly exceeds appetite, the organization has a bigger governance problem.

7. Connect impact tolerance to service maps

Impact tolerance only works if the service is mapped.

A service impact tolerance should connect to:

• service owner
• business processes
• systems
• data
• vendors
• facilities
• people and roles
• controls
• incidents
• vulnerabilities
• continuity plans
• crisis plans
• scenario tests
• issues
• evidence

The FCA expects firms to identify and document the people, processes, technology, facilities, and information needed to support important business services.  

That mapping is what makes impact tolerance practical.

If a service has a tolerance but dependencies are not mapped, the organization cannot know whether it can remain within tolerance.

8. Connect impact tolerance to scenario testing

Impact tolerances need testing.

A scenario test should ask:

• What disruption are we testing?
• Which important service is affected?
• What impact tolerance applies?
• Which dependencies are tested?
• What assumptions are used?
• Did the service remain within tolerance?
• What failed?
• What issues were opened?
• What remediation is required?
• What evidence supports the result?

The Bank of England / PRA / FCA policy materials state that firms and FMIs should test their ability to remain within impact tolerances in severe or extreme but plausible scenarios and use testing to identify vulnerabilities.  

That is the key.

Impact tolerance is not proven by documentation.

It is tested through disruption scenarios.

Common mistakes to avoid

Mistake 1: Using appetite, tolerance, and impact tolerance interchangeably

They are related, but different.

Risk appetite is broad risk-taking guidance.

Risk tolerance is measurable variation.

Impact tolerance is maximum tolerable service disruption.

Mistake 2: Writing risk appetite statements that cannot guide decisions

“Low appetite for risk” is not useful unless it connects to thresholds, controls, KRIs, issues, and escalation.

Mistake 3: Defining tolerances without owners

A tolerance without an owner becomes a dashboard metric.

A tolerance with an owner becomes accountable.

Mistake 4: Setting impact tolerances without mapping dependencies

A service tolerance is not meaningful if the organization does not know which systems, vendors, data, facilities, and people support the service.

Mistake 5: Ignoring controls

Controls help keep risk within appetite and tolerance.

Failed controls should feed appetite reporting.

Mistake 6: Treating incidents as separate from appetite

Incidents are evidence that risk is materializing.

Material incidents should prompt review of appetite, tolerances, impact tolerances, controls, and remediation.

Mistake 7: Reporting thresholds without decisions

A tolerance breach should trigger action.

If the dashboard shows a breach but no decision or escalation, the process is incomplete.

A practical test for your organization

Pick one material risk.

Then ask whether your current GRC model can show:

• the related business objective
• the risk appetite statement
• the risk owner
• the risk tolerance threshold
• KRIs tied to the tolerance
• controls that support the tolerance
• evidence showing control operation
• issues that affect the tolerance
• incidents that changed the risk view
• accepted-risk records
• escalation rules
• dashboard status
• decisions needed

Then pick one important service.

Ask whether your current model can show:

• service owner
• impact tolerance
• dependencies
• supporting systems
• supporting vendors
• critical data
• supporting facilities
• continuity plan
• scenario test results
• incidents affecting the service
• issues threatening the tolerance
• remediation status
• evidence of readiness
• decisions needed

If answering those questions requires risk registers, resilience documents, dashboards, emails, spreadsheets, incident tickets, vendor files, and meetings, appetite and tolerance are not connected enough.

That is common.

It is also the opportunity.

Final thought

Risk appetite, risk tolerance, and impact tolerance are not just terminology.

They are decision tools.

Risk appetite helps leaders define how much risk the organization is willing to take in pursuit of strategy.

Risk tolerance turns that appetite into measurable thresholds and escalation points.

Impact tolerance defines how much disruption an important service can absorb before harm becomes unacceptable.

Connected GRC makes these concepts operational.

It links appetite to risks, risks to tolerances, tolerances to KRIs, KRIs to controls, controls to evidence, evidence to testing, testing to issues, issues to remediation, incidents to lessons, services to impact tolerances, and dashboards to decisions.

That is the practical difference.

Risk appetite sets direction.

Risk tolerance defines boundaries.

Impact tolerance protects service delivery.

All three matter.

And they work best when they are connected.