Who should own joiner, mover, and leaver governance?

Ownership usually sits with identity, IT security, or IGA teams, but it must be coordinated with HR, managers, and application owners. HR supplies authoritative lifecycle triggers, managers validate business need, and identity teams enforce provisioning and revocation. Without that shared ownership, lifecycle controls become inconsistent and easy to bypass.

Why This Matters for Security Teams

Joiner, mover, and leaver governance is not just an HR process. It is the control plane that determines who gets access, when that access changes, and how quickly it is removed when a person changes roles or exits. When ownership is vague, provisioning becomes inconsistent, revocation lags, and exceptions start to outnumber policy. That creates real exposure across SaaS, cloud, and internal systems, especially where identity changes are still handled manually.

Security teams usually do not fail because the policy is missing. They fail because no single function is accountable for the full lifecycle, from trigger to deprovisioning. NIST’s Cybersecurity Framework 2.0 treats governance as an ongoing organisational responsibility, not a one-time setup. NHIMG’s lifecycle guidance for NHIs makes the same point for machine identities: lifecycle ownership must be explicit or revocation and review will drift. The governance lesson applies even more strongly when people, applications, and secrets all change at different speeds. In practice, many security teams encounter orphaned access only after a mover event or termination has already been missed.

How It Works in Practice

The most effective operating model is shared ownership with clear handoffs. HR or workforce systems should be the authoritative source for employment status and role changes. Managers should approve business need, especially for privileged or sensitive access. Identity, IT security, or IGA teams should enforce the workflow, provision access, and ensure leavers are removed quickly across connected systems.

For joiners, the process should start from an approved role profile, not an ad hoc ticket. For movers, the key task is not only adding new access but also removing access that is no longer appropriate. For leavers, the priority is fast revocation, including disabling accounts, rotating shared secrets where needed, and validating that downstream applications have processed the change. The practical control objective is to make lifecycle events authoritative, repeatable, and auditable.

• Define one system of record for employment and role status.
• Map every access package to a business role or job function.
• Require approval for exceptions, not for routine joins.
• Automate deprovisioning wherever the application supports it.
• Review stale accounts, dormant access, and orphaned secrets on a fixed cadence.

NHIMG’s Top 10 NHI Issues shows why lifecycle failures remain so persistent: governance gaps often appear first as over-privileged or forgotten identities, then become audit findings or incidents. The 2024 ESG Report: Managing Non-Human Identities also underscores the impact of poor lifecycle hygiene, with 72% of organisations having experienced or suspecting a breach involving NHIs. These controls tend to break down when mergers, contractor churn, or decentralised app ownership make it unclear who can authorise removal.

Common Variations and Edge Cases

Tighter lifecycle control often increases administrative overhead, so organisations must balance speed against assurance. That tradeoff becomes most visible in high-churn environments, shared service centres, and third-party-heavy ecosystems.

There is no universal standard for every exception pattern yet. Current guidance suggests keeping the ownership model consistent, then allowing controlled variations for contractors, interns, temporary transfers, and emergency access. The main difference is who initiates the event and how quickly the entitlement is revalidated. For example, a contractor leaver may need faster certificate and token revocation than a standard employee exit, while a mover in a regulated function may require reapproval before access is restored.

Practical edge cases often involve shared accounts, service accounts, and local application admins. These do not fit cleanly into HR-driven workflows, so identity teams need compensating controls such as periodic attestations, secret rotation, and application owner sign-off. NHIMG’s regulatory and audit perspective is useful here because auditors care less about organisational charts than about whether ownership is documented, testable, and enforced. Where application owners can create access outside central workflows, governance breaks down fastest because the approval trail no longer matches the actual entitlement state.

Related resources from NHI Mgmt Group

• How should security teams automate joiner, mover, leaver governance in a regulated environment?
• How should security teams automate joiner-mover-leaver processes in IGA programmes?
• Who should own identity governance when it spans cloud and enterprise systems?
• Who should own password reset governance in a healthcare environment?