Joiner-Mover-Leaver Evidence

What JML Evidence Shows in Practice

Joiner-Mover-Leaver evidence is the proof trail that identity lifecycle events actually happened: accounts were created, changed, and removed when they should have been. It turns a policy claim into an auditable record of what the organisation did.

For a glossary term like this, the key idea is that evidence is not limited to the central IAM console. If an application can grant, retain, or revoke access, its logs or workflow records must also show the lifecycle change.

Why This Evidence Matters for Governance

JML evidence is what lets teams verify that onboarding, role changes, and offboarding were completed consistently across the systems that matter. That includes HR-driven provisioning, access reviews, and deprovisioning steps that may occur outside the core IAM platform.

Without that end-to-end record, an organisation may have good intentions but no reliable proof that access was removed everywhere. In practice, that is where orphaned access, stale entitlements, and delayed revocation begin to accumulate.

This is also why joiner-mover-leaver evidence often spans more than one control owner. Identity governance, application owners, and platform teams may all hold part of the audit trail, and the evidence set is only as strong as its weakest system of record.

What Good JML Evidence Contains

Useful evidence usually shows the identity event, the source of the request or trigger, the approval or policy basis, the date and time of the change, and the systems touched. For movers, it should show both removal of old access and assignment of the new role set when those steps are separated.

For leavers, the strongest records show that access was deprovisioned across every relevant application, not merely disabled in one directory. For applications that create or retain access, the SCIM and Automated Provisioning Guide is a useful companion because it explains how automated provisioning and deprovisioning should be evidenced in connected systems.

Application governance evidence is especially important when entitlements are granted locally, because the central IAM record alone may not show whether the downstream system actually executed the access change. That is the difference between an approval and a completed control.

How to Read JML Evidence in an Audit or Review

Strong JML evidence answers three questions: was the right change requested, was it approved or policy-driven, and did every relevant system carry out the action. If any one of those is missing, the evidence is incomplete even if the identity platform looks clean.

That review becomes more important when access is distributed across SaaS apps, bespoke platforms, and privileged systems. A central record may show intent, but only application-level evidence proves the final state.

For a broader view of how lifecycle controls, entitlements, and governance fit together, IAM and IGA Basics provides the identity governance context that JML evidence supports. If the organisation needs lifecycle coverage for non-human actors as well, NHI Lifecycle Management Guide shows how the same lifecycle principles extend to automated identities and related credentials.

Risk and Threat Considerations

Weak JML evidence creates a gap between declared access governance and actual system state. The risk is not just poor auditability, it is lingering access after role changes or termination, which can leave accounts active long after they should have been removed.

Failure mechanism: A central IAM record can show that a joiner, mover, or leaver process was initiated while downstream applications, tokens, keys, or local entitlements were never changed, leaving hidden access behind.

Impact: Attackers, insiders, or simple process failures can exploit that gap for unauthorized access, privilege retention, or data exposure, and auditors may have no complete trail to prove the organisation closed the access path.

Practitioner Guidance

Why practitioners should care: JML evidence should be treated as a control outcome, not a paperwork artifact. If evidence does not exist in every system that can create or retain access, then the lifecycle process is not fully verifiable.

Governance implication: Ownership must extend beyond the IAM team to application and platform owners who can prove local provisioning and deprovisioning. That shared responsibility is what makes the evidence set complete enough for assurance.

Practitioner takeaway: The best JML evidence trail is the one that can show, end to end, that access was both authorised and actually removed where it existed.

Related resources from NHI Mgmt Group

• Why do service accounts and API keys complicate joiner-mover-leaver processes?
• How can organisations use access profiles in joiner-mover-leaver workflows?
• How should security teams automate joiner-mover-leaver workflows?
• What breaks when joiner-mover-leaver workflows are mostly manual?