# DORA Compliance Checklist 2026: Practical Implementation Guide

Source: https://www.cyadviso.com/dora-compliance-guide
Last reviewed: 2026-04-29
Tags: DORA

DORA compliance checklist for 2026: scope, ICT risk framework, incident reporting, resilience testing, third-party risk, evidence and governance management.

---

**Last reviewed: 29 April 2026** — Format: 8-step numbered checklist. Estimated reading time: 5 min.

**Key takeaways**

- DORA — [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554) — has applied since **17 January 2025**. Compliance is an operating discipline, not a one-off project.
- Core obligations: an approved ICT risk management framework, incident classification + reporting, a Register of Information, resilience testing, and ICT risk in board reporting.
- Supervisors and partners ask for **current evidence**, not policy PDFs — keep a living evidence index.
- Fastest path for an EMI / PI / CASP: confirm scope and competent authority → stand up the framework → operate the workflows → maintain the evidence.

## Short answer

DORA compliance in 2026 is an operating discipline, not a readiness slogan.

The Digital Operational Resilience Act — [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554) — has applied since **17 January 2025**. Financial entities now need current evidence that ICT risk, incident reporting, resilience testing and ICT third-party risk controls are in place and working.

For most EU financial entities, the practical checklist is:

1. confirm DORA scope and competent authority;
2. approve and operate an ICT risk management framework;
3. maintain an incident classification and reporting workflow;
4. keep a Register of Information for ICT third-party arrangements;
5. test digital operational resilience and close findings;
6. report ICT risk to the management body;
7. maintain an evidence index for supervisory or partner review.

This guide is tactical — a structured checklist for teams working through implementation. For the broader fintech SMB roadmap, see [DORA Compliance Guide for European Fintech SMBs](/comprehensive-guide-dora-compliance-fintech-smb). For the regulation's legal obligations by chapter, see [DORA Requirements in 2026](/dora-requirements-2025).

## DORA compliance checklist at a glance

| Area | What must exist | Evidence to keep | Common owner |
|---|---|---|---|
| Scope | Entity and service scope under DORA | Licence map, entity map, NCA mapping | Compliance |
| Governance | ICT risk management framework | Approved framework, board minutes, review history | CEO / Board / Risk |
| ICT risk | Risks, controls and owners | ICT risk register, control mapping, remediation tracker | CTO / CISO |
| Incidents | Classification and reporting process | Incident log, timestamps, classification rationale | Security / Operations |
| Third parties | Register and supplier controls | Register of Information, supplier assessments, contract tracker | Risk / Procurement |
| Testing | Resilience test programme | Test plan, reports, failed assumptions, remediation | CTO / Security |
| Continuity | Recovery and communication plans | BCP/DR plans, RTO/RPO evidence, tabletop notes | Operations |
| Evidence | Review-ready pack | Evidence index and document owner list | Compliance / PMO |

The objective is not to create paperwork for its own sake. The objective is to prove that operational resilience is governed, tested and improved.

## Step 1: Confirm scope and authority

DORA applies to financial entities listed in Article 2. For fintechs and digitally dependent financial firms, common categories include:

- credit institutions;
- payment institutions;
- electronic money institutions;
- investment firms;
- crypto-asset service providers authorised under MiCA;
- insurance and reinsurance undertakings;
- other financial entities listed in the Regulation.

The first implementation step is to create a scope note. It should identify:

- the regulated legal entity;
- licence type;
- country of authorisation;
- relevant national competent authority;
- critical or important functions;
- ICT services supporting those functions.

Do not leave this as an informal assumption. Scope decisions affect incident reporting, Register of Information preparation, supplier criticality and board oversight.

### Scope evidence table

| Question | Evidence |
|---|---|
| Which legal entity is regulated? | Licence register extract or internal entity map |
| Which authority supervises it? | NCA mapping by jurisdiction and licence type |
| Which services are critical or important? | Business impact analysis or critical-function register |
| Which ICT systems support those services? | Asset inventory and dependency map |
| Which third parties support those systems? | Supplier register and Register of Information |

For jurisdiction-specific NCA links, use the [DORA National Competent Authorities selected-jurisdiction hub](/dora-national-competent-authorities).

## Step 2: Build the ICT risk management framework

DORA expects financial entities to maintain an ICT risk management framework approved and overseen by the management body. For a practical implementation, the framework should connect:

- ICT governance and roles;
- asset and dependency inventory;
- critical or important functions;
- risk identification and assessment method;
- security controls;
- incident management;
- business continuity and disaster recovery;
- resilience testing;
- third-party ICT risk;
- reporting and review cadence.

The framework should not be a static policy. It should be linked to a live ICT risk register, control owners and remediation tracking.

### Minimum framework artefacts

