DORA Compliance Checklist: 59 Requirements by Article (Free Template, 2026)

The Digital Operational Resilience Act (DORA) is the EU's new regulation ensuring that financial entities can withstand, respond to, and recover from ICT-related disruptions. If you are a smaller financial firm — a payment institution, a niche investment firm, a regional insurer, or a crypto-asset service provider — DORA applies to you. And it has been in effect since January 2025.

This guide cuts through the complexity to give you a practical path to compliance, proportionate to your size. Not sure where you stand? The free DORA compliance tool scores the five pillars in about ten minutes and lists your gaps; this checklist is then the article-by-article list to work through.

Does DORA apply to your firm?

DORA applies to virtually all regulated financial entities in the EU, including credit institutions, payment institutions, e-money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, fund managers, central counterparties, trade repositories, crowdfunding platforms, and data reporting service providers.

If you hold a financial licence in an EU member state, assume DORA applies unless you fall under one of the narrow exclusions in Article 2(3) (for example, some very small insurers and occupational pension funds). ICT providers are not regulated as financial entities, but their contracts with financial clients must meet DORA's requirements, and providers that the European Supervisory Authorities (ESAs) designate as critical ICT third-party providers are overseen directly by them. The ESAs published the first list of 19 designated providers on 18 November 2025, including major cloud and IT service companies.

Smaller firms get some relief, but it is narrower than often assumed. The simplified ICT risk management framework in Article 16 applies only to specific entities: small and non-interconnected investment firms, payment and electronic money institutions exempted under the payment services and e-money rules, institutions exempted under the Capital Requirements Directive, and small occupational pension funds. It is not available to every microenterprise. Microenterprises (fewer than 10 staff and no more than €2M annual turnover or balance sheet) benefit from lighter requirements in specific articles instead. Either way, you still need a documented ICT risk framework and you still report major incidents.

Check your readiness: Use our free DORA compliance tool (39-question checker) to assess your current posture across all 5 pillars.

The DORA checklist

The 59 items below follow the structure of Regulation (EU) 2022/2554 (DORA) and its technical standards. Two labels show where the regulation itself narrows the scope:

Not for microenterprises the article applies to financial entities "other than microenterprises" (fewer than 10 staff and annual turnover or balance sheet of no more than €2M).
Not for simplified-framework entities the article excludes the entities listed in Article 16(1), such as small and non-interconnected investment firms and exempted payment and e-money institutions.

Those Article 16(1) entities do not apply sections 1 and 2 (Articles 5 to 15) at all. They follow the simplified ICT risk management framework of Article 16 and Title III of Delegated Regulation (EU) 2024/1774 instead; sections 3 to 6 still apply to them, apart from the items labelled above.

0 of 59 done

Your ticks are saved in this browser only. Nothing is sent anywhere.

1. Governance (Article 5)

The management body defines, approves, oversees and is responsible for the ICT risk management framework. Art. 5(2)
Clear roles and responsibilities are set for all ICT-related functions. Art. 5(2)(c)
The management body sets and approves the digital operational resilience strategy, including the ICT risk tolerance level. Art. 5(2)(d)
The management body approves and periodically reviews the ICT business continuity policy and the ICT response and recovery plans. Art. 5(2)(e)
The management body approves and periodically reviews the ICT internal audit plans. Art. 5(2)(f)
A budget for digital operational resilience, including security awareness and training, is allocated and reviewed. Art. 5(2)(g)
The management body approves the policy on the use of ICT services from third-party providers, and has reporting channels on those arrangements and on major incidents. Art. 5(2)(h)–(i)
A role monitors ICT third-party arrangements, or a member of senior management is designated for it. Art. 5(3) Not for microenterprises
Management body members follow regular training to understand and assess ICT risk. Art. 5(4)

2. ICT risk management framework (Articles 6–14)

