Who is accountable for DORA compliance when responsibility spans IT, risk, legal, procurement, and the board?

Why This Matters for Security Teams

DORA compliance is rarely a single-function task. It cuts across resilience testing, third-party risk, incident handling, governance, and evidence retention, so accountability has to be explicit rather than assumed. The board cannot delegate its oversight duty into obscurity, and operational teams cannot inherit legal obligations by accident. A useful baseline is the NIST Cybersecurity Framework 2.0, which reinforces that governance must connect strategy, risk, and operational execution. The common failure is not a lack of effort but a lack of decision rights. IT may own tooling, risk may own control assurance, legal may interpret obligations, procurement may manage supplier clauses, and the board may expect consolidated reporting, yet none of that creates accountability unless roles are defined and tested. DORA makes that gap visible because supervisory review asks who approved, who monitored, who escalated, and who can prove it. In practice, many security teams encounter DORA breakdowns only after an incident or audit request has already exposed the missing ownership model, rather than through intentional governance design.

How It Works in Practice

Accountability works best when it is mapped to a named governance structure with clear escalation paths. The board or an executive committee should set tolerance for operational risk, approve the control program, and receive regular reporting on material ICT risk and third-party exposure. The CISO, compliance lead, and risk function usually form the operational control spine, while legal and procurement translate requirements into contract terms, due diligence, and supplier monitoring. A practical model usually includes:

• A single accountable executive for DORA reporting and remediation tracking.
• Documented control owners for resilience testing, incident response, and supplier oversight.
• Legal review for contractual obligations, exit rights, and notification clauses.
• Procurement controls for onboarding, renewal, and concentration risk checks.
• Board reporting that shows risk trends, unresolved gaps, and evidence of follow-through.

For implementation discipline, many organisations map this structure to control libraries such as NIST SP 800-53 Rev 5 Security and Privacy Controls so they can assign ownership to specific control families rather than vague functions. That helps when evidence must show not just that a control exists, but who owns it, who tests it, and who accepted residual risk. It also reduces ambiguity during supplier incidents, where procurement may hold the contract but IT holds the dependency and legal holds the notification timeline. These controls tend to break down when accountability is spread across matrix organisations with regional autonomy because no single leader can compel closure on control gaps.

Common Variations and Edge Cases

Tighter governance often increases coordination overhead, requiring organisations to balance clear accountability against slower approval cycles and added reporting burden. That tradeoff is real, especially where IT operations, enterprise risk, and legal review sit in separate chains of command. One variation is the use of shared responsibility models for outsourced ICT services. Current guidance suggests this can work, but only if the internal party still owns oversight, escalation, and evidence collection. Another edge case is group-wide governance, where a parent company sets standards but local entities face different regulatory interpretations. In that setting, there is no universal standard for every operating model, so the safer approach is to define one accountable entity per regulated perimeter and then map supporting roles beneath it. Boards often ask whether accountability can be “shared.” Operationally, yes, but legally and evidentially it must still be assignable. Shared tasks are not the same as shared accountability. If every function is responsible, no function is answerable when a control fails. That is especially important when legal or procurement teams control contract language but do not own the operational risk that the contract is meant to mitigate. Where the question becomes more complex is in NHI-heavy environments, such as automated procurement workflows or agentic AI systems that trigger supplier actions. In those cases, accountability should extend to the human owner of the workflow, not the software agent itself.

Related resources from NHI Mgmt Group

• Who should be accountable for risk management in a pre-IPO environment when responsibilities span finance, IT, compliance, and the board?
• Who should be accountable for beneficial ownership reporting when legal, compliance, and operations all touch the process?
• Why do non-human identities create compliance risk even when policies exist?
• Who is accountable for reducing access risk when governance spans security, compliance, and application owners?