How to Run an Access Review That Passes a SOC 2 Audit

Direct answer: An access review that passes has four things: a complete list of who had access to what, a named reviewer who was qualified to judge it, a dated record of decisions including removals, and evidence the removals actually happened. Missing the last one is the most common exception in SOC 2.

Why this control fails so often

It is quarterly, it is nobody's favourite task, and it produces no visible benefit when it goes well. It is also the control auditors sample hardest, because inappropriate access is the root of a large share of real incidents.

The list has to be complete

Reviewing your identity provider is not reviewing your access. Cover production infrastructure, the identity provider itself, source control, the customer database, any admin console handling customer data, and anything with a standing key or service account.

Service accounts are the usual gap. They do not leave the company, nobody owns them, and they accumulate permissions. An auditor who asks "who owns this key and when was it last rotated" will find them.

The reviewer has to be able to judge

Somebody who knows whether a given engineer should still have production access. In practice that is an engineering lead per system, not one person signing for everything. A review signed by someone who could not possibly know is a documentation exercise, and it reads that way.

The record is the deliverable

Date, systems covered, who reviewed, the full list as it stood, decisions taken, and evidence of action. "Reviewed, no changes" for four consecutive quarters in a company that hired and lost people will attract questions.

Keep the artefact immutable. A spreadsheet that gets overwritten each quarter cannot prove what was reviewed in March.

A process small teams can keep up

Put the four dates in the calendar for the year with a named owner. Export access lists to a dated file. Have each system owner mark keep or remove. Action removals within a week and screenshot the result. Store everything together against the control. Ninety minutes a quarter, done properly, and it is the single highest-return habit in the whole programme.

Our free Workspace holds the schedule and the evidence against the control it satisfies, and SOC 2 Evidence Collection is where we run it with you when a period is already half gone.

Running one that takes an hour instead of a day

The reason access reviews get skipped is that they are usually run badly, which makes them miserable, which makes people avoid them. A well-structured review is genuinely quick.

Pull the access list per system as an export with a timestamp, not a screenshot. Group by role rather than by person, so the reviewer is answering "should support engineers have production read access" rather than working through 60 individuals. Pre-flag the exceptions: accounts that have not logged in for 90 days, accounts belonging to people who changed teams, accounts with permissions nobody else in that role has. Then send the reviewer only the decisions, not the whole list.

The reviewer should be the person who owns the system or the team, not the person who administers it. Administrators reviewing their own grants is a control weakness auditors specifically look for.

The removals are the evidence

A review that removes nothing, quarter after quarter, invites the obvious question. Real companies accumulate access: people change teams, projects end, contractors finish. If nothing is ever revoked, either the review is not being performed properly or joiners and leavers are already handled perfectly, and the second is rare.

Evidence the removal, not just the decision. The ticket, the timestamp, and ideally a follow-up export showing the account is gone. The most common exception in this area is a documented decision to revoke with no proof the revocation happened.

Service accounts, keys and tokens

These are the standing gap. They have no employment status to trigger a review, they often predate everyone currently on the team, and they accumulate permissions because expanding them is easier than scoping them.

Every non-human credential needs a named human owner, a documented purpose, a scope, and a rotation expectation. Reviewing them means asking whether the purpose still exists and whether the scope is still minimal. An auditor asking who owns a key and when it was last rotated will find the ones nobody can answer for.

Cadence and coverage

Quarterly is the common commitment and is what most system descriptions state. If you commit to quarterly, an auditor will sample four in a twelve month window and any missing one is an exception, so consider whether your description should say quarterly for privileged systems and annually for lower-risk ones rather than quarterly for everything.

Coverage matters as much as cadence. The systems teams forget are the ones outside engineering: the billing platform, the analytics tool with production data in it, the support desk that can see customer records, the marketing automation platform holding contact data, and any third-party admin console. If customer data is reachable from it, it belongs in the review.

Tying it to joiners and leavers

The review is a detective control. It finds what the preventive controls missed. If the review keeps finding departed employees with active access, the real problem is offboarding, and fixing the review will not fix it.

Auditors read the two together. A clean offboarding process with reviews that occasionally catch an edge case tells a coherent story. Reviews that repeatedly catch former employees tell a different one, and it is the story that gets sampled harder.

Getting this control to run every quarter without anyone having to remember is unglamorous and entirely mechanical, which is why it is one of the first things an ongoing retainer takes over.

