Operational Resilience: How Financial Firms Meet DORA, SS1/21, and FCA Requirements

Operational resilience is not business continuity by another name. Business continuity asks: "How do we keep operating when something goes wrong?" Operational resilience asks: "What is the maximum disruption we can tolerate before it causes intolerable harm to consumers, market integrity, or financial stability — and can we stay within that tolerance?" The distinction matters because it shifts the focus from internal recovery time to external impact.

For financial firms operating across the EU and UK, three overlapping frameworks now set the operational resilience agenda. This guide maps those frameworks, identifies where they align and diverge, and provides a practical approach for building a single compliance programme.

DORA: The EU's Operational Resilience Framework

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) — DORA — has applied since January 17, 2025. It applies to virtually all regulated financial entities in the EU: credit institutions, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, insurance and reinsurance undertakings, and their critical ICT third-party service providers.

DORA's Five Pillars

1. ICT risk management (Articles 5–16): Financial entities must maintain a comprehensive ICT risk management framework including identification and classification of ICT-supported business functions, protection and prevention measures, detection of anomalous activities, response and recovery capabilities, and backup and restoration policies.
2. ICT-related incident management (Articles 17–23): Classification of ICT-related incidents by severity, mandatory reporting to competent authorities within 4 hours for major incidents (initial notification), with intermediate report within 72 hours and final report within 1 month.
3. Digital operational resilience testing (Articles 24–27): Regular testing of ICT systems including vulnerability assessments, network security testing, and — for significant entities — threat-led penetration testing (TLPT) at least every 3 years, based on the TIBER-EU framework.
4. ICT third-party risk management (Articles 28–44): Due diligence on ICT third-party providers, contractual requirements, concentration risk monitoring, and — critically — the designation of Critical Third-Party Providers (CTPPs) by the ESAs, who face direct oversight.
5. Information sharing (Article 45): Voluntary sharing of cyber threat intelligence and vulnerability information between financial entities.

DORA's Regulatory Technical Standards (RTS)

The ESAs (EBA, ESMA, EIOPA) have published multiple RTS and ITS that provide the operational detail behind DORA's high-level requirements. Key RTS in force include:

• RTS on ICT risk management framework: Detailed requirements for ICT asset management, network security, encryption, access control, ICT operations management, and ICT project and change management
• RTS on incident classification: Materiality thresholds for incident reporting — including criteria based on the number of clients affected, duration of the incident, geographic spread, data losses, and economic impact
• RTS on TLPT: Requirements for threat-led penetration testing scope, methodology, testers' qualifications, and reporting
• RTS on third-party arrangements: Minimum contractual provisions for ICT outsourcing agreements, including exit strategies, audit rights, and sub-outsourcing controls

UK Operational Resilience: SS1/21 and PS21/3

The UK framework — the Bank of England's Supervisory Statement SS1/21 and the FCA's Policy Statement PS21/3 — takes a different but complementary approach. Firms were required to identify important business services and set impact tolerances by March 31, 2022, and to demonstrate they can remain within impact tolerances through severe but plausible scenarios by March 31, 2025.

Important Business Services

The UK framework centres on the concept of "important business services" — services a firm provides to external end users (clients, other market participants, the broader market) where disruption could cause intolerable harm to consumers, market integrity, or the safety and soundness of the firm. This is more outcome-focused than DORA's function-based approach.

Examples of important business services for different firm types:

• Retail bank: Providing access to deposits (ATM, online banking, branch services), processing payments, originating mortgages
• Investment firm: Executing client orders, providing custody services, settlement processing
• Insurer: Processing and paying claims, providing policy administration, managing policyholder communications
• Payment firm: Processing payment transactions, maintaining payment account access

Impact Tolerances

For each important business service, firms must set impact tolerances — the maximum tolerable level of disruption. Impact tolerances are expressed as maximum duration of disruption (e.g., "customers cannot be without access to deposit accounts for more than 24 hours") and may also include volume thresholds ("no more than 5% of daily payment transactions may be affected simultaneously").

Impact tolerances must be set with reference to the harm that disruption would cause to consumers, the firm, and the broader financial system — not by reference to what the firm's current recovery capabilities can achieve. If recovery capabilities don't meet the impact tolerance, the firm must invest to close the gap.

Mapping and Testing

Firms must map the people, processes, technology, facilities, and information that support each important business service, identify vulnerabilities in those dependencies (including third-party dependencies), and test through severe but plausible scenarios that the firm can remain within impact tolerances.

Scenario testing should include: technology failure (complete loss of a primary data centre), third-party failure (a critical cloud provider outage lasting 48+ hours), cyber attack (ransomware encrypting critical systems), people disruption (unavailability of key personnel or entire teams), and facility disruption (loss of access to primary operational premises).

Mapping the Overlaps

