DORA Compliance Checker

The Digital Operational Resilience Act (DORA), formally Regulation (EU) 2022/2554, is the EU's comprehensive framework for ensuring that financial entities can withstand, respond to, and recover from all types of ICT-related disruptions and threats. Unlike a directive, DORA is a regulation — it applies directly across all EU member states without requiring national transposition.

DORA entered into force on 16 January 2023 and applies from 17 January 2025. It covers virtually all regulated financial entities in the EU, from major banks to small payment institutions, plus critical ICT third-party service providers to the financial sector.

The regulation was created in response to the financial sector's growing dependence on ICT systems and third-party technology providers. A single ICT failure at a major cloud provider or a successful cyberattack on a bank's core systems can have cascading effects across the entire financial system. DORA aims to ensure this digital backbone is resilient.

Pillar 1: ICT Risk Management (Articles 5-16)

Financial entities must establish a comprehensive ICT risk management framework that is documented, approved by the management body, and regularly reviewed. This includes identifying all ICT assets, implementing protection and detection measures, maintaining business continuity plans, and continuously learning from incidents. The management body bears ultimate accountability — a significant shift that puts ICT resilience firmly on the board's agenda.

A simplified ICT risk management framework (Article 16) is available to specific entities, such as small and non-interconnected investment firms and exempted payment or e-money institutions. It is not available to every microenterprise, although microenterprises get lighter requirements in several articles.

Pillar 2: ICT Incident Management (Articles 17-23)

DORA requires financial entities to implement a robust ICT incident management process with clear classification criteria. Major incidents must be reported to the competent authority on an aggressive timeline: 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 (Commission Delegated Regulation (EU) 2025/301). This 4-hour window is among the tightest in any EU regulation.

Pillar 3: Digital Operational Resilience Testing (Articles 24-27)

Entities other than microenterprises must keep a testing programme proportionate to their size and risk profile, and run appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions (Article 24(6)). The tests are chosen from a range that includes vulnerability assessments and scans, scenario-based tests and penetration testing (Article 25). Entities identified by their competent authority must also carry out Threat-Led Penetration Testing (TLPT) at least every three years (Article 26). Weaknesses found must be addressed.

Pillar 4: ICT Third-Party Risk (Articles 28-44)

This is one of DORA's most impactful pillars. Financial entities must maintain a register of information on all contractual arrangements for ICT services, report at least yearly on new arrangements, and provide the full register to their competent authority on request (Article 28(3)). Contracts must include specific provisions (SLAs, audit rights, incident notification, exit clauses), and concentration risk must be actively monitored. Critical ICT providers are subject to a new EU-level oversight framework led by the European Supervisory Authorities.

Pillar 5: Information Sharing (Article 45)

DORA encourages — but does not mandate — participation in cyber threat intelligence sharing arrangements within the financial sector. When entities do share, DORA provides a framework to protect confidentiality and ensure compliance with data protection rules.

Member states set the administrative penalties and remedial measures for breaches of DORA, and national competent authorities apply them (Article 50). Penalties must be effective, proportionate, and dissuasive. DORA does not set maximum fine amounts the way GDPR does.

For critical ICT third-party providers, the European Supervisory Authorities can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover to compel compliance with oversight measures.

Under Article 50(4), competent authorities must at least be able to order an entity to stop conduct that breaches DORA, require practices to cease temporarily or permanently, adopt measures including pecuniary ones to restore compliance, and issue public notices naming the entity and the breach. Sector rules on authorisation, such as withdrawing a licence, continue to apply alongside DORA.

Both DORA and NIS2 address cybersecurity, but they serve different purposes and scopes. DORA is a sector-specific regulation for financial entities focused on digital operational resilience. NIS2 is a cross-sector directive covering essential and important entities across 18 sectors.

Under the lex specialis principle, DORA takes precedence over NIS2 for financial entities where their requirements overlap. If you are a financial entity subject to DORA, you comply with DORA's ICT risk management and incident reporting requirements rather than NIS2's — though NIS2 may still apply for areas not covered by DORA.

Key differences include incident reporting timelines (DORA: 4 hours initial; NIS2: 24 hours early warning) and third-party oversight (DORA creates an EU-level framework for critical ICT providers; NIS2 has no equivalent).

After three screening questions (entity type, EU activity and microenterprise status), the checker asks 39 questions across the five pillars. Each one names the DORA article it comes from, so you can check the legal text yourself and use your answers as the start of a gap analysis. The same questions are available to AI assistants through our MCP server (tool dora_gap_assessment).

Pillar 1: ICT Risk Management (10 questions)

• Is there a documented ICT risk management framework approved by the management body? (DORA Art. 5, Art. 6)
• Does the management body bear ultimate responsibility for ICT risk management? (DORA Art. 5)
• Are adequate budget and resources allocated for ICT security and resilience? (DORA Art. 5)
• Are all ICT assets (hardware, software, data, network) identified and classified? (DORA Art. 8)
• Are ICT systems protected with appropriate cybersecurity measures (encryption, access control, segmentation)? (DORA Art. 9)
• Are detection mechanisms in place for ICT anomalies and incidents? (DORA Art. 10)
• Are ICT business continuity and disaster recovery plans documented and tested? (DORA Art. 11)
• Are backup and restoration procedures in place with defined RPO/RTO? (DORA Art. 12)
• Are lessons learned from incidents and testing used to improve the ICT risk framework? (DORA Art. 13)
• Are communication plans for ICT-related incidents established? (DORA Art. 14)

