A user access review is a periodic check that every person still needs the access they hold, and that you can prove you checked. It’s a core control for SOC 2 and ISO 27001, and the thing teams most often scramble to reconstruct at audit time. This guide walks through how to run one properly, and how to make the next one far less painful.
What is a user access review?
A user access review (sometimes called access recertification) answers a simple question for each grant of access: does this person still need this, at this level? You go system by system, confirm or remove each person’s access, and record the outcome. The point isn’t just to tidy up access, it’s to produce evidence that the control operated across the review period.
When to run one
Cadence depends on sensitivity and your framework, but a reasonable baseline:
- Quarterly for sensitive systems, production, cloud infrastructure, anything with customer data, admin-level access.
- At least annually for everything else.
- On every change as a continuous complement, when someone offboards or changes role, adjust access then, so the periodic review becomes a confirmation rather than a cleanup.
Auditors care less about the exact frequency than about it being consistent and evidenced.
Step by step
1. Define the scope
Decide which systems and which people are in this review. For a SOC 2 review that’s typically your in-scope systems and everyone with access to them. Write the scope down, it’s part of the evidence.
2. Pull the current access
For each in-scope system, get the current list of who has access and at what level. This is the step that hurts when access lives in spreadsheets and memory: the list is only as accurate as the last person who updated it. A live register of who has access to what removes this pain. The list is already current.
In Driply, there’s nothing to pull. The register is already live: filter the Catalog by tool or by owner to see exactly who holds what, at which level, right now, no export-and-reconcile step.
3. Route each system to an owner
Send each system’s access list to the person accountable for it. A named tool owner who knows what that tool should grant will give a real review; a generic admin reviewing systems they don’t use tends to rubber-stamp. Keep an admin as a backstop so nothing stalls.
In Driply, assign a tool owner to each tool and the review routes itself to the person who actually knows it. Owners can approve, reduce, and revoke for their own tools; admins stay a permanent safety net so nothing waits on someone who’s away.
4. Review each grant
For every person on the list, the reviewer decides:
- Keep, still needed at this level.
- Reduce, needed, but at a lower level (least privilege).
- Remove, no longer needed; revoke it.
Flag anything unexpected: access nobody remembers granting, contractors who’ve rolled off, elevated access that was meant to be temporary.
5. Act on the decisions
Revoke or adjust the access that didn’t pass. In a system of record like Driply you record the revoke and your team performs the change in the tool; the decision and its reason are captured either way.
6. Record the outcome
Capture what was reviewed, by whom, what changed, and when. If your access decisions already land in an append-only log, this step is automatic. The review is the record, and it can’t be quietly edited afterward.
7. Export the evidence
Generate the evidence for the period, typically a branded PDF or CSV showing the access reviewed, the reviewers, and the changes made. This is what you hand the auditor.
A simple user access review checklist
- Scope defined (systems + people) and written down
- Current access pulled for each in-scope system
- Each system routed to its accountable owner
- Every grant marked keep / reduce / remove
- Removals and reductions actioned
- Outcome recorded with reviewer, decision, and date
- Evidence exported for the review period
- Next review scheduled
And this is how it works with Driply
The seven steps above are the manual version. In Driply the same review is a campaign you start and work through, and the record writes itself as you go.
- Start the review and set its scope. Choose the tools in scope or run it across the whole register. The campaign captures who holds what at that moment, so the list you certify is the one that existed when you started, not one shifting underneath you.
- Each line routes to the person who knows it. Tools with an owner go to that owner; anything unowned stays with admins. Nobody assembles a spreadsheet or chases a thread.
- Decide per grant: certify, flag, or remove. Certify what is still right, flag what needs a second look, remove what should go. Lines carrying risk (a privileged level, sensitive data, access that has gone stale) are held back from the bulk "certify all remaining" sweep, so the fast path cannot quietly rubber-stamp the ones that matter most.
- A removal is not done until it is done. Marking a grant for removal asks you to confirm it was actually removed in the tool, and the campaign is not complete while that confirmation is outstanding. Driply records the decision and the follow-through; your team performs the change in the tool itself.
- Complete it and export the evidence. Completing the campaign rolls it into an evidence pack: who reviewed what, which decisions were made, which removals were confirmed, and when. That is the artefact an auditor asks for, exported for the period.
- Set the cadence once. Quarterly, semi-annual, or annual. The next campaign is created when the current one completes, so a review cannot be quietly skipped and two can never pile up at once.
Between reviews, access expiry keeps the picture from drifting and every decision lands in the append-only log, so the next review starts from an accurate state instead of a reconstruction. See access reviews and expiry for the detail.
How to make reviews continuous
The reason access reviews hurt is that they’re treated as a quarter-end event on top of access that’s drifted all quarter. Flip it: if access carries an expiry and decisions are recorded as they happen, the picture never drifts far from least privilege, and the periodic review becomes a quick confirmation of an already-accurate state.
That’s the model Driply is built around: automatic access expiry and a live, exportable record keep access current between audits, and every grant, approval, and revoke lands in an append-only trail you can export. Driply documents and proves the access; your team performs the actual change in each tool. The result is that passing a SOC 2 access review is an export, not an investigation.
Common mistakes to avoid
- Reviewing from a stale spreadsheet. If the list isn’t current, the review certifies fiction.
- One person reviewing everything. Without context, it becomes a rubber stamp.
- No evidence trail. “We did review it” isn’t evidence; a timestamped, immutable record is.
- Only reviewing at audit time. Adjust access on every offboarding and role change so the review is a confirmation, not a rescue.
- Forgetting to schedule the next one. Consistency is the control; book it before you close the current review.