What Should an IGA Joiner-Mover-Leaver Control Prove?
What Should an IGA Joiner-Mover-Leaver Control Prove?
An IGA joiner-mover-leaver control should prove that each access change began with an authorized workforce event, applied the right entitlements across every connected system, removed rights that no longer had a business basis, and left time-stamped evidence. The proof must cover successful actions, failed changes, exceptions, approvals, and final reconciliation.
Key takeaways
- A joiner record must connect an authoritative worker event to approved access and completed provisioning.
- A mover record must show both newly granted rights and rights removed because the previous role ended.
- A leaver record must prove timely disablement, credential revocation, ownership transfer, and exception closure.
- A control is incomplete when its dashboard reports success but connected applications, failed actions, or manual exceptions are missing.
The exposure is measurable. The Microsoft Digital Defense Report 2024 reported 600 million identity attacks per day against Microsoft customers. The Verizon 2025 Data Breach Investigations Report analyzed 22,052 security incidents, including 12,195 confirmed breaches; the human element appeared in roughly 60% of breaches, while third-party involvement doubled from 15% to 30%.
Those figures do not prove that IGA would have prevented each event. They show why a CISO should require evidence rather than trust a workflow diagram. Infocentric’s Identity Governance and Administration service explains the operating scope; the control test begins where the product description ends.
A useful acceptance rule is simple: no lifecycle event is complete until expected access matches observed access. Keep failures visible, assign every exception to an owner, and require a dated closure record. That rule gives the security team a testable result without pretending that automation removes judgment.
What evidence should each lifecycle event produce?
Each lifecycle event should produce a traceable chain from the source event to the final state in every in-scope system. The following JML evidence chain is an original control artifact constructed for this article and checked against NIST SP 800-53 Rev. 5 controls AC-2 and PS-4 and Section 20 of the Philippine Data Privacy Act.
| Event | Evidence chain | Failure that must remain visible |
|---|---|---|
| Joiner | Authoritative worker record → approved access basis → account and entitlement results → reconciliation | Missing identity attributes, rejected provisioning, duplicate account, or unapproved manual grant |
| Mover | Role-change event → old-versus-new access decision → removals and grants → owner acceptance | Retained former-role access, late source update, policy conflict, or application not connected to IGA |
| Leaver | End event → account disablement and credential revocation → asset or data ownership transfer → closure | Late disablement, active token, unmanaged account, failed action, or unresolved exception |
NIST SP 800-53 Rev. 5 states that organizations should “Create, enable, modify, disable, and remove accounts” under defined policy and criteria. AC-2 also connects account management to personnel transfer and termination. PS-4 covers disabling access and revoking authenticators when employment ends. NIST leaves the time periods and policy details to each organization, so a project team should not invent a universal deadline.
Test the evidence chain in this order:
- Select real joiner, mover, and leaver events from the authoritative workforce source.
- Match each event to the identity record, policy decision, approval, and expected application actions.
- Compare expected actions with target-system results, not only the IGA workflow status.
- Inspect failed actions, retries, manual changes, and approved exceptions.
- Reconcile the final accounts and entitlements to the person’s current status and role.
A useful test includes at least one failed connector action and one manual exception. That choice proves whether the process exposes incomplete work instead of turning partial execution into a green dashboard.
How should ownership and timing be set?
Ownership and timing should be set by event, decision, and target system before automation is approved. Human resources or the designated workforce source owns the employment event; the business access owner decides role-based need; application owners confirm target-system execution; security governs policy and exceptions; internal audit independently tests evidence. Your operating model may assign different titles, but it should not leave one team to request, approve, execute, and certify the same change.
For timing, define a service target and an escalation point for each event class. A scheduled transfer and an involuntary termination do not carry the same risk. NIST AC-2 and PS-4 deliberately use organization-defined time periods. Record the chosen target, its business reason, the clock’s starting event, and the authority that can approve delay. Measure completion at the target system, not when a ticket enters a queue.
Philippine organizations also need a privacy anchor. Section 20 of Republic Act No. 10173 requires reasonable and appropriate organizational, physical, and technical measures against unlawful processing and unlawful access. Section 20(e) says confidentiality duties continue after a transfer or termination. The law does not name IGA or prescribe one deprovisioning deadline, so the control record should show how your timing and scope reflect your processing risk.
Use a short decision register for every approved exception:
- The access owner names the account, entitlement, person, and business reason.
- The risk owner records compensating controls and the exception’s expiration date.
- The application owner records the exact action that could not be completed.
- Security records retry, escalation, and closure evidence.
For identity-program context, use Infocentric’s identity management primer and its discussion of why IGA is a business priority. The JML evidence chain remains the acceptance test for the control you actually operate.
What do security leaders ask about JML controls?
Security leaders usually ask about scope, proof, exceptions, and buying sequence. The answers below are control-design defaults, not universal legal deadlines or product guarantees.
Is disabling the directory account enough for a leaver?
No. The leaver test should also cover connected applications, active sessions or tokens where supported, shared credentials, physical or hardware authenticators, and information formerly controlled by the person. NIST PS-4 explicitly covers access, authenticators, organizational property, and retained access to organizational information.
What is the authoritative source for a JML event?
The authoritative source is the approved system or process that can establish a person’s current workforce status and effective date. It may be an HR system or another governed source for contractors. The control should record source ownership, required identity attributes, late updates, and correction handling.
Should mover controls remove access before granting a new role?
The sequence should follow the risk and continuity needs of the role change. The control must compare former and new access, identify incompatible overlap, name the approver, and record both removals and grants. A completed grant does not prove that access from the former role was removed.
How should applications outside the IGA connector scope be handled?
Keep every unmanaged application in the JML scope register with an owner, manual procedure, evidence requirement, and target date for integration or accepted exclusion. A connector inventory is not an access inventory. Failed emails or unsigned tickets should remain open exceptions rather than being counted as completed removals.
What should a CISO approve before buying IGA automation?
Approve in writing the authoritative-source design, in-scope applications, entitlement ownership, lifecycle rules, timing classes, exception authority, reconciliation method, and evidence-retention needs. Infocentric’s identity and access management portfolio can frame the wider program, but these control decisions should precede product acceptance.