Pillar 2: ICT Incident Management (8 questions)

• Is there a documented ICT incident management process? (DORA Art. 17)
• Are early warning indicators for ICT incidents defined and monitored? (DORA Art. 17)
• Is there an incident classification scheme aligned with DORA criteria (clients, duration, data loss, criticality)? (DORA Art. 18)
• Can you submit an initial notification to the competent authority within 4 hours of classifying a major incident? (DORA Art. 19)
• Can you submit an intermediate report within 72 hours? (DORA Art. 19)
• Can you submit a final report within 1 month? (DORA Art. 19)
• Is root cause analysis conducted for all major ICT incidents? (DORA Art. 17)
• Are relevant incidents communicated to affected clients and stakeholders? (DORA Art. 14, Art. 19)

Pillar 3: Digital Operational Resilience Testing (8 questions)

• Is there an established digital operational resilience testing programme? (DORA Art. 24)
• Are vulnerability assessments conducted at least annually? (DORA Art. 25)
• Is penetration testing conducted at least annually on critical systems? (DORA Art. 25)
• Are scenario-based tests (disaster recovery, business continuity) conducted? (DORA Art. 25)
• Is network security assessment performed regularly? (DORA Art. 25)
• Is open source / software composition analysis conducted? (DORA Art. 25)
• Are all vulnerabilities from testing remediated within defined timelines? (DORA Art. 24)
• Is Threat-Led Penetration Testing (TLPT) conducted every 3 years (if required)? (DORA Art. 26)

Pillar 4: ICT Third-Party Risk (9 questions)

• Is there a documented strategy for ICT third-party risk management? (DORA Art. 28)
• Is a register of all ICT third-party provider arrangements maintained? (DORA Art. 28)
• Is the register reported to the competent authority at least annually? (DORA Art. 28)
• Is a risk assessment conducted before entering new ICT third-party arrangements? (DORA Art. 28)
• Is ICT concentration risk assessed and monitored? (DORA Art. 29)
• Are exit strategies documented for critical ICT third-party services? (DORA Art. 28)
• Do contracts include required provisions (SLAs, audit rights, incident notification, termination)? (DORA Art. 30)
• Is ongoing monitoring of ICT provider performance and security conducted? (DORA Art. 28, Art. 30)
• Do contracts require provider cooperation during supervisory inspections? (DORA Art. 30)

Pillar 5: Information Sharing (4 questions)

• Has participation in cyber threat intelligence sharing arrangements been assessed? (DORA Art. 45)
• Are information sharing agreements in place that protect confidentiality? (DORA Art. 45)
• Is received threat intelligence integrated into ICT risk management? (DORA Art. 45)
• Are personnel designated to manage information sharing activities? (DORA Art. 45)

Each question counts once: Yes scores 1, Partially scores 0.5, and No or an unanswered question scores 0. A pillar's score is its points divided by its number of questions. The overall score is the points across all 39 questions, so pillars with more questions (ICT risk management has 10, information sharing 4) weigh more in the total.

Three things to keep in mind when you read the result:

• Pillar 5 is voluntary. Article 45 allows information sharing arrangements but does not require them, so a low score there is less urgent than a low score in pillars 1 to 4.
• TLPT applies only if your authority says so. Threat-led penetration testing (Article 26) is required only of entities identified by their competent authority. If you have not been identified, answer that question "Yes" so it does not show as a gap.
• Proportionality is not scored. Article 4 lets you apply the rules in proportion to your size and risk profile, and microenterprises are exempt from some requirements. The score assumes the full set applies; adjust your reading if a requirement does not apply to you.

This page and our checklist answer different questions. Use the one that fits where you are:

• DORA compliance checker (this tool): 39 practical questions, a score per pillar and a list of gaps in about 10 minutes. Best for a first readiness check or a quick update for management.
• DORA compliance checklist: the 59 core requirements of the regulation with article references and the microenterprise and Article 16 exemptions, which you can tick off, save and print. Best when you need to work through the legal text requirement by requirement, for example before an audit.

Many teams use both: the checker to find the weak pillars, then the checklist to go through those pillars in detail.

1. Fix governance first. Under Article 5 the management body defines, approves and is responsible for the ICT risk management framework. Without that approval, the rest of your work has no owner. Our ICT risk management framework guide lists what to document.
2. Make sure you can report a major incident. You need classification criteria based on Delegated Regulation 2024/1772, a named person who decides, and templates for the initial notification (4 hours after classification, no later than 24 hours after you become aware), the intermediate report and the final report.
3. Build the register of information. Article 28(3) requires a register of all contractual arrangements for ICT services, available to your competent authority on request. See DORA register of information for the templates and fields.
4. Review ICT contracts. Article 30 lists the clauses every ICT contract needs, with more for services that support critical or important functions. Our Article 30 checklist helps you review them.
5. Plan testing. Set up a testing programme and test the systems that support critical or important functions at least yearly (Article 24(6)).
6. Reassess. Run the checker again after each phase and keep the results as evidence of progress for your management body and supervisor.

The Pro report turns your answers into this plan: every gap with a recommended action, a priority and the DORA article, ordered into a 30/60/90-day roadmap you can download as a PDF.