DORA Compliance Checklist
A structured checklist for achieving compliance with the Digital Operational Resilience Act (DORA), covering ICT risk management, incident reporting, resilience testing, third-party oversight, information sharing, and governance.
- 1
DORA compliance rests on six interconnected pillars: ICT risk management, incident reporting, resilience testing, third-party oversight, information sharing, and governance.
- 2
The management body is directly responsible for the ICT risk management framework under Article 5(2) — this includes ongoing training, active oversight, and accountability for implementation.
- 3
Incident reporting follows a strict three-stage timeline: initial notification within 4 hours of classification (max 24 hours from awareness), intermediate report within 72 hours, and final report within one month.
- 4
The ICT third-party register must be maintained in the ESA-prescribed format and reported annually, covering all contractual arrangements with ICT service providers.
- 5
Resilience testing is mandatory at least annually for all systems supporting critical or important functions, with TLPT required every three years for designated entities.
Step 1: Establish the ICT Risk Management Framework (Articles 5-16)
The foundation of DORA compliance is a comprehensive ICT risk management framework. Article 6(1) requires financial entities to have in place a sound, comprehensive, and well-documented ICT risk management framework as part of their overall risk management system. This framework must include strategies, policies, procedures, ICT protocols, and tools necessary to duly and adequately protect all information assets and ICT assets, including computer software, hardware, servers, as well as all relevant physical components and infrastructures.
Your first action is to conduct a comprehensive inventory of all ICT assets, information assets, and ICT services that support your business functions. Article 8 requires financial entities to identify, classify, and adequately document all ICT-supported business functions, roles, and responsibilities, the information assets and ICT assets supporting those functions, and the configurations, interconnections, and interdependencies with internal and external ICT systems. This inventory forms the baseline for all subsequent risk management activities — you cannot manage risks to assets you have not identified.
Next, develop and formalise your ICT risk management policies and procedures. Article 9 requires specific protection and prevention measures, including ICT security policies, network security management, access control mechanisms, encryption and cryptographic controls, and ICT change management procedures. Article 10 addresses detection capabilities, requiring mechanisms to promptly detect anomalous activities. Article 11 covers response and recovery, mandating an ICT business continuity policy, disaster recovery plans, and backup policies. Each of these must be documented, approved by the management body, and subject to regular review. The management body bears ultimate responsibility for the ICT risk management framework under Article 5(2).
Article 5(2) makes the management body directly responsible for defining, approving, overseeing, and being accountable for the implementation of all arrangements related to the ICT risk management framework. This is a personal governance obligation, not a delegable administrative task.
Step 2: Implement Incident Classification and Reporting (Articles 17-23)
DORA Chapter III establishes detailed requirements for ICT-related incident management, classification, and reporting. Article 17(1) requires financial entities to define, establish, and implement an ICT-related incident management process to detect, manage, and notify ICT-related incidents. This process must include early warning indicators, procedures for identifying, tracking, logging, categorising, and classifying incidents, roles and responsibilities for different incident types, communication plans for staff, external stakeholders, and media, and reporting procedures to the competent authority.
Article 18 establishes the incident classification criteria, which were further detailed by the European Supervisory Authorities in Regulatory Technical Standards. The primary classification criteria include: the number of clients or financial counterparts affected, the duration of the incident, the geographic spread, the data losses in terms of availability, authenticity, integrity, or confidentiality, the criticality of the services affected, and the economic impact. Incidents meeting the major incident thresholds defined in the RTS must be reported to the competent authority. The classification must be applied consistently and documented for supervisory review.
The reporting timeline under Article 19 follows a three-stage process. An initial notification must be submitted within four hours of classifying the incident as major (and no later than 24 hours after the entity becomes aware of the incident). An intermediate report providing updated information must be submitted within 72 hours of the initial notification. A final report analysing the root cause and describing remediation actions must be submitted within one month of the incident. Financial entities must also notify their clients and, where applicable, other financial entities, without undue delay when the major ICT-related incident has or may have an impact on their financial interests. Build these reporting timelines into your incident response procedures and conduct regular tabletop exercises to verify your ability to meet them under pressure.
The 4-hour initial notification deadline from classification (max 24 hours from awareness) is extremely demanding. Ensure your incident response team has pre-approved notification templates, designated contacts at the competent authority, and 24/7 on-call coverage to meet this timeline.
Step 3: Build the Resilience Testing Programme (Articles 24-27)
Chapter IV of DORA requires all in-scope financial entities (except microenterprises) to establish, maintain, and review a comprehensive digital operational resilience testing programme. The programme must be proportionate to the entity's size and risk profile, but at minimum must include the basic testing activities specified in Article 25: vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.
Start by mapping your current testing activities against the Article 25 requirements to identify gaps. Many financial entities already conduct some form of vulnerability scanning and penetration testing, but may lack formalised scenario-based testing, physical security reviews, or open-source analyses. For each testing type, define the scope (which systems and functions are covered), the frequency (minimum annual for all systems supporting critical or important functions), the methodology, the qualifications of testers, and the process for tracking and remediating findings. Ensure that internal testers are independent from the areas they test and are free from conflicts of interest.
If your entity is designated for threat-led penetration testing (TLPT) under Article 26, you must engage qualified external testers meeting the Article 27 requirements and coordinate the TLPT scope with your competent authority. TLPT must be conducted at least every three years and must test critical or important functions on live production systems. Begin preparations well in advance — a TLPT engagement typically takes six to twelve months from scoping to closure, including the threat intelligence phase, red team execution, and remediation. Even if you are not currently designated for TLPT, familiarise yourself with the TIBER-EU framework and consider conducting voluntary threat-led testing to strengthen your resilience posture.
Step 4: Maintain the ICT Third-Party Register and Contractual Compliance (Articles 28-30)
DORA Chapter V imposes comprehensive third-party ICT risk management obligations. Article 28(3) requires financial entities to maintain and update a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. This register must be available to the competent authority on request and must be reported annually. The European Supervisory Authorities have published Implementing Technical Standards (ITS) specifying the standard templates and format for the register, ensuring uniformity across the EU financial sector.
Building the register requires you to identify every ICT third-party service provider your entity relies on, including cloud providers, software vendors, managed service providers, data analytics providers, and any other third party providing ICT services. For each provider, the register must capture: the identity of the provider, the services provided, a description of the functions supported, the classification of those functions as critical or important (or not), the contract start and end dates, governing law and jurisdiction, data processing locations, and any subcontracting arrangements. The register must distinguish between arrangements supporting critical or important functions and those that do not.
Article 30 specifies the key contractual provisions that must be included in arrangements with ICT third-party service providers. These include a clear description of all functions and services, the locations where data is processed and stored, provisions on availability, authenticity, integrity, and confidentiality of data, provisions ensuring access, recovery, and return of data in the event of insolvency or termination, service-level descriptions with quantitative and qualitative performance targets, notice periods and reporting obligations of the provider, rights of access, inspection, and audit for the entity and its competent authority, and clear termination rights. For arrangements supporting critical or important functions, Article 30(3) adds further requirements including exit strategies, minimum notice periods, and the provider's obligation to support transition to alternative providers. Review all existing ICT third-party contracts against these requirements and negotiate amendments where gaps are identified.
Step 5: Establish Information Sharing Arrangements (Article 45)
Article 45 of DORA encourages financial entities to participate in voluntary information-sharing arrangements concerning cyber threat intelligence and vulnerabilities. While this is framed as encouragement rather than a strict mandate, competent authorities may view participation — or the lack thereof — as an indicator of the entity's commitment to digital operational resilience. The provision reflects the EU's recognition that cyber threats to the financial sector are often systemic in nature and that collective defence through information sharing is more effective than isolated responses.
To operationalise this requirement, identify relevant information-sharing communities and frameworks. Within the EU financial sector, key initiatives include the Euro Cyber Resilience Board (ECRB) for pan-European financial infrastructure, national ISACs (Information Sharing and Analysis Centres) such as FI-ISAC in the Netherlands or the CERTFin in Italy, sector-specific CERTs and SOC communities, and commercial threat intelligence sharing platforms. The choice of communities should align with your entity's sector, geography, and risk profile.
Establish internal governance for information sharing. Article 45(2) specifies that financial entities shall notify their competent authority of their participation in information-sharing arrangements. Internally, you need policies governing what types of information can be shared (and what must be withheld due to confidentiality or regulatory constraints), who is authorised to share on behalf of the entity, how incoming intelligence is ingested and acted upon, and how the quality and relevance of shared intelligence is evaluated. Information sharing must be conducted in a manner that respects applicable data protection and competition law constraints. Pseudonymisation and anonymisation of shared data should be used where appropriate to avoid inadvertent disclosure of entity-specific vulnerabilities or incident details.
Step 6: Governance and Oversight Structures (Articles 5 and 13)
DORA places governance at the apex of the compliance framework. Article 5(1) requires financial entities to have in place an internal governance and control framework that ensures an effective and prudent management of all ICT risks. Article 5(2) makes the management body — the board of directors or equivalent — directly responsible for defining, approving, overseeing, and being accountable for the implementation of all arrangements related to the ICT risk management framework. This is not a rubber-stamping exercise; the management body must actively engage with ICT risk and demonstrate competence in doing so.
Article 5(4) requires members of the management body to actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk and its impact on the operations of the financial entity. This includes regularly following specific training. Organisations must therefore ensure that board-level training programmes include ICT risk and cybersecurity content, and that this training is documented and refreshed at appropriate intervals. The training should cover the entity's ICT risk profile, the DORA obligations applicable to the entity, the entity's ICT risk management framework and testing programme, and emerging threats and trends relevant to the financial sector.
Article 13 requires financial entities to incorporate digital operational resilience into their broader learning and evolving framework. This means using insights from ICT-related incidents, resilience testing, and supervisory activities to update and improve the ICT risk management framework on an ongoing basis. Post-incident reviews, lessons-learned exercises, and trend analysis should feed back into the risk management framework, policies, and procedures. The management body must be informed of significant findings and must approve material changes to the framework. Establish a regular reporting cadence — quarterly is typical — in which the ICT risk management function presents to the management body on the status of the ICT risk management framework, testing programme results, incident trends, third-party risk posture, and any material changes in the ICT threat landscape.
DORA compliance is not a one-time project — it is an ongoing governance obligation. Build recurring review cycles into your board calendar and ICT risk management processes to ensure continuous compliance as the threat landscape, technology environment, and regulatory expectations evolve.
Bringing It All Together: Prioritisation and Timeline
With DORA having applied since 17 January 2025, the implementation window has closed and financial entities must now demonstrate compliance across all six pillars. For entities still working to close gaps, prioritisation is essential. The ICT risk management framework (Step 1) and governance structures (Step 6) are foundational — without them, the other pillars cannot function effectively. Incident classification and reporting (Step 2) is the next priority due to the tight reporting timelines and the potential for immediate supervisory scrutiny following a major incident.
The third-party ICT register (Step 4) is a particularly data-intensive workstream that many entities have found challenging. The ITS templates require granular information about every ICT third-party arrangement, and gathering this data often requires coordination across procurement, legal, IT, and business functions. If your register is not yet complete, focus first on arrangements supporting critical or important functions, which are subject to the most demanding contractual requirements under Article 30(3) and present the highest supervisory risk.
Resilience testing (Step 3) and information sharing (Step 5) can be phased in parallel with the other workstreams. For testing, the minimum viable programme is an annual cycle of vulnerability scanning and penetration testing covering systems that support critical or important functions, with a documented methodology for prioritising and remediating findings. More advanced testing activities and TLPT preparation can follow as the programme matures. For information sharing, initial participation in at least one relevant community or ISAC demonstrates good faith and provides immediate intelligence benefits.
Finally, treat compliance as a continuous improvement cycle, not a destination. The regulatory technical standards, implementing technical standards, and supervisory guidelines associated with DORA continue to be refined. Monitor ESA publications, engage with industry working groups, and build flexibility into your compliance programme to accommodate evolving expectations. Regular gap assessments — at least annually — should verify that your programme remains aligned with the current regulatory requirements.
Is DORA compliance required now, or is there a transition period?
DORA (Regulation 2022/2554) entered into force on 16 January 2023 and has applied since 17 January 2025. There is no transition period — financial entities must be fully compliant as of the application date. Unlike a directive, DORA is a regulation and applies directly in all EU Member States without transposition. The European Supervisory Authorities (EBA, EIOPA, ESMA) have published regulatory technical standards and implementing technical standards that provide further detail on specific requirements. Entities that are not yet fully compliant should prioritise gap closure and engage proactively with their competent authority.
How does DORA interact with existing financial regulations like MiFID II or Solvency II?
DORA is designed to complement existing financial regulations by establishing a uniform layer of ICT risk management and digital resilience requirements across the entire EU financial sector. It applies alongside MiFID II, Solvency II, CRD/CRR, PSD2, and other sector-specific legislation. Where existing regulations contain ICT risk requirements (e.g., EBA Guidelines on ICT and security risk management), DORA provides a more comprehensive and harmonised framework that supersedes patchwork sectoral guidance. Financial entities should map their existing ICT-related compliance activities to DORA requirements to identify overlaps and gaps, leveraging existing investments where possible.
What is the penalty for non-compliance with DORA?
DORA Article 50 empowers competent authorities to adopt all supervisory measures necessary to ensure compliance, and Article 52 requires Member States to lay down rules establishing appropriate administrative penalties and remedial measures. Unlike NIS2, DORA does not specify harmonised maximum fine amounts — the penalty amounts are determined by each Member State. However, given the critical importance of financial stability and the precedent set by existing financial regulation enforcement, penalties are expected to be significant. Additionally, competent authorities can issue binding instructions, require remediation, and — in the context of critical ICT third-party provider oversight — impose periodic penalty payments under Article 35(8).
Do we need to report all ICT incidents, or only major ones?
Under Article 19, only major ICT-related incidents must be reported to the competent authority. The classification of an incident as major is determined by applying the criteria and thresholds set out in Article 18 and the associated Regulatory Technical Standards. These criteria include the number of clients affected, the duration, geographic spread, data losses, criticality of services impacted, and economic impact. However, Article 17 requires financial entities to record and classify all ICT-related incidents — not just major ones — and to monitor and analyse trends. Entities may also voluntarily report significant cyber threats under Article 19(2). Maintaining comprehensive incident logs is essential for both regulatory compliance and internal learning.
What should we do about ICT third-party contracts that do not meet DORA requirements?
Article 28(7) and (8) address this directly. Financial entities must identify and assess the risks of contractual arrangements that do not meet DORA requirements and must take appropriate steps to address deficiencies. For existing contracts, this typically means negotiating amendments to include the mandatory provisions specified in Article 30. Where a third-party provider refuses to amend the contract, you must assess the residual risk and consider alternative providers. For contracts supporting critical or important functions, Article 28(8) provides that competent authorities may require financial entities to terminate arrangements that pose undue risk. Begin by prioritising contracts supporting critical or important functions for review and amendment, and build DORA-compliant templates into your procurement process for all new arrangements.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.