Who should own identity lifecycle governance across HR and IT?

Ownership should be shared, but accountability must be explicit. HR usually owns the status event, IT or identity teams own execution, and application owners own exceptions. Without clear accountability, lifecycle controls fail at the handoff points where access changes are most likely to stall.

Why This Matters for Security Teams

identity lifecycle governance fails most often at organisational boundaries, not in the directory itself. HR generates the employment event, IT executes provisioning and deprovisioning, and application owners control the exceptions, but if no one is explicitly accountable, access changes stall in queues or are applied inconsistently. The result is avoidable overexposure, orphaned access, and audit findings that point to process gaps rather than tool gaps.

Current guidance from the NIST Cybersecurity Framework 2.0 treats identity governance as a shared control objective, but shared does not mean ambiguous. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows why lifecycle discipline matters: access that is not created, changed, reviewed, and revoked on time becomes standing risk. In practice, many security teams encounter lifecycle failures only after a termination, transfer, or vendor offboarding event has already left active access behind, rather than through intentional control testing.

How It Works in Practice

Effective lifecycle governance starts by separating ownership from execution. HR should own the source event for employee status changes, IT or identity teams should own the technical workflow that provisions and revokes access, and application or data owners should approve exceptions where access does not fit standard policy. That division keeps the process auditable while preserving operational speed. The real requirement is not that one group does everything, but that each handoff has a named accountable owner, a timestamp, and a defined SLA.

For NHI-heavy environments, the same principle applies with more rigor because service accounts, API keys, and automation identities do not wait for manual cleanup. The OWASP Non-Human Identity Top 10 highlights how stale credentials, excessive privilege, and weak rotation controls turn lifecycle gaps into breach paths. NHI Management Group’s NHI Lifecycle Management Guide reinforces that lifecycle governance should include onboarding, change management, periodic review, rotation, and revocation, not just joiner-mover-leaver workflows for humans.

• Use HR as the authoritative source for employment state and worker category.
• Use IT identity teams to automate provisioning, deprovisioning, and entitlement sync.
• Require application owners to approve non-standard access and certify exceptions.
• Log every lifecycle transition with evidence for audit and incident response.
• Map NHI ownership to the business service, not the individual administrator.

When done well, lifecycle governance becomes a control chain rather than a ticket queue. These controls tend to break down when HR data is incomplete, contractors are managed outside the standard onboarding path, or applications maintain their own local accounts because the identity source of truth is not enforced consistently.

Common Variations and Edge Cases

Tighter ownership models often increase coordination overhead, requiring organisations to balance speed against assurance. That tradeoff is most visible in mergers, outsourced operations, and highly regulated environments where identity events originate in multiple systems and no single team controls the full workflow.

Current guidance suggests that there is no universal standard for this yet, but the safest pattern is explicit accountability with shared execution. For example, in contractor-heavy environments, procurement may trigger the event while IT performs the lifecycle action, and the hiring manager or service owner must validate end dates and access scope. For NHIs, lifecycle ownership can be even more fragmented because a platform team may create the identity, a developer may embed the secret, and a product owner may be the only person who understands the service dependency.

That is why lifecycle governance should be documented as a RACI, backed by automation, and reviewed after every incident or audit finding. NHI Management Group’s research on Ultimate Guide to NHIs and the broader lifecycle section helps teams see where revocation, rotation, and ownership fail in real environments, especially when exceptions become permanent. In practice, the hard part is not writing the policy, but enforcing it across systems that were never designed to share a single identity authority.

Related resources from NHI Mgmt Group

• Who should own lifecycle decisions when access is delegated across IT, HR, and app owners?
• Who should own lifecycle governance across IAM and access controls?
• Who should own identity lifecycle automation decisions across IT, security, and HR?
• Who should own identity and device governance in a consolidated work platform?