General

SOC 2 Access Reviews: A Practical Guide for IT Managers

Your company is going through a SOC 2 audit. Congratulations, sort of. It means you're growing, your customers are asking for it, and now someone has to actually demonstrate that you control who has access to what.

March 17, 20266 min read

Your company is going through a SOC 2 audit. Congratulations, sort of. It means you're growing, your customers are asking for it, and now someone has to actually demonstrate that you control who has access to what.

If you're the IT manager who just got handed this responsibility, you might be staring at the SOC 2 Trust Services Criteria wondering what exactly "logical and physical access controls" means in practice. Let me save you some reading: a huge chunk of it comes down to access reviews.

Regular, documented, provable access reviews.

What SOC 2 actually requires for access

SOC 2 is built around Trust Services Criteria, and the one that keeps IT managers up at night is CC6: Logical and Physical Access Controls. Within that, the key requirements related to access reviews are:

CC6.1: The entity implements logical access security measures to protect against unauthorized access. Translation: you need to control who can access your systems.

CC6.2: Prior to issuing credentials, the entity registers and authorizes new users. Translation: there's a process for granting access, and it's not "someone guessed the admin password."

CC6.3: The entity authorizes, modifies, or removes access based on roles. Translation: access changes go through some kind of approval process.

And then there's the ongoing monitoring piece: you're expected to periodically review access to make sure it's still appropriate. Your auditor is going to ask for evidence that this happens.

What an access review actually looks like

Let's strip away the compliance jargon. An access review is someone with authority (usually a manager or system owner) looking at a list of who has access to something and confirming: "Yes, this person should still have this access."

That's it. It's not complicated conceptually. It gets complicated operationally.

Here's what a typical review cycle looks like:

1. Generate the access report. Pull a list of all users and their current access. In Entra ID, this means group memberships, app assignments, role assignments, and any privileged access.

2. Distribute to reviewers. Send each manager a list of their team members' access for review. The CTO reviews developer access. The Head of Sales reviews sales team access. The finance director reviews who can access the accounting system.

3. Reviewers confirm or flag. For each person, the reviewer says either "this is correct" or "this needs to change." If someone has access they no longer need, it gets flagged for removal.

4. Remediate. Actually remove the access that was flagged. This step gets forgotten more often than you'd think.

5. Document everything. Log the review: who reviewed, when, what decisions were made, what actions were taken. This is what your auditor will look at.

The spreadsheet approach (and why it falls apart)

Most companies start SOC 2 access reviews with spreadsheets. You export a list of users from Entra ID, split it up by department, email it to managers, and ask them to review. They (eventually) respond with their confirmations, you make the changes, and you save everything in a shared drive.

It works for the first cycle. Maybe the second. Then it starts falling apart.

Managers forget to respond. You send reminders. They respond three weeks late. By the time you get everyone's input, the data is stale because people have joined, left, or changed roles.

And the documentation? It's scattered across email threads, Excel files, and Teams messages. When the auditor asks for evidence of your Q3 access review, you're spending half a day reconstructing the paper trail.

The fundamental problem is that a spreadsheet-based process depends entirely on human discipline and follow-through. For something that needs to happen every quarter like clockwork, that's a fragile foundation.

What auditors are really looking for

Having been through a few of these, here's what actually matters to your SOC 2 auditor:

Consistency. Did you run reviews on a regular cadence (quarterly is standard)? Or did you do one in January and then forget until November?

Coverage. Did you review all critical systems, or just the obvious ones? Your auditor will check if you reviewed access to your cloud infrastructure, your code repositories, your customer data stores, and your admin accounts.

Timeliness of remediation. When the review identified inappropriate access, how quickly was it revoked? "We found it in the Q2 review and fixed it in Q4" is not going to impress anyone.

Evidence. Can you produce a clean record of the entire review cycle? Who reviewed, when, what was decided, what was done about it. If the answer requires digging through email, that's a red flag.

Privileged access. Auditors pay extra attention to admin accounts and elevated privileges. These should be reviewed more frequently and with more scrutiny.

Setting up a process that actually survives audit season

Here's the approach I'd recommend for any company doing SOC 2 for the first time:

Define scope. List every system that holds sensitive data or provides critical functionality. For most companies on Microsoft 365, this includes Entra ID (the identity provider itself), Azure subscriptions, Microsoft 365 apps, and any third-party SaaS tools integrated via Entra.

Set a cadence. Quarterly is the standard. Put it on the calendar. Treat it like payroll: it happens on schedule, every time, no exceptions.

Assign reviewers. Each system or group of users needs an owner who will do the review. This should be the person who actually understands whether someone needs that access, usually the team lead or department head.

Automate what you can. At minimum, automate the report generation. Pulling user access data manually is slow and error-prone. Ideally, automate the distribution to reviewers and the collection of responses too.

Track remediation. When someone flags an access issue, track it to resolution. Don't just note "access needs to be removed" and hope someone does it. Assign it, track it, close it.

Centralize your evidence. Keep everything in one place. Dates, decisions, actions, completion confirmations. When the auditor asks, you should be able to pull the complete record in minutes, not hours.

The automation question

Can you do SOC 2 access reviews without automation? Technically, yes. Plenty of companies pass audits with manual processes.

But it's painful, and it doesn't scale. Every quarter, you're repeating the same tedious export-distribute-collect-remediate-document cycle. Your IT team loses days to the process, and the risk of gaps in your evidence increases every time.

The companies that have the smoothest audit experiences are the ones that automated access reviews early. They click a button, reviews get distributed, responses get tracked, remediation gets logged, and the audit evidence is already there when the auditor shows up.

If this sounds like your situation, Adcyma is free for up to 25 users. For larger teams, you can start a free 14-day trial. No credit card, no consultants.

Try Adcyma free — no credit card needed

Set up identity governance for your Entra ID or Active Directory environment in under a day.