DORA Compliance Guide 2026: What UK Financial Firms Must Do Now

DORA compliance cybersecurity means meeting the Digital Operational Resilience Act (Regulation (EU) 2022/2554), which entered into force across EU financial entities on 17 January 2025. If your firm operates in the UK but maintains EU branches, serves EU clients, or provides ICT services to EU-regulated institutions, DORA applies to you directly. Not indirectly. Not eventually. Now.

Most DORA content targets continental European banks or treats UK firms as bystanders. That framing is wrong, and it is costing compliance teams real money in unnecessary duplication or, worse, in gaps they do not know exist. This guide is written specifically for CISOs, CTOs, and compliance officers at UK financial services firms with EU operations. You will find the scope rules, the five core pillars, a practical ICT third-party risk checklist, and a clear map of how DORA aligns with and diverges from the FCA and PRA frameworks you are already operating under.

What DORA Actually Covers (and Who It Catches)

DORA applies to a broad set of financial entities operating within the EU. Article 2 of the regulation lists 21 categories, including credit institutions, investment firms, payment institutions, insurance and reinsurance undertakings, crypto-asset service providers, and data reporting service providers. It also directly captures ICT third-party service providers when designated as critical by the European Supervisory Authorities (ESAs).

The territorial scope is where UK firms get caught. DORA targets institutions that are authorised and regulated within the EU. If your group structure includes an EU-authorised subsidiary, that entity must comply in full. If you provide ICT services to EU-regulated financial institutions as a third-party provider, DORA can require you to establish or designate an EU subsidiary as a primary point of contact with regulators. Cloud providers, managed security service providers, and core banking software vendors serving EU banks are all within scope of this extraterritorial reach.

The July 2024 CrowdStrike outage illustrated precisely why regulators pushed this framework through. A single third-party ICT failure disrupted financial services across multiple jurisdictions simultaneously. DORA exists to ensure that cannot happen without firms having tested, documented, and contractually accountable responses ready.

The Five DORA Pillars: What Each One Demands

DORA structures its requirements around five interconnected pillars. Each pillar carries specific technical standards, most of which are defined through Regulatory Technical Standards (RTS) published by the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA). The RTS release schedule has extended into 2025 and 2026, so staying current is not optional.

Pillar 1: ICT Risk Management Framework

Financial entities must maintain a comprehensive ICT risk management framework that sits at board level. Senior leadership cannot delegate accountability downward to IT departments. The framework must include an ICT strategy aligned with the firm’s overall business strategy, defined risk tolerance levels, asset inventories covering all ICT hardware and software, and documented policies for protection, detection, containment, recovery, and repair.

Critically, the framework must be reviewed at least annually and after any major ICT incident. If you are already running an ISO/IEC 27001 or NIST Cybersecurity Framework programme, you have a foundation to build from, but DORA adds requirements those frameworks do not mandate, particularly around digital operational resilience testing and third-party dependencies.

Pillar 2: ICT-Related Incident Reporting

DORA imposes a three-stage incident reporting timeline. You must submit an initial notification within four hours of classifying an incident as major. An intermediate report follows within 72 hours. A final report is due within one month of the intermediate report. These timelines apply to the competent national authority in the relevant EU member state, not the FCA.

Major ICT incidents are classified using criteria set out in the RTS, including the number of clients affected, the duration of the disruption, and the geographic spread. For UK firms running parallel incident reporting under FCA operational resilience rules, you will need integrated reporting workflows that satisfy both regimes simultaneously. The FCA’s own incident reporting obligations under PS21/3 and SS1/21 share intent with DORA but differ in classification thresholds and submission formats.

Your incident response planning process must account for both reporting tracks if your firm has EU-regulated entities. Building a single classification engine that outputs two report formats is the most practical solution most compliance teams reach after running parallel drills.

Pillar 3: Digital Operational Resilience Testing

DORA requires two tiers of testing. Basic testing applies to all in-scope entities and includes vulnerability assessments, network security assessments, gap analyses, and scenario-based tests. Advanced testing in the form of Threat-Led Penetration Testing (TLPT) applies to significant financial entities on a three-year cycle and must follow the TIBER-EU framework.

TLPT exercises are intelligence-led red team operations targeting the firm’s live production systems. They are materially more demanding than standard penetration tests. The ESAs coordinate with national competent authorities, and results must be shared with regulators. If your firm already runs red team exercises under the FCA’s CBEST framework, those exercises align closely with TLPT methodology, and you may be able to evidence partial equivalence, though formal mutual recognition has not been confirmed as of March 2026.

Pillar 4: ICT Third-Party Risk Management

This pillar generates the most compliance workload for most firms. DORA requires that your institution remains accountable for operational resilience even when ICT services are fully outsourced. You cannot contract your way out of the obligation.

Specific requirements include mandatory contractual provisions covering service level agreements, audit rights, business continuity obligations, sub-contractor transparency, and exit strategy clauses. Enhanced provisions apply when the outsourced services support critical or important functions. You must also maintain a Register of Information covering all ICT third-party arrangements, submitted to regulators in XML or CSV format using the standardised template published by the ESAs in December 2024.

