Who should own user lifecycle governance in an organisation?

Why This Matters for Security Teams

User lifecycle governance is where identity risk either stays controlled or quietly accumulates. When joiners, movers, and leavers are handled inconsistently, access outlives employment context, approvals go stale, and application owners inherit roles they never agreed to govern. Identity teams may own the workflow, but the control fails if HR, managers, and app admins treat lifecycle events as someone else’s problem. Current guidance from NIST Cybersecurity Framework 2.0 reinforces that governance must map to clear accountability, not just ticket routing.

For NHI Management Group, the operational pattern is the same across human and non-human identities: lifecycle ownership has to be explicit, measurable, and tied to authoritative triggers. The lifecycle lens in NHI Lifecycle Management Guide shows why handoffs matter, because every transition is a chance for entitlements to drift. In practice, many security teams discover lifecycle gaps only after a terminated user still has access, rather than through intentional governance reviews.

That gap is not theoretical. NHIMG research on Regulatory and Audit Perspectives consistently points to weak evidence of ownership as a recurring audit issue, especially when identity, HR, and application teams each assume another function is validating changes.

How It Works in Practice

Effective lifecycle governance is usually split into three control layers. Identity or IAM teams should own the policy, workflow, evidence, and exceptions. HR or another authoritative source should trigger employee state changes, such as hire, transfer, leave, or termination. Application administrators should own role mapping, entitlement validation, and service-specific exceptions. That division prevents one team from both creating and approving access without checks.

In mature environments, the workflow is event-driven. HR status changes trigger identity provisioning or deprovisioning, the IAM platform executes policy-based actions, and app owners confirm that mapped roles still match job function. The model works best when access reviews are tied to application ownership and when exceptions have expiry dates. This is especially important for secrets and service accounts, where lifecycle ownership must include rotation, revocation, and dependency tracking. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because lifecycle failure is often really a visibility failure.

• Identity teams define workflow, control points, and audit evidence.
• HR or another source of truth triggers state changes.
• Application owners approve role design and entitlement exceptions.
• Security teams measure deprovisioning speed, stale access, and exception aging.

This model aligns with the control emphasis in the OWASP Non-Human Identity Top 10, which treats unmanaged credential lifecycle as a direct exposure path. The operating principle is simple: no single team should both attest access and execute the change without independent review. These controls tend to break down in federated organisations with many SaaS applications because ownership of entitlements is distributed across business units and no one maintains a complete source-of-truth map.

Common Variations and Edge Cases

Tighter lifecycle governance often increases coordination overhead, requiring organisations to balance speed against control evidence. That tradeoff becomes visible during reorganisations, contractor offboarding, mergers, and high-churn engineering teams, where the “right” owner may change faster than the process can be updated.

There is no universal standard for this yet, but current guidance suggests that ownership should follow control responsibility, not organisational hierarchy. For example, a central identity team may run the process, while a SaaS product owner approves role definitions, and a manager validates business need. In highly regulated environments, audit teams may also require a separate control owner who can attest that the process works as designed, even if they do not perform the change.

Exceptions are where lifecycle governance usually fails. Temporary access, non-employee workers, shared accounts, and delegated administration often need different approval paths and shorter review windows. The strongest practice is to make exceptions explicit, time-bound, and reviewed on a schedule, rather than letting them become shadow policy. NHIMG’s Top 10 NHI Issues is a useful reminder that the same governance mistake can affect both human and non-human identities: ownership ambiguity creates persistence.

Related resources from NHI Mgmt Group

• Who should own the governance of business app integrations?
• Who should own SaaS app lifecycle decisions when business units self-procure tools?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?