What software automates user access reviews for SOC 2 compliance?

Access governance platforms that connect to each SaaS tool, build the who-has-what inventory, run review campaigns with reviewers and decisions, execute the removals, and export evidence. Lutril does this for SaaS tools and AI agents in one campaign, with decisions taken in Slack, Teams or the app UI.

How often do SOC 2 and ISO 27001 require access reviews?

Neither standard fixes a number. SOC 2 CC6.1 to CC6.3 and ISO 27001 A.5.18 require that access rights are reviewed at regular intervals and on role change or departure, and that the review is evidenced. Quarterly for privileged access and at least annually for everything else is what most auditors accept.

What evidence does an auditor want from an access review?

The scope (which systems, which accounts), who reviewed each line, the decision, the date, and proof that removals actually happened in the target system. A spreadsheet with ticks fails the last point. Lutril's campaign export carries the revocation log alongside the decisions.

Do AI agents need to be in the access review?

Yes. An agent holds credentials and permissions like any account. Lutril includes registered agents in the same campaign as employees, so an idle or over-scoped agent gets the same keep-or-remove decision, and the decision executes.

SOC 2 Wants Proof. Not a Spreadsheet.

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

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.