How to Comply With DORA: The Complete 2026 Requirements Checklist

The Digital Operational Resilience Act has applied since 17 January 2025. If you run a bank, insurer, investment firm, payment or e-money institution, crypto-asset service provider, or you sell ICT services into any of them, DORA is a live supervisory obligation today.

This guide sets out what DORA requires, who is in scope, which deadlines have already passed, and a practical checklist to get compliant and stay that way. It was last reviewed on 22 October 2026.

📌 The short answer: how to comply with DORA

DORA is Regulation (EU) 2022/2554. It is directly applicable in every EU member state, so the core rules are the same wherever you operate.

To comply, a financial entity must:

1. Run an ICT risk management framework that is documented, reviewed and owned by the management body (Articles 5 to 16).
2. Classify ICT-related incidents and report major ones to its competent authority on fixed deadlines (Articles 17 to 23).
3. Test its digital operational resilience, including threat-led penetration testing where the authority requires it (Articles 24 to 27).
4. Manage ICT third-party risk, including a register of information and mandatory contract clauses (Articles 28 to 44).
5. Decide on threat intelligence sharing and document that decision (Article 45).

In 2026 supervisors are no longer asking whether you have a policy. They are asking you to show the evidence that it works.

Who is in scope of DORA

Article 2 lists the financial entities DORA applies to. The European Commission estimated the regime would cover more than 22,000 entities across the EU.

The main categories are:

• Credit institutions, payment institutions, account information service providers and electronic money institutions.
• Investment firms, trading venues, central counterparties, central securities depositories and trade repositories.
• Crypto-asset service providers authorised under MiCA, and issuers of asset-referenced tokens.
• Alternative investment fund managers and UCITS management companies.
• Insurance and reinsurance undertakings, insurance intermediaries and institutions for occupational retirement provision.
• Credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, data reporting service providers and securitisation repositories.

DORA also reaches ICT third-party service providers. Cloud platforms, data centres, network providers and financial software vendors feel it through their customers' contracts, and the most important ones are now under direct EU oversight.

Proportionality and the simplified framework

Article 4 requires every rule to be applied in proportion to the entity's size, risk profile and the nature of its services. That shapes how deep your documentation and testing need to go.

Article 16 goes further. It switches off Articles 5 to 15 for a defined group and replaces them with a simplified ICT risk management framework. That group is:

• Small and non-interconnected investment firms.
• Payment institutions and electronic money institutions that are exempted under the payment services and e-money directives.
• Certain credit institutions exempted under the Capital Requirements Directive.
• Small institutions for occupational retirement provision.

Microenterprises get lighter treatment in specific articles, but they do not automatically qualify for Article 16. Even under the simplified regime you still need a documented framework, monitoring, business continuity and incident reporting.

The five pillars of DORA compliance

Every DORA requirement sits under one of five pillars. Use them as the backbone of your programme and your evidence folders.

Pillar 1: ICT risk management (Articles 5 to 16)

This is the foundation. The management body defines, approves and oversees the framework, and it carries ultimate accountability. Board members are expected to keep their ICT risk knowledge current.

The framework needs to cover the full lifecycle:

• Identification: an up-to-date inventory of ICT assets, information assets, business functions and their dependencies, including third parties.
• Protection and prevention: access control, encryption, patching, network security and change management.
• Detection: monitoring that can spot anomalous activity quickly.
• Response and recovery: an ICT business continuity policy plus response and recovery plans.
• Backup and restoration: backup policies and recovery procedures that are actually tested.
• Learning and evolving: post-incident reviews and test findings that feed back into the framework.
• Communication: crisis communication plans for staff, clients and the public.

The framework must be reviewed at least once a year, and after major incidents or supervisory findings. Firms other than microenterprises also need independent internal audit of the framework on a regular basis.

The detailed control expectations sit in the regulatory technical standards on the ICT risk management framework, Commission Delegated Regulation (EU) 2024/1774.