A documented ICT risk management framework covers strategies, policies, procedures, protocols and tools protecting all information and ICT assets, including premises and data centres. Art. 6(1)–(2)
The framework is reviewed at least yearly (periodically for microenterprises), after major ICT-related incidents, and after supervisory, testing or audit findings. Art. 6(5)
ICT risk is managed and overseen by a control function with appropriate independence (three lines of defence or an equivalent model). Art. 6(4) Not for microenterprises
The framework is regularly audited by auditors with ICT expertise, and critical audit findings follow a formal remediation process. Art. 6(6)–(7) Not for microenterprises
A digital operational resilience strategy sets the ICT risk tolerance, information security objectives with KPIs and risk metrics, and the ICT reference architecture. Art. 6(8)
ICT-supported business functions, roles, information assets and ICT assets are identified, classified and documented, and reviewed at least yearly. Art. 8(1)
An inventory of all information and ICT assets exists (including remote sites and network resources), critical assets are mapped, and so are their configurations and interdependencies. Art. 8(4), 8(6)
All processes that depend on ICT third-party providers are documented. Art. 8(5)
Sources of ICT risk, cyber threats and vulnerabilities are identified continuously; risk scenarios are reviewed at least yearly. Art. 8(2)
A risk assessment is carried out on every major change to systems or processes, and on legacy ICT systems at least yearly. Art. 8(3), 8(7) Not for microenterprises
A documented information security policy protects the availability, authenticity, integrity and confidentiality of data. Art. 9(4)(a)
The network is managed so that connections can be severed or segmented instantly to stop contagion. Art. 9(4)(b)
Physical and logical access is limited to what legitimate, approved functions require, with sound administration of access rights. Art. 9(4)(c)
Strong authentication is in place, cryptographic keys are protected, and data is encrypted based on classification and risk assessment. Art. 9(4)(d)
ICT changes are recorded, tested, assessed, approved, implemented and verified under a documented change management process. Art. 9(4)(e)
Documented policies for patches and updates exist. Art. 9(4)(f)
Detection mechanisms have alert thresholds and automatic alerts to incident response staff, and are regularly tested. Art. 10(1)–(2)
An ICT business continuity policy and ICT response and recovery plans exist, based on a business impact analysis (BIA). Art. 11(1)–(3), 11(5)
Business continuity and response and recovery plans are tested at least yearly and after substantive changes; crisis communication plans are tested. Art. 11(6)
Continuity tests include cyber-attack scenarios and switchovers to redundant capacity, backups and facilities. Art. 11(6) Not for microenterprises
A crisis management function exists to manage internal and external crisis communications. Art. 11(7) Not for microenterprises
A backup policy sets the scope and minimum frequency of backups by criticality; restoration procedures exist and are tested periodically; restores on own systems use ICT systems segregated from the source. Art. 12(1)–(3)
Recovery time and recovery point objectives are set for each function. Art. 12(6)
Redundant ICT capacities are maintained (microenterprises assess whether they need them). Art. 12(4) Not for microenterprises
Post-incident reviews follow every major ICT-related incident that disrupts core activities. Art. 13(2)
Senior ICT staff report to the management body at least yearly on lessons learned and recommendations. Art. 13(5)
ICT security awareness and digital operational resilience training are compulsory for all staff, including senior management. Art. 13(6)
Crisis communication plans and communication policies exist, and at least one person handles public and media communication on incidents. Art. 14

3. Incident management and reporting (Articles 17–19)

An ICT-related incident management process is in place with early warning indicators, roles per incident type, escalation and communication plans. Art. 17(1), 17(3)
All ICT-related incidents and significant cyber threats are recorded, and root causes are identified and addressed. Art. 17(2)
Incidents are classified with the Article 18(1) criteria and the materiality thresholds of Delegated Regulation (EU) 2024/1772. Art. 18; RTS 2024/1772
Major incidents are reported to senior management, and the management body is informed of their impact, response and new controls. Art. 17(3)(e)
Initial notification to the competent authority within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it (if classified as major later, within 4 hours of that classification). Art. 19(4); RTS 2025/301 Art. 5
Intermediate report within 72 hours of the initial notification; final report within one month of the latest intermediate report. Art. 19(4); RTS 2025/301 Art. 5
Clients are informed without undue delay when a major incident affects their financial interests. Art. 19(3)

4. Digital operational resilience testing (Articles 24–26)

