Who should be accountable when controls fail?

Accountability should sit with the control owner, the process owner, and the approving manager, depending on where the failure occurred. If a workflow lets one identity bypass separation of duties, the failure is structural, not just personal. That means governance must assign ownership for fixing the process, not only for disciplining the person involved.

Why This Matters for Security Teams

When controls fail, accountability is not just a compliance question. It determines whether the organisation treats the incident as a one-off mistake or as a broken control design. NHI governance makes this especially important because secrets, service accounts, tokens, and agent permissions often span teams, platforms, and approval chains. NIST’s NIST Cybersecurity Framework 2.0 frames this as an ownership and governance problem, not only an operational one.

In practice, failures often surface through leaked credentials, overbroad access, or approvals that bypass separation of duties. The issue is rarely limited to the person who clicked the wrong button. It usually reflects unclear control ownership, weak review paths, or a manager who approved an exception without understanding the downstream exposure. NHIMG’s research on the Ultimate Guide to NHIs — Standards shows that governance expectations must be explicit because NHI estates are distributed and easy to misassign across DevOps, cloud, and security functions. In practice, many security teams discover accountability gaps only after the control has already failed, rather than through deliberate review of ownership and escalation paths.

How It Works in Practice

Effective accountability starts by separating three roles: the control owner, the process owner, and the approving manager. The control owner is responsible for how a safeguard is designed and maintained, such as secret rotation, token TTL, or access review logic. The process owner is responsible for the workflow that uses the control, such as CI/CD deployment, service onboarding, or agent approval gates. The approving manager is accountable for exceptions and risk acceptance when the workflow deviates from policy.

This matters because control failure usually happens at a boundary. For example, if an application team can bypass secret rotation because a platform default was never enforced, the failure belongs to the control owner and the process owner together. If a manager signs off on permanent access where JIT access was required, the approval path becomes part of the failure. NIST guidance on governance aligns with this shared responsibility model, while NHIMG’s DeepSeek breach analysis shows how exposed credentials and overshared data can turn one weak decision into a broad exposure event.

• Assign one named owner for every control, not just every system.
• Document who can approve exceptions and how long an exception remains valid.
• Record whether a failure came from design, operation, or approval.
• Review recurring failures as process defects, not just user errors.

For AI and agentic workloads, the same logic applies, but the blast radius is often larger because autonomous systems can chain tools and persist in ways humans do not anticipate. Those controls tend to break down when ownership is split across platform, security, and product teams without a single accountable decision-maker because no one is empowered to close the gap.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster delivery against clearer decision rights. That tradeoff is unavoidable in mature environments, especially when multiple teams touch the same NHI or agent workflow.

One common edge case is a shared platform control, such as a central secrets manager or identity broker. In that model, the platform team may own the control, but application teams still own their usage. Best practice is evolving here: there is no universal standard for exactly how to split accountability, so the practical approach is to document who owns configuration, who owns adoption, and who signs off on residual risk. Another edge case is delegated approval in large organisations, where a line manager approves access but does not understand the technical exposure. In those cases, the approving manager remains accountable for the decision even if the control owner owns the implementation.

For NHI and agentic systems, accountability gets harder when credentials are embedded in pipelines or when autonomous tools operate under inherited permissions. NHIMG’s research on The State of Secrets in AppSec shows how fragmentation and slow remediation make control failures harder to trace back to a single team. That is why organisations should treat accountability as a documented governance mechanism, not an after-the-fact blame exercise.

Related resources from NHI Mgmt Group

• Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?
• Why do software signing controls fail even when policies exist?
• Who is accountable when risk-based access decisions fail audit or compliance testing?
• Why do IT application controls fail even when IT general controls look strong?