Who is accountable when a homegrown IAM process fails an audit or leaves access active too long?

The accountable owner is the identity and access governance function, even when the failure originated in custom code or an inherited script. Frameworks such as the NIST Cybersecurity Framework expect organisations to assign ownership, document controls, and maintain evidence for access decisions.

Why This Matters for Security Teams

When a homegrown IAM workflow fails an audit or leaves access active too long, the problem is rarely just a broken script. It is usually a governance gap: unclear ownership, missing control evidence, and no reliable checkpoint for who approved the access in the first place. That is why audit teams look beyond code quality and ask whether the organisation can prove decision authority, review cadence, and revocation discipline, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG guidance on Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

The practical risk is that custom automation often grows faster than the control model around it. A script may provision access correctly on day one, then silently drift as systems change, owners change, or exception handling accumulates. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which is a sign that many teams still treat workload access as an implementation detail instead of an accountable control domain. In practice, many security teams encounter this only after an auditor asks for evidence that no one can produce.

How It Works in Practice

Accountability should sit with the identity and access governance function, even when engineering built the workflow and operations owns the platform. That function does not need to write every line of code, but it does need to own the control objective: who can grant access, under what conditions, how long access stays active, and how revocation is verified. The cleanest way to do that is to separate build ownership from control ownership and document both. NIST SP 800-53 Rev 5 Security and Privacy Controls supports this model by requiring assigned responsibilities, traceable authorization decisions, and reviewable evidence.

In a homegrown process, the accountable owner should be able to answer four audit questions without reconstructing the system from logs:

• What access is granted, to whom, and for which business purpose?
• Who approved the access, and what policy or exception justified it?
• What is the expiry or review interval for that access?
• How is removal verified when a user leaves, a project ends, or an entitlement becomes stale?

If the process depends on scripts, the scripts themselves are not the control. The control is the governance around them: versioning, testing, exception handling, and periodic recertification. Where non-human identities are involved, NHIMG recommends aligning lifecycle management to explicit provisioning and revocation stages, as outlined in the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10. These controls tend to break down when ownership is split across engineering and security but no single function is responsible for proving timely revocation.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance faster delivery against stronger evidence and review discipline. That tradeoff becomes more visible in inherited scripts, legacy platforms, and DevOps-heavy environments where no one team owns the full access path from request to revocation.

One common edge case is the “shadow owner” problem: a script was built by a former engineer, deployed by operations, and relied on by application teams, so no current stakeholder feels accountable. Another is exception sprawl, where temporary access becomes effectively permanent because there is no enforced expiry or recertification. In those environments, current guidance suggests treating the governance owner as accountable even if technical execution is distributed, because accountability cannot be delegated into an automation pipeline.

For audit readiness, the best practice is evolving toward explicit control mapping, not informal trust in the codebase. That means documenting the approval path, defining a named control owner, and maintaining evidence that access is reviewed and removed on schedule. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference when access needs to be tied to lifecycle events rather than ad hoc developer judgment. The model becomes weaker in highly distributed environments with multiple clouds, multiple secret stores, and inconsistent logging, because proving timely removal then depends on evidence that is fragmented by design.

Related resources from NHI Mgmt Group

• Who is accountable when a shared-device access process fails compliance or audit review?
• Who is accountable when third-party access stays active too long?
• Who is accountable when a cloud IAM deployment fails audit or access governance?
• Who is accountable when third-party access to personal data persists too long?