A risk-based digital operational resilience testing programme is established, maintained and reviewed. Art. 24(1), 24(3) Not for microenterprises
Tests are carried out by independent parties, internal or external, without conflicts of interest. Art. 24(4) Not for microenterprises
Procedures exist to prioritise, classify and fix all issues found in tests, and to validate the fixes. Art. 24(5) Not for microenterprises
All ICT systems and applications supporting critical or important functions are tested at least yearly. Art. 24(6) Not for microenterprises
Tests are chosen from the Article 25 range (vulnerability scans, network security assessments, scenario-based tests, penetration tests and others). Art. 25(1), 25(3)
If the competent authority identifies the entity: threat-led penetration testing (TLPT) at least every 3 years. Art. 26(1) Not for microenterprises Not for simplified-framework entities

5. ICT third-party risk (Articles 28–30)

A strategy on ICT third-party risk is adopted and reviewed, including a policy on ICT services supporting critical or important functions. Art. 28(2) Not for microenterprises Not for simplified-framework entities
A register of information on all contractual arrangements for ICT services is maintained, using the templates of Implementing Regulation (EU) 2024/2956, distinguishing services that support critical or important functions. Art. 28(3); ITS 2024/2956
The competent authority receives a yearly report on new ICT arrangements, and is told in time about planned arrangements for critical or important functions. Art. 28(3)
Before contracting: assess criticality, supervisory conditions, risks including concentration risk, due diligence on the provider, and conflicts of interest. Art. 28(4), 29
Contracts can be terminated in the Article 28(7) cases (significant breach, evidenced weaknesses, loss of supervisory access, and others). Art. 28(7)
Exit strategies, and documented and tested exit plans, exist for ICT services supporting critical or important functions. Art. 28(8)
Every ICT contract contains the Article 30(2) elements: service description, data and service locations, data protection, data return on exit, service levels, incident assistance, cooperation with authorities, termination rights, training participation. Art. 30(2)
Contracts for critical or important functions also contain the Article 30(3) elements: precise service levels, notice duties, provider continuity plans and security, TLPT participation, unrestricted audit and access rights, and a mandatory exit transition period. Art. 30(3)

6. Information sharing (Article 45, voluntary)

If you join a cyber threat information-sharing arrangement, the competent authority is notified of your membership (and when it ends). Art. 45(3)

Need to work through this with evidence and owners? The DORA Compliance Checklist pack ($34) contains a gap-assessment workbook, an ICT incident classification matrix, an ICT risk management framework template and a third-party ICT provider register, as editable Excel and Word files.

The 5 pillars of DORA compliance

Pillar 1: ICT Risk Management

You need a documented ICT risk management framework approved by your management body. For smaller firms, this does not need to be a 100-page document. At minimum it should cover your ICT asset inventory (what systems and data you have), your risk assessment process (what threats you face and how you address them), your protection measures (encryption, access control, endpoint security), and your detection mechanisms (how you would know if something goes wrong).

The management body must approve this framework and take accountability for it. This is not something you can fully delegate — DORA places the responsibility squarely on the board or equivalent governing body.

Pillar 2: ICT Incident Management

DORA requires a formal incident management process with classification criteria. The critical compliance point is the reporting timeline for major incidents, set by Commission Delegated Regulation (EU) 2025/301: an initial notification within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it (an incident first classified as major after those 24 hours must be notified within 4 hours of that classification); an intermediate report within 72 hours of the initial notification; and a final report within one month of the latest intermediate report.

For smaller firms, the key question is: could you classify and report an incident to your competent authority within 4 hours? If the answer is no, this is your most urgent gap. You need predefined classification criteria, clear escalation paths, and template notifications ready to go. Our DORA Compliance Checklist includes an ICT Incident Classification Matrix designed for exactly this purpose.

Pillar 3: Digital Operational Resilience Testing

You must maintain a testing programme proportionate to your size and risk profile. Except for microenterprises, you must test all ICT systems and applications supporting critical or important functions at least yearly (Article 24(6)). For smaller firms, this typically means vulnerability assessments, penetration testing of critical systems and scenario-based disaster recovery tests. Entities identified by their competent authority must also carry out Threat-Led Penetration Testing (TLPT) at least every three years (Article 26); entities using the Article 16 simplified framework are exempt from TLPT.

