Accountability sits with the institution’s risk, compliance, and executive leadership, not just the IAM team. DORA treats identity as part of operational resilience, so business owners must be able to evidence control effectiveness, continuity planning, and incident readiness across the full environment.
Why This Matters for Security Teams
Under DORA, identity failure is not a narrow IAM defect. It is an operational resilience issue that can affect service continuity, incident response, and audit evidence across the institution. Accountability therefore extends beyond the platform team to the risk function, compliance leadership, and executive management that must prove controls are designed, working, and monitored.
That matters because identity controls often fail in the same places as broader resilience controls: undocumented service accounts, weak secrets governance, and poor revocation discipline. NHI Management Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which makes control assurance difficult before an incident and even harder after one. DORA’s own resilience expectations, as set out in the EU Digital Operational Resilience Act (DORA), reinforce that these failures are governance issues, not just technical misconfigurations.
In practice, many security teams encounter the accountability gap only after an audit finding, service disruption, or compromised credential has already forced a regulatory review.
How It Works in Practice
For DORA, accountability should be mapped to named business owners, control owners, and incident owners rather than left with a generic IAM operations group. The risk function defines the control objective, compliance interprets the regulatory obligation, and executive leadership signs off that evidence exists for design, testing, remediation, and recovery. The IAM team implements the technical controls, but it does not own the regulatory outcome alone.
A practical model is to assign accountability across the identity lifecycle:
- Business owners approve why the identity exists and what service it supports.
- Platform or IAM teams enforce issuance, rotation, and offboarding.
- Security and risk teams verify least privilege, logging, and exception handling.
- Compliance and internal audit test whether controls meet DORA expectations and can be evidenced.
That division matters because DORA is ultimately asking whether the firm can operate, recover, and prove resilience when identity breaks. The regulatory and audit perspective on NHIs makes this point clear: identity evidence must be traceable across governance, lifecycle, and incident readiness. Standards such as the NIST Cybersecurity Framework 2.0 also support this operating model by tying identity control to governance, protection, detection, and recovery outcomes.
Where this works best is when institutions maintain a control register that links each privileged identity or secret to a service owner, risk treatment, test evidence, and recovery runbook. These controls tend to break down in highly distributed environments with shadow IT, outsourced service accounts, and unclear data ownership because no single accountable party can produce end-to-end evidence quickly.
Common Variations and Edge Cases
Tighter accountability often increases reporting overhead, requiring organisations to balance regulatory evidence against operational speed. That tradeoff becomes more visible in subsidiaries, shared services, and vendor-managed platforms where the line between control owner and service operator is blurred.
Best practice is evolving for third-party and cloud-native environments. Current guidance suggests that if an external provider issues or stores secrets on behalf of the institution, accountability for compliance still remains with the regulated entity, even when execution is delegated. That is especially important when non-human identities are embedded in CI/CD pipelines, automation scripts, or managed integrations, because the control failure may originate outside the security team but still fall inside the firm’s DORA obligation.
Incident-driven accountability also needs to be explicit. If a secret leak, expired certificate, or orphaned service account causes a resilience event, the response should identify who validated the control, who remediated it, and who confirmed the evidence trail. The 52 NHI Breaches Analysis is useful here because it shows how identity failures often cascade into broader operational impact rather than staying as isolated access issues. In practice, regulated firms should treat accountability as a standing governance requirement, not a post-incident blame exercise.
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, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | DORA identity failures are governance and accountability issues. |
| NIST CSF 2.0 | PR.AC-1 | Identity access governance is central to preventing control failures. |
| NIST AI RMF | Risk governance maps to accountability for operationally critical identity controls. |
Document control ownership, testing, and escalation paths for identity-related resilience risks.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