| Artefact | Purpose | Review cadence |
|---|---|---|
| ICT risk management framework | Describes governance and control model | At least annually and after material change |
| ICT risk register | Tracks material ICT risks and treatments | Quarterly or after material change |
| Asset inventory | Shows systems and data supporting services | Monthly/quarterly depending on change rate |
| Control owner matrix | Shows who operates each control | On role or process change |
| Remediation tracker | Shows open gaps and closure evidence | Weekly/monthly until closed |

## Step 3: Operate incident classification and reporting

DORA requires financial entities to detect, manage, classify and report major ICT-related incidents. Article 19 establishes the reporting duty; the detailed classification and reporting approach is set through related EU technical standards.

Your incident process should record:

- when the event was detected;
- when it was assessed as ICT-related;
- when it was classified;
- who approved the classification;
- whether NCA reporting was triggered;
- which services, customers, providers or data were affected;
- what remediation was opened after closure.

### Major ICT incident reporting timeline

| Report | Timing logic | Evidence |
|---|---|---|
| Initial notification | Within 4 hours after classification as major, and no later than 24 hours after detection/awareness | Detection timestamp, classification timestamp, approver, submitted notification |
| Intermediate report | Within 72 hours of the initial notification | Updated impact, containment status, affected services |
| Final report | Within one month of the latest intermediate report | Root cause, remediation, lessons learned |

Local channels and templates are set by the competent authority. Verify the current submission route before filing.

## Step 4: Maintain the Register of Information

DORA Article 28 requires financial entities to maintain a Register of Information for ICT third-party service arrangements. This is one of the most important DORA evidence artefacts because it connects suppliers, services, functions and contractual arrangements.

The register should help answer:

- Which ICT third-party providers do we use?
- Which legal entity uses the service?
- Which service or function does the provider support?
- Is the supported function critical or important?
- Where is the provider located?
- Are subcontractors involved?
- What is the contract status?
- Is there an exit strategy?

### Register implementation checklist

| Task | Output |
|---|---|
| Consolidate supplier lists | One ICT supplier universe |
| Classify ICT services | In-scope / out-of-scope decision |
| Map to functions | Provider to service to critical function |
| Review contracts | Clause tracker for Article 30 requirements |
| Add ownership | Business owner, technical owner, contract owner |
| Validate completeness | Review against finance, procurement and system inventories |

For a deeper guide, see [DORA Register of Information: A Complete Guide for Financial Institutions](/dora-register-of-information).

## Step 5: Review ICT third-party contracts

DORA third-party risk is not only the register. Contracts for ICT services, especially those supporting critical or important functions, need the right operational and legal provisions.

Relevant contract areas include:

- service description and locations;
- security requirements;
- access and audit rights;
- incident notification and support;
- subcontracting conditions;
- data protection and data return;
- business continuity and disaster recovery;
- exit support and transition assistance;
- termination rights.

The practical deliverable is a clause tracker.

| Contract area | Evidence |
|---|---|
| Audit/access rights | Clause reference and gap status |
| Incident support | Notification times and cooperation obligations |
| BCDR | Recovery commitments and test/support obligations |
| Subcontracting | Approval / notification mechanism |
| Exit | Transition support, data return, deletion, portability |

## Step 6: Test resilience and close findings

DORA expects resilience testing based on risk and criticality. For many firms, the immediate requirement is not sophisticated testing. It is a credible annual testing programme that produces findings and closes them.

Useful tests include:

- backup restore test;
- disaster recovery test;
- payment or customer-service outage tabletop;
- third-party failure scenario;
- vulnerability assessment;
- access-control review;
- incident response exercise.

Threat-led penetration testing under Article 26 applies at least every three years to financial entities identified by competent authorities. Do not present TLPT as universal. Maintain proportionate testing evidence unless your authority has identified the entity for TLPT.

### Testing evidence

| Test | What to record |
|---|---|
| Backup restore | System, date, recovery time, exceptions |
| DR test | Scenario, affected services, RTO/RPO, decision log |
| Incident tabletop | Participants, decisions, gaps, actions |
| Supplier failure test | Provider, impacted function, workaround |
| Vulnerability assessment | Findings, severity, owner, closure evidence |

## Step 7: Put DORA into board reporting

DORA governance requires management-body oversight. The board or management body does not need to read every technical log, but it does need a clear view of ICT risk, incidents, suppliers, resilience and remediation.

A practical DORA board pack includes:

| Section | What to show |
|---|---|
| ICT risk posture | Top ICT risks and changes since last report |
| Incidents | Significant events, DORA classification decisions, lessons learned |
| Third-party risk | Critical providers, contract gaps, concentration risks |
| Testing | Tests performed, failed assumptions, remediation |
| Compliance | Register of Information status, NCA interactions |
| Decisions | Risk acceptances, budget, ownership changes |

The management-body evidence is often what separates a real DORA programme from a document set.

## Step 8: Create the DORA evidence index

When a supervisor, partner bank, auditor or investor asks for DORA evidence, sending scattered documents creates avoidable friction. Maintain an evidence index with owner, location, review date and status.

