How do identity teams connect app requests to joiner-mover-leaver governance?

By treating requests as lifecycle events, not one-off tickets. Each approved request should map to an owner, a business reason, and a review or removal trigger tied to role changes and offboarding, so access does not outlive the need for it.

Requests Become Governance Events, Not Just Access Tickets

Identity teams get the cleanest JML outcome when an application request is treated as a lifecycle event with an owner, a purpose, and a review point. That shifts the question from “should this user get access now?” to “how will this access be governed through role changes, transfers, and eventual removal?”

That framing matters because a granted entitlement can become stale the moment the person changes team, project, manager, or employment status. A request should therefore carry enough context to survive later review, not just enough detail to approve it once.

For practitioners building the workflow, the most useful anchor is the identity lifecycle itself, not the ticket queue. The request should land in the same control path as provisioning, recertification, and deprovisioning, so the business reason and the owner stay attached to the access decision over time. Joiner-Mover-Leaver (JML) Guide

What Good Mapping Looks Like in Practice

A strong mapping links each application request to a person or service owner, a business justification, and a lifecycle trigger that says when the access should be rechecked or removed. In practice, that means the request record should answer who approved it, why the access exists, and what event ends it.

The common failure is to treat approval as the end state. If the workflow does not bind the request to a mover event, an offboarding event, or a scheduled review, then access can outlive the role that justified it. That is how exception access turns into normal access.

This is also where governance and provisioning have to align. Teams that want fewer stale entitlements usually need a model where request approval, role assignment, and review/removal are all visible in the same policy structure. IAM and IGA Basics

When requests are tied to automated provisioning, the governance question becomes whether the automation also carries the removal condition. SCIM and Automated Provisioning Guide

How Identity Teams Keep Access From Outliving the Need

Identity teams usually need three control points: request intake, lifecycle trigger, and revocation path. If any one is missing, the process becomes partial governance rather than joiner-mover-leaver governance.

At intake, require the request to name the access owner and the business purpose. At the lifecycle layer, connect the entitlement to a mover or leaver condition, not a static approval date. At removal, make sure the workflow can actually withdraw access, not only log that a review happened.

For broader programmes, the best practice is to connect this request pattern to the same operating model used for access reviews, role design, and entitlement cleanup. That prevents “approved once” access from drifting into permanent access across many applications. IGA Buyer’s Guide

If the request is part of a larger identity security programme, it should be managed as a governed lifecycle control with clear ownership, not a helpdesk convenience. Identity Security Programme Guide

Risk and Threat Considerations

When application requests are not tied to lifecycle governance, the main risk is access creep: approvals linger after a job change, project end, or departure. That creates excess privilege, weakens accountability, and makes it harder to tell whether access is still justified.

Failure mechanism: The request is approved once, but no enforced mover or leaver trigger removes or revalidates the entitlement, so access remains active beyond its business need.

Impact: Users can retain permissions that no longer match their role, which raises the chance of unauthorized access, audit findings, and broader blast radius if an account is misused or compromised.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	PS-4 — Personnel Termination	Leaver-triggered access removal is central to JML governance.
	AC-2 — Account Management	Requests, provisioning and revocation are core account lifecycle controls.
	AC-6 — Least Privilege	JML governance is meant to prevent access from exceeding current job need.
Recommendation — Tie offboarding events to immediate account and entitlement removal. Require each approved request to create a tracked account lifecycle record. Limit entitlements to the minimum access justified by the current role.
ISO/IEC 27001:2022	A.5.18 — Access rights	Access rights must be provisioned, reviewed and removed as roles change.
Recommendation — Review and revoke access rights when job duties or employment status change.
CIS Controls v8	CIS-5 — Account Management	JML requests depend on managed onboarding, changes and offboarding.
Recommendation — Centralize account lifecycle requests and enforce timely removal on departure.

Practitioner Guidance

What to prioritise: Capture owner, business reason, and expiry or review trigger on every request before you worry about fine-tuning approval routing. Those three fields make the request governable later.

What to verify: Check that the deprovisioning or recertification path is actually connected to the same entitlement the request created. If removal depends on manual memory, the control will drift.

Common mistake: Treating approval as proof of continuing need. A good JML process assumes the need will change and builds the review point into the request itself.

Practitioner takeaway: The best joiner-mover-leaver designs do not just grant access correctly, they make it easy to prove when that access should end.