Accountability sits with the organisation that operates the critical service, even when controls are implemented by internal teams or external providers. Security, IAM, governance, and risk leaders must ensure access policies, assurance checks, and monitoring are aligned to regulatory duties. For NIS2 and DORA, identity security is part of proving resilience, not just proving technical control.
Why This Matters for Security Teams
Under NIS2 and DORA, identity security compliance is not delegated away just because a managed service provider, cloud team, or IAM platform handles the controls. The regulated entity still has to prove that access governance, assurance checks, monitoring, and incident response are effective. That matters because identity failures are a common path to resilience failures, and resilience is what these regimes measure.
NHI risk makes this sharper. NHIs outnumber human identities by 25x to 50x in modern enterprises, and NHIs are frequently the path through which credentials, API keys, and service access are exposed. NHIMG’s Ultimate Guide to NHIs shows why governance gaps persist, while the regulatory and audit perspectives section is especially relevant when teams must evidence control ownership. In practice, many security teams discover accountability gaps only after an audit finding or third-party incident has already exposed them.
Regulators care less about who clicked the console and more about who can demonstrate control, oversight, and timely remediation. The legal and operational burden sits with the service operator, and that includes failures introduced by outsourced identity workflows. For baseline control intent, practitioners should anchor to the NIS2 Directive – official EU legal text and the EU Digital Operational Resilience Act (DORA).
How It Works in Practice
Accountability should be mapped to the organisation that owns the regulated service, then broken down into named control owners across security, IAM, risk, and operations. That means someone is responsible for access policy design, someone else for evidence collection, and someone else for exception handling, but the regulated entity retains the duty to ensure the whole chain works. NIST’s Cybersecurity Framework 2.0 is useful here because it frames governance, protection, detection, response, and recovery as an integrated system rather than a single technical control.
For NIS2 and DORA, identity security compliance is usually demonstrated through a combination of:
- documented accountability for IAM policy decisions and approvals
- regular access reviews for privileged, third-party, and machine identities
- evidence that credentials are rotated, revoked, and monitored on schedule
- logs showing who approved exceptions, when they expired, and how they were closed
- oversight of providers that issue or manage secrets on the organisation’s behalf
This is where NHI control hygiene matters operationally. The Top 10 NHI Issues page highlights how excessive privilege, weak rotation, and poor offboarding become audit problems as well as security problems. The point is not only to secure service accounts and API keys, but to prove that access remains justified, time-bound, and traceable. Current guidance suggests that evidence quality matters as much as policy wording, especially where external providers administer parts of the identity stack. These controls tend to break down when ownership is split across multiple vendors because no single party can produce complete, timely evidence.
Common Variations and Edge Cases
Tighter identity governance often increases operational overhead, so organisations have to balance auditability against service speed and provider complexity. That tradeoff is especially visible in multi-entity groups, where a parent company writes standards but subsidiaries operate different IAM tools, or where cloud, SaaS, and outsourcing arrangements create gaps in evidence ownership. Best practice is evolving, but there is no universal standard for this yet.
One common edge case is third-party managed identity services. A provider may run provisioning, rotation, or monitoring, but the regulated entity still needs contract clauses, assurance reporting, and the ability to terminate access without delay. Another is machine identity ownership: service accounts, tokens, and API keys often fall between IT, platform engineering, and application teams unless accountability is explicitly assigned. That is why NHIMG’s lifecycle processes for managing NHIs should be read alongside DORA’s resilience expectations, not as a separate technical concern.
For teams formalising controls, the practical test is simple: can the organisation prove who owns each identity control, what evidence exists, and how quickly failures are remediated? If the answer depends on a vendor ticket queue or an informal Slack thread, accountability is not yet operationally real.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and NIS2 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | NIS2 places accountability on the regulated entity for security governance and resilience. | |
| DORA | DORA requires financial entities to prove ICT resilience, including identity controls. | |
| NIST CSF 2.0 | GV.RR | Governance and roles clarify who owns identity compliance outcomes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential rotation and lifecycle control are central to NHI compliance evidence. |
| NIST AI RMF | AI RMF governance principles help assign accountability across complex digital identity operations. |
Assign a named control owner for identity security and retain evidence proving oversight, monitoring, and remediation.
Related resources from NHI Mgmt Group
- Who is accountable when an organisation accepts mediocre identity security and later suffers preventable risk or compliance issues?
- Who should be accountable for moving identity security from tactical projects to a business programme?
- Who should be accountable when identity fraud moves across compliance, fraud, and verification teams?
- Who should be accountable when platform claims do not match the actual identity security architecture?
