DORA
DORA applies to EU financial entities (and, in part, their critical ICT third-party providers). The catalog covers logging and monitoring, detection, incident reporting and third-party risk. Incident reporting is staged: initial notification, intermediate report, final report — every stage applies to a major incident; the earliest is satisfied by the reported time and later stages are shown on the incident.
| Registry id | dora |
| Kind | regulation |
| Jurisdiction | EU |
| Instrument | Regulation (EU) 2022/2554 (Digital Operational Resilience Act) |
| Catalog versions | 2026-09 from 2025-01-17 (current) — As applicable from 17 January 2025 |
| Verified against instrument | no — see the banner above |
Roles (frameworks.dora.financial_entity_type) |
financial_entity, ict_third_party_provider |
| Incident deadline rules | initial: 4 h, intermediate: 3 days, final: 30 days |
| Retention floors | none at classification level |
| Obligations | 4 |
Deadline rules
Section titled “Deadline rules”Staged rules: every stage applies to a qualifying incident. The earliest stage is the report, satisfied by reported_at; later stages are follow-ups shown on the incident and satisfied by closing it.
| Rule | Deadline from became_aware_at |
|---|---|
initial |
4 h |
intermediate |
3 days |
final |
30 days |
Deadlines are computed and shown, never enforced — see incidents.
Obligations and their evidence
Section titled “Obligations and their evidence”Each obligation lists the statements it is shown against. The basis is one of recomputed, judged, indicator or declared (what the bases mean); the resolver is from the shared library.
ICT security — logging and monitoring
Section titled “ICT security — logging and monitoring”art9-4-logging-monitoring · Art 9(4) · applies from 2025-01-17
ICT security policies, procedures and tools include logging and monitoring of ICT systems. Written from public summaries of the instrument; check the published text before relying on this. Applies to every system for which the framework is active.
| Statement | Basis | Resolver | Does not show |
|---|---|---|---|
| Every governed action produced a sealed record, including refusals. | recomputed | records.every_verdict_sealed |
Integrity is not completeness: covers actions routed through the gateway only; records sealed late by backfill are reported separately. |
| The tenant log’s tree heads covering the window were countersigned by an independent witness. | recomputed | records.witnessed |
A receipt shows inclusion at a tree size, not a witness-observed time; a same-operator witness is self-attested. |
| Liveness, drift and health were evaluated every day. | recomputed | monitoring.daily_health |
Shows the monitoring ran; what a human did with its findings is shown in the inbox trail. |
Detection of anomalous activities
Section titled “Detection of anomalous activities”art10-detection · Art 10 · applies from 2025-01-17
Mechanisms promptly detect anomalous activities — guardrail and policy verdicts are sealed records. Written from public summaries of the instrument; check the published text before relying on this. Applies to every system for which the framework is active.
| Statement | Basis | Resolver | Does not show |
|---|---|---|---|
| Every action outside the contract or grant was refused. | recomputed | authz.out_of_grant_refused |
Covers actions the gateway observed; the grant itself is a declaration. |
| The audit row chain over the window recomputes intact, or every gap is a declared prune. | recomputed | records.integrity_verified |
Detects alteration after the fact; it cannot show that a row was accurate when written. |
ICT-related incident management and reporting
Section titled “ICT-related incident management and reporting”art17-19-incident-reporting · Art 17, Art 19 · applies from 2025-01-17
An incident management process; major ICT-related incidents reported to the competent authority in stages (initial 4 h, intermediate 72 h, final one month). Written from public summaries of the instrument; check the published text before relying on this. Applies to every system for which the framework is active.
| Statement | Basis | Resolver | Does not show |
|---|---|---|---|
| An incident register is kept and no open incident is past its deadline. | recomputed | incidents.register_exists |
Shows incidents someone entered; an incident nobody recorded cannot be counted. |
| Major incidents received an initial notification within 4 hours. | recomputed | incidents.reported_within_deadline {"framework": "dora"} |
Shows the initial stage against the reported time; intermediate and final reports are shown on the incident, not enforced. |
ICT third-party risk
Section titled “ICT third-party risk”art28-third-party-risk · Art 28 · applies from 2025-01-17
ICT third-party risk is managed as part of the ICT risk framework, with a register of contractual arrangements. Written from public summaries of the instrument; check the published text before relying on this. Applies to every system for which the framework is active.
What the gateway cannot show: Organisational duty, evidenced by declaration only.
| Statement | Basis | Resolver | Does not show |
|---|---|---|---|
| Vendor-operated systems and the register of ICT arrangements are declared. | declared | profile.field_declared {"path": "frameworks.dora.ict_third_party_register_reference"} |
The register of information is organisational; its content is not evaluated. |
Related
Section titled “Related”- Framework registry & evidence bases — how catalogs, resolvers and the version in force work
- The Compliance console — the Obligations matrix for this framework
- Incidents, reports & documentation

