The DORA compliance checklist for EU financial entities.
A practical, pillar-by-pillar checklist for the Digital Operational Resilience Act — every obligation, the artefact your competent authority will ask for, and the Lojycal surface that produces it. Use it as your gap analysis, your kick-off plan, or your supervisory-dialogue cheat sheet.
Who this checklist is for
DORA applies to ~22,000 EU financial entities and to the ICT third-party providers that serve them. This checklist is sized for the in-scope teams who actually have to deliver the evidence.
Banks & credit institutions
From SIs supervised by the ECB to less-significant institutions under national authorities — DORA replaces fragmented ICT guidance with one regulation.
Payment, e-money & investment firms
Payment institutions, e-money institutions, MiFID investment firms, crypto-asset service providers under MiCAR — full DORA scope.
Insurers, IORPs & market infrastructure
Insurance and reinsurance undertakings, IORPs, CSDs, CCPs, trading venues, trade repositories, credit rating agencies, crowdfunding service providers.
Critical ICT third-party providers
ICT providers designated as CTPPs by the Lead Overseer (ESA-level) — and any ICT supplier in scope as a critical-or-important arrangement of a regulated entity.
The five DORA pillars at a glance
Every DORA obligation maps to one of these five pillars. The checklist below is grouped the same way.
1. ICT risk management
A board-approved framework: identify, protect, detect, respond, recover, learn, communicate. Title II of DORA.
Articles 5–16
2. ICT incident reporting
Detect, classify, report. Initial, intermediate and final notifications to the competent authority within RTS deadlines.
Articles 17–23
3. Resilience testing
Risk-based testing programme. TLPT (threat-led penetration testing) every three years for significant entities.
Articles 24–27
4. ICT third-party risk
Register of information, contractual essentials, criticality tagging, exit strategy, sub-outsourcing oversight.
Articles 28–44
The DORA compliance checklist
Tick each item when you can produce the artefact on demand — not when a policy document mentions it. Each row links the obligation to the Lojycal surface that auto-generates the evidence.
| Pillar | Checklist item | Auto-generated by |
|---|---|---|
| 1. ICT risk | Board-approved ICT risk management framework (Art. 6) with named accountable owner | Trust Center → Risk + Posture |
| 1. ICT risk | ICT asset & dependency inventory, classified by criticality (Art. 8) | Asset Lifecycle |
| 1. ICT risk | Protection & prevention controls: cryptography, access management, network segmentation (Art. 9) | KMS + RBAC + AAL2 |
| 1. ICT risk | Detection mechanisms with documented alert thresholds (Art. 10) | SIEM + Anomaly Engine |
| 1. ICT risk | Response & recovery procedures, BCP and DRP tested at least annually (Art. 11) | Trust Center → Hardening |
| 1. ICT risk | Backup, restoration and recovery procedures with documented RTO/RPO (Art. 12) | Asset Lifecycle + Backup Evidence |
| 1. ICT risk | Learning & evolving — post-incident reviews fed back into the framework (Art. 13) | Incident Ledger |
| 2. Incident reporting | ICT-related incident management process with documented classification criteria (Art. 17) | Incident Ledger |
| 2. Incident reporting | Classification per RTS: clients affected, data losses, duration, geographical spread, economic impact (Art. 18) | Incident Classifier |
| 2. Incident reporting | Initial / intermediate / final supervisory reports in the official ESA template (Art. 19) | Report Builder |
| 2. Incident reporting | Voluntary notification of significant cyber threats supported (Art. 19(2)) | Incident Ledger |
| 3. Testing | Documented resilience testing programme covering all ICT systems supporting critical functions (Art. 24) | Trust Center → Pentest & Reviews |
| 3. Testing | Test inventory: vulnerability scans, source-code reviews, scenario tests, performance tests (Art. 25) | Trust Center → Pentest |
| 3. Testing | TLPT (Threat-Led Penetration Testing) every 3 years for significant entities (Art. 26) | Trust Center → Pentest uploads |
| 3. Testing | Each finding linked to a remediation ticket and a re-test with signed closure (Art. 27) | Trust Center + Workflows |
| 4. Third-party risk | Register of information on ALL contractual arrangements with ICT third-party providers (Art. 28) | Vendor Governance → TPP Register |
| 4. Third-party risk | Criticality tagging: critical-or-important function vs. other (Art. 28(2)) | Vendor Governance |
| 4. Third-party risk | Pre-contractual due diligence + risk assessment recorded per arrangement (Art. 28(4)) | Vendor Governance → Contract Ledger |
| 4. Third-party risk | Key contractual provisions present: service description, data location, audit rights, exit strategy (Art. 30) | Vendor Governance → Contract Ledger |
| 4. Third-party risk | Concentration risk assessed for each critical ICT third-party arrangement (Art. 29) | Vendor Governance |
| 4. Third-party risk | Sub-outsourcing chain documented for every critical-or-important arrangement (Art. 30(2)(a)) | Vendor Governance → TPP Register |
| 5. Info sharing | Decision recorded on participation in cyber threat information-sharing arrangements (Art. 45) | Trust Center → Governance Log |
| 5. Info sharing | Notification to competent authority of participation in such arrangements | Trust Center |
This checklist is a working compliance aid — not legal advice and not exhaustive. Apply your sector-specific RTS/ITS and your competent authority's expectations. Article references are to Regulation (EU) 2022/2554.
Print it, share it, ship it as signed evidence
Most teams turn DORA into a 200-page Word document. The faster path is a live checklist where every tick is backed by machine-readable evidence — and the whole thing exports as a signed PDF + JSON bundle the day before the supervisory dialogue.
Lojycal writes every workflow run, every dual-control decision, every contract change and every test result to a WORM (write-once, read-many) audit log. The Trust Center bundles a chosen window into a signed Evidence Pack — JSON, CSV and PDF, with a detached HMAC signature using a per-organisation key. The TPP register exports in the exact ESA RTS layout, ready for supervisory submission.
Use the checklist as a 90-day rollout
A typical financial entity moves from 'we have a policy' to 'we can prove it' in a single quarter because the artefacts assemble themselves from live systems.
- Pillar 1 + 4 baseline
Days 0–30 — Framework & scope
Confirm in-scope status. Tick Pillar 1 items by mapping existing ICT controls. Stand up the TPP register from contract data and vendor inventory.
- Pillar 2 + 3 wired up
Days 31–60 — Incident & testing
Wire SIEM/EDR egress to the incident classifier. Tick Pillar 2 items as classification + RTS reports become automated. Run the first resilience test cycle and link findings to remediation tickets.
- Supervisory-ready
Days 61–90 — Rehearsal & evidence
Rehearse the initial/intermediate/final notification flow against a major-incident scenario. Generate a signed Evidence Pack and a TPP register export. Decide on information-sharing arrangements (Pillar 5).
DORA checklist — common questions
Who must comply with DORA?
Article 2 of Regulation (EU) 2022/2554 lists ~20 categories of financial entities: credit institutions, payment & e-money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, insurance & reinsurance undertakings, IORPs, credit rating agencies, crowdfunding service providers, and others. DORA also applies to ICT third-party providers designated as critical (CTPPs) by the Lead Overseer.
When did DORA start applying?
DORA has applied since 17 January 2025. The RTS and ITS technical standards (incident classification, register of information, TLPT, sub-outsourcing) supplement the regulation and apply on the same date or shortly after publication in the Official Journal.
What evidence do supervisors actually ask for?
Expect requests for: the ICT risk framework (board-signed), the asset & dependency inventory, evidence of testing (TLPT for significant entities), the register of information on third-party arrangements in the ESA RTS template, classification & reporting timelines for any incidents, and proof that findings are remediated and re-tested. Lojycal produces each of these from live data.
Does the checklist replace a DORA gap analysis?
No — it is a faster way to structure one. Treat each row as a binary: can you produce the artefact today, or not? The rows where you cannot are your gap. Lojycal then turns each gap into a workflow that produces the missing artefact automatically.
How does this checklist relate to NIS2?
DORA is lex specialis for the EU financial sector — for in-scope entities its ICT incident reporting and third-party rules override NIS2. The underlying controls overlap substantially, so most NIS2 work counts toward DORA. The checklist above is DORA-specific; see /nis2-compliance-automation for the NIS2 equivalent.
Can I export this checklist as evidence?
Yes. Generate a signed Evidence Pack from the Trust Center — it bundles the ticked items, the underlying artefacts (incident reports, TPP register, test results) and a detached HMAC signature in JSON, CSV and PDF.
Tick every box. Export the proof. Move on.
Stop rewriting DORA documentation each quarter. Use the checklist live, and let Lojycal produce the artefacts behind each tick.