Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.rootkey.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

The Digital Operational Resilience Act (DORA, EU 2022/2554) applies to financial entities in the EU - including banks, payment institutions, investment firms, insurance companies, crypto-asset service providers, and their critical ICT third-party service providers. It has applied since January 2025. DORA introduces binding requirements for ICT risk management, incident classification and reporting, digital operational resilience testing, and third-party ICT risk - all with documentation and audit obligations that regulators can examine. The defining feature of DORA compliance is auditability: financial entities must demonstrate, with verifiable evidence, that their ICT systems were managed and monitored in accordance with the regulation. That evidence must hold up under adversarial scrutiny, including during incident investigations where the entity itself may be a subject of review.

​
Article-Level Coverage

​
Chapter II - ICT Risk Management (Articles 5–14)

ArticleRequirementROOTKey capability
Art. 6ICT risk management framework with documented policiesAnchor policy documents and configuration baselines at creation and each revision
Art. 8ICT asset managementTamper-evident asset inventory records with version history
Art. 9Protection and prevention - data integritySHA-256 anchoring ensures no alteration of ICT records after creation
Art. 10Detection - monitoring of anomalous activitiesAnchor SIEM and monitoring events to create tamper-evident detection records
Art. 11Response and recovery - ICT-related incident recordsImmutable incident timeline, response actions, and recovery decisions
Art. 12Backup and restoration - recovery point evidenceAnchor backup verification records with blockchain timestamp
Art. 13Learning and evolving - post-incident analysis recordsAnchored post-incident reports with verifiable timestamps

​
Article 17 - ICT-Related Incident Management

DORA Article 17 requires financial entities to establish and maintain an ICT-related incident management process. Key documentation requirements:
RequirementROOTKey role
Classify ICT incidents at time of detectionAnchor classification decision at moment of triage - blockchain timestamp proves classification was not retroactively changed
Maintain incident lifecycle recordsEach stage of the incident lifecycle (detection → containment → recovery → closure) anchored separately
Preserve evidence for regulatory examinationImmutable, independently verifiable incident record - verifiable by ECB, EBA, ESMA, or national competent authorities without accessing your systems
Demonstrate response timeline accuracyBlockchain timestamps on each record cannot be backdated - response times are mathematically provable

​
Article 19 - Reporting of Major ICT-Related Incidents

DORA Article 19 requires financial entities to report major incidents to their competent authority. ROOTKey supports the evidence requirements at each reporting stage:
Reporting stageTimelineROOTKey role
Initial notificationWithin 4 hours of major incident classificationAnchored classification record proves timing - timestamp cannot be altered
Intermediate reportWithin 72 hoursAnchored incident detail record provides tamper-evident status at time of reporting
Final reportWithin 1 month of resolutionFull anchored audit trail of incident timeline - independently verifiable by competent authority

​
Article 28 - General Principles on ICT Third-Party Risk

DORA Article 28 requires financial entities to manage the risks arising from ICT third-party service providers - including their software supply chains.
RequirementROOTKey capability
Register and monitor ICT third-party service providersAnchor vendor assessment records and due diligence evidence
Assess ICT third-party concentration riskImmutable records of which critical functions depend on which providers
Verify software and artifact integrityAnchor build artifacts and release packages in CI/CD pipelines - detect tampering between build and deployment
Maintain contractual documentationAnchor SLA terms, service descriptions, and amendment records at signing
→ See also: Software Integrity use case

​
Compliance Summary

DORA PillarKey ArticlesROOTKey Solution
ICT risk managementArt. 6–14Tamper-evident policy, asset, and configuration records
ICT incident managementArt. 17Immutable incident lifecycle and classification records
Incident reportingArt. 19Blockchain-timestamped evidence packages for competent authorities
Resilience testingArt. 25–39Anchored test plans, results, and remediation records
Third-party riskArt. 28Vendor assessment records, software supply chain integrity

​
Applicable Entities

Entity typeDORA classification
Credit institutions (banks)Essential
Payment institutionsIn scope
Investment firmsIn scope
Crypto-asset service providers (CASPs)In scope
Insurance and reinsurance undertakingsIn scope
Central securities depositoriesIn scope
ICT third-party service providers (critical)Oversight regime
Data reporting service providersIn scope

Request a DORA compliance review

We’ll map your DORA obligations to a ROOTKey implementation - including evidence package design for ECB, EBA, ESMA, or national competent authorities.

Regulatory audit trail use case

Full implementation guide for DORA-compliant audit trails and incident evidence management.