The Memorandum of Understanding signed in January 2026 between the European Supervisory Authorities and the UK's FCA and PRA is not a diplomatic nicety. It is an operational trigger. Financial entities with operations in both jurisdictions now face coordinated supervisory scrutiny rather than the siloed oversight that previously allowed inconsistencies to hide in the gaps between regulatory regimes. If your cross-border DORA program still runs as two parallel compliance tracks, the margin for that approach just collapsed.
What the MoU Actually Establishes
The cooperation framework creates structured information-sharing arrangements between the ESAs (EBA, EIOPA, and ESMA) and the UK's Financial Conduct Authority and Prudential Regulation Authority. This is not a mutual recognition agreement. Neither side has agreed to accept the other's standards as equivalent. Instead, they have agreed to share supervisory intelligence, coordinate on critical ICT third-party provider oversight, and align incident notification expectations where entities operate across both jurisdictions.
Three provisions matter most for practitioners. First, the MoU enables joint or parallel assessments of ICT third-party providers designated as critical under DORA's oversight framework (Articles 31-44) when those providers also serve UK-regulated entities. Second, it establishes protocols for incident information sharing, meaning a major ICT incident reported to one authority under DORA Article 19 notification requirements will likely reach the other authority within days, not weeks. Third, it creates a consultation mechanism for enforcement actions that could affect entities regulated in both jurisdictions.
The practical implication is stark. Before the MoU, a financial group could operate with meaningfully different ICT risk narratives in London and Frankfurt. That asymmetry is now visible to both sides simultaneously.
Why Cross-Border Fragmentation Was Already a Liability
Even before the MoU formalized information sharing, the fragmentation problem was well understood. Large financial groups typically maintained separate DORA compliance teams for EU entities and operational resilience teams for UK entities, often with different tooling, different provider taxonomies, and different evidence standards. This structure evolved organically: different regulatory timelines (DORA applied from January 2025; the UK's operational resilience framework had its own implementation dates), different terminology, and different supervisory cultures all encouraged local optimization.
The cost of that fragmentation becomes apparent in three scenarios. During a shared ICT provider incident, response coordination stalls because EU and UK teams use different severity classifications and different escalation triggers. During supervisory examinations, inconsistencies in how the same provider is risk-rated across entities undermine the group's credibility. During board reporting, executives receive different risk narratives for what is fundamentally the same dependency exposure.
None of these failures are hypothetical. ENISA's threat landscape data and the ESAs' own incident reporting summaries confirm that cross-border ICT incidents affecting multiple entities in the same group are increasingly common. The supply chain risk patterns documented across 2024-2025 show exactly how shared provider dependencies create correlated failure paths.
The Dual Compliance Challenge: DORA and UK Operational Resilience
DORA and the UK's operational resilience framework share a common intellectual heritage but diverge in structure and emphasis. Understanding where they align and where they diverge is the foundation for any workable cross-border program.
DORA takes a prescriptive, control-based approach. Articles 5-16 specify ICT risk management framework requirements with granular obligations around ICT asset management, encryption, network security, vulnerability management, and business continuity. The regulation prescribes specific content for the ICT risk management framework, specific testing requirements (including TLPT under Articles 26-27), and specific incident reporting timelines with defined notification windows.
The UK framework takes an outcomes-based approach centered on important business services, impact tolerances, and scenario testing. It asks firms to identify their most important business services, set maximum tolerable disruption levels, and test whether they can stay within those tolerances during severe but plausible scenarios.
The overlap is significant but not complete. Both frameworks require firms to understand their third-party dependencies, test their resilience, and manage concentration risk. But DORA demands a register of all ICT third-party arrangements (Article 28(3)) with specific contractual provisions, while the UK framework focuses on mapping dependencies for important business services without prescribing a universal register format. DORA mandates specific TLPT testing for significant entities; the UK requires scenario testing but with more flexibility in methodology.
For groups operating in both jurisdictions, the question is not whether to comply with both, but how to build one operating model that satisfies both without duplicating everything.
Building a Unified Operating Model with Jurisdictional Overlays
The architecture that works is a single core operating model with jurisdiction-specific overlays. Centralize everything that can be centralized. Localize only what regulation or supervisory expectation requires.
Core layer (shared across jurisdictions):
- Unified ICT provider taxonomy and risk rating methodology
- Single evidence standard for control testing (calibrated to the more demanding requirement)
- Common incident classification framework with severity definitions
- Shared asset inventory with consistent criticality assessment
- Group-level third-party risk management policies and concentration risk monitoring
Jurisdiction overlay (localized):
- DORA Article 28(3) register format and contractual clause requirements for EU entities
- UK important business service mapping and impact tolerance definitions
- Notification timelines and authority-specific reporting templates
- Local supervisory engagement protocols and examination preparation
- National transposition variations for NIS2 obligations that intersect with DORA scope
The overlay should be thin. If your EU and UK teams cannot explain the same provider's risk in compatible terms, the core layer is not working. If evidence produced for one jurisdiction cannot be repurposed (with formatting adjustments) for the other, you are duplicating work that should be shared.
Incident Response Under Coordinated Oversight
The MoU's incident information-sharing provisions create the most immediate operational pressure. When a significant ICT incident affects entities in both jurisdictions, the supervisory response will be coordinated. That means your incident response must also be coordinated.
Practically, this requires five capabilities:
-
Single incident record with multi-jurisdiction tagging. One incident should not exist as two separate tickets in two separate systems. Maintain a single incident record with jurisdiction-specific notification tracking attached to it.
-
Harmonized severity classification. If your EU entities classify an incident as "major" under DORA Article 18 criteria while your UK entities classify the same event as moderate under their framework, you will spend supervisory dialogue explaining the inconsistency rather than demonstrating your response capability.
-
Coordinated notification timing. DORA's initial notification window (Article 19) and the UK's notification expectations need to be managed from one timeline. The MoU means one authority will likely know what you reported to the other.
-
Unified root cause analysis. Post-incident reviews that reach different conclusions about the same event in different jurisdictions are a credibility problem that will attract supervisory attention.
-
Cross-entity communication protocols. Decide in advance who coordinates group-level supervisory communication during an incident. Ambiguity here guarantees inconsistency under pressure.
The CTPP and Provider Oversight Dimension
DORA's critical third-party provider (CTPP) designation framework under Articles 31-44 adds another layer to cross-border complexity. When an ICT provider is designated as critical under DORA, it becomes subject to direct oversight by a Lead Overseer (one of the ESAs). The MoU means that oversight intelligence will flow to UK authorities when the same provider serves UK-regulated firms.
For financial groups, this has procurement and concentration risk implications. Provider risk assessments need to account for the regulatory attention a CTPP designation brings. Exit strategies required under DORA need to be credible across all jurisdictions. Concentration risk analysis needs to be performed at the group level, not entity by entity.
The January 2026 CTPP designation list and subsequent updates make this concrete. If your group uses a designated CTPP in both jurisdictions but manages the relationship through separate procurement and oversight processes, the MoU ensures that inconsistency will be visible to both sets of regulators.
Governance Design: The Board and Senior Management Layer
Cross-border oversight coordination is ultimately a governance design decision. Boards and senior management of financial groups need to answer three structural questions:
First, who owns the group-level view of ICT risk? If the answer is "it depends on which entity you ask," the governance structure is not adequate for the post-MoU environment. A single group-level ICT risk function with authority to set standards and resolve conflicts is not optional.
Second, how are trade-off decisions made? When EU and UK requirements conflict (or when resources must be allocated between jurisdictions), there must be a clear decision-making process. This is not a compliance team decision; it requires senior management engagement with documented rationale.
Third, how is supervisory engagement coordinated? With the MoU enabling information sharing, the group needs a coherent supervisory engagement strategy. This means coordinated messaging, consistent risk narratives, and preparation for the reality that supervisors in both jurisdictions will compare notes.
Board-level reporting should reflect the unified operating model. If the board receives separate EU and UK ICT risk reports that tell different stories, the governance gap is at the top, and that is where supervisors will look first.
Quarterly Testing: The Proof Point
The most credible evidence that a cross-border operating model works is regular testing. Run at least one cross-entity scenario per quarter that exercises the interfaces between EU and UK operations.
Scenario design should target the seams: a shared provider outage that triggers incident notification in both jurisdictions; a vulnerability in a component used across entities that requires coordinated patching and exception management; a supervisory information request that requires consistent data from both sides.
The output of these exercises is not a pass/fail score. It is a list of coordination failures that need fixing before they surface during a real event or supervisory engagement.
Key Takeaways
- The MoU eliminates the information gap between EU and UK supervisors. Assume anything reported to one authority will reach the other. Build your operating model accordingly.
- One core model with thin jurisdictional overlays beats two parallel programs. Centralize provider taxonomy, evidence standards, and incident classification. Localize only what regulation specifically requires.
- Incident response coordination is the highest-priority capability to build. A cross-border incident where your EU and UK teams tell different stories is now the fastest path to supervisory concern.
- Concentration risk analysis must be performed at group level. Entity-level assessments that miss group-level provider dependencies will not satisfy post-MoU scrutiny.
- Test the seams quarterly. Run cross-entity scenarios that exercise the interfaces between jurisdictions. The coordination failures you find in testing are the ones that would otherwise surface during incidents or examinations.
Financial groups that invested early in unified compliance platforms rather than jurisdiction-specific point solutions will find the MoU validates their architecture. For everyone else, the window to restructure before coordinated supervisory attention arrives is measured in quarters, not years.