What auditors ask for, in order

Knowing the sequence helps, because each question tests something different and a package that anticipates all four is reviewed quickly.

First, the population: a complete list of systems in scope and, for a sampled one, the full list of accounts as at the review date. They are testing completeness, so an export with a timestamp and the person who ran it is what satisfies this.

Second, the review record: who reviewed, when, and what they decided. They are testing that a qualified person made judgements rather than that a file exists.

Third, the follow-through: for each decision to revoke, evidence the revocation happened and when. This is the step that generates most exceptions.

Fourth, the exceptions within the review: if an account was flagged and retained, why. A documented rationale for keeping something unusual is a strength. Silence about it is not.

Common findings and how to avoid them

The review was performed but not evidenced, because it happened in a meeting. Fix by producing the artefact during the meeting rather than after.

The reviewer was the administrator, which is a segregation problem. Fix by having the system or team owner sign off, even where the administrator prepares the pack.

Only the identity provider was reviewed, missing the systems with local accounts. Fix by maintaining a scoped system list and reviewing against the list rather than against whatever is convenient.

The review is dated the same week as fieldwork for all four quarters, which tells the auditor exactly what happened. Fix by doing them on schedule, which is the only real fix.

Terminated employees appear in the review. This is a finding about offboarding rather than about the review, and it will be read that way.

Scaling the review as you grow

At twenty people, a spreadsheet and an hour works fine. At a hundred and fifty across more systems, the same approach collapses into a day of tedium that gets postponed, and postponement is how the control dies.

What scales is role-based review with exception surfacing. Define what access each role should have, compare actual to intended, and put only the differences in front of a human. The reviewer then answers twenty questions instead of scanning six hundred rows, and the record is more defensible because it shows a standard being applied rather than individual judgement calls.

The prerequisite is that roles are defined somewhere, which most companies discover they have never done. Doing it once produces a control that stays cheap as headcount grows.

Where this fits in the wider programme

Access review sits alongside joiner-mover-leaver, privileged access management and the principle of least privilege, and auditors read them as a set. Strength in one compensates for weakness in another only up to a point: excellent offboarding with no reviews still fails the review control, and diligent reviews that keep finding the same problems point at a broken process upstream.

It is also the control with the clearest link to real incidents. A large share of breaches involve access that should have been removed, which is why auditors sample it hardest and why it is worth getting right beyond the audit.

Your first review, when you have inherited a mess

The advice above assumes a baseline that exists. Most companies running their first review have none. Permissions have accumulated for four years, half the grants were made by people who have left, and the honest answer to "should this account have this access" is that nobody knows.

Adjudicating that account by account is how first reviews stall for six weeks and then get abandoned. The faster route is to rebuild. Define what each role should have, revoke everything that does not match, and let people ask for what breaks. It is uncomfortable for about four days, and it leaves a defined baseline that every later review compares against. Announce it, schedule it away from a release, and keep a channel open for restores.

Record it as what it was. An auditor reading "initial baseline established, 47 grants revoked, 6 restored on request within 72 hours" knows exactly what happened, and it is far more credible than a first review that quietly approved everything.

The accounts that live outside the identity provider

Group-based provisioning through an identity provider covers the easy population. The exceptions are where findings come from, and every environment has the same few.

Break-glass accounts. The root account, the emergency administrator, the credential in the safe. These exist for good reasons, but they need an owner, MFA, alerting on any use, and a record that the use was reviewed. An unmonitored break-glass account is the most privileged unowned thing in most environments.

Contractors and vendor support staff. Contractors are not in your HR system, so no offboarding trigger fires when the statement of work ends; keep a contract end date against each account and treat it as a scheduled expiry. Several platforms also let a vendor's own support engineers into your tenant on a standing permission granted once during onboarding. Check whether it is still enabled and whether it can be made request-based.

Applications not behind single sign-on. Any tool that puts SAML behind an enterprise tier ends up with local accounts and local passwords, and those do not disappear when somebody leaves the identity provider. This is the honest business case for paying the higher tier on the two or three tools holding real data: it removes a whole category of review work and of finding.

Cloud IAM is where the real privilege sits

Reviewing a cloud account by listing users misses most of what matters, because the users are few and the machine identities are many.

