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.\n\nImpact Tolerance vs. RTO:\n\n| Dimension | Recovery Time Objective (RTO) | Impact Tolerance |\n|---|---|---|\n| Focus | Internal system recovery | External harm threshold |\n| Perspective | IT/operations | Consumer/market impact |\n| Metric type | Time to restore system | Maximum acceptable disruption |\n| Scope | Single system | End-to-end business service |\n| Includes dependencies? | Usually no | Yes -- third parties, infrastructure |\n| Regulatory origin | Business continuity planning | Operational resilience frameworks |\n\nSetting Impact Tolerances:\n\nBanks must consider:\n1. Duration -- How long can the service be unavailable before intolerable harm occurs?\n2. Volume -- How many transactions/customers can be affected?\n3. Value -- What monetary threshold of disrupted activity is intolerable?\n4. Data integrity -- How much data loss or corruption is acceptable?\n\nWorked Example:\nCedargrove Bank identifies \"Retail Payments Processing\" as an important business service. The impact tolerance setting process:\n\nStakeholder analysis:\n- Consumers cannot pay bills or receive salaries\n- Merchants cannot process card transactions\n- Potential regulatory fines for payment system disruption\n\nImpact tolerance set:\n- Duration: Maximum 4 hours of complete outage before intolerable consumer harm\n- Volume: No more than 50,000 transactions affected per incident\n- 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.