DORA Requirements: A Plain-Language Breakdown
DORA is live. Every financial entity operating in the EU must now evidence ICT risk management, incident reporting, resilience testing, third-party controls, and board-level governance. StartComply maps every DORA requirement to a workflow, so your team can prove compliance continuously.
Trusted by 100+ organisations across Europe
DORA 
ICT Risk 
Incident Reporting 
Resilience Testing 
Third-Party Risk What you need to know about DORA requirements
- DORA requirements have been legally binding since 17 January 2025, with fines up to €10 million or 2% of global annual turnover for financial entities.
- The five pillars are ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.
- DORA Article 5 places direct legal responsibility for the ICT risk management framework on the management body.
- Incident reporting under Article 19 requires a 24-hour early warning and a 72-hour detailed notification after a major incident is classified.
- Third-party ICT contracts must meet Article 30 requirements in full, including pre-2025 contracts with no grandfathering.
- TLPT under Article 26 is mandatory for significant financial entities at least every three years, covering live production systems.
- Asset registers, test results, board approvals, and incident logs must be continuously evidenced, not created once and filed away.
Source: requirements.md. Last updated January 2025.
DORA requirements are live.
The evidence burden sits with leadership.
A governed, evidenced, continuous DORA programme
- Article 5: management body defines, approves, and oversees the ICT risk management framework
- Article 6 and Article 8: ICT risk framework, asset mapping, and interdependency documentation
- Article 17 and Article 19: incident classification plus 24-hour, 72-hour, and final reporting workflows
- Article 24 and Article 26: resilience testing and TLPT for significant financial entities
- Article 28 and Article 30: ICT third-party register, concentration risk, exit strategies, and contract clauses
Penalty exposure: financial entities can face fines up to €10 million or 2% of global annual turnover, with additional exposure for critical ICT third-party providers.
Manual registers, slow classification, and incomplete contract evidence
- ICT assets and information assets documented in separate files with no live dependency map
- Incident classification handled manually, creating reporting deadline risk
- Resilience test findings stored without owners, remediation dates, or sign-off trail
- ICT third-party contracts missing audit rights, exit clauses, data location terms, or service-level evidence
- Board approvals recorded without version history, risk decisions, or accountable ownership
- No single view connecting Article 5 governance to Article 28 third-party exposure
The audit reality: regulators do not just ask whether DORA work happened. They ask for the record, owners, dates, decisions, evidence, and remediation trail.
Every DORA Requirement Mapped to a Workflow
ICT Risk Management Framework
Build and maintain the Article 6 framework that identifies, classifies, protects, detects, responds, and recovers across critical functions.
- Board-approved ICT risk framework mapped to DORA Article 5 and Article 6
- Live ICT asset, information asset, and dependency registers for Article 8
- Protection and detection controls aligned to Articles 9 and 10
- Review records, version history, and sign-off evidence after incidents or supervisory findings
Incident Classification and Reporting
Move from manual incident triage to structured DORA reporting workflows that protect the 24-hour and 72-hour windows.
- Article 17 incident logging, classification, and escalation
- Article 19 early warning, intermediate report, and final report workflow
- Significant cyber threat notification pathway where relevant
- Time-stamped evidence trail for each classification decision
Digital Operational Resilience Testing
Plan, evidence, remediate, and retest your resilience programme without losing findings in disconnected reports.
- Article 24 testing programme for vulnerability, network, gap, and scenario-based testing
- Article 26 TLPT tracking for significant financial entities
- Independent tester evidence and production-scope records
- Remediation owners, due dates, retesting, and management sign-off
ICT Third-Party Risk and Contracts
Control Article 28 and Article 30 obligations with a single register of ICT providers, critical functions, contracts, and remediation status.
- ICT third-party provider register with critical or important function mapping
- Concentration risk monitoring across critical services and providers
- Contract remediation for audit rights, exit strategies, data location, portability, and service levels
- Critical ICT third-party provider oversight evidence for ESA cooperation
StartComply vs. The Alternatives
DORA compliance depends on connected evidence. A spreadsheet can list controls, but it cannot run the governance, incident, testing, and third-party workflows regulators expect.
StartComply was built for European compliance teams that need DORA evidence to be available on demand, not reconstructed manually before every audit.
What Are DORA Requirements?
DORA requirements are the legally binding obligations financial entities must meet under the Digital Operational Resilience Act. They cover how organisations govern ICT risk, manage incidents, test operational resilience, control ICT third-party providers, and participate in cyber threat information sharing.
The regulation applies directly across all EU member states. There is no national transposition layer to wait for, and no local interpretation that removes the core obligations. The management body owns the framework, meaning DORA is a board-level accountability issue, not a technical checklist.
The five core pillars are ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Each pillar creates specific evidence requirements that must be maintained continuously.
You cannot run DORA as five disconnected workstreams. StartComply links governance, risk registers, incident workflows, test findings, and third-party controls into one auditable system of record.
How StartComply Covers DORA Requirements in Six Steps
Assign board ownership DORA Art. 5
Define, approve, and oversee the ICT risk management framework at management-body level. StartComply records approvals, responsible owners, review dates, and decision history so governance is evidenced, not assumed.
Document ICT assets and dependencies DORA Art. 6 & 8
Create a live register of ICT assets, information assets, systems supporting critical functions, and their interdependencies. Asset mapping must stay current, because regulators expect a living register rather than a PDF archive.
Operationalise protection, detection, and recovery DORA Art. 9-11
Track encryption, access controls, multi-factor authentication, network segmentation, detection measures, business continuity, and recovery testing through article-mapped controls and evidence records.
Classify and notify major ICT incidents DORA Art. 17 & 19
Log, classify, escalate, and report major ICT incidents through a defensible methodology. StartComply helps protect the 24-hour early warning, 72-hour detailed report, and one-month final report timelines.
Run resilience testing and remediate findings DORA Art. 24 & 26
Manage vulnerability assessments, network security assessments, gap analyses, scenario-based testing, and TLPT where required. Findings feed back into the ICT risk framework with remediation owners and sign-off.
Manage ICT third-party risk DORA Art. 28-30
Maintain your ICT third-party register, map providers to critical or important functions, monitor concentration risk, and remediate contracts for audit rights, exit strategies, service levels, security requirements, and data portability.
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 DORA Requirements
What financial entities are subject to DORA requirements?
DORA applies to over 20 categories of financial entity operating in the EU. These include credit institutions, payment service providers, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, and ICT third-party providers designated as critical. The regulation is directly applicable across all EU member states with no national transposition. If you provide financial services in the EU, you are almost certainly in scope.
What are the DORA incident reporting timelines?
DORA Article 19 sets three deadlines. First, a 24-hour early warning to the competent authority after a major ICT incident is classified. Second, a detailed incident report within 72 hours. Third, a final report within one month of the initial notification. Classification delays are the most common failure point. Entities must have a defensible, documented methodology for classifying incidents as major or not.
Do DORA requirements apply to third-party ICT contracts signed before 2025?
Yes. There is no grandfathering provision. All contracts with ICT third-party providers covering critical or important functions must comply with DORA Article 30 requirements regardless of when they were signed. This includes mandatory clauses on audit rights, exit strategies, data location, service levels, and security standards. Regulators expect a remediation programme to be underway.
What is Threat-Led Penetration Testing and who must conduct it?
Threat-Led Penetration Testing (TLPT) is an advanced resilience test mandated under DORA Article 26 for significant financial entities. It simulates real-world attack scenarios against live production systems using external threat intelligence. TLPT must be conducted at least every three years by qualified independent testers. The TIBER-EU framework provides the methodological baseline.
What is the difference between DORA requirements and NIS2 requirements?
DORA is sector-specific legislation for financial entities. NIS2 is a broader directive covering essential and important entities across multiple sectors. Financial entities subject to DORA are generally considered to meet NIS2 obligations through DORA compliance, given DORA’s stricter requirements. However, the two frameworks are not identical.
What fines can regulators impose for failing DORA requirements?
Fines vary by entity type and breach severity. For financial entities, competent authorities can impose fines up to €10 million or 2% of global annual turnover, whichever is higher. For critical ICT third-party providers under ESA oversight, fines can reach 1% of average daily global turnover, applied daily until compliance is achieved.
Turn DORA Requirements Into Audit-Ready Workflows.
Which Organisations Must Meet DORA Requirements?
DORA applies to financial entities operating in the EU and to critical ICT third-party providers designated for direct oversight. The scope is broad, and the regulation is directly applicable across all EU member states.
For most financial services organisations, the practical question is no longer whether DORA matters. The question is whether the evidence trail is already strong enough for supervisory review.
DORA is not just an IT compliance exercise. The management body is directly responsible for approving and overseeing the ICT risk management framework.
DORA Compliance Timeline: Where Requirements Stand Now
DORA came into full effect. Financial entities operating in the EU must meet ICT risk management, incident reporting, testing, third-party risk, and governance obligations.
Article 30 contract remediation is already live. Pre-2025 ICT provider contracts are not exempt and must contain the mandatory DORA clauses.
Major ICT incidents require an early warning, detailed report, and final report after classification. Slow manual classification can become the breach.
Threat-Led Penetration Testing is mandatory for significant financial entities at least every three years, with results feeding back into the ICT risk framework.
Asset registers, test results, board approvals, incident logs, and third-party records must be continuously evidenced, not rebuilt when an audit arrives.
Operating across the EU?
DORA is directly applicable across member states. No transposition delay removes the obligation to evidence your ICT risk framework, incident workflows, testing programme, and ICT third-party controls.
The 10 Evidence Areas Behind DORA Requirements
A complete DORA programme is not one policy document. It is a structured evidence system covering governance, ICT controls, incidents, testing, suppliers, and continuous review.
Management-body governance
Board approval, oversight, risk appetite, accountable owners, and sign-off records for the ICT risk management framework.
ICT risk management framework
Documented policies, procedures, controls, review cycles, and article-mapped evidence across ICT risk operations.
ICT asset and dependency register
Live mapping of ICT assets, information assets, critical functions, systems, and interdependencies.
Protection and detection controls
Encryption, access controls, multi-factor authentication, segmentation, monitoring, and detection capabilities.
Business continuity and backups
Tested continuity plans, recovery time objectives, recovery point objectives, and geographically separate backup evidence.
Incident classification methodology
A defensible process for logging, classifying, escalating, and documenting major ICT-related incidents.
Incident reporting workflow
Early warning, detailed report, and final report workflow with timestamps, owners, authority notifications, and decision evidence.
Resilience testing programme
Vulnerability assessments, network security assessments, gap analyses, scenario-based tests, findings, remediation, and retesting.
Threat-Led Penetration Testing
TLPT scope, tester independence, production system coverage, results, remediation, and management sign-off for significant entities.
ICT third-party register and contracts
Provider register, critical function mapping, concentration risk, mandatory contract clauses, audit rights, exit strategies, and data portability terms.