Look at role assumption rather than user lists: which roles can be assumed, by whom, and from where. Cross-account trust relationships are a standing gap, configured once during an integration and never revisited, and the reviewer usually cannot tell from the console what sits on the other side any more. Deploy roles used by continuous integration are another, frequently holding broad write permissions in production and authenticating with long-lived keys in a repository setting nobody audits.

Two things are worth checking every quarter: any policy with a wildcard on both action and resource, which is almost always a shortcut somebody meant to tighten later, and any long-lived access key older than 90 days, which in most environments can be replaced with federated short-lived credentials. Moving continuous integration to federated identity removes a permanent credential from your review population entirely, which beats reviewing it well.

Database and support-tool access, which auditors ask about specifically

Application-level access is the part teams document. Two other paths reach the same customer data and get overlooked.

The first is direct database access. Read replicas wired to a business intelligence tool, a warehouse fed by a pipeline carrying production tables, and engineers with a connection string for debugging all reach customer records without touching the application. The analytics path in particular tends to have far more people on it than anyone expects.

The second is the support impersonation feature. Almost every B2B product lets support staff view the product as a customer, and auditors have become pointed about it because it is unrestricted access to customer data by design. They want it limited to specific roles, each use logged with the acting user and the target account, the logs reviewed rather than merely retained, and ideally the customer able to see it happened. An impersonation feature with no logging is a more serious finding than a stale user account.

Evidence that does not hold up

Reviews fail on evidence quality more often than on the review itself. A few specific traps.

Screenshots without context. An image of a user list with no date, no visible system name and no indication of who took it proves nothing about when it was true.

Exports that quietly filter. Many admin consoles default to active users only, paginate at 50, or exclude guests, service accounts and pending invitations. Check the export against the total the console reports. A population missing a category is not complete, and completeness is the first thing tested.

Tools that only show current state. If a platform shows who has access today but cannot reconstruct March, the export you took in March is your only evidence. Preserve the raw file somewhere immutable, alongside the conclusion drawn from it.

Removal evidence that is only a ticket. A closed ticket saying access was revoked is a claim; a later export showing the account is gone is proof. Where a system cannot produce one, a timestamped screenshot of the account status after the change will do.

One review, several frameworks

Teams frequently run a separate review for each framework, which is wasted effort. The same artefact satisfies the SOC 2 logical access criteria, the ISO 27001 controls covering access rights and their review, the HIPAA requirement for authorisation and workforce clearance procedures, and the PCI DSS requirement to review access at least every six months.

The differences are cadence and scope rather than method. PCI is explicit about a six-month minimum for in-scope systems. HIPAA expects workforce clearance and termination procedures covered alongside the access itself. ISO 27001 wants the review linked to your role definitions. Design it once against the strictest cadence you are subject to, tag the artefact with every control it satisfies, and stop running it three times. Our free traztech Workspace files the evidence against every control it maps to, which is most of the saving.

When a review turns up something serious

Occasionally a review finds real exposure rather than tidy-up work: a former contractor with live production credentials, an API key committed to a public repository, a service account used from an unfamiliar address.

At that point it stops being a compliance task. Revoke first and investigate second, preserve the logs before anything rotates them out, and work out what the credential could reach and whether it did. Whether it becomes a reportable incident depends on what was accessible and on your contractual and privacy obligations, and that decision belongs to the incident process rather than the access review. What matters here is that the finding, the escalation and the outcome are recorded together. A review that quietly revoked something interesting and moved on has thrown away the best evidence it will ever produce.

When not to buy anything for this

Access review is the control we are least inclined to sell. Below roughly fifty people it is a spreadsheet, an export, a calendar entry and ninety minutes, and money spent on a compliance automation platform to run it at that size buys a nicer interface for a job you could do by hand. Those platforms earn their cost once they are integrated with enough of your stack to pull populations automatically, and at fifteen people they are not.

Outsourcing the judgement does not work either. The reviewer has to know whether a given engineer should still have production access, and no outside firm knows that about your team. What can be handed over is the machinery: the schedule, the exports, the exception surfacing, the chasing and the filing, so the internal owner spends time only on decisions. That is the shape of an ongoing retainer, and it is worth considering only once the calendar reminder has stopped working on its own.

If access reviews are the thing standing between you and a report, the real problem is usually elsewhere: joiners and leavers, or a scope nobody wrote down. That is compliance work rather than access review work, and it is cheaper to fix once than to compensate for every quarter.