Firms discovered mid-2025 that legacy outsourcing contracts with hyperscalers and core banking vendors often lack the specific DORA audit rights and exit clauses required. Renegotiating those contracts, particularly with providers like AWS, Microsoft Azure, and Google Cloud, took longer than expected. If you have not already reviewed your cloud security contracts for DORA compliance, that review is overdue.

Pillar 5: Information Sharing

DORA creates a voluntary framework for sharing cyber threat intelligence between financial entities. Participation is optional, but the regulation provides legal safe harbours for sharing threat data that would otherwise raise confidentiality concerns. ESMA and EBA are coordinating the trusted communities through which this sharing occurs.

In practice, most large UK financial groups are already participating in information sharing through FS-ISAC (Financial Services Information Sharing and Analysis Center) or sector-specific threat intelligence programmes. DORA formalises and expands this, particularly for EU-coordinated threat intelligence on ICT vulnerabilities affecting multiple financial entities simultaneously.

UK Operational Resilience vs DORA: Where They Align and Where They Diverge

The FCA, PRA, and Bank of England introduced the UK’s operational resilience framework in March 2022, with a final compliance date of 31 March 2025. The Critical Third Parties (CTP) regime, which directly supervises key ICT providers, took effect from 1 January 2025. Both regimes share the same intent as DORA but differ in architecture.

The most material gap for UK firms running dual compliance programmes is the Register of Information. DORA requires a structured, machine-readable register of all ICT third-party arrangements, submitted annually to the competent authority. No equivalent exists under UK rules. If your EU entities are in scope, you need this register built and maintained separately from your UK outsourcing register.

The contractual requirements under DORA Article 30 also go significantly further than the FCA’s existing outsourcing guidance. Exit clauses, sub-contractor disclosure, and ICT provider audit rights must now be explicitly written into contracts, not just implied through service agreements. Many firms found their existing contracts with major ICT providers inadequate when reviewed against Article 30.

ICT Third-Party Risk Management: Practical Checklist

The following checklist covers the minimum requirements your DORA-compliant ICT third-party risk programme must address as of the current regulatory standard. Each item reflects a specific obligation in the regulation or its associated RTS.

Contract Review and Remediation

• Audit all ICT third-party contracts for DORA Article 30 mandatory clauses: service descriptions, data locations, incident response procedures, cooperation obligations, audit rights, and exit terms
• Classify each contract as supporting a critical or important function (enhanced clauses required) or non-critical (standard clauses required)
• Verify that sub-contracting chains are disclosed and that you have the right to audit sub-contractors supporting critical functions
• Confirm that each contract includes a termination-for-cause provision aligned with DORA’s exit strategy requirements
• Document remediation actions and target dates for contracts that cannot be renegotiated before the next regulatory review window

Register of Information Build and Maintenance

• Map all ICT third-party arrangements, including sub-contractors, across all EU-regulated entities in your group
• Classify each arrangement using the ESA standardised taxonomy: critical, important, or other
• Build the register in XML or CSV format using the ESA template published in December 2024
• Establish a quarterly review cycle to capture new arrangements, contract changes, and provider exits
• Test XML submission against the competent authority’s validation rules before the first regulatory submission deadline

Ongoing Provider Monitoring

• Implement risk-tiered monitoring: critical providers require quarterly performance reviews; important providers require semi-annual reviews
• Define concentration risk thresholds and document your assessment of substitutability for each critical ICT provider
• Require annual resilience attestations from critical ICT providers
• Conduct at least one on-site or documented remote audit of each critical ICT provider annually
• Track and escalate any sub-contractor changes by critical providers within 30 days of notification

Exit Strategy and Business Continuity

• Document an exit plan for each critical ICT provider covering data portability, transition timelines, and interim service continuity arrangements
• Test exit scenarios for your top-three critical ICT dependencies at least annually
• Verify that business continuity plans explicitly cover the failure or withdrawal of each critical ICT provider
• Ensure exit plans account for regulatory notification obligations if a critical ICT provider exits the market or is acquired

Running this type of zero trust security architecture review in parallel with DORA third-party risk assessment is efficient because both programmes require you to map ICT dependencies, classify asset criticality, and document access controls at the provider level.

DORA Timeline and Key Deadlines for 2025-2026

DORA entered into force on 16 January 2023 and became applicable on 17 January 2025. The regulatory technical standards governing implementation detail have been released in tranches, and several remain in consultation or pending adoption as of Q1 2026.

The ESAs published the first batch of RTS in January 2024, covering ICT risk management, major incident classification, and the TLPT framework. The second batch, covering the Register of Information format and specific sub-contracting requirements, was published in late 2024. The ESA’s oversight framework for critical ICT third-party providers is being operationalised through 2025, with initial CTP designations expected by mid-2026.

