User Access Review: Periodic Certification, Scope, Decisions and Evidence (Part 2)
Run access certification as a risk-based control where accountable managers or role owners review actual user-role access and record keep, remove or remediate decisions with evidence.
Explanation
📌 KEY POINTS
✅ Verifies current appropriateness, not historical approval — the whole point is "still," not "once."
⚠️ A completed spreadsheet with no actual removal executed is not an effective control.
💡 Risk-based review focuses more frequently on privileged/SoD-sensitive/dormant access; lower-risk access follows a standard cycle.
━━━━━━━━━━━━━━━━━━━━
▶ 1. DEFINE SCOPE FIRST
- Systems, user populations, business roles, critical privileges, review frequency
- Reviewers need understandable role descriptions and risk context — dozens of cryptic technical role names produces weak evidence
━━━━━━━━━━━━━━━━━━━━
▶ 2. EACH LINE NEEDS AN AUDITABLE DECISION
- Retain, remove, change, or investigate
- Removal decisions must flow to deprovisioning AND be verified — a completed spreadsheet with no actual removal is not a control
━━━━━━━━━━━━━━━━━━━━
▶ 3. RISK-BASED CADENCE
- Privileged, SoD-sensitive, or dormant access reviewed more frequently
- Lower-risk access follows a standard cycle
- Service/technical users need owner certification too
━━━━━━━━━━━━━━━━━━━━
▶ 4. WHAT TO MEASURE
- Overdue reviews, reviewer completion quality, removal execution, repeated re-grant after revocation
✅ CHECKPOINT: explain why a fully-completed review spreadsheet can still represent a control failure.
Real project scenario
A manager revoked a sensitive role during quarterly certification, but the role remained assigned because the review tool was not integrated with deprovisioning. Audit treated the control as ineffective. The process added removal tracking and post-certification verification.
Common mistakes
- Reviewing cryptic technical roles with no description.
- Treating review completion as proof removals happened.
- Ignoring technical/service users.
- Applying identical frequency to all access risk.
- Letting overdue certifications accumulate.
Best practices
- Give reviewers business-readable access context.
- Prioritize critical access.
- Track removals to completion.
- Review technical users.
- Measure overdue/ineffective decisions.
Interview angle
Explain scope, reviewer, decision evidence and downstream deprovisioning. Strong answers distinguish certification from provisioning.
Practice this lesson
Quick check
1. Explain scope, reviewer, decision evidence and downstream deprovisioning. In the User Access Review context, which answer shows the strongest practical judgment?
2. Run access certification as a risk-based control where accountable managers or role owners review actual user-role access and record keep, remove or remediate decisions with evidence. A production team now has to make a design decision in User Access Review: Periodic Certification, Scope, Decisions and Evidence. Which option best preserves reliability and supportability?
3. A review of User Access Review: Periodic Certification, Scope, Decisions and Evidence finds this risky pattern: "Letting overdue certifications accumulate.". Which corrective action is strongest?
Interview questions
1. 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.
2. What are the most important design decisions, trade-offs, and best practices in User Access Review?
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.