The EU Digital Operational Resilience Act is a financial-sector regulation that requires organisations to prove they can resist, respond to, and recover from ICT disruption. It sets governance, testing, reporting, and third-party accountability expectations across the organisation, with board-level responsibility for resilience outcomes.
What DORA Actually Governs
dora is not a product standard or a narrow IT control checklist. It is a financial-services resilience regime that treats ICT disruption as an enterprise risk, tying technology stability to governance, accountability, and regulatory proof of operational resilience.
Its reach matters because the regulation focuses on whether a firm can keep critical services running, not just whether it has policies on paper. That shifts the subject from isolated technical hardening to resilience as a managed business capability, with board oversight and evidence of control effectiveness.
Core Obligations Under DORA
The main obligations cluster around five areas: governance, ICT risk management, incident reporting, resilience testing, and third-party oversight. In practice, DORA expects firms to identify critical functions, manage ICT dependencies, test recovery assumptions, and maintain clear accountability for resilience outcomes.
This is why DORA often changes internal ownership models. Technology, operations, compliance, risk, and procurement cannot treat resilience as a separate specialty, because the regulation links them through a single operational objective: sustained delivery of financial services under disruption.
For a useful official reference point, the EU authority page for EU Digital Operational Resilience Act (DORA) summarises the resilience, incident, and third-party expectations that drive this regime.
Third-Party and ICT Supply Chain Implications
DORA is especially important where firms depend on cloud providers, managed services, software suppliers, or other ICT third parties. The regulation recognises that operational resilience can fail outside the perimeter of the regulated entity, so provider concentration, exit readiness, contractual clarity, and oversight become part of the control model.
That makes DORA broader than vendor due diligence. It requires firms to understand which external dependencies can interrupt critical services, how those dependencies are monitored, and what evidence exists that the organisation can recover even when a supplier or platform is impaired.
These concerns align with the same governance and accountability themes discussed in NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives, where regulatory proof and auditability are treated as part of identity and access governance.
Why DORA Is a Governance and Assurance Regime
DORA matters because it raises resilience from an engineering concern to a governance and assurance requirement. The practical question is not only whether controls exist, but whether they are testable, reportable, and owned at the right management level.
That is why DORA pages often sit at the intersection of risk management, audit readiness, and operational control design. Firms need evidence that resilience has been designed into the service model, not assumed from infrastructure alone.
For identity, control, and audit-adjacent disciplines, the most relevant lens is whether the organisation can show that access, dependencies, and recovery paths are governed with the same discipline as other material operational risks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | DORA is a resilience and operational-risk regime for financial entities. |
| GV.OV-01 — Oversight of Cybersecurity Risk Management | DORA emphasises board-level accountability and oversight for resilience outcomes. | |
| PR.IR-01 — Resilience Planning | DORA requires firms to prepare for disruption and recovery of critical services. | |
| Recommendation — Align ICT resilience controls to enterprise risk management and board reporting. Assign senior oversight for resilience testing, incidents, and remediation. Document recovery objectives and validate continuity assumptions for critical ICT services. | ||
| ISO/IEC 27001:2022 | A.5.29 — Information security during disruption | DORA focuses on maintaining secure operations during ICT disruption. |
| A.5.19 — Information security in supplier relationships | DORA places strong accountability on ICT third-party dependencies. | |
| A.5.30 — ICT readiness for business continuity | DORA requires operational resilience and continuity under disruption. | |
| Recommendation — Use disruption controls that preserve security while services recover. Build supplier oversight into contracts, monitoring, and assurance reviews. Validate continuity plans against critical service and dependency scenarios. | ||
| CSA Cloud Controls Matrix | GRC — Governance, Risk and Compliance | DORA combines governance, reporting, and accountability across ICT resilience. |
| SEF — Security Incident Management, E-Discovery, and Forensics | DORA requires incident reporting and response discipline for material ICT events. | |
| Recommendation — Map resilience responsibilities, evidence, and reporting into a governed control model. Operationalise incident triage, evidence capture, and regulatory reporting workflows. | ||
Related resources from NHI Mgmt Group
- What happens when an EU financial service provider lacks a clear incident response plan under DORA?
- What is the difference between DORA and broader EU regulations such as NIS2 and the EU AI Act?
- How should organisations operationalize compliance across DORA, NIS 2, and the EU AI Act?
- Why do DORA, NIS 2, and the EU AI Act push teams toward stronger risk classification and reporting?