For UK firms, the practical compliance timeline is driven by when your EU-regulated entities come under supervisory scrutiny. National competent authorities across EU member states have indicated that the 2025 supervisory cycle will focus on ICT risk management frameworks and Register of Information completeness. Testing and advanced TLPT requirements will be the priority for 2026 and 2027 supervisory reviews.

The FCA-PRA-Bank of England joint statement from 2024 confirmed that UK regulators are monitoring DORA implementation by dual-regulated firms with EU operations, and that UK firms should not assume the UK CTP regime provides equivalent cover for DORA obligations. The two regimes operate in parallel and must be complied with separately.

AI Systems and Emerging Technology Under DORA

DORA was drafted before generative AI became a mainstream operational dependency for financial services firms. The regulation’s ICT risk management requirements apply to AI systems in the same way they apply to any other ICT service, but the risk profile is materially different in ways that existing compliance frameworks do not fully capture.

AI models operating within financial services firms introduce third-party dependencies that may not appear in your current outsourcing register. If your credit risk models use an API-based large language model, that provider is an ICT third party under DORA. If your fraud detection system depends on a cloud-hosted AI service, that dependency must be documented, classified, and contractually governed.

The AI security risks specific to financial services, including model manipulation, prompt injection, and training data poisoning, all represent ICT risk vectors that your DORA ICT risk management framework should explicitly address. As of March 2026, the ESAs have signalled that AI risk will be a supervisory focus in 2026-2027, and firms that have already mapped their AI dependencies will be substantially better positioned for those reviews.

DORA Compliance: Frequently Asked Questions

Does DORA apply to UK-only financial firms with no EU operations?

No. DORA applies to financial entities authorised under EU law or ICT providers designated as critical to the EU financial sector. A purely UK-based firm serving only UK clients under FCA regulation is not directly in scope of DORA. However, the FCA and PRA have signalled alignment with DORA principles in their own operational resilience frameworks, which became mandatory for all FCA-regulated firms by 31 March 2025.

What happens if a UK firm’s EU subsidiary fails to comply with DORA?

National competent authorities in the relevant EU member state can impose supervisory measures including remediation orders, increased reporting requirements, and public disclosure of non-compliance. For critical ICT third-party providers designated under DORA, the ESAs can impose periodic penalty payments of up to 1% of average daily global turnover for each day of non-compliance, for up to six months. EU-regulated banking subsidiaries can face restriction of their ability to conduct business in extreme cases.

How does DORA interact with NIS2?

The EU’s NIS2 Directive (Network and Information Security Directive 2022/2555) and DORA overlap significantly for financial entities. The EU’s position is that financial entities subject to DORA are treated as having met their NIS2 obligations through DORA compliance, since DORA is considered lex specialis relative to NIS2 for the financial sector. You should not need to run separate NIS2 and DORA compliance programmes for your EU financial entities, but confirm this with local legal counsel as member state transposition varied.

Is the UK CBEST framework equivalent to DORA TLPT?

Not formally. CBEST and DORA TLPT share the same intelligence-led red team methodology and are both based on the TIBER framework. However, there is no mutual recognition agreement between UK regulators and EU supervisory authorities as of March 2026. Firms should document the methodology overlap and present it to their lead overseer, but should not assume full equivalence without explicit confirmation from the competent national authority.

What is the DORA Register of Information and when does it need to be submitted?

The Register of Information is a structured data file covering all ICT third-party service providers and their contractual arrangements with your EU-regulated entity. It uses the standardised ESA template released in December 2024 and must be submitted in XML or CSV format. National competent authorities set submission deadlines at member state level, with most requiring initial submission in 2025 and annual updates thereafter.

Can DORA compliance obligations be outsourced to a third party?

No. Article 28 of DORA states explicitly that financial entities may use ICT third-party service providers but must retain full responsibility for their DORA compliance obligations. You cannot contractually transfer your ICT risk management, incident reporting, or testing obligations to a vendor or managed service provider. Regulatory accountability stays inside your institution.

What to Do in the Next 90 Days

If you are a UK firm that has not yet fully mapped your DORA obligations, the following sequence reflects how most compliance teams are prioritising their work in early 2026. Start with scope confirmation: identify every EU-regulated entity in your group and determine whether you also provide ICT services to EU-regulated financial institutions as a third-party provider. Both trigger DORA obligations separately.

Run your ICT third-party contract review next. The Register of Information obligation means you need a complete inventory before you can build the register, and the contract review will surface gaps that take time to remediate through renegotiation. Prioritise providers supporting critical or important functions, since enhanced contractual requirements apply to those arrangements and they carry the greatest supervisory scrutiny.

Integrate your incident reporting workflows last, but do not underestimate the lead time. Four hours from major incident classification to initial notification is tight, and it requires pre-built templates, pre-designated reporting contacts at the competent authority, and a classification decision tree that does not depend on a management committee convening before you can file. Run a live simulation before you need it in a real incident.

ShieldOperations works with financial services firms to design and test DORA-aligned cybersecurity programmes, incident response playbooks, and ICT third-party risk frameworks. Contact us to discuss your specific scope and gap position.