ANUGAL UAC SERIES · 4 OF 6 · ENFORCEMENT
Certified but Never Revoked: Closing the Enforcement Gap
In April, a reviewer revoked a contractor's access to the finance system. In October, the auditor found the account still active. The decision was real. The enforcement never happened. Between them sat an export, an email, a ticket queue, and nobody's job.
THE SHORT ANSWER
Revocations fail because most certification processes stop at the decision: a spreadsheet cell says revoke, then a manual email or ticket carries it toward an application team that never confirms. Closing the gap means decisions flow directly into provisioning: campaign completion triggers deprovisioning requests automatically, tracked to execution, with evidence attached.
Where do revocations go to die?
Follow one revoke through a typical enterprise and the failure explains itself.
| Step | Where it breaks | Who was supposed to own it |
|---|---|---|
| Export the revokes | The spreadsheet leaves the system of record; versions multiply | Certification admin |
| Email the application team | The request joins an inbox with no SLA and no tracking | Nobody, formally |
| Raise a ticket | The ticket closes as done without verifying the account state | App support queue |
| Confirm removal | This step does not exist in most programs | Nobody |
This is the failure your own review documents. An auditor who finds a revoked-on-paper account still active holds two findings in one sample: the control gap, and written proof you knew.
A revocation that needs a human relay is a suggestion, not a control.
What does decision-to-enforcement look like?
The fix is structural: put the decision inside the system that executes it. Four properties define the closed loop.
- Complete is a trigger. Closing the campaign automatically creates deprovisioning requests for every revoked access, with no manual execution step in between.
- Decisions ride existing workflows. Revocations flow into the same provisioning engine that grants access, with its approvals, routing, and logging intact.
- Certify, revoke, sync. The loop runs against connected systems directly, so the target state and the decided state converge instead of drifting.
- Recurrence prevents the backlog. Recurring recertification aligned to role and organizational change keeps each campaign small enough to enforce fully.
Complete should be a trigger, not a status.
How do you know it worked?
Enforcement earns trust the same way any control does: by proving itself. Every deprovisioning request tracks to completion. The target system's state gets verified against the decision. Exceptions escalate to a named owner with a date. And the evidence attaches to the campaign record, so the auditor's October sample finds a closed loop instead of a live account.
The Decision-to-Enforcement Checklist
THE DECISION-TO-ENFORCEMENT CHECKLIST
- Every revoke decision creates a deprovisioning request automatically.
- Every request is tracked to completion, with an owner and an age.
- Removal is verified against the target system, not assumed from the ticket.
- Evidence of execution attaches to the campaign record itself.
- Exceptions escalate with named owners and expiry dates.
Mistakes that reopen the gap
- Closing the campaign before revocations execute. Completion should mean enforced, not decided.
- Measuring decisions instead of removals. The metric that matters is accounts changed, not cells filled.
- Running enforcement through email. Anything without tracking, verification, and evidence is a hope with a subject line.
Frequently asked questions
Why do access revocations fail?
Because the decision and the execution live in different systems joined by manual steps: exports, emails, and tickets with no verification. Each handoff loses a share of the revokes, and no step confirms the account changed. The gap is structural, not a diligence problem.
What is deprovisioning?
The removal of a user's access from a target system: disabling accounts, removing roles, or ending entitlements. In a governed certification, deprovisioning requests generate automatically from revoke decisions and run through provisioning workflows with full logging.
Does automatic revocation break business operations?
Not when it runs through governed workflows. Revocations follow the same routing and approvals as grants, exceptions escalate to named owners, and time-boxed retention exists for genuine transition needs. What breaks operations is the surprise cleanup after months of drift.
How Anugal solves it
Anugal UAC was built around one rule: a decision that does not execute is not a decision.
HOW ANUGAL SOLVES IT
- Complete triggers enforcement. Campaign-level Complete automatically raises deprovisioning requests for all revoked access, with no manual execution step.
- Decisions flow into provisioning. Certification outcomes ride the same workflows that grant access, closing the gap between decision and enforcement.
- Access creep gets structurally eliminated. Recurring recertification aligned to role and organizational change keeps entitlements matched to current business need.
- Execution is evidenced. Decision and enforcement both log automatically, so the campaign record proves the loop closed (per Anugal's UAC materials).
About Anugal. Anugal is the Agentic Identity Governance and Administration platform from Business Core Solutions (BCS). It orchestrates identity lifecycle, access requests, certifications, and risk governance across the enterprise, with 350+ integrations through SCIM 2.0, REST APIs, OData, SOAP, SAP ABAP, and SQL.
SEE IT ON YOUR OWN CAMPAIGN DATA
Bring one recent certification export and we will show you what Anugal UAC surfaces in it: the risk, the rubber-stamps, and the revocations that never executed.
hello@businesscoresolutions.com
Next in this series is live: Agentic AI Access Reviews: Advisory, Assisted, Controlled
