Who is accountable for ICT risk management under DORA?

Why This Matters for Security Teams

DORA makes accountability explicit: senior management cannot treat ICT risk as a technical back-office issue, because operational resilience depends on visible ownership, reporting, and evidence. That matters for identity because non-human identities often sit outside classic user governance, yet they can trigger outages, supplier failures, and control breakdowns just as quickly as human accounts. The regulatory lens is clear in the EU Digital Operational Resilience Act (DORA) and in NHIMG’s guidance on Ultimate Guide to NHIs — Regulatory and Audit Perspectives, where governance gaps are treated as audit and resilience issues, not just access hygiene. For many organisations, the real problem is not that a policy exists, but that no one can show who approved, monitored, and tested the identities that actually run the business.

NHIMG research shows the scale of the exposure: 72% of organisations have experienced or suspect a breach of non-human identities, and 46% confirm they have. In practice, many security teams encounter the accountability gap only after an incident exposes who failed to own the evidence trail, rather than through intentional governance design.

How It Works in Practice

Under DORA, accountability should be translated into named ownership across three layers: board oversight, executive ICT risk management, and operational control owners. The board sets risk appetite and expects regular reporting. Senior management ensures the ICT risk framework is implemented, resourced, tested, and remediated. Control owners then manage the identity and access mechanisms that create or reduce risk, including service accounts, API keys, certificates, secrets rotation, and privileged access.

For NHI governance, this means identity inventory and lifecycle controls are part of ICT resilience, not a separate IAM project. Teams should be able to answer who owns each non-human identity, what it can access, when it was last reviewed, how secrets are rotated, and what evidence exists for offboarding. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames identity lifecycle management as a control objective tied to operational risk.

• Assign a business owner and a technical owner for every critical NHI.
• Map NHI privileges to the systems and services they can affect, including suppliers and CI/CD paths.
• Require evidence for rotation, revocation, and periodic review of secrets and service accounts.
• Include NHI scenarios in resilience testing, recovery exercises, and incident reporting.
• Align reporting to board-level ICT risk metrics using the same rigor as other operational controls.

DORA reporting becomes credible when the organisation can show that identity governance is measurable, reviewed, and tied to recovery outcomes. This approach is consistent with the NIST Cybersecurity Framework 2.0, which treats governance and oversight as first-class functions alongside protection and recovery. These controls tend to break down when NHIs are embedded in DevOps pipelines with shared ownership, because no single team can produce complete evidence for approval, rotation, and revocation.

Common Variations and Edge Cases

Tighter accountability often increases reporting overhead, requiring organisations to balance operational speed against auditability and resilience evidence. That tradeoff is especially visible in cloud-native environments, where service accounts, workload identities, and ephemeral credentials change faster than quarterly control reviews can keep up.

Best practice is evolving, but current guidance suggests that delegated execution does not equal delegated accountability. A platform team may run the IAM tooling, yet senior management remains responsible for ensuring the control environment works end to end. That distinction matters when third parties host critical services, because DORA expects oversight of supplier dependencies, not just internal policy. NHIMG’s Top 10 NHI Issues is a practical reminder that over-privilege, stale secrets, and poor visibility are common failure modes, while the Ultimate Guide to NHIs — Why NHI Security Matters Now shows why these issues translate directly into operational exposure.

There is no universal standard for exactly how to split accountability between the board, CISO, CIO, and product owners. The safe operational pattern is to document decision rights, define evidence requirements, and rehearse escalation paths before an incident exposes ambiguity. The model is weakest in organisations with federated engineering teams and unmanaged third-party integrations, because accountability becomes distributed while the incident still demands a single answer.

Related resources from NHI Mgmt Group

• Why do centralized IT management tools often create identity risk?
• Why do Kubernetes management tools increase identity risk for IAM teams?
• Who is accountable when browser-based identity risk causes a data leak?
• Why do management-plane vulnerabilities create outsized risk compared with ordinary server bugs?