How-to
How to run a user access review with a small team
Also called an access review, a periodic access review, an entitlement review, or access recertification.
The review itself takes an afternoon. What decides whether it was worth doing is the part most teams skip: checking that the removals it found actually happened.
A user access review is a periodic check that every person's access to a system is still needed, made by someone who can judge the need, with the removals it finds carried out and verified, and a record kept of all three. A review that produces decisions but not verified removals has produced a document, not a change.
The steps
- Scope it to what matters. Not every system every time. Start with the ones whose misuse you would have to disclose: production infrastructure, the identity provider's admin roles, source control, and anywhere customer or financial data lives. Three to six systems is a review a small team will finish.
- Export groups and roles, not accounts. One row per person per group or role, with nested groups expanded. Reviewing a list of accounts tells you who exists; it says nothing about what they can do, and nested membership is where the surprises are.
- Assign the reviewer who knows the work. That is usually the person's team lead, not IT and not the system owner — they can say whether the task still exists. Nobody reviews their own access, including the person running the review.
- Decide each row: keep, remove, or ask. Set a deadline for "ask". A row still unanswered at the deadline is a decision too, and it should be written down as one, not carried to next quarter.
- Remove, then verify. Make the removals, then export again and compare. This step is the whole point and the one most often missing: the removal ticket was closed, the group membership was not.
- Keep the record. The export, the decisions, who made them, and the second export that proves the removals. That set is what answers an auditor or a customer's security questionnaire, and it is also next quarter's starting point.
A template
One row per person, per group or role, per system. The columns that make a row decidable are the ones exports usually lack — why it was granted and when it was last used. Fill what you can; an empty "granted for" column is itself a finding.
| System | Person | Group or role | Granted | Granted for | Last used | Reviewer | Decision | Removal verified |
|---|---|---|---|---|---|---|---|---|
| AWS prod | a.lee | prod-admins | 2025-03-14 | Q1 migration | 2025-06-02 | j.ortiz | Remove | 2026-10-03, re-export |
| GitHub | a.lee | platform-maintainers | 2024-11-01 | Team member | Yesterday | j.ortiz | Keep | — |
| Okta | r.shah | Super Administrator | 2023-08-20 | (blank) | Unknown | m.chen | Ask → Remove at deadline | 2026-10-10, re-export |
The example rows are illustrative. The third is the one every review finds: a powerful role, granted years ago, reason unrecorded, usage unknown. It is also the row reviewers are most tempted to keep, because nobody wants to be the one who removed admin from the person who turns out to need it on Friday.
Where small-team reviews go wrong
- Last quarter's spreadsheet, copied forward. Decisions get inherited instead of made. Start each review from a fresh export, every time.
- Service accounts left out. They hold some of the broadest access in the estate and have no manager to review them. Give each one a named owner, and review it like a person.
- "Keep" as the default. Reviewers approve what they cannot judge. If a reviewer cannot say what a row is for, the row goes to "ask", not "keep".
- Break-glass accounts reviewed as people. They are meant to hold standing privilege. Review whether they were used, and why, not whether they should exist.
- No verify step. Already said, and worth saying twice.
Make the next review smaller, not faster
Most advice on access reviews is about speeding up the reviewer: better exports, reminders, one-click approve. That helps, and it leaves the underlying arithmetic alone. Every standing grant becomes a row, rows accumulate faster than quarterly reviews remove them, and reviewers facing hundreds of rows approve most of them. The access creep guide covers why a periodic correction cannot keep up with a process that produces the error continuously.
The alternative is to stop producing rows. Access that is granted for a window and removed automatically when it closes does not need a reviewer to take it back — nobody holds it by the time the review comes round. What is left to review changes shape:
| Reviewing standing access | Reviewing time-bound access | |
|---|---|---|
| What is reviewed | Every membership, per person | Each access package: who may request it, what it grants, how long it lasts, who approves |
| Rows | People × groups, growing every quarter | Packages, plus the short list of standing exceptions |
| Evidence of removal | A second export, if anyone takes one | The grant log: every grant's start, end and removal, recorded as it happens |
| A missed review means | Another quarter of standing access | The packages are unchanged; nothing was left switched on |
Standing access does not disappear entirely — break-glass accounts, service accounts and the handful of roles that genuinely are full-time stay on the list, and they are exactly the rows worth a reviewer's attention. That is the real gain: the review gets small enough that every row is read.
How often
Quarterly for production and administrative access and annually for everything else is the common pattern, and it is a reasonable one. Cadence matters less than completion: a quarterly review that never verifies its removals is worse than an annual one that does, because it produces four times the paperwork asserting the same unchanged access.
How TemprBac fits
TemprBac turns standing memberships into time-bound grants across Entra ID, Okta, Google Workspace, GitHub, AWS IAM and Active Directory. Each request records who asked, the reason they gave where the package asks for one, who approved, when the access started, and when it was removed — removal is recorded as its own event, separately from the request to remove, so the log shows what actually happened rather than what was intended. Reports export to CSV for the record step above. It does not run the review of your remaining standing access for you; it makes that list short.