DORA Compliance Checklist 2026

In this article ↓

Short answer
DORA compliance checklist at a glance
Step 1: Confirm scope and authority
Scope evidence table
Step 2: Build the ICT risk management framework
Minimum framework artefacts
Step 3: Operate incident classification and reporting
Major ICT incident reporting timeline
Step 4: Maintain the Register of Information
Register implementation checklist
Step 5: Review ICT third-party contracts
Step 6: Test resilience and close findings
Testing evidence
Step 7: Put DORA into board reporting
Step 8: Create the DORA evidence index
30-day implementation plan
Common implementation mistakes
Mistake 1: Treating DORA as a policy project
Mistake 2: Keeping the supplier register separate from the Register of Information
Mistake 3: Missing the incident decision trail
Mistake 4: Overclaiming TLPT
Mistake 5: No board evidence
Related reading
Primary sources
Bottom line
FAQ
What should a DORA compliance checklist include in 2026?
Is DORA still a future readiness project?
Who owns DORA compliance inside a fintech?
What is the most important DORA evidence artefact?
Does every DORA entity need TLPT?
Where should a fintech verify DORA incident reporting channels?

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

Key takeaways

DORA — Regulation (EU) 2022/2554 — 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 — 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:

confirm DORA scope and competent authority;
approve and operate an ICT risk management framework;
maintain an incident classification and reporting workflow;
keep a Register of Information for ICT third-party arrangements;
test digital operational resilience and close findings;
report ICT risk to the management body;
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. For the regulation's legal obligations by chapter, see DORA Requirements in 2026.

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.

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.

Stuck on the Register of Information or scope mapping?

A 15-minute call with a CISO who has run DORA for EU-licensed EMIs, PIs and CASPs — no pitch, just where you actually stand.

Book a free 15-min call →

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.

Primary sources

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.

DORA Compliance Checklist 2026: Practical Implementation Guide