SOC 2 Wants Proof.
Not a Spreadsheet.

Most access reviews are a formality. Managers approve without context, shadow IT goes unreviewed, and evidence is thin. Here is what SOC 2 and ISO 27001 actually require, and what closing the gap looks like.

All posts

Your access review works on paper

Every quarter, someone on the security team sends a spreadsheet to 40 managers. The managers are busy, uncertain about what their reports actually use, and unclear on what "review" really means. They click approved on most rows and send it back. Someone collects the responses. The audit evidence folder gets another attachment.

This is how most companies do access reviews today. It satisfies the letter of the requirement. It increasingly doesn't satisfy auditors, and it definitely doesn't satisfy the spirit of what SOC 2 and ISO 27001 are asking for.

What the standards actually require

Both SOC 2 and ISO 27001 care about the same fundamental question: can you prove that access is controlled, appropriate, and cleaned up when it shouldn't be there anymore?

Relevant controls
SOC 2CC6.2
Logical access to system components is restricted to authorized users. New accounts are provisioned only with appropriate authorization. Access is based on the minimum necessary for the user's role.
SOC 2CC6.3
Logical access is removed or modified in a timely manner when no longer needed, including terminations, role changes, and changed business requirements.
ISO 27001A.8.2
Access rights of all employees and contractors are reviewed at regular intervals. Rights are adjusted or revoked when no longer appropriate following role changes or departures.
ISO 27001A.8.3
All access rights of employees and contractors are removed upon termination or expiry of employment, contract, or agreement.

The key distinction for SOC 2 is between Type I and Type II. Type I says: "we have controls designed to achieve these criteria." Type II says: "those controls operated effectively over the audit period." For access reviews, Type II means demonstrating that reviews happened, were complete, and resulted in removals, consistently over 6–12 months.

"We have a policy" is a Type I answer to a Type II question.

Three ways access reviews fail in practice

Failure 1: The coverage gap
Your IdP shows you the apps it manages. But SaaS adoption has outpaced SSO rollout at most companies. Employees sign up with a Google login, use personal accounts, or get provisioned directly in tools that aren't federated. The result: your access review only covers a fraction of actual access. During a SOC 2 audit, a sampled user in Salesforce, Notion, or HubSpot will often have accounts that weren't in scope. That's a finding.
Failure 2: The context gap
The review email reaches a manager. They see: "Sarah Chen: Salesforce, HubSpot, Notion, Jira, Linear, Figma, Loom, GitHub." Forty rows like this for every person on the team. What the manager needs to answer is: does Sarah still need all of this? Most managers don't know. They don't know Sarah hasn't logged into Figma in 3 months, or that her Salesforce admin permissions were expanded for a project that ended in Q1. So they approve everything. The review becomes a formality.
Failure 3: The remediation gap
Even when a manager flags something for removal, the action doesn't always happen. A spreadsheet comment says "revoke Salesforce admin for Tom." Two weeks later, Tom still has Salesforce admin. There's no connection between the review decision and the provisioning system. SOC 2 evidence of a review that identified exceptions but didn't remediate them is worse than no review at all. It shows you knew and did nothing.

What good evidence looks like

What auditors want to see is a closed loop: discovery → review → decision → remediation → evidence. Each step traceable, timestamped, and attributable to a named reviewer.

Here's what a structured review campaign looks like when the data is actually there to support it:

Q2 2026 Access Review · Engineering
12 / 14 reviewed
User Access Last active Decision Reviewer
Sarah Chen GitHub · Notion · Jira · Linear 2 days ago Keep M. Torres
Tom Okafor GitHub · Salesforce (admin) · AWS 94 days ago Revoke admin M. Torres
Priya Nair Figma · Notion · Linear 61 days ago Revoke Figma M. Torres
James Wu GitHub · Jira · Confluence · AWS Yesterday Keep M. Torres
Amara Diallo HubSpot · Notion · Slack 4 days ago Pending unassigned

The "last active" column is what makes the difference between a real review and a rubber stamp. Without it, a manager reviewing Tom's access has no basis for a decision. With it, "94 days ago" on a Salesforce admin account is an obvious flag.

For audit purposes, the export from this review needs to show:

Scope: which users and systems were in scope for the review period
Completion: who reviewed what, with timestamps and reviewer identity
Exceptions: what was flagged for removal or downgrade, and why
Remediation: evidence that flagged access was actually removed, with timestamps
Coverage gaps: SaaS tools where access wasn't reviewed because they weren't in scope. Auditors will look for these.

The frequency question

SOC 2 doesn't prescribe a specific review cadence, but most auditors expect quarterly reviews for privileged access and at least annual for standard users. ISO 27001 says "at regular intervals", typically interpreted as quarterly or semi-annual depending on your risk profile.

The more useful question is: why is frequency the constraint?

The quarterly cadence is an artifact of the manual process. Collecting access data, building spreadsheets, chasing manager responses, reconciling removals. It takes long enough that doing it more often isn't realistic. But the underlying risk is continuous. Someone changes roles on a Tuesday in February. The next review isn't until April. For two months, they have access they shouldn't.

When access data is live and review campaigns are automated, reviews can be triggered by events: a role change, a project closing, 60 days of inactivity, rather than just the calendar. The quarterly review becomes a compliance artifact that confirms what continuous monitoring already caught, rather than a first line of discovery.

That's the difference between access review as a compliance exercise and access review as an actual control.

Access reviews that close
the loop

Lutril automates the full review cycle: discovery across all SaaS, context-enriched decisions for reviewers, closed-loop remediation, and audit-ready evidence exports. SOC 2 and ISO 27001 ready.

Get a demo See how it works