DORA Implementation Checklist: 15 Items for 2026

Featured image for 'DORA Implementation Checklist: 15 Items for 2026' — Sedric branded [sedric-rebrand-v2]
Sedric Team
Communications
Share article on
Linkedin logoX logo

TL;DR — DORA has been in application since 17 January 2025, and supervisors across the EU have moved from "do you have a plan?" to "show us the evidence". This checklist gives you fourteen concrete items, mapped to the five pillars of Regulation (EU) 2022/2554, that a Head of Compliance or DPO can use to pressure-test where the firm stands today.

Table of contents

What DORA actually requires

The five pillars of DORA (EU 2022/2554): ICT risk management, incident reporting, resilience testing, third-party risk, information sharing.

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — establishes a single rulebook for ICT risk across virtually every regulated financial entity in the Union: credit institutions, payment and e-money institutions, investment firms, CCPs and trading venues, AIFMs and UCITS management companies, insurance and reinsurance undertakings, crypto-asset service providers authorised under MiCA, and several others listed in Article 2.

The Regulation is built around five pillars, each fleshed out by Level 2 Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) drafted by the ESAs (EBA, ESMA, EIOPA):

  1. ICT risk management (Articles 5–16) — a governance and risk framework owned by the management body.
  2. ICT-related incident management, classification and reporting (Articles 17–23) — including the major-incident notification chain.
  3. Digital operational resilience testing (Articles 24–27) — including threat-led penetration testing (TLPT) for significant entities.
  4. Managing ICT third-party risk (Articles 28–44) — contracts, the register of information, exit strategies and the Critical ICT Third-Party Provider (CTPP) oversight framework.
  5. Information and intelligence sharing (Article 45) — voluntary, but increasingly an expected practice.

DORA is a regulation, not a directive — it applies directly. The Joint Committee of the ESAs, your national competent authority (NCA), and (for designated CTPPs) the Lead Overseer at ESA level have overlapping but distinct supervisory remits.

Why it matters in 2026

DORA has been in application for sixteen months as of this writing. Three things have changed since the application date.

First, NCAs have started running targeted thematic reviews. The DNB, the ACPR, the Bank of Italy and BaFin all published 2025 supervisory priorities that put DORA squarely at the top. The focus has moved from policies to evidence: incident logs, TLPT scoping documents, signed updated contracts, and a register of information that is actually complete.

Second, the first Register of Information submissions under the ITS in Commission Implementing Regulation (EU) 2024/2956 went in via the EBA's collection in April 2025 and again in April 2026. Many firms discovered, painfully, that their procurement data did not survive contact with the data model.

Third, the ESAs published the first list of Critical ICT Third-Party Providers (CTPPs) in 2025, opening the formal oversight regime. Firms relying on those CTPPs now have specific contractual and concentration-risk expectations that go beyond the baseline.

A penalty regime is operative. Article 50 lets NCAs impose administrative penalties and remedial measures; Member States have transposed criminal sanctions where applicable. We have not yet seen a marquee fine, but enforcement letters and Section 166-style skilled-person reviews are circulating.

Pillar 1 — ICT risk management (items 1–4)

DORA readiness checklist — 14 concrete items mapped to the five pillars of EU 2022/2554.

The management body owns ICT risk. Articles 5 and 6 are clear that the board cannot delegate ultimate accountability and must possess sufficient knowledge to challenge management.

Item 1 — Board-approved ICT risk management framework

You need a single, board-approved document (or controlled set) that covers the elements of Article 6(8): strategies, policies, procedures, ICT protocols and tools to protect information and ICT assets. The framework must be reviewed at least once a year and after any major ICT-related incident. Evidence the review minutes; do not rely on the policy date alone.

Item 2 — Identification and classification of ICT-supported business functions

Article 8 requires you to identify, classify and adequately document all ICT-supported business functions, the supporting information assets, and the ICT third-party dependencies that underpin them. This is the foundation of the ICT risk register, without which the rest of the framework cannot stand up.

Item 3 — Protection, detection and response controls

