Accountability sits across cybersecurity, legal, compliance, enterprise risk, procurement, IT, and executive leadership because DORA is a cross-functional resilience requirement. If cybersecurity is left solely responsible, the operating model usually lacks the business engagement needed to maintain accurate evidence and remediation ownership.
Where accountability sits when DORA readiness breaks down
DORA readiness is not owned by a single team because the failure usually appears at the seams between policy, control operation, evidence, third-party oversight, and governance. The practical question is not only who writes the control, but who can prove it is operating, who fixes exceptions, and who accepts residual risk when remediation stalls. That is why accountability needs to extend beyond security into legal, compliance, procurement, enterprise risk, IT, and executive leadership, especially where third-party and ICT dependency decisions shape the resilience posture. For the regulatory context, see DORA Digital Operational Resilience Act.
When accountability is too narrow, readiness becomes a documentation exercise rather than an operational discipline. Teams may have policies on paper while evidence, testing, exception handling, and supplier oversight remain fragmented across functions. That creates a common governance gap: no single owner for the end-to-end outcome, but many owners for isolated tasks.
In practice, many organisations discover this only after a control failure, audit challenge, or remediation delay exposes that business owners, not just security teams, were never made accountable for keeping resilience evidence current.
How DORA accountability works in practice
DORA accountability works best when it is treated as an operating model question rather than a compliance label. The accountable function needs authority to assign work, demand evidence, and escalate unresolved issues, while other teams remain responsible for their specialist tasks. Security may design and monitor controls, but legal and procurement often own contract terms, IT owns technical remediation, enterprise risk owns risk acceptance, and executives own the decision to fund or prioritise fixes. That division matters because readiness failures usually come from handoff gaps, not from a single missing control.
One useful way to think about this is by asking who owns each stage of the resilience lifecycle:
- Who defines the control expectation and evidence standard?
- Who collects and validates proof that the control is working?
- Who owns remediation when the gap is found?
- Who approves exceptions when the gap cannot be closed quickly?
- Who is accountable for supplier dependencies and contractual leverage?
For ICT third-party risk, accountability becomes even more important because supplier oversight cannot be left as an informal security task. If procurement owns the commercial relationship but never receives resilience requirements, the organisation may fail to secure audit rights, incident notification terms, or service continuity assurances. If legal owns the clause library but no business sponsor tracks renewal risk, contractual control can drift from operational reality. DORA readiness therefore depends on a joined-up model where each function knows its part and leadership arbitrates when priorities conflict. The official DORA overview from EU Digital Operational Resilience Act DORA is useful for aligning internal ownership with the regulatory intent.
Where this guidance breaks down is when the organisation has no named risk owner, no evidence repository, or no authority to force remediation across departments.
Shared ownership, hard edges, and the exceptions that cause most failures
Tighter accountability often increases coordination overhead, so organisations must balance clear ownership against the risk of creating parallel governance that slows delivery. The practical challenge is to distinguish shared responsibility from blurred responsibility: several teams can contribute, but one party must own the outcome.
There is also a genuine trade-off in supplier-heavy environments. Centralising accountability in security can speed coordination, but it can also weaken business ownership of commercial commitments and recovery decisions. Leaving accountability entirely with the business can improve adoption, but it often produces weak control evidence unless compliance and security provide strong standards and challenge.
Common edge cases include outsourced services, multi-entity groups, and matrix organisations where local teams operate under central policy. In those settings, the question is not whether the parent company is accountable in the abstract, but whether local entities can actually produce evidence, approve exceptions, and escalate incidents within the right timeframes. Another frequent failure point is evidence ownership: teams assume that because a control exists somewhere, someone else is tracking proof of operation. That assumption usually fails during supervisory review. Where shared service models exist, accountability should be explicit for the control owner, the evidence owner, and the risk decision-maker, because those are not always the same role. In practice, organisations that treat DORA as a security-only programme usually find that accountability gaps surface first in supplier management and exception handling, not in the controls themselves.
Risk and Threat Considerations
DORA readiness failures create governance and resilience risk even before any incident occurs, because weak ownership allows control gaps, stale evidence, and unresolved supplier dependencies to accumulate. The most material exposure is not simply non-compliance, but loss of operational visibility over who must act when a resilience requirement is missed.
Failure mechanism: accountability fragments across functions, so no single owner can enforce remediation, validate testing, or sustain third-party oversight. That gap is especially dangerous where contractual obligations, operational controls, and risk acceptance are split between different teams.
Impact: organisations can end up with controls that exist in policy but not in practice, delayed remediation, weak supplier leverage, and poor auditability when supervisors ask who owns the resilience outcome.
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 CIS Controls v8 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT Third-Party Risk Management — ICT Third-Party Risk Management | Accountability for readiness often breaks at supplier and contract oversight. |
| Governance and Control Framework — Governance and Control Framework | The question is fundamentally about who owns the regulatory outcome. | |
| Recommendation — Assign clear owners for ICT supplier oversight and enforce contract-backed resilience requirements. Name one accountable executive owner for DORA readiness and track control evidence through governance. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Resilience failure here is an enterprise risk ownership problem. |
| GV.OV — Cybersecurity Governance | The issue concerns cross-functional governance and accountability. | |
| Recommendation — Embed DORA readiness into enterprise risk ownership and escalation decisions. Use governance oversight to assign, review, and enforce cross-functional readiness obligations. | ||
| CIS Controls v8 | 5 — Account Management | Readiness depends on explicit ownership and lifecycle control of responsibilities. |
| Recommendation — Maintain named ownership for critical accounts, suppliers, and control responsibilities. | ||
Practitioner Guidance
What to prioritise: assign one accountable owner for the end-to-end DORA readiness outcome, then separate that from the supporting responsibilities of security, legal, procurement, IT, and risk. If multiple teams can act, one team must still be able to compel action and close gaps.
What to verify: confirm that each critical control has a named owner, an evidence owner, and a risk decision-maker. If those three roles are not explicit, readiness will usually fail at exception handling or during supervisory challenge rather than during routine operations.
Escalation / exception: treat repeated delays in evidence collection, supplier response, or remediation approval as an accountability failure, not just a project delay. That is the point at which leadership intervention becomes necessary, because the organisation has lost control of the operating model rather than a single task.
Practitioner takeaway: DORA readiness fails most often when responsibility is distributed but authority is not, so the real test is whether one accountable function can force closure across the full control, supplier, and evidence chain.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
