Compliance Checklist·10 min read

DORA Compliance Checklist for Financial Services

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act — has applied since 17 January 2025. Every financial entity in the EU must now demonstrate operational resilience against ICT-related disruptions. This guide breaks the regulation into actionable steps your compliance team can follow today.

1. What Is DORA and Who Does It Apply To?

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is a binding EU regulation that establishes a uniform framework for managing ICT risk in the financial sector. Unlike a directive, DORA applies directly across all 27 member states — no national transposition required.

DORA was adopted on , entered into force on , and became fully applicable on . Its scope covers more than 22,000 financial entities and ICT service providers operating within the EU, including:

  • Credit institutions (banks) and payment institutions
  • Insurance and reinsurance undertakings
  • Investment firms, management companies, and alternative investment fund managers
  • Central securities depositories, central counterparties, and trading venues
  • Crypto-asset service providers authorised under MiCA
  • ICT third-party service providers, including cloud computing providers, data analytics firms, and software vendors designated as “critical” by the European Supervisory Authorities (ESAs)

Microenterprises (fewer than 10 employees and annual turnover or balance sheet below €2 million) benefit from simplified requirements under Article 16, but they are not exempt.

2. Key Dates and Enforcement Timeline

DateMilestone
14 Dec 2022DORA adopted by European Parliament and Council
16 Jan 2023Entry into force (published in OJ L 333)
17 Jan 2024First batch of Regulatory Technical Standards (RTS) published by ESAs
17 Jul 2024Second batch of RTS and Implementing Technical Standards (ITS) finalised
17 Jan 2025Full application — all entities must comply
2025–2026ESAs designate critical ICT third-party providers; oversight framework operational

3. The Five Pillars of DORA

DORA is structured around five pillars. Each imposes specific obligations and — since January 2025 — is subject to supervisory enforcement. Below is a checklist of actionable requirements under each pillar.

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

This is the backbone of DORA. Financial entities must establish and maintain a comprehensive ICT risk management framework, reviewed at least annually and after every major ICT incident.

  • Assign management body accountability. Article 5 requires the management body to define, approve, oversee, and bear ultimate responsibility for the ICT risk management framework. Board members must undertake regular training on ICT risk.
  • Maintain an up-to-date ICT asset inventory. All information assets and ICT assets must be documented, classified by criticality, and mapped to business functions (Article 8).
  • Implement protection and prevention measures. Deploy policies covering network security, access control, encryption, patch management, and data integrity (Article 9).
  • Establish detection capabilities. Anomalous activity monitoring, multiple layers of controls, and alert thresholds must be in place, with allocation of sufficient resources to monitor ICT operations around the clock (Article 10).
  • Define response and recovery procedures. ICT business continuity plans, disaster recovery plans, and crisis communication procedures must be documented, tested, and updated at least annually (Articles 11–13).
  • Conduct post-incident reviews. After every significant ICT disruption, perform a root cause analysis and feed lessons learned back into the risk framework (Article 13).

Pillar 2: ICT-Related Incident Reporting (Articles 17–23)

DORA harmonises incident reporting across the EU, replacing the patchwork of sector-specific notification rules.

  • Classify incidents using the prescribed criteria. The RTS on incident classification specify thresholds based on clients affected, data integrity loss, duration, geographic spread, economic impact, and criticality of services affected.
  • Submit initial notification within 4 hours. For major ICT incidents, an initial report must be submitted to the competent authority within 4 hours of classification (and no later than 24 hours from discovery).
  • Provide an intermediate report within 72 hours. Update the competent authority with current status, root cause analysis (if available), and mitigation measures.
  • Deliver a final report within one month. Include the full root cause analysis, total impact assessment, and remediation actions taken or planned.
  • Notify clients where their interests are affected. If the incident impacts financial services provided to clients, inform them without undue delay and advise on protective measures (Article 19).
  • Log and track all ICT incidents. Maintain a record of all ICT-related incidents (not just major ones), including recurring operational problems, to support trend analysis and supervisory review.

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

Testing is essential to validate whether the controls from Pillar 1 actually work under stress.

  • Establish a risk-based testing programme. Proportionate to the entity's size and risk profile, the programme must include vulnerability assessments, open-source analysis, network security assessments, gap analyses, physical security reviews, and software scans (Article 25).
  • Run basic tests at least annually. All financial entities must perform regular testing of ICT tools, systems, and processes. Non-microenterprise entities must adopt a structured testing methodology.
  • Conduct Threat-Led Penetration Testing (TLPT) every three years. Entities identified by competent authorities as systemically important must carry out advanced adversarial testing. TLPT must follow the TIBER-EU framework guidelines and be performed by qualified external testers (Article 26).
  • Remediate all findings. Testing results, including discovered vulnerabilities, must be reported to the management body and fully remediated, with validation of the remediation.

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