Articles 9 to 11 require controls across the standard cyber lifecycle: secure development, network segmentation, access management, monitoring, anomaly detection, business continuity and disaster recovery. RTS on ICT risk management tools (Commission Delegated Regulation (EU) 2024/1774) sets minimum content.

Item 4 — Learning and evolving

Article 13 requires you to capture lessons learned from incidents, tests and significant operational disruptions, and feed them back into the framework. In practice this is a tracked register of "what changed" — a thin artefact that, when missing, is the easiest finding a supervisor will write.

Pillar 2 — ICT-related incident reporting (items 5–7)

Item 5 — Incident classification process aligned to the RTS

Commission Delegated Regulation (EU) 2024/1772 sets the criteria for classifying ICT-related incidents as "major" and cyber threats as "significant". You need a process — owned by IT but governed by compliance/risk — that applies the seven criteria (clients/financial counterparties affected, reputational impact, duration, geographical spread, data losses, criticality of services, economic impact) and produces a defensible classification within hours, not days.

Item 6 — The three-stage reporting flow

For each major incident, Article 19 requires:

  • Initial notification to your NCA without undue delay (the ITS sets 4 hours from classification, and no later than 24 hours from detection).
  • Intermediate report within 72 hours of the initial notification.
  • Final report no later than one month after the latest intermediate report or, where applicable, after the incident is resolved.

You also need a customer notification protocol where appropriate under Article 19(3), and an aggregated voluntary notification for significant cyber threats.

Item 7 — Reporting templates pre-mapped to your tooling

The ITS in Commission Implementing Regulation (EU) 2024/2956 (and the corresponding RTS) prescribes the standard reporting templates. Pre-fill what you can: legal entity identifiers, parent group, services affected. Most firms now have a "DORA incident pack" that the duty officer can populate in the first hour.

Pillar 3 — Digital operational resilience testing (items 8–10)

Item 8 — Annual testing programme

Article 24 requires a risk-based testing programme — at minimum vulnerability assessments, scans, source code reviews, scenario-based tests, compatibility testing, performance testing and end-to-end testing — for all critical ICT systems, at least annually.

Item 9 — TLPT for significant entities

Threat-led penetration testing (Articles 26 and 27) applies to entities identified by NCAs based on size, risk profile and criticality. The TIBER-EU framework is the de facto methodology, with the RTS in Commission Delegated Regulation (EU) 2024/1773 setting scope and execution rules. TLPT runs at least every three years; remediation reports are reviewed by the NCA.

Item 10 — Independent testers and intra-group exceptions

Article 27 distinguishes between external and internal testers. Internal testers can be used under conditions, including periodic independent review. Document the conflict-of-interest controls — supervisors ask about this in walk-throughs.

Pillar 4 — ICT third-party risk (items 11–13)

The third-party pillar is where most firms have the largest gap. We have a dedicated piece on DORA third party risk; the checklist items below are the supervisory headline.

Item 11 — Register of Information complete and submitted

Maintain the Register of Information (Article 28(3)) using the templates in the ITS. Submit at the frequency and date prescribed by your NCA (annually in the first cycle). The data model is unforgiving — incomplete LEI fields, missing function identifiers, and unmapped sub-contractor chains are the most common findings.

Item 12 — Contractual clauses aligned to Article 30

Every ICT third-party arrangement supporting a critical or important function must contain the mandatory contractual provisions in Article 30(2) and (3): description of services, locations, data processing and storage, access and audit rights, exit assistance, sub-outsourcing rules, incident reporting and termination triggers. Legacy contracts almost always need an addendum.

Item 13 — Exit strategies and concentration risk

Article 28(8) requires documented exit strategies for arrangements supporting critical or important functions. Article 29 requires assessment of ICT concentration risk at the firm and group level, with attention to the use of CTPPs.

Pillar 5 — Information sharing (item 14)

Item 14 — Voluntary information-sharing arrangements

Article 45 permits, and encourages, arrangements for exchanging cyber threat information and intelligence. Joining an ISAC or sectoral threat-sharing community is the standard implementation. The bar is low; the absence is increasingly noted.

