The board is accountable, not just the IT or security team. DORA makes resilience a leadership responsibility because keeping the business running is a governance issue as much as a technical one. That means executives must oversee risk appetite, critical service prioritisation, supplier oversight, and incident preparedness so resilience is embedded into business strategy.
Why DORA Makes Resilience a Board-Level Accountability
DORA treats operational resilience as a governance outcome, not a back-office recovery task. When business continuity is at risk, the accountable body has to be the governing leadership that sets risk appetite, approves critical service priorities, and accepts the residual risk of outages or dependency failures. That is why resilience cannot be delegated away to operations alone.
The practical implication is that accountability sits with the board even when execution sits elsewhere. Business continuity planning, ICT risk oversight, third-party dependency management, and incident readiness all need executive ownership because they determine whether the firm can keep delivering critical services under stress. This is the core shift DORA introduces: resilience is part of how the business is run, not just how technology is maintained.
A useful way to read the rule is that the board owns the decision structure, while IT, security, risk, and operations provide the controls and evidence. If critical services depend on concentrated suppliers, fragile recovery paths, or unclear escalation paths, the leadership team is still accountable for the exposure even if the failure originated in a technical layer.
What Accountability Looks Like in Practice
Board accountability under DORA becomes visible through the questions leadership must be able to answer, and the decisions it must be prepared to make. That includes which services are critical, how much downtime is tolerable, which supplier dependencies are acceptable, and what evidence shows the business can recover within the required time. Without those decisions, resilience remains aspirational.
- Set and review tolerance for disruption against critical business services, not just infrastructure uptime.
- Require clear ownership for incident response, recovery testing, and supplier escalation paths.
- Ensure continuity plans are tested against realistic failure scenarios, including third-party and cyber disruption.
- Track whether management actions reduce exposure or merely document it after the fact.
For leadership, the key issue is governance discipline. A continuity plan that exists only as a document is not accountability. A plan that is tested, measured, and tied to service priorities is the kind of evidence DORA expects to see.
Risk and Threat Considerations
When accountability is unclear, resilience failures tend to surface at the exact moment the business needs coordinated action. The most common risk is not a single control failure, but a chain of weak ownership, where no one has authority to prioritise restoration, challenge supplier assumptions, or accept temporary degradation of service.
Failure mechanism: Critical services rely on untested dependencies, incomplete recovery assumptions, or supplier arrangements that leadership has not actively governed, so disruption escalates faster than the organisation can decide and respond.
Impact: Business continuity breaks down, recovery takes longer than expected, and the firm may face operational, regulatory, and client-impact consequences even if technical teams executed their own procedures correctly.
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 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Article 5 — Management Body Accountability | DORA places operational resilience governance on the management body. |
| Article 6 — ICT Risk Management Framework | Operational resilience depends on governed ICT risk controls and recovery planning. | |
| Article 28 — ICT Third-Party Risk Management | Supplier dependencies can drive continuity risk and must be governed at leadership level. | |
| Recommendation — Assign board ownership for resilience decisions and review critical service continuity oversight regularly. Maintain an ICT risk framework that supports continuity, recovery, and service prioritisation. Oversee third-party dependencies and require contractual and operational resilience assurances. | ||
| NIST CSF 2.0 | GV.OC — Organisational Context | Critical-service prioritisation depends on leadership defining business context and objectives. |
| RC.RP — Recovery Planning | Continuity risk is reduced by planned and tested recovery capabilities. | |
| ID.SC — Supply Chain Risk Management | Supplier dependence is a major continuity risk under DORA. | |
| Recommendation — Define critical services and align resilience decisions to business objectives and tolerance levels. Validate recovery plans through exercises that reflect realistic disruption conditions. Govern supplier dependencies and confirm resilience requirements across critical providers. | ||
Practitioner Guidance
What to prioritise: Treat the board or equivalent governing body as the owner of resilience decisions, then force clarity on which services are truly critical, which dependencies can fail, and what recovery time is acceptable for each one.
What to verify: Check that continuity, supplier oversight, and incident preparedness are tied to real service-level decisions rather than generic policy statements. Leadership should be able to show evidence of testing, escalation authority, and follow-through on remediation.
Practitioner takeaway: Under DORA, the question is not whether technical teams can restore systems, but whether leadership has taken responsibility for keeping critical services running when assumptions fail.
Related resources from NHI Mgmt Group
- Why do third-party ICT dependencies create the biggest operational resilience risk under DORA?
- Who is accountable for ICT risk management under DORA?
- Who is accountable when cyber resilience controls fail under NIS2 and DORA?
- Who is accountable when enterprise risk decisions affect security, compliance, and business resilience?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
