You can document a least privilege policy, configure RBAC, and roll out MFA across every app in your stack, and an auditor will still ask the same follow-up question: how do you know it's actually working?
That's what a user access review is for. It's the mechanism that turns "we have access controls" into "we can prove our access controls are functioning as intended," which is the distinction SOC 2 auditors are actually evaluating.
We've sat with enough IT and security teams through this exact pre-audit phase to know where the real risk sits: not in the policy, but in proving the policy is actually being followed. Here's how we approach running a user access review for SOC 2, what separates a manual review from an automated one, and what auditors actually expect to see as evidence.
What a User Access Review Is Actually Checking
Internal controls apply to your applications. Your users get access to those applications. The entire point of access controls is to keep unauthorized users and malicious actors out of systems holding sensitive data.
A user access review is how you verify that's actually happening: that only authorized users hold access to a given application, at the access level appropriate to their role, with no unauthorized or excessive permissions sitting unnoticed. Without this check, you have a policy. With it, you have evidence the policy is enforced.
Step 1: Decide Who Performs the Review
Before running the review itself, decide whether your internal team or an external auditor owns it.
If you already have people experienced in access review and audit processes, keeping it in-house avoids the added cost of outside help. If your team lacks that depth, bringing in an external auditor makes more sense, but the auditor needs to be CPA-certified through the AICPA. A non-certified auditor risks handing you inaccurate findings about your control effectiveness, which sets back your audit readiness rather than advancing it.
Most organizations that go the in-house route eventually look for a platform to handle the mechanics of the review itself, which is where the manual-versus-automated decision comes in.
Step 2: Run the Review (Manual vs Automated)
Take a concrete example: testing whether your least privilege access control is actually holding up across your application stack.
The manual approach
This is still how most organizations run access reviews, and it looks roughly like this:
- Compile a list of users, applications, and current access rights by pulling data from multiple directories and databases into a spreadsheet.
- Go through each user individually to determine whether they should still have access, and at what permission level.
- Flag discrepancies: users with excessive or inappropriate access relative to their role.
- Assemble a separate team to investigate and resolve each flagged discrepancy, reconfiguring access where needed.
It works, technically. But it's slow, labor-intensive, and entirely dependent on the accuracy of manual data-pulling and manual judgment calls across potentially hundreds of users and dozens of applications. There's no real guarantee the findings are complete or reliable, which is exactly the kind of gap an auditor will probe.
The automated approach
An access review platform like Zluri removes the manual data-wrangling and judgment-call bottlenecks entirely.
Once you specify the application and user type to review, Zluri integrates directly with the application and automatically pulls user details: name, status (active or inactive), department, position, and entitlements. It then evaluates whether each user is authorized to hold access to that application, and whether their current permission level is actually necessary for their role.
When it detects a misalignment, such as a user holding access they shouldn't, or permissions broader than their role requires, it can trigger remediation directly through workflows, adjusting or revoking access without requiring a separate cleanup team to be assembled after the fact.
Every review produces a UAR (user access review) report: who was reviewed, what was found, what action was taken, who took it, and when. Because the data collection and evaluation are automated, the report doesn't carry the same risk of human error or inconsistency that manual reviews do, and it's exactly the kind of evidence auditors want to see when they ask you to demonstrate control effectiveness.
Step 3: Run a Follow-Up Review If Issues Were Found
If the review turns up no discrepancies, you're clear to move toward your final SOC 2 audit. If it does surface issues, fix the underlying control (reconfigure permissions, tighten the policy, whatever the gap calls for), then run a follow-up review specifically to confirm the fix actually worked before heading into the audit.
This loop, review, fix, re-review, is what gives you confidence walking into the final audit rather than hoping the auditor doesn't find what you already suspected was there.
Why This Pre-Assessment Step Actually Matters
It's tempting to treat this as redundant since the auditor is going to evaluate your controls anyway during the official audit. But auditors don't just test controls in isolation. They request evidence, in the form of reports, that demonstrates your controls have already been validated as effective and aligned to the relevant Trust Services Criteria, along with a management assertion that the information provided is accurate.
That evidence does two things for the auditor: it shows the organization takes its security posture seriously, and it gives the auditor something concrete to cross-check against during the audit itself, rather than relying purely on point-in-time testing. A user access review for SOC isn't a box-checking exercise before the "real" audit. It's the evidence the real audit runs on.
Frequently Asked Questions
What do external auditors include in the final SOC audit report?
The methods and standards used to test each control, how long the evaluation took, what issues (if any) were identified, and recommendations for fixing them. If no issues are found, certification is issued directly.
What's the difference between a Type 1 and Type 2 SOC audit?
Type 1 evaluates whether your controls are well-designed at a single point in time. Type 2 evaluates both the design and the operating effectiveness of those controls over a sustained period, typically 6 to 12 months, which means it checks not just whether a control exists but whether it consistently worked over time.
How often should you run user access reviews for SOC 2?
Quarterly, bi-annually, or annually, depending on your organization's risk profile and audit cycle. If a review surfaces issues, you'll need to run a follow-up review sooner to confirm the fix, regardless of your standard cadence.
Can access reviews be fully automated for SOC 2 purposes?
Data collection, authorization evaluation, and basic remediation can be automated end to end with a platform like Zluri. Final sign-off and management assertion still require human review, but the bulk of the evidence-gathering work no longer has to be manual.
.svg)
