| Key Takeaways |
| The UK (FCA/PRA) framework takes a holistic, outcomes-based approach covering all disruption types, while DORA is prescriptive and focused specifically on digital/ICT operational resilience. |
| UK rules center on important business services (IBS) and impact tolerances; DORA is built around five pillars: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. |
| Both frameworks converged on 2025 compliance deadlines: UK firms by 31 March 2025, DORA-regulated entities by 17 January 2025. |
| DORA grants European supervisory authorities direct oversight over critical ICT third-party providers; the UK achieves similar coverage through the Critical Third Party (CTP) regime under SS6/24. |
| Firms operating across both jurisdictions can build a unified compliance program by mapping overlapping requirements and addressing jurisdiction-specific gaps. |
| DORA penalties can reach 2% of annual worldwide turnover or up to 1 million euros for individuals; UK regulators retain unlimited fining powers. |
| Organizations embedding both frameworks into their enterprise risk management programs gain resilience advantages beyond mere compliance. |
Financial services organizations operating across the UK and EU face a dual regulatory challenge. The FCA and PRA’s operational resilience framework requires firms to identify important business services, set impact tolerances, and demonstrate they can stay within those tolerances during severe disruptions.
The EU’s Digital Operational Resilience Act (DORA) mandates comprehensive ICT risk management, incident reporting, resilience testing, third-party oversight, and information sharing across 20 categories of financial entities.
Both frameworks reached critical compliance milestones in 2025, creating urgency for cross-border firms to understand exactly where they overlap and where they diverge.
The stakes are significant. DORA non-compliance can trigger fines of up to 2% of annual worldwide turnover, while UK regulators retain unlimited fining powers under the Financial Services and Markets Act.
Beyond penalties, operational disruptions in financial services carry direct economic costs: Splunk and Oxford Economics (2024) report that Global 2000 companies lose 9% of annual profits to downtime, including both direct costs and cascading customer impact.
This guide provides a structured, side-by-side comparison of the FCA/PRA operational resilience framework and DORA.
Each section examines a specific dimension of the two regimes, supported by comparison tables, worked examples, and practical recommendations for organizations managing dual compliance. By the end, you will have a clear map of where efforts can be consolidated and where jurisdiction-specific work is unavoidable.
Figure 1: Regulatory timeline comparing UK operational resilience milestones (FCA/PRA) with DORA implementation dates across 2021-2026.
Origins and Regulatory Philosophy
The UK and EU frameworks emerged from the same concern (financial sector resilience to operational disruption) but took materially different design approaches. Understanding these philosophical differences is essential for interpreting specific requirements correctly.
The UK framework, published in March 2021 through PRA SS1/21 and FCA PS21/3, adopts an outcomes-based approach.
Regulators defined the goal (firms must remain within impact tolerances for important business services during severe disruptions) and left firms significant discretion in how they achieve that outcome.
The framework deliberately covers all types of disruption: cyber attacks, technology failures, pandemics, natural disasters, supplier failures, and internal operational breakdowns.
This breadth reflects the PRA and FCA’s experience with events like the TSB IT migration failure, pandemic disruption, and third-party outages.
Organizations already managing business continuity under ISO 22301 will recognize the all-hazards philosophy.
DORA, published in December 2022 as EU Regulation 2022/2554, takes a rules-based, prescriptive approach focused specifically on digital operational resilience.
The regulation specifies detailed requirements for ICT governance structures, incident classification taxonomies, testing frequencies, third-party contract clauses, and register-of-information submissions.
This prescriptiveness reflects the EU’s regulatory tradition and the specific concern that financial sector dependence on a small number of ICT providers creates systemic concentration risk.
DORA applies to 20 categories of financial entities, from banks and insurers to crypto-asset service providers, creating the broadest scope of any operational resilience regulation globally.
| Dimension | UK (FCA/PRA) | EU (DORA) |
| Regulatory approach | Outcomes-based: define the goal, firms choose the method | Rules-based: prescriptive requirements with detailed technical standards |
| Resilience scope | All-hazards: cyber, technology, people, premises, third party, pandemic | Digital/ICT-focused: technology, cyber, data, ICT third parties |
| Core concept | Important Business Services (IBS) and impact tolerances | Five pillars: ICT risk management, incident reporting, testing, third-party risk, information sharing |
| Proportionality | Built-in: firms apply rules proportionate to size and complexity | Tiered: simplified requirements for smaller entities, enhanced for systemically important firms |
| Legislative form | Supervisory statements (SS1/21, SS6/24) and policy statements (PS21/3) | EU Regulation (directly applicable) with Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) |
| Enforcement authority | FCA and PRA with unlimited fining powers | National competent authorities with EU-wide coordination; fines up to 2% turnover or EUR 1M for individuals |
The Five Pillars of DORA Explained
DORA is structured around five interconnected pillars that together form a comprehensive digital resilience framework.
Each pillar carries specific requirements that financial entities must implement. Understanding these pillars is the starting point for any gap analysis against the UK framework.
Figure 2: The five pillars of the Digital Operational Resilience Act (DORA), each with specific regulatory requirements for EU financial entities.
| Pillar | DORA Requirement | UK Equivalent | Gap Analysis |
| 1. ICT Risk Management | Comprehensive ICT risk management framework with governance, identification, protection, detection, response, and recovery procedures | Covered broadly under operational risk management and SS1/21 mapping requirements, but not ICT-specific at this granularity | UK firms need to formalize ICT-specific governance and procedural documentation to DORA standards |
| 2. Incident Reporting | Mandatory classification, initial notification within 4 hours, intermediate and final reports to national competent authority | Existing FCA/PRA incident reporting (SUP 15), but less prescriptive on timelines and classification taxonomy | Significant gap: DORA mandates stricter timelines and a harmonized classification taxonomy |
| 3. Resilience Testing | Basic testing annually; advanced threat-led penetration testing (TLPT) every 3 years for significant entities | Scenario testing within impact tolerances required; CBEST framework available but not universally mandated | Moderate gap: UK has testing infrastructure but lacks DORA’s mandatory TLPT cadence for all significant firms |
| 4. Third-Party Risk | Register of information on ICT third-party providers; direct ESA oversight of critical third-party providers (CTPPs) | CTP regime (SS6/24) gives PRA/FCA oversight of designated critical third parties; firms must manage third-party concentration | Strong overlap: both regimes address third-party concentration risk with direct regulatory oversight mechanisms |
| 5. Information Sharing | Voluntary arrangements for sharing cyber threat intelligence among financial entities | No formal equivalent in UK operational resilience rules; CISP and sector-specific sharing exist separately | Minor gap: UK has informal mechanisms but lacks DORA’s explicit legal framework for threat intelligence sharing |
UK Operational Resilience: Core Requirements
The FCA/PRA framework centers on three core requirements that firms must meet: identifying important business services, setting impact tolerances, and performing important business services mapping and testing to demonstrate the firm can remain within those tolerances during severe disruptions.
These requirements apply to banks, building societies, PRA-designated investment firms, insurers, recognized investment exchanges, enhanced-scope senior managers and certification regime (SM&CR) firms, and FCA-regulated firms.
| Requirement | What Firms Must Do | Evidence of Compliance |
| Identify IBS | Catalogue all services delivered to external customers/markets. Apply materiality filter: would disruption cause intolerable harm to consumers, threaten market integrity, or endanger firm viability? | Documented IBS register with service descriptions, customer segments, business owners, and harm assessments |
| Set impact tolerances | Define maximum tolerable disruption per IBS measured by time, volume, and customer harm. Reference severe-but-plausible scenarios. Align with board-approved risk appetite. | Impact tolerance schedule approved by the board. Scenario documentation. Evidence of calibration against historical incidents. |
| Map and test | Map all resources (people, processes, technology, data, third parties) supporting each IBS. Test ability to remain within tolerances through progressive exercises: desktop, simulation, live. | Dependency maps per IBS. Test plans and results. Remediation registers for tolerance breaches. Evidence of lessons-learned integration. |
| Governance and self-assessment | Board ownership of operational resilience. Annual self-assessment. Integration with risk management and business continuity programs. | Board minutes. Self-assessment reports. Evidence of integration with ERM framework and BCP program. |
The UK framework deliberately avoids prescribing how firms should structure their ICT risk management, incident response, or testing programs.
This flexibility is both a strength (allows proportionate implementation) and a challenge (less regulatory certainty about what constitutes compliance).
Organizations building their compliance programs should anchor their approach in enterprise risk management frameworks and the three lines model to ensure governance clarity.
Side-by-Side Comparison: Key Dimensions
The following table provides the most granular comparison of FCA/PRA operational resilience and DORA requirements across twelve operational dimensions. Organizations can use this as a gap analysis template to identify where their current compliance program satisfies both regimes and where additional work is needed.
Figure 3: Comparative depth of regulatory requirements across eight operational resilience dimensions. The UK scores higher on IBS mapping, impact tolerances, and non-ICT disruptions. DORA leads on ICT risk management, incident reporting, third-party oversight, and information sharing.
| Dimension | UK (FCA/PRA) | EU (DORA) |
| Scope of entities | Banks, insurers, investment firms, exchanges, enhanced SM&CR firms, FCA solo-regulated firms | 20 entity types: banks, insurers, investment firms, payment institutions, crypto-asset providers, data reporting providers, and more |
| Definition of resilience | Ability to prevent, adapt to, respond to, recover and learn from operational disruptions | Ability to build, assure and review operational integrity from a technological perspective |
| Service identification | Important Business Services (IBS): external services whose disruption causes intolerable harm | Critical or important functions: functions whose failure would materially impair financial performance, compliance, or service continuity |
| Impact measurement | Impact tolerances: maximum tolerable disruption per IBS (time, volume, harm) | No direct equivalent; uses risk-based testing thresholds and incident severity classification |
| ICT governance | General governance expectations; no ICT-specific governance structure mandated | Dedicated ICT risk management framework; management body must approve ICT strategy, policies, and business continuity plans |
| Incident reporting | SUP 15 material incident reporting; no harmonized classification or timeline | Mandatory classification taxonomy; initial notification within 4 hours for major incidents; intermediate and final reports required |
| Testing requirements | Scenario testing within impact tolerances; progressive sophistication expected | Annual basic testing; TLPT every 3 years for significant entities using TIBER-EU framework |
| Third-party oversight | CTP regime (SS6/24): PRA/FCA designate and oversee critical third parties | Register of information (RoI) on all ICT third-party providers; ESAs directly oversee designated CTPPs |
| Concentration risk | Firms must assess concentration risk in third-party dependencies | Explicit requirements to assess substitutability and avoid excessive dependence on single providers |
| Information sharing | No formal framework in operational resilience rules | Legal framework for voluntary cyber threat intelligence sharing arrangements |
| Proportionality | Firms apply rules proportionate to nature, size, complexity | Simplified ICT risk management for smaller entities; enhanced requirements for systemically important firms |
| Extraterritorial reach | Applies to UK-regulated entities; CTP regime can cover international providers serving UK firms | Applies to EU-regulated entities; CTPP oversight extends to non-EU providers serving EU financial entities |
Third-Party Oversight: CTP vs CTPP Regimes
Both frameworks recognized that financial sector resilience depends heavily on a small number of technology providers.
Both created mechanisms for direct regulatory oversight of critical providers, but the design and scope differ. Organizations managing third-party risk across both jurisdictions need to understand these distinctions.
| Feature | UK CTP Regime (SS6/24) | DORA CTPP Oversight |
| Designation authority | HM Treasury designates CTPs on recommendation from regulators | ESAs designate CTPPs based on systemic importance criteria and register-of-information analysis |
| Oversight mechanism | PRA and FCA issue rules, gather information, and conduct on-site inspections of designated CTPs | Lead Overseer (assigned ESA) conducts assessments, issues recommendations, and can request remediation plans |
| Scope of providers covered | Third-party providers designated as critical to UK financial stability | ICT third-party service providers assessed as critical to EU financial entities |
| Enforcement powers | Regulators can direct CTPs to take action; non-compliance is a regulatory breach | Lead Overseer can issue recommendations; NCA enforcement for non-compliance; periodic penalty payments up to 1% daily worldwide turnover |
| Contractual requirements | Firms must include resilience provisions in CTP contracts | Mandatory contract clauses covering SLAs, audit rights, exit strategies, subcontracting, and data location |
| Register/reporting | Firms must maintain oversight records on CTP dependencies | Mandatory Register of Information (RoI) submitted to NCAs/ESAs by 30 April 2025 and annually thereafter |
Resilience Testing: Approaches Compared
Testing is where both frameworks demand tangible evidence of resilience capability. The approaches share common ground (both expect scenario-based testing) but differ in prescriptiveness, frequency mandates, and testing methodology.
The scenario analysis and stress testing discipline underpins both regimes.
| Testing Aspect | UK (FCA/PRA) | EU (DORA) |
| Basic testing | Firms must test ability to remain within impact tolerances; progressive sophistication expected over time | All entities must perform annual ICT testing: vulnerability assessments, network security, gap analysis, software reviews |
| Advanced testing | No universal mandate; CBEST available for systemic firms; PRA expects increasing test sophistication | Mandatory TLPT (Threat-Led Penetration Testing) every 3 years for significant entities; must follow TIBER-EU or equivalent |
| Scenario design | Severe-but-plausible scenarios tailored to each IBS; firms choose scenarios with board approval | Scenarios must cover range of ICT risks; regulators may specify scenarios for TLPT exercises |
| Third-party inclusion | Testing should cover third-party dependencies where material to IBS delivery | CTPPs must participate in TLPT; pooled testing arrangements allowed for entities sharing same CTPP |
| Reporting | Test results feed into self-assessment; shared with supervisors on request | Test results reported to NCA; TLPT results shared with Lead Overseer for CTPP exercises |
Figure 4: Comparative enforcement power and prescriptiveness across five dimensions. DORA leads on mandatory incident reporting and threat-led penetration testing; the UK regime has broader CTPP oversight through direct regulatory designation.
Building a Dual Compliance Strategy
Organizations regulated in both the UK and EU can avoid duplicating effort by building a unified compliance program anchored in shared requirements.
The strategy involves three layers: a common foundation of overlapping requirements, jurisdiction-specific modules for divergent obligations, and an integrated governance structure that satisfies both regulators.
Common Foundation (Satisfies Both)
| Compliance Area | How to Consolidate |
| Governance and board oversight | Establish a single operational resilience steering committee with board-level sponsorship. Document governance arrangements that satisfy both PRA/FCA expectations and DORA ICT governance requirements. |
| Service/function identification | Map IBS (UK) and critical/important functions (DORA) in a single exercise. Use the broader UK definition as the baseline and tag functions that also meet DORA criteria. |
| Dependency mapping | Build end-to-end dependency maps covering all five resource dimensions (people, processes, technology, data, third parties). These maps serve UK IBS mapping and DORA ICT dependency requirements simultaneously. |
| Third-party risk management | Maintain a single third-party risk register covering all providers. Include DORA-mandated contract clauses and UK resilience provisions in all ICT contracts. |
| Scenario testing | Design a unified testing program that covers impact tolerance testing (UK) and ICT resilience testing (DORA) using common scenarios adapted for jurisdiction-specific requirements. |
UK-Specific Additions
Beyond the common foundation, UK-regulated firms must address: impact tolerance calibration per IBS (DORA has no direct equivalent), non-ICT disruption scenarios (premises loss, pandemic, key-person absence), and self-assessment reporting to PRA/FCA supervisors.
These elements require distinct workstreams but can leverage dependency maps and governance structures already built for the common foundation. Organizations should integrate these requirements into their risk management lifecycle and risk assessment process.
DORA-Specific Additions
EU-regulated entities must additionally address: the Register of Information (RoI) submission to national competent authorities, DORA’s prescriptive incident classification and reporting timelines (4-hour initial notification), mandatory TLPT every three years for significant entities, and the information-sharing framework.
The RoI is particularly resource-intensive: it requires detailed documentation of all ICT third-party relationships, including subcontracting chains.
Organizations with mature GRC frameworks can extend existing vendor management databases to produce the RoI.
Key Risk Indicators for Dual-Framework Compliance
Monitoring compliance health across both frameworks requires a consolidated KRI set. The following indicators cover both UK and DORA requirements and should be integrated into the organization’s KRI dashboard.
Understanding KRI vs KPI distinctions helps ensure these metrics drive action, not just reporting.
| KRI | Framework Coverage | Green | Amber | Red |
| IBS impact tolerance test pass rate | UK (primary), DORA (supporting) | > 95% | 80-95% | < 80% |
| ICT incident reporting within 4 hours | DORA (primary) | 100% | 90-99% | < 90% |
| TLPT completion rate (3-year cycle) | DORA (primary) | On schedule | 1-3 months delayed | > 3 months delayed |
| Register of Information completeness | DORA (primary) | > 98% fields populated | 90-98% | < 90% |
| Third-party SLA breach rate | Both frameworks | < 2% | 2-5% | > 5% |
| Dependency map currency (days since update) | Both frameworks | < 90 days | 90-180 days | > 180 days |
| Non-ICT scenario test coverage | UK (primary) | All IBS tested annually | 75-99% coverage | < 75% coverage |
| Board resilience report frequency | Both frameworks | Quarterly+ | Semi-annual | Annual or less |
Implementation Roadmap
The following roadmap targets organizations building or aligning a dual-compliance operational resilience program. Adapt durations to organizational complexity.
| Phase | Actions | Deliverables | Success Metrics |
| Days 1-30: Assessment | Perform gap analysis against both frameworks. Map existing IBS register and DORA critical functions inventory. Identify overlapping and divergent requirements. Assess current third-party documentation against RoI requirements. | Gap analysis report. Unified service/function inventory. RoI readiness assessment. Dual-compliance project plan. | Gap analysis completed. 80%+ of services mapped to both frameworks. RoI data gaps quantified. |
| Days 31-60: Build | Consolidate dependency maps to serve both frameworks. Draft impact tolerances (UK) and ICT risk management documentation (DORA). Update third-party contracts with DORA mandatory clauses. Design unified testing program. | Consolidated dependency maps. Impact tolerance schedule. Updated contract templates. Unified test plan. RoI draft submission. | Dependency maps cover all five dimensions. Impact tolerances set for 100% of IBS. Contract clause compliance at 90%+. |
| Days 61-90: Test and Govern | Execute first round of consolidated testing. Submit RoI to NCA (if applicable). Prepare board resilience report covering both frameworks. Establish ongoing governance cadence and KRI monitoring. | Test results report. Submitted RoI. Board resilience pack. KRI dashboard. Governance terms of reference. | Testing completed for all critical services/functions. RoI submitted on time. Board report delivered. Quarterly review cycle launched. |
Challenges and How to Avoid Them
| Pitfall | Root Cause | Remedy |
| Running two separate compliance programs | UK and DORA teams operate independently, creating duplicate governance, duplicate mapping, and inconsistent terminology | Appoint a single operational resilience lead with dual-framework mandate. Build one dependency map and governance structure that serves both. |
| Treating DORA as ICT-only | DORA assigned entirely to IT/CISO without business ownership of critical functions and risk governance | Ensure business-line ownership of critical function identification. DORA governance requirements demand management body involvement, not just IT. |
| Ignoring non-ICT scenarios in UK program | Over-focus on technology risk (influenced by DORA) causes UK firms to under-test for pandemic, premises, and people disruptions | Maintain a balanced scenario library covering technology, people, premises, third-party, and systemic disruption categories for UK IBS testing. |
| Under-investing in the Register of Information | RoI treated as a one-time data collection exercise rather than an ongoing asset management process | Build RoI as a living database integrated with vendor management. Automate data refresh from procurement and contract management systems. |
| Confusing impact tolerances with RTOs | Teams set impact tolerances using existing RTO/RPO data without recalibrating for customer harm and market impact | Redefine tolerances from the customer perspective. Use incident data, customer complaints, and scenario modeling to calibrate harm thresholds. |
| Neglecting TLPT planning | Significant entities delay threat-led penetration testing until the regulatory deadline approaches, leaving insufficient time for procurement and red-team engagement | Plan TLPT 12+ months in advance. Pre-qualify testing providers. Coordinate with CTPPs for pooled testing where applicable. |
Looking Ahead: Convergence Trends for 2025-2027
Regulatory convergence between the UK and EU frameworks will accelerate over the next two years.
The Basel Committee’s Principles for Operational Resilience, Australia’s CPS 230, and Singapore’s MAS Business Continuity Management Guidelines all share structural similarities with the FCA/PRA and DORA approaches.
Organizations that invest in a flexible, modular compliance architecture today will find it progressively easier to onboard new jurisdictional requirements as they emerge.
Technology-enabled compliance is becoming the baseline expectation. Regulators increasingly expect firms to demonstrate automated dependency mapping, real-time KRI monitoring, and machine-readable regulatory reporting.
The DORA Register of Information requirement is an early signal of this trend: regulators want structured, queryable data about operational resilience, not narrative documents. Firms investing in ERM technology platforms that support both frameworks natively will gain a significant efficiency advantage.
Third-party oversight will intensify. Both the UK CTP regime and DORA CTPP oversight framework are in their early implementation phases. As regulators gain experience, expect more prescriptive requirements around concentration risk, exit planning, and substitutability testing.
The financial sector’s dependence on a small number of cloud providers, payment processors, and data vendors makes this an area of sustained regulatory focus.
Organizations should proactively strengthen their third-party risk management programs beyond minimum compliance to build genuine resilience against provider failure or disruption.
Need help navigating dual-framework compliance? Visit riskpublishing.com for comparison frameworks, gap analysis templates, and expert risk management consulting services tailored to cross-border operational resilience programs.
References
1. PRA SS1/21 – Operational Resilience: Impact Tolerances for Important Business Services – PRA supervisory statement on IBS and impact tolerances.
2. FCA PS21/3 – Building Operational Resilience – FCA policy statement on operational resilience requirements.
3. EU Regulation 2022/2554 – Digital Operational Resilience Act (DORA) – Full text of the EU DORA regulation.
4. ESMA – Digital Operational Resilience Act (DORA) – ESMA’s DORA guidance and technical standards.
5. Bank of England – SS6/24 Critical Third Parties – UK critical third-party oversight framework.
6. PwC – Comparing International Expectations on Operational Resilience – Cross-jurisdictional comparison of resilience frameworks.
7. K&L Gates – Digital Operational Resilience: EU and UK Update – Legal analysis of DORA and UK framework alignment.
8. Sidley Austin – UK Operational Resilience Rules: 31 March 2025 – Practical guidance on UK compliance deadline readiness.
9. White & Case – Operational Resilience in UK, EU and US: A Comparison – Multi-jurisdictional regulatory comparison.
10. ISO 22301:2019 – Business Continuity Management Systems – International BCM standard referenced by both frameworks.
11. Basel Committee – Principles for Operational Resilience (BCBS d516) – Global principles underpinning both UK and EU approaches.
12. EIOPA – Digital Operational Resilience Act – EIOPA implementation guidance for insurers.
13. Splunk/Oxford Economics – The Hidden Costs of Downtime (2024) – Research on financial impact of operational disruptions.
14. IBM – What Is the Digital Operational Resilience Act? – Overview of DORA requirements and compliance considerations.
Chris Ekai is a Risk Management expert with over 10 years of experience in the field. He has a Master’s(MSc) degree in Risk Management from University of Portsmouth and is a CPA and Finance professional. He currently works as a Content Manager at Risk Publishing, writing about Enterprise Risk Management, Business Continuity Management and Project Management.