Three Findings, One Quarter's Budget

Order: (b) svc_batch, then (a) Patel, then (c) review quality - but (c) is the reason the other two survived, so it must be fixed in the same cycle.

1. svc_batch - Domain Admin, orphaned. Highest because the combination is explosive: domain-wide privilege (blast radius = the whole estate, including the DC and the backup system) plus no accountable owner (nobody will notice a change in its behaviour) plus a nightly job that must run unattended, so the credential is usable at a predictable time every day. A service account with DA is the standard path from a single compromised application server to domain compromise. Exploitability is not theoretical: anyone who reads the scheduled task or the job's config gets DA.

2. Patel - Finance approver plus repo admin. This is a segregation-of-duties conflict with a live fraud path: engineering commit access to payment code plus authority to approve accounts-payable changes. It is also a mover case that the Joiner-Mover-Leaver process missed, which means the same failure exists for every other transfer. Blast radius is bounded by Finance's payment limits but the loss is direct money and it is discoverable by an auditor or a counterparty.

3. Rubber-stamped reviews. Lower immediate blast radius per click, but it destroys the detective control that is supposed to catch (a) and (b). If 22% of 1,900 entitlements were approved in 90 seconds, you have no evidence any of the remaining 1,482 were actually examined - assume the review produced zero assurance for this quarter and that several unknown conflicts are live.

Practical consequence: the ranking drives the sequence, not the budget. Strip svc_batch of Domain Admin and reassign ownership this week; freeze Patel's finance role pending the manager's written justification; re-run the review for risk-tiered entitlements only rather than the whole 1,900.

Root cause is architectural, not clerical. Helio has two authoritative sources for 'who works here': the IdP (fed by HR) and the ERP (fed by a human exporting a file). The mover and leaver events that matter - transfers like Patel's and terminations - depend on a manual step with no error detection, no reconciliation, and no owner. The CSV also creates timing skew: HR is updated when a transfer is approved, the ERP when someone remembers to export.

Symptoms of this root cause: accounts that exist in the ERP but not the IdP (and vice versa), leavers still able to approve invoices, and reviewers certifying entitlements against a population that is itself wrong. Fixing individual accounts without fixing the source guarantees recurrence.

Fund first: make the IdP the single authoritative source for workforce identity and connect the ERP to it via a scheduled, monitored provisioning integration (SCIM, or a service-to-service API feed if the ERP can't do SCIM). Not a better CSV - any file-based bridge keeps the manual step.

Minimum bar for that integration:

• Automated, at least daily, with job failure alerts to a named owner.
• Reconciliation report: identities in IdP but not ERP, and ERP but not IdP, produced every run and reviewed weekly.
• Leaver action within one hour of HR termination, and transfer action that triggers automatic revocation of the old role set (the specific control that would have caught Patel).

What I would not fund first: a bulk cleanup of the ERP table. It will be re-polluted within a quarter and it produces no lasting control. Clean the data as part of the cutover, using the reconciliation report as the acceptance test.

The current review fails on three design points: it reviews everything (so reviewers skim), it asks the wrong people (managers approve what they can't assess), and it captures a binary approve/deny with no rationale.

Changes:

1. Risk-tier the population. Tier 1 - privileged, SoD-relevant, and externally facing entitlements - reviewed quarterly by the entitlement owner (the person accountable for the system or role), not the line manager. Tier 2 - broad business apps - semi-annual with sampling. Tier 3 - commodity access - annual, tied to role, auto-certified on role match.
2. Make the reviewer see the consequence. Show each entitlement with what it grants, the SoD conflicts it creates (Patel's finance role should have surfaced as 'conflicts with ENG-Repo-Admin'), and last-used data. An approver who sees 'unused for 180 days' behaves differently from one who sees a role name.
3. Require a rationale field for every privileged approval, and revoke-by-default for entitlements unused in 90 days unless a justification is entered.
4. Break 'approve all'. Remove the bulk action for Tier 1, cap items per page, and require the reviewer to open the detail for privileged items. This is a UX control, not a policy control, and it is the one that most directly attacks finding (c).
5. Measure the reviewers, not just the result. Track approval time per item, bulk-approval rate, and deny rate per manager. A manager with a 0% deny rate across a large privileged population should be removed as a reviewer and replaced by the entitlement owner.
6. Add a reconciliation outside the review: automated SoD conflict detection run monthly against live entitlements, so the review is not the only place a conflict can be found.

Evidence it worked: bulk-approval rate on Tier 1 near zero, average review time per privileged item in minutes not seconds, a non-trivial and explainable deny/revoke rate, and a measurable drop in standing privileged entitlements. If the first cycle after the change still shows 78% approved in three days, the redesign did not take and the reviewers need to be changed, not the form.