DORA Compliance Checklist: Assess Your Readiness
DORA is live. Financial entities across the EU now need audit-ready evidence across ICT risk management, incident reporting, resilience testing, third-party oversight, and governance. StartComply turns the DORA compliance checklist into automated workflows, continuous monitoring, and regulator-ready proof.
Trusted by 100+ organisations across Europe
DORA 
ICT Risk 
Resilience Testing 
Third-Party Risk What you need to know about the DORA compliance checklist
- DORA has been fully applicable since 17 January 2025, with no grace period for in-scope financial entities.
- The five DORA pillars are ICT risk management, incident reporting, resilience testing, third-party risk management, and governance with information sharing.
- Major ICT incidents trigger strict timelines: 4-hour early warning, 72-hour intermediate report, and one-month final report.
- All ICT third-party contracts must be reviewed against Article 30 mandatory provisions, including audit rights and exit strategies.
- Management bodies bear ultimate responsibility for the ICT risk management framework under DORA Article 5.
- TLPT is required at least every three years for significant financial entities and must be reported to competent authorities.
- Fines for DORA non-compliance can reach €10 million or 2% of global annual turnover for financial entities.
Source page: checklist.md. Last updated January 2025.
DORA is live. A checklist only works if it produces evidence.
Five pillars with operational proof
- ICT risk management framework approved by the management body
- All ICT assets identified, classified, and mapped to dependencies
- Major ICT incident reporting workflow for 4-hour, 72-hour, and one-month deadlines
- Annual digital operational resilience testing, with TLPT where required
- Complete ICT third-party register with criticality classification and contract evidence
- Governance, audit, and remediation records available on demand
Audit reality: claiming compliance is not the same as proving it. DORA evidence must show what happened, when, who owned it, and how gaps were remediated.
Spreadsheets, static documents, and scattered evidence
- No reliable audit trail when evidence sits in email threads
- Asset inventories become outdated as systems and vendors change
- Incident classification and escalation deadlines depend on manual reminders
- Testing schedules, findings, and remediation actions live in separate files
- Third-party contract gaps remain unresolved until an audit exposes them
- Board reporting shows policies, but not always operational evidence
The compliance gap: a checklist is useful only when every item is linked to live controls, owners, documents, dates, and remediation status.
What the DORA Compliance Checklist Covers
Pillar 1: ICT Risk Management Framework
DORA requires a comprehensive ICT risk management framework that is part of the organisation’s overall risk management system.
- Management body approval and accountability
- ICT asset inventory and dependency mapping
- Access controls, monitoring, protection, and prevention
- Business continuity and recovery objectives tested in practice
Pillar 2: ICT-Related Incident Reporting
Major ICT-related incidents trigger strict reporting obligations to the competent authority once classified.
- 4-hour early warning process
- 72-hour intermediate report template
- One-month final report workflow
- Cyber threat reporting for significant threats
Pillar 3: Digital Operational Resilience Testing
All in-scope entities must run recurring resilience tests, while significant entities may also need Threat-Led Penetration Testing.
- Annual vulnerability and security testing
- Business continuity and disaster recovery exercises
- TLPT scope and approved external testers where required
- Remediation plans for critical findings
Pillar 4: Third-Party ICT Risk Management
DORA makes ICT third-party oversight a formal compliance obligation, not a procurement side task.
- Complete ICT third-party provider register
- Criticality classification and concentration risk checks
- Article 30 contract provisions, including audit rights
- Exit strategies and ongoing provider monitoring
Pillar 5: Governance and Information Sharing
DORA governance sits with the management body, with audit, reporting, and operational resilience embedded across the organisation.
- Board-level ICT risk approval and training evidence
- Annual audit of the ICT risk framework
- Named owners across all five DORA pillars
- Documented decision on threat intelligence sharing
DORA Compliance Checklist: Platform vs. Manual Management
A DORA checklist must produce current, traceable evidence across all five pillars. Static files can list obligations, but they rarely prove operational compliance.
StartComply converts checklist items into owners, workflows, evidence, monitoring, deadlines, and remediation records.
What Is a DORA Compliance Checklist?
A DORA compliance checklist is a structured way to assess whether your organisation meets the mandatory requirements of the Digital Operational Resilience Act. It should cover the regulation’s five core pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and governance with information sharing.
The checklist is not just a documentation exercise. Regulators assessing DORA compliance will look at your governance approvals, incident logs, test results, third-party contracts, remediation actions, and audit trail. Being able to evidence each checklist item is what turns a compliance statement into a defensible position.
In this context, ICT means the technology, infrastructure, cloud services, SaaS vendors, outsourced operations, and digital systems your organisation relies on to deliver financial services. That means the checklist must cover both internal controls and external provider dependencies.
Practical rule: every checklist item should map to an owner, evidence source, review cadence, control status, and remediation path. If one of those is missing, the item is not audit-ready.
The Five DORA Checklist Pillars
ICT Risk Management Framework Articles 5-13
Maintain a management-approved ICT risk management framework, identify and classify ICT assets, define access controls, monitor ICT systems, test continuity plans, and feed post-incident learnings back into the framework.
ICT-Related Incident Reporting Articles 17-23
Document incident ownership, classify major ICT incidents correctly, trigger the 4-hour early warning, prepare the 72-hour intermediate report, and track the final report within one month.
Digital Operational Resilience Testing Articles 24-27
Run annual resilience testing across vulnerability assessments, network tests, application security tests, and recovery exercises. Significant financial entities must also plan TLPT at least every three years. See the DORA framework guide for how testing fits into the broader regulatory architecture.
Third-Party ICT Risk Management Articles 28-44
Maintain a complete ICT third-party register, classify criticality, review contracts against Article 30, confirm audit rights, document exit strategies, and monitor critical providers after onboarding.
Governance and Information Sharing Articles 5, 6, 45
Evidence management-body accountability, ICT risk training, annual audit of the ICT framework, named owners across DORA pillars, and a documented decision on threat intelligence sharing.
Client Testimonials
“We evaluated enterprise platforms costing 10x more. StartComply does what we need at a price that makes sense.”Elena Kowalski
“Finally, a compliance tool that understands European regulations. StartComply got us audit-ready in weeks, not months.”Maria Papadopoulou
“The AI policy engine alone saved us hundreds of hours. And the third-party risk management is exactly what DORA requires.”Thomas Müller
Frequently Asked Questions About the DORA Compliance Checklist
Which organisations must follow a DORA compliance checklist?
DORA applies to more than 20 categories of financial entity operating in the EU, including credit institutions, payment institutions, investment firms, insurance undertakings, crypto-asset service providers, and critical ICT third-party service providers. If your organisation provides financial services in the EU or provides ICT services to EU financial entities, you are likely in scope. Entity type determines which obligations apply and at what level of intensity.
How often should I review my DORA compliance checklist?
DORA does not set a single review frequency for the entire checklist because different obligations have different cadences. The ICT risk management framework must be reviewed at least annually and after every major ICT incident. Basic resilience testing must occur at least annually. TLPT occurs at least every three years where required. Third-party registers must be updated continuously as providers change.
What are the fines for failing to meet DORA requirements?
For financial entities, DORA fines are set by national competent authorities and can reach €10 million or 2% of total annual worldwide turnover, whichever is higher. For critical ICT third-party service providers under direct European Supervisory Authority oversight, periodic penalty payments can reach €1 million per day.
Does DORA apply to ICT suppliers as well as financial firms?
Yes. ICT third-party service providers designated as critical by the European Supervisory Authorities fall under DORA’s direct oversight framework under Articles 31 to 44. Even non-critical ICT providers that contract with in-scope financial entities must meet the Article 30 contractual requirements requested by their financial entity clients.
What is the difference between basic testing and TLPT under DORA?
Basic digital resilience testing under Articles 24 and 25 applies to all in-scope financial entities and includes vulnerability assessments, network security tests, and business continuity exercises. Threat-Led Penetration Testing under Articles 26 and 27 is an advanced requirement for significant financial entities identified by competent authorities.
Can I use a spreadsheet to manage DORA compliance?
Technically yes, but it is a significant operational risk. DORA requires continuous asset monitoring, strict incident reporting timelines, ongoing third-party oversight, and recurring testing cycles. Spreadsheets create version control problems, audit trail gaps, and manual errors that are difficult to defend to a regulator.
Turn Your DORA Checklist Into Audit-Ready Evidence.
Who Does DORA Apply To?
DORA applies to more than 20 categories of financial entity operating in the EU. This includes traditional financial institutions, market participants, insurance organisations, crypto-asset service providers, and ICT third-party providers that support financial entities.
The exact obligations depend on the entity type, proportionality, supervisory expectations, and whether advanced requirements such as TLPT apply:
Management accountability is central. DORA compliance cannot sit only with IT because the management body bears ultimate responsibility for the ICT risk management framework.
DORA Compliance Timeline: Where Things Stand Now
DORA entered into force, starting the implementation period for in-scope financial entities and ICT third-party service providers.
DORA became fully applicable across the EU. In-scope entities are expected to meet operational resilience requirements, not just prepare for them.
Competent authorities review governance documentation, incident reporting processes, resilience testing evidence, and third-party ICT risk controls.
There is no grace period. Organisations still relying on spreadsheets for evidence, incident deadlines, testing schedules, or ICT third-party registers are carrying active regulatory risk.
Checklist priority:
Start with the areas that create the clearest audit trail: major incident reporting, ICT third-party contract gaps, asset inventory completeness, testing evidence, and management-body approvals.
The 10 Components of a Complete DORA Checklist
Use these components to move from a static checklist to an evidence-backed compliance programme.
Management-body approval
Formal approval of the ICT risk management framework, with board-level awareness of material risks, incidents, testing results, and remediation.
ICT asset inventory
Documented inventory of information assets, software, hardware, infrastructure, systems, and third-party dependencies.
Access controls and monitoring
Operational access controls, privileged access review, anomaly detection, and continuous monitoring across ICT systems.
Business continuity and recovery
Documented business continuity plans, crisis communication processes, RTOs, RPOs, and tested recovery procedures.
Incident classification and reporting
Clear incident ownership, classification criteria, early warning, intermediate report, final report, and significant cyber threat reporting.
Resilience testing programme
Annual vulnerability, network, application, continuity, and disaster recovery testing, with findings tracked to remediation.
TLPT readiness
Threat-Led Penetration Testing scope, approved provider selection, test scheduling, reporting, and remediation for significant entities where required.
ICT third-party register
Complete provider register with criticality classification, due diligence records, concentration risk, and ongoing monitoring.
Article 30 contract review
Contractual evidence for audit rights, access rights, security standards, data portability, business continuity, sub-outsourcing, and exit strategies.
Audit and remediation trail
Annual ICT framework audit, management reporting, assigned owners, tracked findings, and evidence that remediation was completed.
