Operational disruptions are not always avoidable. Technology outages, supplier failures, cyber incidents and people-related disruptions can affect even well-prepared organisations. The critical question is how much disruption a business service can withstand before the consequences become unacceptable.
An impact tolerance defines the maximum tolerable level of disruption to an important business service, measured by time and other relevant indicators of harm. It helps organisations translate operational resilience from a broad objective into a measurable boundary for decision-making, scenario testing and recovery planning.
For risk, business continuity, technology, compliance and senior leadership teams, impact tolerances connect customer outcomes to practical operational decisions. They clarify what must be protected, which dependencies matter most, and when a disruption is approaching an unacceptable level.
This guide explains the meaning of impact tolerances, how they differ from risk appetite and recovery time objectives, and how to define, test and govern them. The regulatory discussion focuses on the United Kingdom's Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) approach; applicability depends on the firm's regulatory status and relevant rules.
Quick AnswerAn impact tolerance is the maximum level of disruption an organisation is prepared to tolerate for an important business service before the resulting harm becomes unacceptable. Under the UK financial-services operational resilience framework, in-scope firms set impact tolerances for important business services and test whether they can remain within them during severe but plausible disruptions. A useful tolerance is measurable, linked to customer or market harm, supported by evidence, and reviewed when services, risks or dependencies change.
Key Takeaways- Impact tolerances describe the maximum tolerable disruption to an important business service, not simply the recovery target for a system.
- They should reflect potential harm to consumers, market integrity, safety, financial stability or other relevant outcomes.
- Time can be an important measure, but customer numbers, transaction volumes, financial thresholds or other indicators may also be needed.
- Scenario testing should challenge whether people, processes, technology, facilities and third parties can keep a service within its tolerance.
- Ownership, evidence, escalation and periodic review are essential to keep tolerances meaningful as the business changes.
What Are Impact Tolerances in Operational Resilience?
An impact tolerance is a defined threshold for the disruption a service can withstand before its effects become intolerable.
The concept starts with the service outcome rather than a particular asset or team. An important business service might be making payments, providing access to a bank account, processing an insurance claim or delivering another service whose disruption could cause significant harm. The tolerance sets the boundary that the organisation must understand and test.
Impact tolerances should be specific enough to support a decision. A statement such as “restore the service quickly” is not a tolerance. A more useful formulation identifies a measurable threshold, a period or condition, the population or outcome affected, and the point at which harm becomes unacceptable. The precise measures depend on the service and the organisation's obligations.
In the UK regulatory context, firms in scope identify important business services, set impact tolerances for them, map the people, processes, technology, facilities and third parties needed to deliver them, and test their ability to remain within tolerances under severe but plausible scenarios. Other organisations may use the concept as a resilience practice even where the specific UK rules do not apply to them.
Why Impact Tolerances Matter
Impact tolerances turn resilience planning into a testable question: can the service continue or recover before unacceptable harm occurs?
Without a defined tolerance, teams can optimise for technical recovery while overlooking the real-world consequences of disruption. A system may be restored within an internal service-level target, yet customers may already have missed critical payments, lost access to essential services or experienced a backlog that takes days to clear.
Impact tolerances help leadership prioritise resilience investment. They make it easier to compare the consequences of a prolonged outage, identify dependencies that could breach a service threshold, and decide where redundancy, alternative processes, supplier arrangements or additional capacity are most valuable.
They also improve scenario testing and escalation. When a scenario includes a measurable threshold, the organisation can identify when the service would breach it, what assumptions drive the outcome, and which controls or recovery actions need improvement. This creates a traceable link between risk assessments, business continuity plans, technology recovery, crisis management and investment decisions.
Impact Tolerance vs. Risk Appetite vs. Recovery Time Objective
These concepts are related, but each answers a different management question.
| Concept | Core question | Typical use |
|---|
| Impact tolerance | How much disruption to an important business service can occur before harm becomes unacceptable? | Defines a service-level boundary for resilience assessment and scenario testing. |
| Risk appetite | How much risk is the organisation willing to take to achieve its objectives? | Guides strategic choices and risk-taking across the organisation. |
| Recovery Time Objective (RTO) | How quickly should a system, process or activity be restored after disruption? | Supports recovery design and continuity planning for specific resources or processes. |
| Maximum Tolerable Period of Disruption (MTPD) | How long can an activity be disrupted before the consequences become unacceptable? | Supports business impact analysis and continuity planning; terminology and application vary by framework. |
An RTO is often set for a technology service or process. An impact tolerance applies to the important business service and considers the harm that can accumulate across multiple components. Several systems may each meet their own recovery targets while the end-to-end service still fails to meet its impact tolerance.
Key distinctionDo not assume that an RTO automatically equals an impact tolerance. Recovery targets should support the service-level tolerance, but the organisation must test the full service, including workarounds, capacity constraints, dependencies and downstream backlogs.
Impact Tolerances Under the UK Regulatory Framework
The FCA and PRA operational resilience framework establishes expectations for relevant regulated firms; it should not be presented as a universal legal requirement for every organisation.
Under the UK framework, in-scope firms identify their important business services, set impact tolerances for those services, map the resources needed to deliver them, and perform scenario testing to assess whether they can remain within the tolerances. The focus is on preventing intolerable harm to consumers and risks to market integrity, rather than merely demonstrating that individual systems can be restored.
The FCA's operational resilience materials and Handbook rules set out requirements for firms within scope. The PRA also has requirements for firms it supervises. The implementation transition period for relevant firms ended on 31 March 2025. Firms should consult the current rules and supervisory materials applicable to their permissions, sector and circumstances rather than relying on a general summary.
Regulatory expectations emphasise meaningful, service-specific measures and credible testing. Time may be a key measure, but it may not capture the full impact of a disruption. For example, the number of affected customers, missed transactions, financial exposure or the inability to access a critical service may be important indicators. A firm should be able to explain why its selected threshold is appropriate and how it is monitored.
The framework does not prescribe one universal tolerance for every service. Firms need to use their own analysis of potential harm, business model, customer needs and relevant obligations. A tolerance should be supported by evidence and governance, not selected solely because it matches the current capabilities of an IT system.
How to Define Impact Tolerances
A defensible tolerance begins with service outcomes and ends with a threshold that can be tested, owned and reviewed.
Step 1: Identify the important business service
Describe the service from the perspective of the customer, market or other recipient. Avoid defining it too narrowly as an application or internal department. Establish the service boundary, the users who depend on it, the expected outcome and the consequences if it is disrupted.
Step 2: Assess potential harm
Consider how disruption could affect consumers, vulnerable customers, counterparties, market integrity, financial stability, safety, legal obligations and the organisation's wider commitments. Assess harm over time and across different customer groups. Document assumptions and distinguish direct effects from secondary effects such as delayed transactions or accumulated work.
Step 3: Select meaningful measures and thresholds
Choose measures that reflect the service's potential harm. These may include duration, affected users, unprocessed transactions, financial value, service availability or a combination of indicators. Define the unit, measurement method, time window and threshold clearly enough that different teams would interpret it consistently.
Step 4: Map dependencies and capabilities
Map the people, processes, technology, information, facilities and third parties needed to deliver the service. Include dependencies that may be hidden behind suppliers, shared infrastructure, identity services, data feeds or manual workarounds. Assess whether the service can remain within tolerance when one or more of these dependencies is unavailable.
Step 5: Test severe but plausible scenarios
Use scenarios that challenge assumptions, such as a prolonged technology outage combined with staff unavailability or a critical supplier failure. Estimate how quickly the tolerance could be breached, what actions are available, and whether those actions work at realistic volumes. Record evidence, limitations and remediation actions.
Step 6: Approve, document and maintain
Assign a named service owner and obtain approval through the organisation's governance process. Record the rationale, evidence, assumptions, monitoring indicators, escalation triggers and review date. Revisit the tolerance when the service, customer profile, regulatory environment, architecture or dependency landscape changes.
Which Metrics Should Organisations Use?
The right metric is the one that captures the potential harm to the service recipient, not simply the one that is easiest to measure.
Duration is often useful because harm may increase as a disruption continues. However, a time-only threshold can conceal the difference between a minor interruption affecting a small group and a short outage affecting a large share of customers. Organisations should consider whether additional measures are needed to describe severity and scale.
DurationHow long the service is unavailable, degraded or unable to meet a critical outcome.
Customers or users affectedThe number, proportion or category of customers who cannot access the service or experience harm.
Transaction volume or valueThe volume or financial value of payments, claims, orders or other critical transactions delayed or disrupted.
Backlog and recovery capacityThe number of unprocessed items and the time required to return to normal service after restoration.
Service quality or critical functionWhether a service is available but unable to deliver an essential outcome, such as secure authentication or accurate processing.
Customer-specific harmWhether vulnerable customers or time-critical needs require additional indicators or escalation triggers.
Define how each measure will be collected and who is responsible for monitoring it. If data is incomplete, record the limitation and establish a plan to improve it. Avoid thresholds that depend on data the organisation cannot obtain during a real incident.
Practical Examples of Impact Tolerances
Examples can illustrate the method, but actual thresholds must be determined for each organisation and service.
Illustrative example onlyThe following scenarios are hypothetical and are not regulatory thresholds or recommendations. They show how a service owner might connect a tolerance to measurable customer or operational outcomes.
Payments service
A payments service owner might assess how a disruption affects the ability to initiate, receive or process time-critical payments. Relevant indicators could include duration of disruption, the number and value of delayed transactions, and the backlog remaining after restoration. The tolerance should reflect the harm caused by missed deadlines and the organisation's obligations, not simply the time needed to restart a payment platform.
Digital banking access
For a digital banking service, the organisation might measure the duration and scale of customer access problems, with separate consideration for customers who need urgent access to funds. Testing should consider dependencies such as authentication, telecommunications, cloud hosting and customer support capacity. Restoring the login page alone may not restore the end-to-end service if customers cannot complete essential transactions.
Insurance claims
An insurer might assess whether a disruption delays urgent claims or prevents customers from receiving time-sensitive support. Possible measures include the number of claims delayed, the age of the oldest urgent claim and the time required to clear a backlog. A tolerance should reflect differences in urgency and customer impact rather than treating every claim as equivalent.
How to Test Impact Tolerances
Testing should show whether the complete service can stay within tolerance during a severe but plausible disruption, and reveal where assumptions fail.
Begin with a scenario that challenges a material dependency or capability. Define the disruption, duration, affected resources, constraints and expected service demand. Involve service owners and relevant technology, operations, risk, business continuity, crisis management and supplier teams. Where appropriate, include customer communications, manual workarounds and decision-making under pressure.
Measure performance against the selected tolerance throughout the scenario. Consider not only the moment of initial failure but also degraded operation, workaround capacity, restoration, reconciliation and backlog clearance. A service may return online quickly while still taking an unacceptable period to process accumulated work.
Document what the test demonstrated, which assumptions were not evidenced, and which actions are required. Assign owners and due dates to remediation. Retest material weaknesses and report residual exposure to the appropriate governance forum. Tabletop exercises can test decisions and coordination, but technical or operational claims may also require simulation, recovery exercises, supplier evidence or end-to-end testing.
Common Mistakes to Avoid
A tolerance is useful only when it represents real harm, can be measured and influences decisions.
Using an IT recovery target as the service toleranceSystem recovery is one input; the end-to-end service and its customers must be considered.
Choosing an arbitrary thresholdDocument the evidence, rationale, customer outcomes and assumptions behind the limit.
Measuring time alone when it is insufficientAdd indicators for scale, severity or the type of harm where these materially change the outcome.
Ignoring dependencies and workaroundsTest the capacity and availability of staff, suppliers, facilities, data and manual processes.
Testing only ideal conditionsUse severe but plausible scenarios and challenge compound failures, resource constraints and realistic demand.
Failing to act on test findingsTrack remediation to closure, escalate unresolved exposure and retest material gaps.
How to Govern and Review Impact Tolerances
Clear accountability and repeatable evidence keep tolerances useful after the initial assessment.
Each important business service should have a clear owner responsible for maintaining the service definition, rationale, metrics, dependency mapping and test evidence. Risk and resilience teams can provide methodology and challenge, while technology, operations, procurement and business teams maintain evidence for their respective capabilities. Senior management should receive a view of whether services can remain within tolerance and what remediation is outstanding.
Governance should define escalation triggers, exception handling, reporting frequency and approval authority. Where a scenario or incident indicates that a tolerance may be breached, decision-makers need to know who can activate continuity arrangements, prioritise limited capacity, communicate with customers and engage critical suppliers.
Review tolerances after material changes such as new products, mergers, major technology changes, supplier transitions, changes in customer behaviour or incidents that reveal previously unrecognised harm. Keep version history and record why thresholds were changed. A tolerance should not be relaxed merely because current capabilities cannot meet it; any proposed change should be justified against the harm analysis and applicable requirements.
How autoResilience Supports Impact Tolerance Management
A structured resilience platform can help teams connect service information, risk assessments, continuity plans, testing evidence and remediation.
Impact tolerance management depends on coordinated information across business and technology functions. Business Continuity Management (BCM) capabilities can support the planning and governance activities that contribute to resilience, while teams retain responsibility for defining service-specific tolerances and meeting applicable obligations.
Centralised service and continuity informationMaintain accessible records that support service-level planning and response.
Risk and dependency visibilityConnect assessments and relevant dependencies to the services they may affect.
Documented plans and responsibilitiesKeep continuity procedures, owners and escalation information organised for review.
Testing and action trackingRecord exercise outcomes, weaknesses, owners and remediation progress.
Governance and reporting supportHelp teams prepare consistent information for management oversight and periodic review.
Platform capabilities should be mapped to the organisation's operating model and evidence requirements. Software supports the process; it does not decide which services are important, determine acceptable harm, or guarantee regulatory compliance.
Best PracticeUse a traceable chain from service definition to harm analysis, tolerance, dependency mapping, scenario results and remediation. This makes it easier to explain why a tolerance exists and what evidence shows the service can remain within it.
Frequently Asked Questions
What is an impact tolerance in simple terms?
It is the maximum level of disruption an organisation can tolerate for an important business service before the consequences become unacceptable. It should be expressed in measurable terms and reflect the service's potential impact on customers, markets or other relevant outcomes.
Are impact tolerances mandatory for every business?
No. The specific UK operational resilience rules apply to firms within the relevant regulatory scope. Other organisations may adopt impact tolerances as a useful resilience practice, but they should not assume that the FCA or PRA requirements apply to them without checking their regulatory position.
What is the difference between an impact tolerance and an RTO?
A Recovery Time Objective is a recovery target usually set for a system, process or activity. An impact tolerance defines the maximum tolerable disruption to an important business service and the harm associated with that disruption. RTOs should support the tolerance, but meeting an RTO alone does not prove that the end-to-end service stayed within tolerance.
Can an impact tolerance be measured only in time?
Time can be an important measure, but it may not fully describe the scale or severity of harm. Depending on the service, organisations may also need measures such as customers affected, delayed transactions, financial value, backlog or the loss of an essential function.
How do organisations set an appropriate tolerance?
They define the service, assess potential harm, choose meaningful and measurable indicators, document the rationale, map dependencies and test severe but plausible scenarios. The tolerance should be supported by evidence and approved through the organisation's governance process.
What does severe but plausible scenario testing mean?
It means testing credible disruption scenarios that are serious enough to challenge the organisation's resilience assumptions. Scenarios may involve technology failure, supplier disruption, staff unavailability or combined events. The aim is to assess whether the service can remain within its tolerance and identify gaps that require action.
How often should impact tolerances be reviewed?
Review frequency should be defined by governance and relevant requirements. Tolerances should also be revisited after material changes to services, customers, technology, suppliers or risks, and when incidents or tests reveal that assumptions or thresholds may no longer be appropriate.
Who should own an impact tolerance?
A named owner for the important business service should be accountable for its definition and ongoing review, supported by risk, resilience, technology, operations and supplier teams. Governance should clarify who approves thresholds, monitors indicators, escalates potential breaches and oversees remediation.
Impact tolerances are most valuable when they connect the consequences of disruption to measurable service outcomes. They give leaders a way to prioritise resilience work, challenge recovery assumptions and assess whether critical services can withstand severe but plausible events.
For a stronger operational resilience programme, keep service definitions, harm analysis, dependency mapping, scenario evidence and remediation connected. Explore autoResilience to see how structured business continuity and risk workflows can support that work.
Written by Shambhavi Singh
Marketing Executive at Ascent Risk & Resilience
Shambhavi Singh is a Marketing Executive at Ascent Risk & Resilience, where she contributes to brand communication, content strategy, and digital storytelling across the organization's risk and resilience solutions. With a background spanning content writing, voice-over artistry, anchoring, public speaking, and social impact, she brings both creativity and clarity to every message she crafts.
Shambhavi's passion for communication started early in her hometown of Varanasi, where her curiosity for culture and heritage shaped her worldview. Driven by a blend of will and skill, she is committed to building meaningful connections, leading with empathy, and contributing to initiatives that create positive change.