30,000 Entitlements, Four-Second Reviews: Rebuilding a Certification Program
Kestrel Health runs quarterly access certification across 40 applications and 30,000 entitlements for 9,000 workers. Last quarter, 58% of campaigns completed on time, the median review time per entitlement was four seconds, and 99.4% of decisions were approvals. Post-campaign analysis finds 2,300 orphaned accounts tied to identities HR cannot match, and 61% of entitlements are birthright access that is not flagged as such, so reviewers see it as discretionary. In SAP, 340 users hold both create-vendor and post-payment permissions, a segregation-of-duties conflict auditors have flagged for three consecutive quarters; the business says the FI configuration cannot be split before the next fiscal year. Two leavers retained access to the revenue-cycle system for 60 days.
1. Redesign the certification campaign. What do you remove, what do you keep, and how do you know the new campaign is actually working?
Read the worked answer
Remove the noise. 61% of the 30,000 is birthright - role-derived, identical for everyone in the role. Certifying it per person per quarter produces 18,000 meaningless decisions and trains reviewers to click approve. Tag birthright at the role level and certify the role definition annually, not each holder quarterly. That leaves roughly 12,000 genuinely discretionary entitlements, and reviewer attention per item rises immediately.
Scope by risk, not by org chart. Tier the remainder: SoD-relevant and privileged entitlements reviewed quarterly by the application owner plus the manager; revenue-cycle and PHI access reviewed quarterly by the manager; everything else semi-annually with sampling-based QA.
Fix the mechanics: reviewers see the last-used date, the manager, and the entitlement's purpose, not just the application name. Non-response escalates to the manager's manager and then revokes - silence is not approval.
Measure the campaign by its outputs, not its completion rate: decisions per minute, approval percentage, revocations executed, and count of entitlements removed. A 99.4% approval rate with a four-second median is a signature of rubber-stamping, and it is the number I would report to the audit committee.
2. 340 users hold conflicting create-vendor and post-payment permissions, and the FI split is a year away. What is your remediation, and what do you refuse to accept?
Read the worked answer
Segment the 340 before touching them. Pull 90 days of activity: how many actually executed both functions? Typical splits are 20–30% active conflicts, the rest dormant or role-inherited. Dormant holders get the conflicting role removed now - no FI change needed, no business disruption. That is the fastest real reduction.
Active conflicts get mitigating controls, not a promise. Independent second-person approval on payment posting, transaction value thresholds, exception reporting reviewed weekly by finance control, and continuous monitoring rather than an annual review that finds the problem eleven months late. Document each control with an owner and test it, because an untested mitigating control is a sentence in a report, not a control.
What I refuse to accept: "the config cannot be split" as a terminal statement for three consecutive quarters. Accept it as a project with a milestone, a named owner, a budget line, and a residual-risk acceptance signed by the CFO with an expiry date. Track the conflict count monthly. A flat count means the compensating controls have become the permanent architecture.
3. 2,300 orphaned accounts and leavers keeping access for 60 days - how do you close the lifecycle gap without disabling something critical?
Read the worked answer
Orphaned does not mean unused. Triage the 2,300 by last activity and owner attributes. Match what you can through manager chains and application ownership; disable dormant accounts (no activity for 90 days) after owner notification, and quarantine active ones for a defined window before disabling. Expect a slice to be service accounts misclassified as human - those move to the secrets program, not the disable list.
Fix the pipeline, not just the backlog. The 60-day revenue-cycle access is a feed problem: HR termination event, IdP disable, application deprovision, all measured separately. Instrument each hop and alert when a termination fails to propagate downstream within the SLA - 24 hours for the IdP, 72 hours for tier-1 applications. Report time-to-deprovision as a control metric, not a project status.
Reconcile continuously. A daily comparison between HR's authoritative record, the IdP, and the downstream application extracts catches both orphans and leavers within a day instead of a quarter. Quarterly certification should be the backstop for judgement calls, never the mechanism that discovers a termination.