What are impact tolerances in operational resilience, and how do banks set them for critical business services?

Impact tolerances define the maximum level of disruption a bank is willing to accept for each important business service before the disruption causes intolerable harm to consumers, market integrity, or financial stability. Unlike traditional disaster recovery metrics (RTO/RPO), impact tolerances are outcome-focused and set from the perspective of external stakeholders.

Impact Tolerance vs. RTO:

Dimension	Recovery Time Objective (RTO)	Impact Tolerance
Focus	Internal system recovery	External harm threshold
Perspective	IT/operations	Consumer/market impact
Metric type	Time to restore system	Maximum acceptable disruption
Scope	Single system	End-to-end business service
Includes dependencies?	Usually no	Yes -- third parties, infrastructure
Regulatory origin	Business continuity planning	Operational resilience frameworks

Setting Impact Tolerances:

Banks must consider:

1. Duration -- How long can the service be unavailable before intolerable harm occurs?
2. Volume -- How many transactions/customers can be affected?
3. Value -- What monetary threshold of disrupted activity is intolerable?
4. Data integrity -- How much data loss or corruption is acceptable?

Worked Example: Cedargrove Bank identifies "Retail Payments Processing" as an important business service. The impact tolerance setting process:

Stakeholder analysis:

• Consumers cannot pay bills or receive salaries
• Merchants cannot process card transactions
• Potential regulatory fines for payment system disruption

Impact tolerance set:

• Duration: Maximum 4 hours of complete outage before intolerable consumer harm
• Volume: No more than 50,000 transactions affected per incident
• Value: No more than $25 million in delayed payments\n\nMapping dependencies:\n- Core banking system (internal)\n- Payment network gateway (third party -- Clearstream Processing)\n- Cloud hosting provider (third party -- Nimbus Cloud)\n- Telecommunications (third party)\n\nScenario testing:\n\n| Scenario | Duration | Transactions Affected | Within Tolerance? |\n|---|---|---|---|\n| Data center failover | 45 minutes | 12,000 | Yes |\n| Cloud provider outage | 6 hours | 180,000 | No |\n| Cyberattack on payment gateway | 3 hours | 95,000 | No |\n| Software deployment failure | 20 minutes | 3,000 | Yes |\n\nThe cloud provider and payment gateway scenarios breach impact tolerances, requiring Cedargrove to invest in:\n- Multi-cloud redundancy\n- Alternative payment routing capabilities\n- Enhanced cyber response procedures for critical third parties\n\nRegulatory Framework (UK/EU/US):\n- UK PRA/FCA: Banks must remain within impact tolerances by March 2025\n- EU DORA: Digital Operational Resilience Act sets similar requirements for ICT risk\n- US OCC/Fed: Interagency guidance on operational resilience aligns with UK principles\n\nKey Exam Points:\n- Impact tolerances are not zero-disruption targets -- they acknowledge that disruptions will occur\n- The board is responsible for setting impact tolerances, not IT\n- Testing must use severe but plausible scenarios, including third-party failures\n- Remediation plans must close gaps between current resilience and impact tolerance requirements\n\nStudy operational resilience in our FRM Part II materials.