The largest innovation in DORA is its direct regulation of ICT third-party providers, particularly those designated as “critical” (CTPPs).

  • Maintain a register of all ICT outsourcing arrangements. Article 28(3) requires a complete register of all contractual arrangements with ICT third-party service providers, reported to competent authorities on request and annually.
  • Perform due diligence before onboarding. Assess the provider's ICT risk posture, financial stability, information security policies, and business continuity arrangements before entering any agreement.
  • Include mandatory contractual clauses. Contracts must address service-level descriptions, data location and processing, availability guarantees, audit rights, incident notification, exit strategies, and cooperation with supervisory authorities (Article 30).
  • Monitor concentration risk. Assess whether over-reliance on a single provider or a small group of providers creates systemic vulnerability. Develop documented exit strategies for critical or important functions.
  • Cooperate with the ESA oversight framework. Critical ICT third-party providers face direct supervision by a Lead Overseer (one of the three ESAs). Financial entities must ensure their providers cooperate with the Overseer's requests for information, on-site inspections, and remediation orders.

Pillar 5: Information Sharing (Article 45)

DORA encourages — but does not mandate — financial entities to share cyber-threat intelligence with each other.

  • Participate in trusted information-sharing communities. Join or establish arrangements for exchanging cyber threat intelligence, indicators of compromise (IoCs), tactics, techniques, and procedures (TTPs) with peer institutions.
  • Define internal policies for what can be shared. Ensure that sharing arrangements include safeguards for business confidentiality, personal data (GDPR), and competition law constraints.
  • Notify your competent authority of participation. Inform the relevant supervisor when your entity enters into an information-sharing arrangement, and document the nature and scope of the exchange.

4. Penalties for Non-Compliance

Enforcement of DORA sits with national competent authorities (NCAs) such as BaFin (Germany), ACPR (France), or De Nederlandsche Bank (Netherlands). The regulation equips NCAs with broad powers:

  • Administrative penalties and remedial measures — NCAs can impose fines, issue cease-and-desist orders, require specific remediation actions, and publish statements identifying the entity and nature of the breach.
  • Periodic penalty payments for critical ICT providers — Under the oversight framework, the Lead Overseer can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover in the preceding business year, applied daily for up to six months, to compel compliance.
  • Personal liability for management body members — Because DORA assigns ultimate responsibility to the management body (Article 5), directors and senior officers may face personal sanctions for governance failures.

Beyond direct fines, the reputational risk of a published enforcement action is significant. Supervisors have signalled that DORA examinations will intensify throughout 2025 and 2026, with thematic reviews focusing on ICT incident reporting readiness and third-party register completeness.

5. Using Automated Monitoring to Stay Ahead

DORA is not a one-time compliance exercise. The ESAs continue to publish delegated acts, regulatory technical standards, implementing technical standards, and guidelines — each of which may change your obligations. National supervisors issue their own circulars and interpretive guidance layered on top of the regulation.

Tracking these developments manually across EUR-Lex, the EBA, ESMA, EIOPA, and 27 national supervisory authority websites is unsustainable. This is where automated regulatory monitoring becomes critical. A platform like Polzia continuously scans over 200 regulatory sources across 21 markets, classifying new publications by topic, jurisdiction, and severity so your team receives only what is relevant.

For DORA specifically, automated monitoring helps you:

  • Catch new RTS and ITS as they are published — ESA delegated acts define the detailed requirements for incident classification, TLPT methodology, and third-party register templates. Missing an update means operating on stale procedures.
  • Monitor national supervisor guidance — NCAs will issue local circulars interpreting DORA for their jurisdictions. If you operate in multiple member states, you need visibility across all of them.
  • Track changes to related regulations — DORA intersects with NIS2, GDPR, MiCA, PSD2, and Solvency II. A regulatory change in one regime may cascade into your DORA obligations.
  • Generate compliance documentation automatically — AI-driven platforms can produce gap analysis memos, board briefings, and action item tracking so your team spends less time on formatting and more time on substance.

Stay on Top of DORA Requirements

Polzia monitors every DORA-related publication from the ESAs and 27 national supervisors — classified, scored, and delivered to your compliance inbox. Start tracking for free.

Start Free — No Credit Card