Pillar 2: ICT-related incident management and reporting (Articles 17 to 23)

You need one consistent process to detect, log, classify, escalate and report ICT-related incidents. This is the pillar where firms most often discover gaps under pressure.

Classification. Commission Delegated Regulation (EU) 2024/1772 sets the criteria. They include:

• Clients, financial counterparts and transactions affected.
• Reputational impact.
• Duration and service downtime.
• Geographical spread.
• Data losses affecting availability, authenticity, integrity or confidentiality.
• Criticality of the services affected.
• Economic impact.

In broad terms, an incident is major when it affects critical services and either involves malicious unauthorised access to network and information systems that may lead to data loss, or meets the thresholds for two or more of the other criteria. Recurring incidents with the same apparent root cause can also add up to a major incident.

Reporting deadlines. Commission Delegated Regulation (EU) 2025/301 fixes the clock for major incidents:

1. Initial notification: as early as possible, and within 4 hours of classifying the incident as major, but no later than 24 hours after you became aware of it.
2. Intermediate report: within 72 hours of the initial notification, even if nothing has changed, plus updates once regular activities are recovered.
3. Final report: within one month of the latest intermediate report, including root cause, remediation and impact figures.

If you cannot meet a deadline, you must tell your competent authority without undue delay and explain why. The reporting templates are in Commission Implementing Regulation (EU) 2025/302.

Two further duties are often missed:

• Where a major incident affects clients' financial interests, you must inform those clients without undue delay.
• You may voluntarily notify significant cyber threats to your authority, and where relevant you should tell potentially affected clients about protective steps.

Pillar 3: Digital operational resilience testing (Articles 24 to 27)

Every in-scope entity outside the simplified regime needs a risk-based testing programme. The baseline includes vulnerability assessments and scans, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing and penetration testing.

All ICT systems and applications that support critical or important functions must be tested at least once a year.

Entities identified by their competent authority must also run Threat-Led Penetration Testing (TLPT) at least every three years. TLPT uses real threat intelligence against live production systems, follows the TIBER-EU approach, and must cover critical or important functions, including those outsourced to ICT providers.

TLPT needs months of lead time, qualified testers that meet Article 27, and careful risk controls for production. If you think you might be identified, start planning before the letter arrives.

Pillar 4: ICT third-party risk management (Articles 28 to 44)

DORA treats your ICT vendors as part of your own risk surface. Four obligations dominate this pillar.

1. Strategy and due diligence. You need an ICT third-party risk strategy, pre-contract due diligence, and an assessment of concentration risk before you sign (Articles 28 and 29).

2. The register of information. Every financial entity keeps a register of all contractual arrangements for ICT services, in the format set by Commission Implementing Regulation (EU) 2024/2956.