The principle of proportionality is your friend here. A 20-person payment firm is not expected to run the same testing programme as a major bank. What matters is that testing is systematic, documented, and that findings are remediated.

Pillar 4: ICT Third-Party Risk

This is often the most complex pillar for smaller firms. You must maintain a register of information on all contractual arrangements with ICT third-party providers (Article 28(3)), make the full register available to your competent authority on request, and report to it at least yearly on new ICT arrangements. According to the European Banking Authority, this applies to all DORA entities, including those using the simplified framework.

The register's format is fixed by Commission Implementing Regulation (EU) 2024/2956: a set of templates (B_01 to B_07, plus B_99 for your terminology) covering your own entity, each contractual arrangement, the providers that sign them, the entities using the services, the ICT supply chain down to the subcontractors that underpin critical or important functions, the business functions supported, and an assessment of each service supporting a critical or important function. Providers that are legal persons are identified by their LEI or EUID. Each data element takes a single value; where more than one value applies, you add a row. Our register of information guide walks through every template.

Contracts with ICT providers must include specific provisions: service descriptions and SLAs, data processing locations, audit and access rights, incident notification obligations, termination and transition procedures, and cooperation with supervisory authorities during inspections.

Concentration risk is another key concern — DORA asks you to assess whether you are overly dependent on a single ICT provider. If your entire infrastructure runs on one cloud platform with no alternative, that is a concentration risk to document and manage.

Pillar 5: Information Sharing

DORA encourages (but does not mandate) participation in cyber threat intelligence sharing arrangements. For smaller firms, this might mean joining a sector-specific ISAC (Information Sharing and Analysis Centre) or subscribing to threat intelligence feeds from your national CSIRT. Even informal information sharing with peer firms counts.

A practical compliance roadmap

Month 1: Foundations. Create or update your ICT risk management framework. Inventory all ICT assets and third-party providers. Get management body approval. Use our DORA Compliance Checker for a baseline assessment.

Month 2: Incident readiness. Establish your incident classification scheme and reporting procedures. Create notification templates for your competent authority. Test the 4-hour notification workflow with a tabletop exercise.

Month 3: Third-party register. Build your ICT provider register with all required fields. Review existing contracts against DORA Article 30 requirements. Identify contracts that need amendments and begin negotiations.

Month 4-6: Testing and ongoing. Conduct vulnerability assessments and penetration testing. Document your testing programme. Establish quarterly review cycles for the ICT risk framework and third-party register.

DORA vs NIS2 — do I need both?

If you are a financial entity subject to DORA, you comply with DORA's requirements for ICT risk management and incident reporting — DORA takes precedence under the lex specialis principle. However, NIS2 may still apply for areas not specifically covered by DORA. In practice, a firm compliant with DORA will largely satisfy NIS2 requirements as well. Use our NIS2 Readiness Check to check for any additional obligations.

Frequently asked questions

Is there an official DORA compliance checklist?

No. DORA (Regulation (EU) 2022/2554) and its technical standards set the requirements, but no EU authority publishes a single checklist. This page maps 59 requirements to their articles. Some national authorities have sent self-assessment questionnaires to the firms they supervise; if yours has, that questionnaire takes precedence. For a scored view of where you stand, use the free DORA compliance tool.

Does the checklist apply to microenterprises and small firms?

DORA applies to all financial entities in its scope, but some articles exclude microenterprises (fewer than 10 staff and no more than €2M turnover or balance sheet) and the entities listed in Article 16(1) follow a simplified ICT risk management framework. Both cases are labelled on the items above, so you can skip what does not apply to you.

Is there a DORA checklist template in Excel?

Yes. The DORA Compliance Checklist pack ($34) has the gap assessment as an Excel workbook by article with status, evidence and owner columns, plus an ICT risk management framework template, a third-party ICT provider register with the fields of ITS 2024/2956, and a major-incident classification matrix.

What is the difference between this checklist and the DORA compliance tool?

The checklist is a list of requirements to tick off and keep as evidence. The DORA compliance tool asks 39 questions across the five pillars, scores each pillar and lists your gaps; the Pro report turns them into a remediation plan. Use the tool first to find the gaps, then the checklist to work through the articles.

DORA Compliance Checklist: 59 Requirements by Article