How does the operational resilience framework address third-party and concentration risk, and what are Impact Tolerance requirements?

Operational resilience is a regulatory framework requiring financial institutions to identify their Important Business Services (IBS), map the resources supporting them (including third parties), set maximum tolerable disruption levels (impact tolerances), and demonstrate the ability to remain within those tolerances during severe but plausible scenarios.\n\nOperational Resilience Framework:\n\n`mermaid\ngraph TD\n A[\"1. Identify Important
Business Services\"] --> B[\"Services whose disruption
would harm consumers, market
integrity, or financial stability\"]\n B --> C[\"2. Map Dependencies\"]\n C --> D[\"People, processes, technology,
facilities, third parties\"]\n D --> E[\"3. Set Impact Tolerances\"]\n E --> F[\"Maximum tolerable duration
and extent of disruption\"]\n F --> G[\"4. Scenario Testing\"]\n G --> H[\"Test ability to remain
within tolerances under stress\"]\n H --> I[\"5. Remediation\"]\n I --> J[\"Close gaps where tolerances
would be breached\"]\n`\n\nThird-Party Risk in Operational Resilience -- Worked Example:\n\nSummitridge Bank identifies 'Retail Payments Processing' as an Important Business Service with an impact tolerance of 4 hours maximum disruption.\n\nDependency mapping reveals:\n- Payment gateway: Operated by Nexuslink (third party)\n- Cloud hosting: Provided by a major hyperscaler\n- Card network connectivity: Via two card networks\n- Fraud screening: Outsourced to Shieldpoint Analytics\n\n| Third Party | Criticality | Substitutability | Recovery Capability | Concentration Risk |\n|---|---|---|---|---|\n| Nexuslink | Critical | Low (18-month migration) | 2-hour failover | 35% UK market share |\n| Cloud hyperscaler | Critical | Very low (24+ months) | Multi-region failover | 40% financial sector |\n| Card Network A | Critical | Moderate (dual routing) | Real-time failover | Systemic utility |\n| Shieldpoint | Important | Moderate (6-month switch) | 8-hour manual fallback | 15% market share |\n\nConcentration Risk Analysis:\n\nThe cloud hyperscaler serves 40% of the UK financial sector. A single outage (as occurred with major cloud providers in 2023) could simultaneously disrupt payments across multiple banks. This is concentration risk at the systemic level -- beyond any single bank's control.\n\nRegulatory Response to Third-Party Concentration:\n\n1. Critical Third Party (CTP) designation: Regulators (UK FCA/PRA, EU DORA) can designate cloud providers and other systemically important third parties as CTPs, subjecting them directly to regulatory oversight\n2. Exit planning: Banks must maintain credible exit plans for all critical third parties, even when practical substitutability is limited\n3. Multi-vendor strategies: Regulators encourage (but cannot mandate) that banks avoid single-provider dependency for critical services\n4. Sub-outsourcing visibility: Banks must map not just their direct vendors but their vendors' vendors (fourth-party risk)\n\nImpact Tolerance Setting:\n\nSummitridge's impact tolerance for Retail Payments: maximum 4-hour disruption affecting no more than 20% of daily transaction volume.\n\nScenario test: Nexuslink suffers a ransomware attack, losing all systems for 72 hours. Can Summitridge remain within tolerance?\n\n- Manual processing capability: 5% of volume (insufficient)\n- Secondary payment gateway: Not yet implemented\n- Result: Tolerance would be breached within 6 hours\n- Remediation: Implement secondary gateway with automated failover by Q3 2026, estimated cost EUR 4.2M\n\nDORA (Digital Operational Resilience Act) Requirements:\nThe EU's DORA regulation (effective January 2025) specifically requires ICT third-party risk management frameworks including contractual provisions for audit rights, exit strategies, incident notification from providers, and concentration risk monitoring at the sectoral level.\n\nStudy operational resilience frameworks in our FRM Part II course materials.