| Evidence category | Examples |
|---|---|
| Governance | ICT risk framework, board pack, approval minutes |
| Scope | Licence map, NCA mapping, critical-function register |
| ICT risk | Risk register, control owner matrix, remediation tracker |
| Incident reporting | Incident policy, classification log, submitted reports |
| Third parties | Register of Information, supplier assessments, contract tracker |
| Resilience testing | Test plan, reports, action tracker |
| BCDR | Continuity plan, DR plan, RTO/RPO evidence |

This index should be reviewed before every major partner-bank due diligence, supervisory interaction or board review.

## 30-day implementation plan

If the programme is immature, start with a focused 30-day sprint.

| Week | Workstream | Output |
|---|---|---|
| Week 1 | Scope and evidence inventory | Entity map, NCA map, document inventory |
| Week 2 | ICT risk and incidents | Risk register draft, incident classification workflow |
| Week 3 | Third parties | Supplier criticality map, Register of Information starter |
| Week 4 | Testing and governance | Test plan, board pack, remediation tracker |

Do not wait for every policy to be perfect. DORA maturity improves through operating cadence: review, test, report, remediate.

## Common implementation mistakes

### Mistake 1: Treating DORA as a policy project

Policies are only useful if they point to live controls and evidence. A reviewer will ask how the process operated, not only whether the document exists.

### Mistake 2: Keeping the supplier register separate from the Register of Information

Procurement lists, finance vendor lists and security supplier lists often diverge. DORA requires a coherent view of ICT third-party arrangements.

### Mistake 3: Missing the incident decision trail

The reporting timeline depends on detection and classification. If timestamps and approvers are missing, the report is hard to defend.

### Mistake 4: Overclaiming TLPT

Threat-led penetration testing is competent-authority-led for identified entities. A smaller firm should show proportionate testing rather than claim a universal TLPT obligation.

### Mistake 5: No board evidence

If ICT risk never reaches the management body, DORA governance is weak even if the technical team is doing useful work.

## Related reading

- [DORA Compliance Guide for European Fintech SMBs: 2026 Evidence Roadmap](/comprehensive-guide-dora-compliance-fintech-smb)
- [DORA Incident Reporting 2026: Initial Notification, Intermediate Report and Final Report Timeline](/dora-incident-reporting)
- [DORA Register of Information: A Complete Guide for Financial Institutions](/dora-register-of-information)
- [DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026](/dora-business-continuity-and-disaster-recovery)
- [EBA Guidelines on ICT and Security Risk Management After DORA](/ebas-guidelines-on-ict-and-security-risk-management)
- [DORA Requirements in 2026: 10 Controls Financial Entities Must Keep Current](/dora-requirements-2025)

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [European Banking Authority — Digital Operational Resilience Act (DORA)](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [EBA — Joint Technical Standards on major incident reporting](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting)
- [ESMA — Digital Operational Resilience Act (DORA)](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora)
- [EIOPA — Digital Operational Resilience Act (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en)

## Bottom line

A DORA compliance checklist should not end with “policy drafted”.

In 2026, the useful end state is:

- scope is clear;
- risks and controls have owners;
- incidents are classified with timestamps;
- suppliers are mapped to critical services;
- contracts have tracked gaps;
- resilience tests create remediation;
- the management body sees the risk picture;
- evidence is indexed and current.

That is the practical standard for DORA readiness after the application date.

## FAQ

### What should a DORA compliance checklist include in 2026?

A practical DORA checklist should include scope confirmation, NCA mapping, ICT risk governance, incident classification and reporting, the Register of Information, ICT third-party contract review, resilience testing, business continuity evidence, board reporting and an evidence index.

### Is DORA still a future readiness project?

No. DORA has applied since 17 January 2025. In 2026, the question is whether the financial entity can show current evidence that the required ICT risk, incident, testing and third-party risk processes operate in practice.

### Who owns DORA compliance inside a fintech?

Ownership is shared, but it should not be unmanaged. The management body is accountable for oversight, while compliance, risk, security, engineering, operations, procurement and legal usually own different evidence workstreams. A named ICT risk, CISO or vCISO lead should coordinate the operating model.

### What is the most important DORA evidence artefact?

There is no single artefact that proves compliance. In practice, the evidence index is the most useful control point because it connects scope, risks, incidents, suppliers, testing, board reporting and remediation into one review-ready view.

### Does every DORA entity need TLPT?

No. Threat-led penetration testing under DORA Article 26 applies to financial entities identified by competent authorities. Other entities still need proportionate digital operational resilience testing, but they should not describe TLPT as a universal obligation.

### Where should a fintech verify DORA incident reporting channels?

The current reporting channel should be verified with the relevant national competent authority. DORA creates the reporting obligation, while local submission routes, portals and templates depend on the jurisdiction and authority.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-compliance-guide