Who is accountable for identity risk in digital operational resilience programmes?

Accountability should sit with the business owners of critical services, supported by security, IAM, and risk teams. Regulators expect identity controls to be demonstrable, measurable, and tied to service continuity. That means naming control owners for privileged access, third-party access, and recovery procedures so identity risk is managed as an operational concern, not a narrow technical issue.

Why This Matters for Security Teams

Identity risk in digital operational resilience programmes is not a back-office IAM concern. It is a service continuity issue, because privileged access, service accounts, third-party credentials, and recovery paths can all become operational single points of failure. DORA makes that expectation explicit by treating resilience as something that must be governed, tested, and evidenced at the service level, not just configured in tooling through the EU Digital Operational Resilience Act (DORA).

The practical mistake is assigning accountability only to IAM or security engineering while business owners remain distant from the controls that keep critical services available. That approach usually fails during outages, vendor compromise, or recovery events, when teams discover that identity decisions were never tied to service ownership. NHIMG research shows why that matters: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which turns access sprawl into an operational resilience problem, not just a security hygiene issue. In practice, many security teams encounter identity failure only after a recovery exercise or third-party incident has already exposed the gap between control ownership and service ownership.

How It Works in Practice

Effective accountability starts by mapping identity controls to critical business services. The service owner should own the risk decision, while security, IAM, and risk functions provide design, monitoring, and challenge. That means naming control owners for privileged access, third-party access, emergency access, secret rotation, and revocation procedures, then proving those controls work under stress. DORA and the NIST SP 800-53 Rev 5 Security and Privacy Controls both support this shared model: account for access, monitor it, and retain evidence that the control operated as intended.

In mature programmes, accountability is operationalized through a few concrete steps:

• Assign one accountable owner for each critical service, not one owner per tool.
• Document who can approve privileged access, who can break glass, and who can revoke access during incidents.
• Link third-party identities and service accounts to the service they support, including renewal and offboarding dates.
• Test recovery procedures using expired secrets, revoked accounts, and vendor access loss to confirm the service still meets tolerance thresholds.
• Capture evidence in risk and resilience reporting so identity controls are measured like any other continuity dependency.

This is especially important because NHI exposure is rarely isolated. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both show that identity failures often cascade through cloud, CI/CD, and integration layers. When identity governance is attached to service ownership, remediation becomes faster because the business impact is already clear. These controls tend to break down in complex outsourced environments because no single party owns the full identity lifecycle across suppliers, platforms, and recovery dependencies.

Common Variations and Edge Cases

Tighter identity accountability often increases governance overhead, requiring organisations to balance resilience assurance against speed, outsourcing complexity, and audit load. That tradeoff becomes visible in multi-entity groups, shared service centres, and heavily federated vendor ecosystems, where the question is not whether access exists but who is able to prove control when something fails.

There is no universal standard for this yet, but current guidance suggests three patterns work better than a narrow IAM-only model. First, critical service owners should accept accountability even when technical control execution sits elsewhere. Second, third-party access must be treated as part of the service risk boundary, not a separate procurement concern. Third, recovery procedures should include identity-specific scenarios such as expired certificates, revoked tokens, and unavailable privileged admins. The Ultimate Guide to NHIs is a useful reference when defining those dependencies, especially where excessive privilege and weak rotation create resilience exposure.

In highly automated environments, accountability may also need to extend to platform teams that operate secret stores, CI/CD systems, or workload identity infrastructure. That does not remove business ownership. It simply means the control chain is longer and the evidence burden is higher. The important test is whether a service owner can explain who controls access, how it is reviewed, and what happens when identity services are unavailable.

Related resources from NHI Mgmt Group

• Who is accountable for improving national fraud resilience when digital fraud risk is high?
• Why do siloed identity and privileged access programs create operational risk?
• Why do identity security programmes struggle to gain traction with admins and business users even when the risk is clear?
• How should security teams turn cyber resilience awareness into stronger identity security programmes?