SOC 2
The SOC 2 user access review, per user
A user access review answers one question for every person in scope: does this individual still need the access they hold — and can you prove someone accountable confirmed it? Under SOC 2 that per-user certification is one of the most-tested access controls. This guide walks through what the review is at the user level, who should sign off on whose access, and the evidence an auditor actually reads line by line.
What “user access review” means under SOC 2
SOC 2’s logical access criteria require organizations to authorize, modify, and remove access appropriately over time. A periodic user access review is a common control used to demonstrate that — you take each user, list what they can reach in an in-scope system, and have an accountable owner confirm it’s still appropriate or remove it. These reviews commonly map to CC6.1–CC6.3. SOC 2 does not prescribe a specific procedure or cadence; your policy defines those, and the auditor tests whether the control operated as you designed it.
Reviewing by user vs. reviewing by system
The same review can be read two ways, and both matter. A system owner looks down their system and asks “should each of these people have this?” A manager or joiner-mover-leaver check looks across a single user and asks “should this person still have all of this?” The second view is where role changes hide — someone who moved from support to finance often keeps both sets of access. A good review surfaces per-user access so a mover’s stale grants don’t survive on the strength of a system owner nodding at a familiar name.
What the per-user evidence has to show
Auditors sample individual users and follow the trail. For each sampled line they want to see:
- The user’s access to the in-scope system as it stood at review time — captured, not reconstructed afterward.
- A keep-or-revoke decision made by a named reviewer with a date, not an implied “no objection”.
- A reviewer with the standing to decide — typically the system or business owner, and someone other than the user under review.
- For every revoke, proof the access was actually removed and when.
Why the snapshot has to be pinned
The most common finding is that the evidence no longer matches the review. If the review is a live query against current state, any access that changed after the reviewer decided makes the record inconsistent — and a mover who was correctly revoked in Q2 but re-granted in Q3 makes the whole period look sloppy. Useboards snapshots each user’s access the moment the review starts and pins it, so the evidence reflects exactly what the reviewer saw. Later changes land in the audit log, not on top of the signed review.
Running it in Useboards
Start a review, choose the in-scope systems, and Useboards builds a per-user snapshot. Reviewers work each line keep or revoke with optional justification; revokes become tracked deprovisioning actions rather than a note to follow up on. Counters on the review header show what’s still outstanding per reviewer, and when it’s done you export a CSV evidence pack — user, access, reviewer, decision, timestamp, and justification per line — ready for the auditor to sample.
Frequently asked questions
What is a SOC 2 user access review?
It’s a periodic check where an accountable owner confirms, for each user, that their access to an in-scope system is still appropriate — or removes it. It’s a common control used to demonstrate access stays appropriate over time, which auditors test under SOC 2’s logical access criteria (commonly CC6.1–CC6.3). SOC 2 doesn’t mandate a fixed procedure or frequency; your policy defines those.
How often should we run it?
Quarterly is a common cadence for privileged and production access, while lower-risk systems may be reviewed less frequently depending on your risk assessment and control design. What auditors test is whether you ran it consistently on the cadence your own policy defines and kept evidence for each period.
Who should review a given user’s access?
Typically the owner of the system the access belongs to, since they can judge whether it’s still appropriate — and someone other than the user being reviewed, to preserve separation of duties. For access that spans several systems, that can mean more than one reviewer touches a single user.
What per-user evidence does an auditor want?
For a sampled user: their access at review time (snapshotted, not rebuilt), a keep/revoke decision by a named reviewer with a date, and proof that any revocation was carried out. Snapshot-based, timestamped evidence holds up far better than a spreadsheet reconstructed after the fact.
Related
Run a per-user review your auditor can sample
Snapshot-based evidence, tracked revocations, CSV export — set up in minutes.