A data platform carries four years of accumulated standing grants: about 900 analysts in roughly 300 groups with permanent read on 6,000 tables. Legal now requires that purpose be recorded and access be time-boxed. You cannot stop analysts working for a day. Give the sequence.

The sequence

1. Observe before changing anything. Turn on query-level audit and build a 90-day matrix of which principal actually read which table. In estates of this age, 60% to 80% of granted principal-table pairs are never exercised. This step is free to reverse and it determines the size of every step after it.
2. Freeze new standing grants and stand the new path up first. Every request from today issues a time-boxed grant with a recorded purpose. Nothing is revoked yet. The point is that the replacement exists and is ergonomic before anyone loses anything.
3. Run the new path in shadow mode. Auto-approve everything, expiry 30 days, no human in the loop. You are measuring request volume and re-request rate, not enforcing policy. If volume is ten times what you sized for, you find out now rather than after revocation.
4. Revoke the unused set. This is the 60% to 80% from step 1, and it is the only large, low-risk move available. Reversible by design: a self-service re-request returns access in minutes, and the re-request rate is the metric that tells you whether step 1 was right.
5. Tier what remains by sensitivity label. Restricted assets go to a named approver; Internal and below stay auto-approved with an expiry. Skipping this tiering is how a migration turns into an approval queue nobody can staff.
6. Delete the legacy groups. This is the point of no return, because the group membership is the only record of who had what. Do it after two full expiry cycles, with the previous state exported to cold storage first.

Where data can diverge, and how you would know

The dangerous divergence is not in the grants, it is in the artefacts created while the grant was live. A materialised view, a BI extract, a notebook-exported CSV or a scheduled report built under a standing grant keeps serving rows after that grant expires, because it runs as the schedule owner rather than as the reader.

The signal: reconcile the set of objects reading a Restricted table against the set of principals currently entitled to it, weekly. A derived object whose owner no longer holds the grant is the finding. Twitch's October 2021 incident is the shape of the risk: the company attributed the exposure to an error in a server configuration change, and what left included internal tooling and creator payout reports for 2019 to 2021, not only primary records. The perimeter has to include what was produced under access, not just the source tables.

The rollback at each stage

Steps 1 to 3 are additive and roll back by turning the new path off. Step 4 rolls back per principal in minutes. Step 5 rolls back by widening the auto-approve tier. Step 6 rolls back only from the export, in hours, and only if you took it.

How long it really takes

For 900 analysts, two to three quarters. The audit and shadow phases take a quarter on their own, and the tiering in step 5 is blocked on sensitivity labels existing, which is usually the real critical path. Teams that promise a quarter have quietly decided to skip step 1.

When this is the wrong answer

If the estate has fewer than about 50 analysts and one sensitivity tier, purpose-recorded just-in- time access is ceremony. Record purpose at the point of the request in a ticket, keep standing grants, and spend the effort on the audit trail instead. Time-boxing earns its cost when nobody can name, from memory, who currently holds access to the most sensitive table.