Digital Operational Resilience Act UK (2026 Guide)
A common post-Brexit scenario looks like this: your group headquarters is in London, but you have an EU-authorized bank or investment firm, an EU payment institution, or an EU insurer somewhere in the EU. Your board asks a deceptively simple question, “Do we need to care about DORA in the UK, or is this purely an EU issue?” The answer is that the digital operational resilience act uk question is rarely about geography. It is about group structures, service delivery, outsourcing chains, and which entity is regulated by which authority.
DORA, the EU Digital Operational Resilience Act (Regulation EU 2022/2554), has applied since January 2025. Even if the UK did not onshore DORA as a UK statute, many UK-based groups and UK ICT providers feel DORA’s practical pull through EU subsidiaries and contracts. This article explains where DORA can affect UK organizations post-Brexit, how it interacts with UK operational resilience expectations, and what governance steps typically reduce duplication without weakening compliance.
If you want a baseline refresher on definitions and why regulators focus on “resilience” rather than only cybersecurity, start with what is digital resilience.
Table of Contents
DORA and the UK: what changed post-Brexit
DORA is an EU regulation. The UK is not required to apply Regulation EU 2022/2554 directly, and “DORA UK” is not a single, unified UK legal regime. That is the starting point.
Here’s the thing: post-Brexit reality does not remove EU regulatory obligations from EU-authorized entities just because their parent sits in the UK. If your EU entity falls within DORA’s scope, you still need DORA-compliant ICT risk management, incident reporting, resilience testing, and ICT third-party risk management. Your UK parent’s policies and tooling may be leveraged, but you still need to meet EU expectations, under EU supervision, for the EU entity.
If you need a DORA basics recap, you can cross-check Dorapp’s supporting explainers such as digital operational resilience act and what is digital operational resilience act.
From a supervisory standpoint, the European Banking Authority (EBA), European Securities and Markets Authority (ESMA), and European Insurance and Occupational Pensions Authority (EIOPA) coordinate technical standards and guidance through the Joint Committee of the ESAs. National Competent Authorities (NCAs) then supervise in practice. Your day-to-day “DORA reality” is often determined by how your NCA interprets governance, evidence quality, and timeliness, within the boundaries of the regulation and RTS and ITS.
Who is in scope and why that matters for UK-led groups
Cross-border confusion often comes from treating DORA as a location-based regulation. What the regulation actually requires is entity-based: DORA applies to “financial entities” in scope under Article 2 of DORA, supervised in the EU, regardless of where the parent company, shared services, or key staff are located.
From a practical standpoint, two scoping decisions tend to drive most “DORA UK” implementation work:
Consider this: you may have a UK parent that believes it has a mature operational resilience framework, but your EU entity still needs to demonstrate DORA-specific governance, artifacts, and reporting. In most cases, that starts with an explicit scope statement for each EU entity, approved under entity-level governance, and maintained as your group structure and technology footprint evolve.
This content is for informational purposes only and does not constitute legal advice. Financial institutions should seek qualified legal or regulatory counsel for institution-specific DORA scoping decisions.
Where DORA can still hit UK-based groups
Most “digital operational resilience UK” questions are really questions about cross-border operating models. DORA can affect UK-based organizations through at least four common pathways.
1) EU-regulated subsidiaries with UK group policies
If you run a UK-led group with one or more EU-regulated financial entities, those EU entities must comply with DORA as supervised entities. In practice, this creates a governance challenge: group-level standards can be reused, but you typically need an EU-entity view of critical functions, ICT dependencies, and reporting thresholds. DORA Article 5 and DORA Article 6 push accountability to management bodies, which means you need clarity on who signs off what, at entity level and at group level.
2) UK entities providing intra-group ICT services to EU entities
Many groups centralize ICT in the UK, for example IAM, SOC operations, core infrastructure, or software engineering. If an EU entity relies on a UK group company as an ICT third-party service provider, DORA’s ICT third-party risk management expectations may shape the contractual and oversight requirements the EU entity imposes. Now, when it comes to DORA Article 28 through DORA Article 44, you are dealing with governance, contracts, exit planning, concentration risk, and ongoing monitoring, not just procurement paperwork.
3) UK vendors supporting EU regulated entities
If you are a UK-headquartered cloud provider, managed security service provider, SaaS provider, or niche fintech platform selling to EU financial entities, your customers may require you to provide evidence and contractual commitments consistent with DORA Article 30. That can materially change your audit support model, incident notification commitments, subcontractor transparency, and even your right-to-audit posture.
4) UK-based risk and compliance functions supporting EU obligations
Even if legal responsibility sits in the EU entity, many groups run second-line risk, third-line audit, and compliance frameworks centrally. In practice, this means UK teams may need to produce DORA-specific artifacts, including a DORA-aligned register of information, mapped control evidence, and documented incident classification decisions that satisfy EU supervisory review.
DORA vs UK operational resilience: where they align and diverge
A frequent misconception is that UK operational resilience compliance automatically “covers” DORA. The reality is overlap, not equivalence. Treating them as identical can create blind spots in evidence and reporting.
Where they generally align
Both DORA and UK operational resilience regimes focus on service continuity and customer harm reduction, especially for critical business services. Both push senior management accountability and expect firms to set tolerances, test capabilities, and learn from incidents.
From an operational standpoint, your existing UK playbooks for BCM, incident management, supplier oversight, and change management can be a strong starting point. You can often reuse taxonomies, risk scoring mechanics, and testing cadences, provided you can demonstrate DORA-specific coverage for the EU entity.
Where they diverge in ways that matter during audits
DORA is more prescriptive in several areas that frequently drive remediation work during DORA gap assessments:
Think of it this way: UK operational resilience often focuses on outcome-based tolerances for important business services. DORA combines outcomes with standardized artifacts and supervisory comparability across the EU.
UK cross-border governance: what supervisors typically expect to see
Cross-border implementation tends to succeed or fail on governance clarity. When your key decision makers, tooling, or operational teams sit in the UK, supervisors still expect the EU entity to demonstrate effective oversight and control under DORA Article 5 and DORA Article 6.
What many compliance teams overlook is that “group governance” can be helpful evidence, but it is rarely sufficient on its own. In supervisory reviews, the questions usually become very specific:
The reality is that the strongest cross-border models document “how the EU entity governs what the UK operates.” This can be done in several ways, subject to your structure and NCA expectations, but it typically includes entity-level approvals, entity-level risk acceptance, and a clear audit trail for key decisions that affect EU critical or important functions.
This content is for informational purposes only and does not constitute legal advice. Financial institutions should seek qualified legal or regulatory counsel for institution-specific governance design under DORA.
Practical implications for UK ICT providers serving EU financial entities
If you are a UK ICT provider, you do not “become subject to DORA” in the same way as an EU financial entity. But you may still experience DORA-driven requirements contractually, because your EU financial entity customers must comply and will transfer requirements downstream.
What many compliance teams overlook is that DORA-driven contract negotiations are not limited to right-to-audit language. EU customers often request practical evidence that you can support their governance and reporting duties, including the ability to identify and manage subcontractors, provide service-level and resilience metrics, and support exit planning.
Contract and oversight topics that typically become non-negotiable
While the exact drafting is a legal matter, the operational reality is that your customer will likely ask for provisions and evidence aligned to DORA Article 30, such as:
Consider this: if your EU customer classifies your service as supporting a critical or important function, the scrutiny goes up. Your onboarding questionnaire, audit support, and resilience evidence become a recurring requirement, not a one-off procurement step.
ICT third-party oversight and the critical ICT provider regime: what UK teams should know
UK teams often focus on Chapter V as a contract remediation exercise. Under DORA, that is only part of the story. DORA also introduces an EU-level oversight framework for critical ICT third-party service providers, involving the European Supervisory Authorities through the Joint Committee, alongside day-to-day supervision of financial entities by NCAs.
Here’s the thing: your EU entity remains responsible for managing ICT third-party risk even if an ICT provider is, or could become, subject to the EU oversight framework for critical providers. In practice, you still need to maintain your own controls for due diligence, risk assessment, monitoring, and exit planning.
For UK-based ICT providers, the key operational implication is that EU customers may request stronger, more standardized evidence, particularly where:
For UK-led groups consuming major cloud or platform services, this also changes internal governance conversations. You may need a repeatable process to assess concentration risk and exit feasibility, not only for external vendors but also for intra-group arrangements that create single points of dependency for EU entities.
This content is for informational purposes only and does not constitute legal advice. Financial institutions and ICT providers should seek qualified legal or regulatory counsel for institution-specific interpretation of Chapter V and related ESA technical standards and guidance.
What to do now: a pragmatic operating model
For compliance and risk leaders, the goal is usually not to build two separate regimes. It is to design a cross-border model where UK practices support EU DORA compliance without losing accountability and traceability.
Step 1: Decide what “DORA scope” means in your group
Start with entity mapping and service mapping. Identify which EU legal entities are in scope, and which ICT services and vendors support their critical or important functions. You need a defensible classification approach, because it drives third-party contract requirements, testing, and governance intensity.
Step 2: Build a single source of truth for EU-required artifacts
In many organizations, the “hard” part of DORA is not writing policies. It is maintaining accurate records across dozens or hundreds of ICT arrangements and keeping evidence current. A structured register of information and a controlled third-party risk process typically reduce friction with supervisors.
One practical approach is to centralize evidence collection while keeping entity-level approvals explicit. A dedicated DORA compliance platform can help here. For example, Dorapp includes a DORApp ROI module designed to manage DORA register-of-information records and generate DORA-oriented exports, and a DORApp TPRM module for third-party risk management and questionnaire automation, with workflow control and audit trail. If you want to understand the “why” behind resilience concepts before designing processes, compare the perspectives in what is digital resilience.
Step 3: Align incident classification logic across UK and EU, then separate reporting
If your group SOC and IR teams sit in the UK, you should still align severity models and decision criteria so EU entities can classify DORA-relevant incidents quickly. In practice, you may run one technical incident process, but two regulatory reporting processes, because the triggers, timelines, and required fields can differ across regulators.
How teams evidence compliance: auditable artifacts that travel across borders
Supervisory conversations tend to become concrete fast. You will be asked to show your current state, your decision-making records, and how you test and improve resilience over time.
The reality is that “we have a policy” is not persuasive unless you can demonstrate operational execution. For UK-led groups, the most reusable artifacts are those that can be produced consistently for each EU entity, with clear ownership and timestamps.
For multilingual groups, you may also face internal communication and training challenges. If you operate in German-speaking markets, you may find it useful to reference internal explainers aligned with local working language, such as digital operational resilience act deutsch and dora digital operational resilience act deutsch, while keeping official supervisory submissions in the required language and format.
Frequently Asked Questions
Is there a “Digital Operational Resilience Act UK” law after Brexit?
Not automatically. DORA is Regulation EU 2022/2554 and applies within the EU legal order. The UK did not become subject to DORA simply by virtue of proximity or market practice. That said, UK-based groups with EU-regulated entities still need those EU entities to comply with DORA, and UK ICT providers may face DORA-derived contractual requirements from EU customers. In practice, “digital operational resilience act uk” usually means managing EU DORA obligations from a UK-led operating model.
Do UK-headquartered financial groups with EU subsidiaries need to implement DORA?
EU subsidiaries that qualify as “financial entities” under DORA must implement DORA within their scope, regardless of headquarters location. Group policies can support implementation, but you should keep entity-level accountability clear, particularly for management body oversight (DORA Article 5 and DORA Article 6), the register of information (DORA Article 28), and incident reporting decisions (DORA Article 17 to DORA Article 23). Supervisors typically expect evidence that the EU entity can govern, approve, and demonstrate resilience outcomes.
Does UK operational resilience compliance cover DORA requirements?
It may cover some outcomes, but it rarely covers DORA end-to-end. DORA includes EU-specific and often more standardized requirements for ICT risk governance, third-party contracting, and reporting artifacts. A common gap is the DORA register of information and the structured incident reporting framework under ITS. Many teams reuse UK resilience testing and BCM structures, then add DORA-specific governance and evidence layers for the EU entity. Validate your approach against your NCA expectations and ESA RTS and ITS.
How does DORA affect UK ICT vendors selling services to EU financial entities?
DORA affects UK ICT vendors mainly through customer requirements. EU financial entities must ensure their ICT contracts and oversight meet DORA Article 30 and related provisions. That can translate into more detailed audit support, subcontractor transparency, resilience metrics, and incident notification commitments. If your service supports a critical or important function, scrutiny typically increases. You should prepare a repeatable evidence pack so you can answer customer questionnaires consistently and reduce repeated bespoke due diligence cycles.
What should a UK-led group standardize across EU entities to reduce duplication?
Standardize the method, not the accountability. In practice, that means a consistent risk taxonomy, shared control catalog, common vendor due diligence questionnaires, and a single evidence repository, while keeping entity-specific sign-offs and reporting lines clear. Harmonize incident classification criteria so the EU entity can make fast DORA decisions, but separate regulatory reporting flows if thresholds differ. A clear internal definition of “critical or important functions” helps avoid inconsistent third-party controls across entities.
What is the biggest DORA-related friction point for cross-border groups?
Data completeness and traceability, especially for ICT third-party arrangements. Teams often discover that vendor lists differ across procurement, IT, and finance, and that intra-group services are undocumented as “third-party” dependencies. Under DORA Article 28 and DORA Article 30, missing fields, unclear service descriptions, and incomplete subcontractor chains can block supervisory readiness. Address this by building a structured register of information and enforcing quality gates for new and renewed contracts.
How should you handle DORA incident reporting if your SOC is in the UK?
Run operational response centrally if that works, but design entity-led regulatory decisioning. Your EU entity needs the ability to classify whether an ICT event is a “major ICT-related incident” under DORA Article 17 and then meet reporting timelines and data requirements under ITS. UK SOC teams should provide the required facts quickly: impacted services, duration, geographic footprint, customer impact, and mitigation actions. Document the decision trail so you can evidence why you did or did not report.
Do UK firms need to perform DORA TLPT?
TLPT under DORA Article 26 is an EU requirement for certain in-scope EU financial entities, typically based on supervisory determination and RTS criteria. A UK parent company is not automatically required to perform DORA TLPT. However, if the EU entity is in scope for TLPT and relies on UK-managed systems, you may need UK stakeholder participation to test end-to-end service paths. Coordinate early on scope, legal permissions, and test rules of engagement to avoid cross-border delays.
What is a practical first deliverable for “DORA UK” readiness work?
A cross-border dependency map that ties EU critical or important functions to ICT services, vendors (including intra-group UK providers), and key subcontractors. This directly supports DORA Article 28 register completeness, DORA Article 29 oversight, and DORA Article 30 contracting upgrades. It also surfaces where UK teams need to provide evidence or operational metrics. Once you can demonstrate a reliable mapping, you can prioritize remediation work based on criticality and concentration risk, rather than treating all vendors equally.
Does DORA apply to UK firms with no EU subsidiary?
In most cases, DORA applies directly to EU-regulated financial entities, not to UK firms simply because they operate in the UK. A UK firm with no EU-authorized financial entity in its group may still feel DORA indirectly if it sells ICT services to EU financial entities, because those customers may impose DORA-aligned contractual and evidence requirements under Chapter V. Whether any additional obligations apply can depend on your contractual role and the services you provide, so you should confirm with qualified legal counsel.
What are the “five pillars” of DORA and do they change for UK-led operating models?
DORA is commonly explained through five core areas: ICT risk management (Chapter II), ICT-related incident management and reporting (Chapter III), digital operational resilience testing (Chapter IV), ICT third-party risk management (Chapter V), and information sharing (Chapter VI). UK-led operating models do not change these obligations for EU entities, but they can change how you implement them, particularly where operational teams sit in the UK while governance and accountability sit in the EU entity.
Is DORA only about cybersecurity?
No. DORA is broader than cybersecurity, even though ICT security is central to it. It focuses on digital operational resilience, including governance, risk management, incident handling and reporting, resilience testing, and third-party oversight. For UK-led groups, this broader scope matters because “security controls” alone usually do not satisfy artifact and governance requirements like the register of information under DORA Article 28 or the contractual provisions under DORA Article 30.
Do UK intra-group ICT services need to be captured in the DORA register of information?
In many group structures, yes, because the EU entity must maintain a register of information on contractual arrangements for ICT services under DORA Article 28. If an EU entity relies on a UK group company for ICT services, that arrangement may need to be recorded with the required level of detail, subject to the structure defined in the applicable ITS and the EU entity’s interpretation with its NCA. This is a common remediation area because intra-group services are often not documented with the same rigor as external outsourcing.
Key Takeaways
Conclusion
The post-Brexit “digital operational resilience act uk” conversation is best handled as a governance and operating model problem, not a question of whether the UK adopted an EU regulation. If you have EU-regulated entities, DORA applies to them, and it will shape how you structure ICT risk management, incident reporting, testing, and ICT third-party oversight. If you are a UK ICT provider, DORA will often arrive contractually, through EU customer demands for audit support, transparency, and resilience evidence.
Your most effective next step is to make the cross-border picture auditable: map EU critical or important functions to ICT services and providers, establish a maintainable register of information, and document decision trails for incidents and third-party risk decisions. If you are evaluating how to operationalize these workflows, you can explore how a dedicated DORA compliance platform like Dorapp structures DORA registers and third-party oversight, or contact the team to understand typical operating models seen across EU-regulated groups.
Over time, the organizations that treat DORA as a continuous execution discipline, rather than a documentation exercise, tend to reduce friction with supervisors and improve resilience outcomes that boards can actually monitor.
Regulatory Disclaimer: This article is provided for informational and educational purposes only. It does not constitute legal advice and should not be relied upon as a substitute for qualified legal or regulatory counsel. DORA compliance obligations vary depending on the nature, scale, and risk profile of each financial entity. Always consult with a qualified legal advisor or compliance professional regarding your specific obligations under the Digital Operational Resilience Act and applicable Regulatory Technical Standards. DORA interpretation and supervisory expectations may evolve as the European Supervisory Authorities (EBA, ESMA, EIOPA) and National Competent Authorities publish additional guidance. This content reflects available information at the time of publication and should be verified against current ESA publications. DORA applies to EU-regulated financial entities as defined under Regulation EU 2022/2554 and should not be assumed to apply outside that scope.
About the Author
Matevž Rostaher is Co-Founder and Product Owner of DORApp. He brings deep experience in building secure and compliant ICT solutions for the financial sector and is positioned by DORApp as an expert trusted by financial institutions on complex regulatory and operational challenges. DORApp’s own webinar materials list him as CEO and Co-Founder of Skupina Novum d.o.o. and CEO and Co-Founder of FJA OdaTeam d.o.o. His articles should carry the voice of someone who understands not just compliance requirements, but the systems and delivery realities behind them.