For firms subject to both DORA and the UK regime, the good news is substantial overlap. The bad news is that the frameworks use different terminology and have different scopes.

Third-Party Concentration Risk

Both DORA and the UK framework emphasise third-party concentration risk — the systemic risk created when multiple financial institutions depend on the same critical third-party provider. In practice, this means cloud concentration (AWS, Azure, and GCP collectively support the majority of EU and UK financial institutions' cloud infrastructure), market data concentration (Bloomberg, Refinitiv), and payment infrastructure (SWIFT, card networks).

DORA addresses this through the CTPP oversight framework — the ESAs can designate third-party ICT providers as "critical" if their failure would have systemic implications. CTPPs face direct ESA oversight including on-site inspections, remediation orders, and potential penalty payments. The UK approach relies on the PRA's and FCA's existing supervisory powers over regulated firms, requiring them to demonstrate they can substitute or replace critical third-party providers within their impact tolerances.

Practical Implications

For compliance and operational risk teams, third-party concentration risk assessment should include:

• Dependency mapping: Identify all critical third-party providers supporting important business services / critical functions
• Substitutability assessment: For each critical provider, assess the feasibility and timeline of switching to an alternative. If substitution would take longer than your impact tolerance, that's a gap.
• Contractual resilience: Review contracts for audit rights, exit provisions, data portability, sub-outsourcing notification, and disaster recovery SLAs
• Concentration monitoring: Track whether the same provider supports multiple important business services — single-provider failure could cascade across the firm

Building a Single Framework

Multi-jurisdiction firms can — and should — build a single operational resilience framework that satisfies DORA, SS1/21, and PS21/3 simultaneously. Here's how:

1. Start with the UK's broader scope: The UK framework covers all operational disruptions, not just ICT. If you build your framework to cover people, process, technology, facilities, and information, it will encompass DORA's ICT-specific requirements as a subset.
2. Map important business services to DORA critical functions: Your important business services (UK) should map onto your critical or important functions (DORA). Where the mapping isn't 1:1, document the relationship and ensure both frameworks' requirements are met for each service/function.
3. Set impact tolerances that satisfy both regimes: UK impact tolerances (outcome-focused) can be supplemented with DORA-specific RTO/RPO requirements to create a single set of tolerance metrics per service.
4. Unified testing programme: Design scenario tests that satisfy both DORA's TLPT requirements and the UK's severe-but-plausible scenario testing. A comprehensive TLPT exercise can cover both regimes' testing expectations.
5. Single third-party risk framework: Apply the stricter of the two regimes' contractual and oversight requirements to all critical third-party providers. DORA's specific contractual requirements (Article 30) are generally more prescriptive than the UK framework.
6. Incident reporting alignment: Maintain a single incident classification framework that maps to both DORA's reporting thresholds and PRA/FCA reporting requirements. DORA's 4-hour initial notification is the tightest deadline and should drive your process design.

Self-Assessment Documentation

Both DORA and the UK framework require documented self-assessment of operational resilience capabilities. For the UK, firms must produce a self-assessment demonstrating they can remain within impact tolerances for each important business service. For DORA, the ICT risk management framework must be documented and reviewed at least annually.

A well-structured self-assessment document should include: an inventory of important business services / critical functions, impact tolerances and the rationale for their calibration, dependency mapping (people, process, technology, facilities, third parties), vulnerability assessment (where are the single points of failure?), testing results (scenarios tested, outcomes, gaps identified), remediation plan (for any gaps between current capabilities and impact tolerances), and governance and accountability (who owns each service, who is accountable to the board?).

"Operational resilience isn't about preventing all disruptions — it's about ensuring that when disruptions occur, the impact on consumers, markets, and the financial system stays within tolerable boundaries. The firms that understand this distinction build frameworks that actually work."

What's Coming Next

Operational resilience regulation continues to evolve. In 2026 and beyond, firms should monitor:

• DORA CTPP designations: The ESAs' first wave of Critical Third-Party Provider designations is expected in 2026. This will create direct oversight of designated providers, but also create additional reporting and cooperation obligations for the financial entities that use them.
• PRA/FCA review: The UK regulators plan to review firms' operational resilience implementations following the March 2025 compliance deadline. Supervisory findings from this review will shape future expectations.
• Cross-border coordination: As both the EU and UK mature their operational resilience frameworks, cross-border coordination (particularly for incident reporting and CTPP oversight) remains a developing area.
• AI and operational resilience: The EU AI Act's requirements for high-risk AI system resilience will increasingly intersect with DORA requirements for financial entities using AI in critical functions.

RegPulse tracks operational resilience developments across both the EU and UK — DORA RTS updates, ESA guidance, PRA supervisory statements, FCA policy updates, and CTPP designation announcements. For related topics, see our guides on DORA ICT risk management, ISO 31000 risk management, and EBA banking regulation.