• The first registers reached the European Supervisory Authorities by 30 April 2025.
• The 2026 cycle used a 31 December 2025 reference date. National authorities set their own entity deadlines (for example 20 March 2026 at the Dutch central bank, and a window from 11 February to 31 March 2026 at Luxembourg's CSSF), then forwarded data to the ESAs.
• Expect an annual cycle. Confirm the 2027 dates with your own competent authority rather than assuming last year's.

3. Contract clauses. Article 30 lists the provisions every ICT contract must contain, such as a clear service description, data location, availability and integrity commitments, assistance during incidents, cooperation with authorities and termination rights. Contracts supporting critical or important functions need more, including full service levels, notice periods, business contingency plans, audit and access rights, participation in TLPT and exit support.

4. Exit strategies. For critical or important functions you must have documented, tested exit plans so you can leave a provider without disruption (Article 28(8)).

Above firm level, the ESAs oversee designated critical ICT third-party providers (CTPPs). The first list, published in November 2025, named 19 providers, including major cloud hyperscalers. Each CTPP has a Lead Overseer, and the ESAs can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover.

Pillar 5: Information and intelligence sharing (Article 45)

DORA allows financial entities to share cyber threat information within trusted communities. Participation is voluntary.

If you join an arrangement, you must notify your competent authority and respect data protection and confidentiality rules. If you do not, record the decision and the reason.

What changed in 2026

DORA itself has not been amended, but the operating picture has moved on since 2025. Keep these points current in your programme:

• Second register cycle completed. Most national authorities ran 2026 submissions in February and March, and the ESAs ran data quality checks afterwards. Registers rejected for errors had to be corrected.
• CTPP oversight is live. Designated providers are now in direct oversight. Expect your largest vendors to come back with updated contract terms and oversight-driven changes.
• Incident reporting guidance. In September 2026 ESMA published operational instructions on DORA incident reporting. They are practical, non-binding instructions, so read them alongside the legal texts, not instead of them.
• Digital Omnibus proposal. On 19 November 2025 the Commission proposed a single incident reporting entry point covering DORA, NIS2, GDPR and other regimes. It is still a proposal, the DORA deadlines are not changed by it, and your current reporting route stays in force until any amendment is adopted and the platform goes live.

✅ Your DORA compliance checklist

Use this as a readiness sweep. Each item maps to one of the five pillars.

1. Confirm your entity type under Article 2 and whether Article 16 applies.
2. Record management body approval of the ICT risk framework, with named accountability.
3. Maintain a current inventory of ICT assets, information assets, functions and dependencies.
4. Map which business functions are critical or important. The strictest rules follow that label.
5. Review the ICT risk framework at least annually and after major incidents.
6. Schedule independent internal audit of the framework.
7. Set incident classification criteria and thresholds in advance, aligned to Delegated Regulation 2024/1772.
8. Name incident responders and decision makers, with out-of-hours contact routes to your regulator.
9. Pre-build report templates that match Implementing Regulation 2025/302.
10. Run a testing programme that covers critical or important systems at least yearly.
11. Confirm with your authority whether TLPT applies, and plan budget and testers if it does.
12. Keep the register of information current as contracts change, not only before submission.
13. Remediate ICT contracts against Article 30, starting with critical or important functions.
14. Document and test exit strategies for critical or important services.
15. Record your decision on threat intelligence sharing.
16. Store evidence for every item where an auditor can retrieve it on demand.

The evidence auditors and supervisors actually ask for

A policy proves intent. Evidence proves operation. In DORA reviews, these are the artefacts that get requested first:

• Board minutes showing approval and challenge of the ICT risk framework and strategy.
• The asset and dependency inventory, with a date it was last reconciled.
• A complete incident log, including incidents you decided were not major and why.
• Backup restoration test results, not just the backup schedule.
• Test reports with tracked remediation of findings.
• The register of information plus a sample of contracts to trace back to it.
• Exit plans with a test or tabletop record.

The most common finding is not a missing document. It is a document nobody can show was reviewed, approved or tested.

Realistic timeline and cost

DORA has applied since January 2025, so for most firms 2026 is about remediation and evidence, not a greenfield build. Here is a realistic view of effort:

• Gap assessment against the five pillars: typically two to six weeks.
• Incident classification and reporting readiness: a few weeks if decision rights and templates are agreed up front.
• Contract remediation: usually the longest workstream, often several months, because vendors have to agree new terms.
• Register of information: heavy the first time, then a recurring data quality task every cycle.
• TLPT: months of preparation and specialist tester fees for identified entities.

The biggest recurring costs are contract renegotiation, testing and the internal effort of keeping evidence current. The quickest way to overspend is to run all of this in spreadsheets and email, where evidence goes stale between reviews.

Common DORA compliance pitfalls

• Treating DORA as an IT project. It is a governance obligation owned by the management body.
• Deciding classification during the incident. That is how firms miss the 4-hour window.
• A register built once and left alone. Data quality failures surface at submission, when it is too late.
• Assuming old contracts are fine. Most predate DORA and lack Article 30 clauses.
• Untested exit plans. An exit strategy that has never been walked through is a hope, not a control.
• Misreading Article 16. Being small does not by itself put you in the simplified regime.
• Running DORA in a silo. It overlaps with NIS2, GDPR and ISO 27001, and duplicated controls create conflicting evidence.

How DORA fits with your other obligations

For financial entities, DORA is the sector-specific regime for ICT risk. It sits alongside, not instead of, your other obligations.

• MiCA: authorised crypto-asset service providers apply DORA on top of MiCA. See our MiCA compliance checklist.
• NIS2: where a sector-specific act like DORA imposes equivalent requirements, those apply instead of the matching NIS2 duties. Our NIS2 compliance checklist explains the interaction.
• ISO 27001: much of Pillar 1 maps onto an ISMS. Start with our ISO 27001 readiness checklist.
• GDPR: an ICT incident involving personal data can trigger both a DORA report and a GDPR breach notification. Align them using our GDPR compliance checklist.

Turn the checklist into an audit-ready programme

DORA rewards firms that can prove what they do, on demand, with current evidence. That is hard to sustain across spreadsheets and shared drives.

RegentComply gives you a ready-made DORA readiness project: the five pillars broken into tracked tasks, evidence attached to each requirement, and recurring reminders for the annual reviews, tests and register updates DORA expects. The platform is free to start, and you only pay for the AI features you choose to use.

👉 See how RegentComply keeps a DORA programme audit-ready: request a demo.

DORA compliance FAQ

When did DORA come into force?

DORA entered into force on 16 January 2023 and has applied since 17 January 2025. The application date is the one that matters, because compliance has been mandatory since then.

Is DORA a regulation or a directive?

DORA is a regulation, Regulation (EU) 2022/2554. It applies directly in every EU member state without national transposition, so the core obligations are the same across the EU.

Who has to comply with DORA?

Financial entities listed in Article 2, including banks, payment and e-money institutions, investment firms, crypto-asset service providers, fund managers, insurers, and market infrastructure. ICT third-party providers are affected through their contracts, and designated critical providers are directly overseen by the European Supervisory Authorities.

What are the DORA incident reporting deadlines?

For a major ICT-related incident: an initial notification within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report.

What makes an ICT incident major under DORA?

Under Delegated Regulation (EU) 2024/1772, an incident is major when it affects critical services and either involves malicious unauthorised access that may lead to data loss, or meets the thresholds for two or more other criteria such as clients affected, duration, geographical spread or economic impact.

What is the DORA register of information?

It is a structured record of every contractual arrangement for ICT services, in the format set by Implementing Regulation (EU) 2024/2956. Firms submit it to their competent authority each year, which forwards it to the European Supervisory Authorities. The 2026 cycle used a 31 December 2025 reference date.

Does DORA apply to small firms?

Yes, but proportionately. Article 16 gives a simplified ICT risk management framework to specific groups such as small and non-interconnected investment firms and exempted payment and e-money institutions. Being a microenterprise does not on its own qualify a firm for Article 16.

What is TLPT and does it apply to my firm?

Threat-Led Penetration Testing is intelligence-led testing of live production systems. It is required at least every three years for entities identified by their competent authority under Article 26. Most smaller firms are not identified, but those that are need months of preparation.

What are the penalties for DORA non-compliance?

Member states set administrative penalties and remedial measures for financial entities, so fines vary by country. For designated critical ICT third-party providers, the ESAs can impose periodic penalty payments of up to 1% of average daily worldwide turnover. Check your national competent authority for the regime that applies to you.

Does DORA replace NIS2 or GDPR?

No. DORA is the sector-specific ICT risk regime for financial entities and takes precedence over equivalent NIS2 requirements, but GDPR and other obligations still apply. A single incident can trigger both DORA and GDPR reporting.

This guide is general information, not legal advice. Always confirm requirements against the official text of Regulation (EU) 2022/2554 on EUR-Lex, the delegated and implementing regulations cited above, guidance from the European Supervisory Authorities, and your national competent authority.