The access-request queue is not where entitlements come from
Ask most organisations how privilege is controlled and you get a description of the request path: a ticket, an approver, a joiner-mover-leaver process, a quarterly review where managers attest to their teams' roles. All of that governs one route into the entitlement graph, and it is the route that is already watched. The interesting failures arrive by the other routes, which have their own approvals designed for a different purpose entirely.
A migration adds a column and the row-level policy that referenced the old one silently stops filtering. A feature flag defaults to on for a tenant tier rather than for a tenant. A configuration change replaces a role mapping in the identity provider. A backfill written to repair a handful of corrupted records runs against the whole table because the predicate was wrong. Every one of those is reviewed as a code or data change by an engineer competent to review code, and none of them is reviewed as a privilege grant by anyone whose job is entitlements. Separation of duties is intact on the request path and absent on the path the change actually took.
When a deployment script becomes an entitlement change
In May 2019 a database script deployed by Salesforce granted broad read and write permissions across affected orgs, so ordinary employees at customer companies could see and modify data they had never been entitled to, and access to services had to be blocked while the permissions were unpicked. What makes it instructive is not the scale but the route. Nobody requested that privilege, so no approver saw a privilege request. It went through the deployment path, where reviewers were looking for correctness and regression, not for who could now read whose records.
The point to draw out is that the ability to grant privilege is itself a privileged operation wherever it lives — in a migration, a script, a configuration repository, a policy bundle — and a control that only inspects the request queue is measuring the wrong population.
Snapshot effective permissions, not role definitions
Reading configuration tells you what was intended. The only thing worth comparing across a release is the resolved answer: for each principal, which resources are reachable under which actions. Effective permissions are the product of the role graph, group membership, inherited grants, row and column policies, tenancy predicates, flag state and any deny that overrides them, and the whole difficulty is that no single artefact in the repository contains that product.
So the mechanism is a job that materialises it. Enumerate principals, or a stratified sample plus every principal in a sensitive group, ask the authorisation system what each may reach, and store the result as a set. Do it before and after every deployment that touches schema, policy, identity configuration or flags, then diff. A diff that grows is a finding; a diff that grows for a population rather than for an individual is an incident until somebody proves otherwise. The virtue of this design is that it is indifferent to how the change arrived, which is exactly the property the request-path control lacks.
Two engineering realities make it harder than it sounds and both are worth naming out loud. Enumeration is expensive at scale, which is why the practical version samples broadly and covers sensitive scopes exhaustively rather than attempting the full cross-product. And in an attribute-based model the decision depends on request context, so what you snapshot is the outcome for a fixed set of synthetic contexts: you are testing the policy, not the universe, and you should say so before the interviewer says it for you.
| How the entitlement changed | Who reviews it today | What the diff catches that they do not |
|---|
| Access request | Named approver, recorded | Nothing new — this path is already covered |
| Schema or policy migration | Code reviewer, for correctness | A predicate that no longer filters |
| Configuration or role mapping | Change approver, for availability | A group that now resolves to more principals |
| Flag or tier default | Product owner, for rollout | A capability enabled for the wrong population |
| Data fix run with elevated rights | Frequently nobody independent | The whole change, including that it happened |
Who is allowed to clear the diff
The separation-of-duties content of this design sits in the last column, not the first. If the diff is generated by the pipeline and read by the engineer who deployed, you have built a self-attestation with extra steps. The person who introduced the change cannot be the person certifying that the change did not widen access, for the same reason a developer does not approve their own release into a regulated environment.
That does not require a separate team, which matters because most organisations asking this question do not have one. It requires that the diff routes to a role rather than to the author, that clearing it is a recorded action with an identity attached, and that an uncleared diff blocks something. If nothing is blocked, the alert becomes another dashboard nobody reads, and an honest answer says so: the control's strength is entirely in what happens when it fires.
Detection time is the number being asked for
The interviewer asked how long it would take, and a strong answer treats that as the design target rather than an aside. A nightly reconciliation means up to a day of unauthorised reads. A pre-deployment gate means the grant never reaches production, but only for changes that pass through the gate. Most estates need both, because the paths that bypass the gate are precisely the ones that caused the problem in the first place.
Then separate the two things you do when it fires. Containment narrows access immediately, and it is worth saying that rolling back the release is frequently not containment: the rollback restores the policy but leaves the derived state — cached decisions, warmed search indexes, exported reports, anything the wider population has already pulled into a spreadsheet. Remediation is the slower work of restoring intended entitlements, and it should proceed from a known-good definition rather than by reversing the diff, because reversing a diff you do not fully understand is how the second incident starts.
The question you will not be able to answer
The forensic gap is the part candidates rarely reach and the part a compliance reader cares about most. Once exposure is contained, somebody will ask which records were actually read during the window and by whom. If your access logs record the authorisation decision but not the resource identity, or if reads are served from a cache that does not log, or if the log's retention is shorter than the time it took you to notice, that question has no answer and you will be reporting an upper bound instead of a fact.
Whether an obligation to notify anyone is triggered, and on what timetable, is a determination for your legal and privacy function, and both the trigger and the deadline vary by jurisdiction and by the nature of the data involved. What you owe them is the evidence to make that determination, and that evidence has to have been captured before the incident rather than reconstructed after it.
Governance that watches the access-request queue is watching one of five doors. Diff effective permissions on every release, route the diff to somebody who did not ship it, and make sure your read logs are good enough to answer the question that comes after containment.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).