Identity and Access Review Automation: Joiner-Mover-Leaver, Dormant Users and Privileged Access (Part 3)
Automate access governance around joiner-mover-leaver events, dormant-account detection and privileged-access review so periodic certification becomes the backstop rather than the only control.
Explanation
📌 KEY POINTS
✅ Periodic review matters, but joiner/mover/leaver changes need to be handled continuously, not just at review time.
⚠️ Movers are the classic SoD-accumulation trap — adding the new role without removing the old one.
💡 Automation should produce exceptions for humans to review, not blindly delete access without business context.
━━━━━━━━━━━━━━━━━━━━
▶ 1. THE THREE LIFECYCLE EVENTS
- Joiners — approved birthright and job access through role/business-role rules
- Movers — need OLD responsibilities removed as well as new ones added; adding-only is the classic cause of SoD accumulation
- Leavers — timely disablement/removal across productive systems and technical channels
━━━━━━━━━━━━━━━━━━━━
▶ 2. DORMANT-USER MONITORING
- Identifies enabled-but-unused accounts
- Evaluate service/system users separately — interactive logon frequency isn't a fair control for every technical identity
━━━━━━━━━━━━━━━━━━━━
⚠️ 3. PRIVILEGED ACCESS GETS EXTRA SCRUTINY
- More frequent review, stronger owner evidence
- Emergency-access assignments, broad admin roles, and anyone who can change authorization — monitored independently from ordinary end-user roles
━━━━━━━━━━━━━━━━━━━━
▶ 4. THE AUTOMATION RULE
- Produce exceptions for humans to review — never blindly delete access without business context
✅ CHECKPOINT: explain why "mover" access changes are riskier than "joiner" or "leaver" changes.
Real project scenario
An employee changed from purchasing to finance and received the new finance roles, but purchasing roles were never removed. A mover-control integration was redesigned to compare target job role against existing access and create explicit removals.
Common mistakes
- Automating additions but not removals.
- Disabling technical users based only on no dialog login.
- Reviewing privileged access only annually.
- Ignoring contractor end dates.
- Letting periodic UAR compensate for weak JML.
Best practices
- Treat mover removal as first-class.
- Classify technical users separately.
- Review privileged access more frequently.
- Use HR/identity lifecycle triggers.
- Measure orphaned and dormant access.
Interview angle
Explain how JML, dormant-account monitoring and privileged review complement periodic access certification.
Practice this lesson
Quick check
1. Scenario — An employee changed from purchasing to finance and received the new finance roles, but purchasing roles were never removed. Which response best addresses the design or operating risk in Identity and Access Review Automation: Joiner-Mover-Leaver, Dormant Users and Privileged Access?
2. A review finds this recurring pattern around Identity and Access Review Automation: Joiner-Mover-Leaver, Dormant Users and Privileged Access: "Applying identical frequency to all access risk." Which principle should the team adopt?
3. A team proposes this shortcut while working on Identity and Access Review Automation: Joiner-Mover-Leaver, Dormant Users and Privileged Access: "Letting periodic UAR compensate for weak JML." Which alternative should you recommend?
Interview questions
1. You are the senior consultant/architect responsible for Identity and Access Review Automation: Joiner-Mover-Leaver, Dormant Users and Privileged Access. The project situation is: An employee changed from purchasing to finance and received the new finance roles, but purchasing roles were never removed. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?
Answer it in your own words first, then compare.
2. You are the senior consultant/architect responsible for User Access Review: Periodic Certification, Scope, Decisions and Evidence. The project situation is: A manager revoked a sensitive role during quarterly certification, but the role remained assigned because the review tool was not integrated with deprovisioning. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.