DORA Compliance Checklist 2026: Evidence by Pillar

Most compliance checklists fail the same way. They list what to do, the list gets ticked, and nothing is left behind. A competent authority does not ask whether you have an ICT risk management framework: it asks to see it, approved, dated, and by a named person. This checklist is built the other way round. Every line pairs an obligation under Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), with the article that imposes it and the artefact that closes it. Work through it and you finish holding an evidence pack rather than a tick list.

How to use this checklist

Each line asks three questions in order: what does the regulation require, where does it say so, and which document in your estate answers it. The third question is the one that decides. If you cannot name the file, its version and its owner, the line is not done. A control that exists in practice but not on paper is indistinguishable, from the outside, from a control that does not exist.

Two calibrations apply before you start. Article 4 requires the framework to be implemented proportionately, taking account of your size, overall risk profile, and the nature, scale and complexity of your services. Article 16 goes further for the categories of entity it names, setting out a simplified ICT risk management framework. Neither is a discount on evidence: a proportionate control still has to be written down, and the reasoning that made it proportionate is itself an artefact worth keeping.

If you would rather score your position first and read afterwards, the interactive DORA compliance checklist walks the same ground as a self-assessment and keeps your progress in the browser. This article is the reference behind it: what each item means, and what closes it.

The five pillars at a glance

Only the first four carry obligations every financial entity must meet. Article 45 is drafted as a permission rather than a duty, which changes what you have to show. That distinction is covered in its own section below, because presenting a voluntary arrangement as a mandatory control is a common and avoidable finding.

Step 0: settle scope before you tick anything

Scope decisions govern every line that follows. An entity that starts building controls before it has written down which category it falls into, and which of its functions are critical or important, ends up with a framework nobody can defend because nobody can explain what it covers.

The definition at Article 3(22) is the hinge of the whole regulation. A function is critical or important where a disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services and activities, or where discontinued or defective performance would materially impair continued compliance with the conditions and obligations of its authorisation. Any single limb is enough. Run the test explicitly, function by function, and write the reasoning down: our guide to evidencing CIF designations sets out what that record contains, and the critical or important functions guide works through the definition itself.

Pillar 1: ICT risk management (Articles 5 to 16)

This is the largest pillar by article count and by effort. It is also the one where checklists most often drift into generic security hygiene. Encryption and multi-factor authentication belong here, but they are not what a reviewer opens first. They open the framework document and look for a date, a version and an approval.

Governance and framework

The follow-up log is the item most often missing. An internal audit report with open findings and no closure trail reads, to a supervisor, as a control that identified a problem and stopped there.

Identification

Article 8 is where most programmes underestimate the work. Mapping assets to functions is not an inventory export: it is the join between what the business does and what the technology runs, and it is the input to every later pillar. Testing scope, register entries and impact tolerances all read from it. Our walkthrough of mapping ICT assets and functions covers the sequence, and setting defensible impact tolerances covers the thresholds that follow.

Protection and prevention

Access recertification and change approval are the two lines here that generate real findings, because both leave dated trails that either exist or do not. Change governance is worth its own attention where production data is involved: see database change governance under DORA.

Detection

The out-of-hours line matters more than it looks. Pillar 2 runs on a clock that starts when an incident is classified as major, and classification cannot wait for Monday morning.

Response, recovery and continuity

Backups that run are not backups that restore. The evidence that closes the Article 12 line is a restoration test on a system that supports a critical or important function, with a measured recovery time compared against the objective you set.

Learning, evolving and communication

Article 13(6) is the line most often treated as optional, and it is not: the wording makes the modules compulsory within the staff training scheme, covering all employees and senior management, with provision for including ICT third-party service providers where appropriate. The separate board duty sits at Article 5(4). Both are set out in detail in our guide to DORA training requirements for board and staff.

Pillar 2: incident management and reporting (Articles 17 to 23)

This pillar is judged on timing, and timing is judged on records. Every deadline runs from a moment somebody decided something, which means the decision needs a timestamp and an owner.

The reporting timeline runs in three stages: an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report within one month. The clock starts at classification, which is precisely why classification cannot be allowed to drift: delaying the decision does not delay the deadline. The practical readiness test is whether a named person, reachable at three in the morning on a Sunday, is empowered to classify an incident as major without convening anybody. Our step-by-step incident reporting guide covers the submission mechanics, and the RTS on incident reporting sets out the classification criteria in full.

Pillar 3: digital operational resilience testing (Articles 24 to 27)

Testing is where scope decisions made in Article 8 come back to be checked. If the asset-to-function mapping is thin, the testing programme cannot be shown to cover the right systems, and the whole pillar becomes hard to defend.