Three recent supervisory signals

  • NCA thematic letter on incident classification (2025). A continental supervisor wrote to a sample of credit institutions asking for the documented rationale behind every "non-major" classification in H2 2024. Firms with thin classification notes were given six weeks to remediate.
  • Register of Information rework programme. Several large insurers spent Q2 2025 reworking their RoI submission after the NCA returned the file with data-quality errors. Procurement and compliance had not aligned on the function-identifier taxonomy.
  • CTPP designation engagement. A 2025 designated CTPP began bilateral engagement with its largest financial-entity customers in advance of the Lead Overseer's first recommendations, asking for evidence of contractual updates and exit testing.

The 14-item DORA implementation checklist

  1. Board-approved ICT risk management framework, reviewed at least annually and after major incidents.
  2. ICT-supported business functions identified, classified and mapped to information assets and third parties.
  3. Protection, detection and response controls aligned to Commission Delegated Regulation (EU) 2024/1774.
  4. Lessons-learned register actively maintained.
  5. Incident classification process aligned to Commission Delegated Regulation (EU) 2024/1772.
  6. Three-stage reporting flow (initial, intermediate, final) with tested SLAs.
  7. Pre-filled reporting templates per Commission Implementing Regulation (EU) 2024/2956.
  8. Annual risk-based testing programme covering all critical ICT systems.
  9. TLPT scoping and engagement plan for in-scope entities, aligned to TIBER-EU.
  10. Independent-tester policy with documented conflict-of-interest controls.
  11. Register of Information complete, accurate, and submitted on the NCA's cycle.
  12. Article 30 contractual clauses present in all critical/important ICT arrangements.
  13. Documented exit strategies and ICT concentration-risk assessment.
  14. Active participation in an information-sharing arrangement.
No items found.

See Sedric in action

Sedric is the AI compliance platform for regulated marketing and communications. Every flag is mapped to the specific rulebook provision, every override is logged with reasoning, and the audit trail is the format regulators expect on first request. Book a 30-minute demo and we will walk through your specific compliance footprint.

FAQ

Who is in scope of DORA?

The list in Article 2 covers virtually every regulated financial entity in the EU, plus crypto-asset service providers authorised under MiCA and the issuers of asset-referenced tokens. Microenterprises benefit from a proportionality regime in Article 16 but are not exempt.

When did DORA enter into application?

17 January 2025. The text was published in the Official Journal in December 2022, and the two-year transition period is over.

What is a "major" incident under DORA?

The classification is set by the RTS (Commission Delegated Regulation (EU) 2024/1772) using seven criteria. In practice, an incident is major when it crosses thresholds on clients affected, duration, data losses or service criticality, among others.

Do we need TLPT?

Only if your NCA identifies you as an in-scope entity based on the criteria in Article 26 and the RTS on TLPT. Significant credit institutions, large investment firms, CCPs and major insurers are the typical candidates.

What is the Register of Information?

A standardised inventory of all ICT third-party arrangements, structured per the ITS. It is submitted to NCAs and forms the basis of the CTPP designation exercise.

How does DORA interact with NIS2?

NIS2 (Directive (EU) 2022/2555) applies to a wider set of essential and important entities. For regulated financial entities, DORA is lex specialis and prevails on ICT risk; NIS2 obligations that go beyond DORA do not generally apply.

Are there fines under DORA?

Yes. Article 50 allows administrative penalties and remedial measures; Member States set the quantum and may add criminal sanctions. Designated CTPPs face periodic penalty payments under Article 35.

Where to go next

If your gap analysis is mostly in pillar 1, start with our DORA ICT risk register template. If pillar 4 is the bigger problem, read DORA third party risk. MiCA-authorised CASPs are also in scope of DORA — pair this with the MiCA authorisation checklist. And if recorded-line and communications obligations are part of your wider workstream, our MiFID II recording requirements piece covers the adjacent regime.

See Sedric in action

Sedric is the AI compliance platform for regulated marketing and communications. Every flag is mapped to the specific rulebook provision, every override is logged with reasoning, and the audit trail is the format regulators expect on first request. Book a 30-minute demo and we will walk through your specific compliance footprint.

Run compliance on autopilot

Convert your static procedures into active AI controllers that protect your brand 24/7.