ChecklistEU

EU DORA Checklist

A checklist you can run per entity - and reuse for audits and supervisory requests.

Structured the way teams execute: scope -> controls -> reporting -> testing -> third parties -> evidence.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

DORA compliance is a system rollout. This checklist is built as a program plan you can run per regulated entity and per group layer. For each item: assign an owner, define acceptance criteria, and keep evidence that is exportable and reproducible.

Section 1

Checklist A - Scope memo and proportionality (do this before building controls)

Your first deliverable should be a scope memo per entity (and a group summary) that maps DORA scope and proportionality to concrete workstreams and owners.

This prevents scope drift and mismatched control builds.

Map each legal entity to Article 2 scope category; record competent authority and reporting perimeter.
Document proportionality decisions and any simplified framework usage; record management body approvals.
Identify critical or important functions and top ICT dependencies (including outsourced services).
Define workstreams and owners: ICT risk controls, incident reporting, testing/TLPT, third-party risk + register, governance cadence.
Create an evidence map: where each required artifact lives and how to export it quickly.

Recommended next step

Turn EU DORA Checklist into an operational assessment

Assessment Autopilot can take EU DORA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU DORA Checklist

Start from EU DORA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU DORA

Review your current process, evidence gaps, and next steps for EU DORA Checklist.

Explore next step

Section 2

Checklist B - ICT risk management control baseline (Chapter II + RTS)

DORA expects a coherent ICT risk management framework: governance + asset inventory + control layers + continuity + communications.

Build this baseline as a control library with acceptance criteria and evidence.

Governance: management body accountability, risk tolerance, and periodic reviews.
Asset inventory and dependency mapping: ICT-supported business functions, information assets, ICT assets, and criticality classification (review at least yearly).
Protection: access control, secure configuration, change management, vulnerability management, backup and resilience patterns for critical services.
Detection: monitoring, alerting, anomaly detection, and log integrity for critical functions.
Response and recovery: runbooks, containment procedures, restore objectives, and post-incident reviews.
Communications: internal escalation, external stakeholder communications, and crisis communications integration.

Section 3

Checklist C - Incident management + major incident reporting (Chapter III + RTS)

This is both an operational workflow and a data pipeline. Build a repeatable process with structured outputs and QA.

Your reporting capability is tested under stress; design it to work during outages.

Incident management process exists (Article 17): early warning indicators, tracking/logging/classification, roles and responsibilities, communications, response procedures.
All ICT incidents and significant cyber threats are recorded consistently; root causes are identified, documented and addressed.
Classification criteria and materiality thresholds are implemented (Article 18 + RTS).
Reporting pipeline can produce: initial notification, intermediate updates, and final report with root cause analysis and actual impact figures (Article 19 + RTS time limits).
Client communications workflow exists for major incidents impacting financial interests.
Evidence: incident register exports, report copies, timestamps, and decision logs.

Section 4

Checklist D - Testing program + TLPT readiness (Chapter IV)

Testing should be planned, risk-based, and repeatable. TLPT is a specialized program: build the governance and supplier model early.

Treat testing outputs as compliance evidence and as engineering backlog inputs.

Testing program (Article 24/25): annual plan, test coverage for critical or important functions, independent testing where required, remediation and validation methodology.
Penetration testing and scenario-based testing are scheduled and evidence retained.
TLPT readiness (Article 26): scoping methodology, production-safe testing controls, and authority interaction plan.
Tester selection and contracts satisfy suitability/independence and confidentiality requirements; professional indemnity coverage verified.
Evidence: test reports, remediation tracking, re-test evidence, management summaries.

Section 5

Checklist E - ICT third-party risk: strategy, contracts, concentration, exit, register (Chapter V + RTS)

Third-party risk is a top enforcement focus because it compounds operational risk across the sector.

Build a vendor governance system that produces contract posture and evidence on demand.

ICT third-party risk strategy exists and is reviewed periodically; includes policy for ICT services supporting critical or important functions (Article 28).
Register of information built and maintained (Article 28): entity + (where relevant) sub-consolidated/consolidated; exportable sections for supervisors.
Concentration/substitutability analysis performed for critical/important ICT services; multi-vendor strategy considered (Article 29).
Contract clause baseline implemented (Article 30 + RTS 2024/1773): audit/access, security, subcontracting transparency, incident cooperation, portability and exit rights.
Exit strategies and transition plans documented and tested for key critical/important services.

Section 6

Checklist F - Governance cadence and evidence pack (make compliance sustainable)

DORA is not a one-off. Build a cadence that keeps controls and reporting accurate and current.

Your objective is to reduce "scramble risk" when supervisors request evidence.

RACI per workstream (controls, incident reporting, testing, third-party governance).
Quarterly review: incident trends, control exceptions, vendor concentration, register accuracy.
Annual review: proportionality decisions, testing program effectiveness, TLPT readiness status.
Evidence repository: versioned policies, procedures, control tests, reports, register exports, management approvals.

Primary sources

References and citations

Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)

eur-lex.europa.eu

Referenced sections

Level 2 RTS detailing DORA contractual clause expectations for critical/important ICT services.

Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)

eur-lex.europa.eu

Referenced sections

Level 2 RTS specifying ICT risk management tools/methods/processes and the simplified framework.

Regulation (EU) 2022/2554 (DORA) - Official Journal

eur-lex.europa.eu

Referenced sections

Primary legal text for DORA workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), and ICT third-party risk + register of information (Chapter V).

Related guides