DORA: what it requires, and how to prove you comply
Short answer
DORA (the Digital Operational Resilience Act) is an EU regulation, in effect since January 2025, for financial entities in the EU and their critical third-party ICT providers. It requires ICT risk management (Articles 5-16), the classification and reporting of major ICT incidents (Articles 17-23), with an initial notification within 4 hours of classification, an intermediate report within 72 hours and a final report within 1 month, resilience testing (Articles 24-27) and ICT third-party risk management (Articles 28-44). ROOTKey maps these requirements onto your existing infrastructure, with verifiable, auditable cryptographic proof.
- Penalty on critical ICT providers
- 1%of average daily worldwide turnover, per day, up to 6 months
- Initial notification
- 4hafter classifying a major incident
- Entity types
- 20+financial entities covered by the regulation
- Mandatory enforcement
- Jan 2025in force across the European Union
Who is covered and what is at stake
DORA (the Digital Operational Resilience Act) took effect in January 2025. It applies to financial entities in the EU, including banks, insurers, investment firms, crypto-asset service providers and their critical third-party ICT providers. The penalties differ by type of entity.
| Entity | Penalty |
|---|---|
| Critical third-party ICT service providers | Periodic penalty payments of up to 1% of average daily worldwide turnover in the preceding business year, imposed daily until compliance and for no more than six months (Art. 35(7) and (8)) |
| Financial entities | Administrative penalties and remedial measures laid down by each member state (Art. 50); DORA sets no EU-wide amount |
Source: Regulation (EU) 2022/2554 on EUR-Lex, Articles 35 and 50.
DORA in five minutes
A plain-language walkthrough of the regulation: who it covers, what it requires, and where data integrity fits in.
NIS2, DORA and GDPR are explained in the same format in the Compliance playlist on our YouTube channel.
What DORA requires, article by article
DORA requires documented ICT risk-management frameworks, business continuity plans, incident classification and reporting, digital operational resilience testing and third-party ICT risk management with immutable audit evidence. This is how each requirement maps onto ROOTKey.
| Article | Requirement | ROOTKey | Status |
|---|---|---|---|
| Articles 5-16ICT risk management | Financial entities must implement a robust ICT risk-management framework with documented policies, controls and continuity mechanisms. | An immutable record of ICT policies with a cryptographic hash verifiable per version and an anchored history - retroactive tampering is cryptographically detectable. | Covered |
| Articles 17-23Incident classification | Classification, monitoring and reporting of major ICT incidents, with defined criteria and set notification deadlines. | Cryptographically signed timestamps for every event. A verifiable chain of custody with structured export to regulators in seconds. Your report states what changed, who, when and where. | Covered |
| Articles 24-27Resilience testing | A programme of regular digital operational resilience testing, including vulnerability assessments and threat-based testing. | Recovery Points with cryptographic integrity verification - verifiable evidence that recovery systems were not compromised before being tested. | Covered 26 · partial |
| Articles 28-44ICT third-party risk | Rigorous management of ICT third-party provider risk, including due diligence, contracts and audit rights. | Cryptographic access verification by design: every third-party access is authenticated with cryptographic proof and immutably logged, with no implicit trust. | Authenticated · immutably logged |
Articles 19-20: incident notification deadlines
DORA requires relevant ICT incidents to be reported to the competent authorities. ROOTKey's cryptographic hash anchoring creates tamper-proof incident timelines that form the evidential basis for regulatory communication.
| Deadline | Stage | Detail |
|---|---|---|
| T0 | Detection and classification | Immutable timestamped logs and structured export - verifiable evidence of the moment of detection and classification, ready in minutes. |
| 4h | Initial notification | Initial notification to the competent authority within 4 hours of classifying a major incident. |
| 72h | Intermediate report | Intermediate report within 72 hours of the initial notification. |
| 1 month | Final report | Final report within 1 month. |
How ROOTKey fits: on top of your infrastructure, not instead of it
ROOTKey doesn't replace existing systems. It adds a layer of cryptographic verification via API - no migrations, no vendor lock-in.
- Auditable cryptographic evidence
- Every critical action produces an independent proof that external auditors can verify without access to the original data.
- Verifiable recovery points
- Backups with cryptographically verified integrity: date, content and integrity, all verifiable.
- Immutable timestamps
- A chain of custody for every security event, with verifiable evidence of when it happened.
Any file, one kind of proof
PDF, images, Word, Excel, PowerPoint, tables and databases: whatever the file, ROOTKey compares it with its sealed original and shows only what was altered.
- Deployment
- SaaS · Private cloud · On-premise
- Connectors
- SharePoint · OneDrive · Amazon S3 · Cloudflare R2 · tables and databases · REST API and webhooks
Integration: live in days, not months
Documented REST API and webhooks, dedicated enterprise support. ROOTKey adapts to your infrastructure - not the other way round.
Integrate via API
Documented REST API and webhooks. Live in days, without replacing existing infrastructure.
Automatic proofs
Every critical event generates an immutable, auditable cryptographic proof, with minimal operational effort.
Instant reporting
A real-time compliance dashboard and evidence exports for regulators in seconds.
Frequently asked questions
What is DORA and who has to comply?
DORA (the Digital Operational Resilience Act) took effect in January 2025. It applies to financial entities in the EU, including banks, insurers, investment firms, crypto-asset service providers and their critical third-party ICT providers.
What does DORA require for ICT risk management?
DORA requires documented ICT risk-management frameworks, business continuity plans, incident classification and reporting, digital operational resilience testing and third-party ICT risk management with immutable audit evidence.
How does ROOTKey support DORA incident reporting?
DORA requires relevant ICT incidents to be reported to the competent authorities. ROOTKey's cryptographic hash anchoring creates tamper-proof incident timelines that form the evidential basis for regulatory communication.
What are the penalties for non-compliance with DORA?
Critical third-party ICT service providers face periodic penalty payments of up to 1% of average daily worldwide turnover in the preceding business year, imposed daily for no more than six months (Art. 35). Penalties for financial entities are laid down by each member state (Art. 50); DORA sets no EU-wide amount.