Home › Guides › Access review

How to run your first access review

Updated 2026-09-14 · 8 min read · by Deepak Gandhi, who builds SOC2Starter

Why this is the finding that catches startups

A SOC 2 Type 2 report is an opinion about whether controls operated over a period. That word does the damage. Most readiness gaps can be closed the week before fieldwork: you can write a policy, approve it, and it exists. You cannot write three quarterly access reviews that did not happen.

If your observation window is six months and the control says reviews happen quarterly, the auditor expects to see two. Producing one dated the week before fieldwork tells them the control did not operate. That is an exception in your report, and depending on severity it can mean restarting the window.

The practical consequence: start running access reviews before you think you need to. The first one is worth running the week you decide to pursue SOC 2, because it starts the clock on the evidence you will later need.

What an access review actually is

Stripped of the jargon, it answers one question per system: should each of these people still have this level of access?

It is not a security scan and it is not an audit of what people did. It is a deliberate, recorded decision by somebody accountable that the current access list is correct. The recorded part is what turns an ordinary piece of hygiene into evidence.

Three things have to be true for it to count:

• Somebody specific reviewed it. A named person, not “the team”.
• Every account got a decision. Keep, change, or remove — including the ones you kept.
• It is dated. A review without a date proves nothing about when the control operated.

Building the inventory first

You cannot review access to systems you have not listed, and the list is usually longer than people expect. Work outward from where data actually sits.

• Identity. Google Workspace, Microsoft 365, or Okta. Start here, because for most companies it is the front door to everything else.
• Cloud infrastructure. AWS, GCP or Azure — including the root account, which is the single most commonly neglected item on this list.
• Source control. GitHub or GitLab: organisation members, owners, and who can push to protected branches.
• Production databases and any admin console that can read customer data.
• Customer support tooling, which very often reads customer data and is very often forgotten.
• Anything holding company-sensitive data: payroll, billing, the password manager.

For each, write down who owns it. The owner is the person who will do the reviewing, and naming them now avoids the review stalling later on the question of who decides.

Running the first one

Set aside an afternoon. For each system in the inventory:

1. Export the current access list. A CSV where possible, a dated screenshot where not. This export is your evidence — save it before you change anything, because it establishes the starting state.
2. Go line by line. For each account: is this a current employee or contractor, do they still need this system, and do they need this level of access? Admin rights that were convenient once tend to persist.
3. Look for the accounts nobody owns. Shared logins, service accounts, integrations installed for a trial two years ago, and personal accounts that were never converted. These are where real risk hides.
4. Record a decision for every line. Including “keep”. A review showing eleven keeps and three removals is evidence; a review showing only the removals looks like a cleanup, not a review.
5. Make the changes, and note the date each was completed.
6. Have the system owner sign off — an email or a dated comment is enough. It does not need to be a formal signature, but it does need to be attributable to a person.

Expect the first review to be uncomfortable. Almost every company finds at least one account belonging to somebody who left. That discovery is the control working, not a reason to hide the record — auditors are far more concerned by reviews that never find anything.

What the first one looks like in practice

A concrete version, at a ten-person company running Google Workspace, AWS and GitHub.

Google Workspace. Export the user list. Eleven accounts for ten people — the extra is a contractor who finished in March. Suspend it, note the date. Two accounts have super-admin that do not need it; drop them to standard. Confirm MFA enforcement is on for everyone, and screenshot the setting with the date visible.

AWS. List IAM users and roles. The root account exists and has MFA, which you verify rather than assume. One IAM user is a leftover from a migration and belongs to nobody; disable it. Two engineers hold broad production permissions that were reasonable when there were four people and are not now; narrow them. Record each change.

GitHub. Organisation members, and specifically who holds owner. The contractor is still a member here too — which is exactly why the review covers every system rather than trusting that offboarding caught everything. Remove them. Confirm branch protection on the default branch requires review, because that is also your change management evidence.

Total elapsed time: an afternoon. Output: three dated exports, a short table of decisions, four completed removals with dates, and your name against each. That package is the evidence, and it is worth more to an auditor than any policy describing the intention to do it.

What to keep afterwards

The artefact matters as much as the activity. For each review, keep in one place:

• The original export with its date.
• The decision per account.
• The removals actually completed, with dates — a decision to revoke access is not evidence that access was revoked.
• The reviewer's name and their sign-off.

Store them where they will still be findable in nine months, when the auditor asks. A folder per quarter works. What does not work is a Slack thread, because the evidence you need will have scrolled out of retention exactly when you need it.

Making it recur without relying on memory

The first review is easy because you have just decided to care. The fourth is where it fails, and the fourth is the one the auditor will look for.

Put the next three in the calendar now, with a named owner on each, before you close the first one. Attach the checklist to the invitation so the person doing it does not have to remember the steps. If your team uses a ticketing system, a recurring ticket beats a calendar entry, because it leaves its own dated trail of having been completed.

The failure mode is almost never that somebody refuses to do the review. It is that nobody was specifically responsible in a quarter when everyone was busy, and a missed quarter cannot be repaired.

Mistakes that turn a real review into a weak one

• Reviewing only the identity provider. SSO is not universal coverage. Databases, cloud root accounts, and support tools frequently sit outside it.
• Recording only removals. Without the full list and the keeps, there is no evidence of the scope actually reviewed.
• Undated screenshots. The single most common evidence defect. If the image does not show a date, the file name should, and the folder should too.
• One person reviewing their own access. For the accounts with the most privilege, have someone else confirm.
• Treating offboarding as a substitute. Offboarding is a separate control. The review is what catches the case where offboarding was missed — which is precisely the case that matters.

Questions people ask

How often should access reviews be done for SOC 2?

Quarterly is the common cadence and the one most startups commit to in their access control policy. The frequency is your choice, but the report tests the cadence you wrote down, so promising monthly reviews and running them twice a year is worse than committing to quarterly and doing it. Pick the interval you will actually sustain.

What systems need to be included in an access review?

Anything holding company or customer data, or granting access to it. In practice that means your identity provider, cloud infrastructure including the root account, source control, production databases and admin consoles, customer support tooling, and business systems such as payroll and the password manager. Reviewing only the identity provider is a common gap, since databases and cloud root accounts often sit outside SSO.

Can I do an access review retroactively before the audit?

No, and this is the most important thing to understand about the control. A Type 2 report tests whether controls operated across the observation window, so a review dated the week before fieldwork demonstrates the opposite of what it needs to. Start running reviews before the window opens; it is the one gap that cannot be closed later.

What evidence proves an access review happened?

The dated export of who had access, a recorded decision for every account including the ones you kept, the completed removals with their dates, and the name of the person who reviewed and signed off. A decision to revoke access is not evidence that access was revoked, so keep proof of both.

Who should perform the access review?

The person who owns the system, because they are the one who can judge whether a given level of access is still appropriate. For highly privileged accounts, including the reviewer's own, have a second person confirm. What matters to an auditor is that the reviewer is a named, accountable individual rather than a team in general.