Two distinctions save time here. The yearly obligation at Article 24(6) applies to every entity in scope and attaches to systems supporting critical or important functions. TLPT under Article 26 applies only to entities identified for it by the competent authority, and runs on a three-year cycle. Conflating the two produces either an over-engineered programme or a gap, depending on which way the confusion runs. The TLPT reference page covers designation and the TIBER-EU alignment, and the phase-by-phase TLPT methodology covers execution.

Pillar 4: ICT third-party risk management (Articles 28 to 44)

This pillar carries the longest lead times of the five. Contract repapering depends on counterparties who have their own queues, and the Register of Information depends on data that usually lives in several systems that were never designed to be joined. Both are measured in months.

Two failure patterns dominate. The first is due diligence that stops at signature: a thorough pre-contract assessment, then no monitoring, no reassessment and no evidence of ongoing oversight. Article 28(1) frames third-party risk as continuous, and the register is the artefact that proves continuity. The second is the exit plan that exists as a paragraph. An exit strategy that has never been costed, sequenced or tested against a date will not survive a question about how long a migration would take. Our guides to the Register of Information submission and the third-party risk register methodology cover both artefacts in detail.

Articles 31 to 44 govern the oversight framework for ICT third-party service providers designated as critical (CTPPs) by the European Supervisory Authorities. Those articles bind the designated providers and their lead overseers rather than you, but two consequences reach your file: knowing whether any of your providers carries the designation, and understanding that the oversight recommendations issued to them may change the service you receive.

Pillar 5: information and intelligence sharing (Article 45)

Article 45 permits financial entities to exchange cyber threat information and intelligence among themselves, within trusted communities and under arrangements that protect the sensitive nature of what is shared. It is drafted as a permission, not an obligation, which is why the checklist line here is different in kind from the four pillars above.

A checklist that presents membership of a sharing community as a mandatory control overstates the regulation. A checklist that omits Article 45 entirely misses the notification duty that attaches once you do participate. Recording the decision, in either direction, closes the line.

The evidence pack a reviewer opens first

Across supervisory conversations and internal audits, the same small set of documents gets requested before anything else. Assembling them as a pack, rather than retrieving them under time pressure, is the single highest-return preparation a programme can make.

• The ICT risk management framework, with the board approval and the date of the last review.
• The list of critical or important functions, with the decision record behind each designation.
• The Register of Information, current, with the CIF flag populated.
• The incident log for the period, and the reports submitted for any major incident.
• The testing coverage matrix: every CIF-supporting system, its last test, and the outcome.
• The contract clause mapping against Articles 30(2) and 30(3).
• Exit plans for arrangements supporting critical or important functions.
• Training completion records, including the management body log under Article 5(4).
• The internal audit reports on the framework, with the follow-up log closing the findings.

Nine documents. If any of them cannot be produced in an afternoon, that is the finding, and it is better discovered by you than by somebody else.

Six checks that fail most often

1. The CIF list has no reasoning behind it. Names of functions, no record of the Article 3(22) test. Everything downstream inherits the weakness.
2. The register is a snapshot. Built for a deadline, accurate on the day, unmaintained afterwards. Article 28(3) expects a living artefact.
3. Restoration was never tested. Backup jobs succeed, and nobody has measured a recovery against the objective.
4. Classification has no owner out of hours. The four-hour clock cannot start if nobody is empowered to start it.
5. Exit plans are paragraphs. No sequence, no cost, no tested duration, no owner.
6. Board training is assumed. Article 5(4) is a duty of the members themselves, and it needs its own log rather than a line in the staff training report.

None of these are exotic. They are what happens when a programme optimises for coverage of a checklist rather than for the strength of the record behind each line.

On penalties, briefly

Article 50 requires Member States to give competent authorities the power to apply administrative penalties and remedial measures, and leaves the rules to national law. That means your exposure depends on your competent authority rather than on a single European figure, and it is why widely repeated percentage-of-turnover caps do not come from DORA. The detail, with the verbatim text, is set out in our guide to DORA penalties and enforcement.

Where certification fits

DORA nowhere requires a certificate. What Article 13(6) requires is training that happened, delivered as a compulsory module, with completion recorded per person; what Article 5(4) requires is that management body members maintain the knowledge to assess ICT risk. A verifiable certificate is the cleanest per-person evidence either duty can produce, and it doubles as the thing that gets a compliance professional recognised for work they already do.

The free DORA Fundamentals course covers the five pillars in the sequence this checklist follows and ends in a certificate, which makes it a workable baseline module for a whole team. Role-specific credentials go deeper where a remit demands it: ICT risk, third-party risk, incident reporting, TLPT, contract management. The full catalogue, with what each programme certifies, is on the DORA certification page.