Free SOC 2 Access Review Template
A spreadsheet built around what Big 4 auditors actually test when they sample your CC6 evidence. 25 realistic sample rows across 8 systems, auto-calculating overdue flags, a summary statistics section, and a built-in guide to what each column proves to your auditor.
Opens in Excel or Google Sheets. No macros. No formulas that break on import.
No sign-up required. CSV opens in Excel, Google Sheets, and Numbers.
What's in this template — and why each column matters
Each column maps to a specific thing an auditor will test. The "Auditor will..." notes below are drawn from actual Big 4 SOC 2 testing procedures for CC6 controls.
User ID + User Type
What it captures: A unique identifier (EMP-001) and category: Employee / Contractor / Service Account.
Why it matters: CC6.1 requires demonstrating unique, individually-attributable identities. Shared accounts without unique IDs are a finding. Service accounts must be listed separately — auditors specifically look for unnamed or undocumented service accounts.
Auditor will: Will cross-reference your User ID list against your HR system to verify no terminated employees appear as Active.
System / Application + Environment
What it captures: One row per person-system pair (e.g., Alice Brennan / GitHub / Production).
Why it matters: CC6.3 periodic reviews must cover every system that holds sensitive data or grants privileged access. Auditors expect per-system granularity — a single 'all systems' row is not acceptable.
Auditor will: Will check that production environments are separated from staging/dev and that production access is more tightly justified.
Access Level
What it captures: Categorised: Super Admin / Admin / Power User / Standard User / Read-Only / API Key Only.
Why it matters: CC6.1 (least privilege) requires demonstrating that access is proportionate to job function. The admin percentage is one of the first things an auditor calculates from your review data.
Auditor will: Will calculate: what % of access grants are admin-level? Will flag any admin without a specific written justification.
Business Justification
What it captures: Why this person needs this specific level of access — specific to their role, not generic.
Why it matters: Generic justifications ('IT team member', 'needs access for their job') are explicitly called out as weak evidence in Big 4 testing procedures. The justification must explain why admin-level access is required when standard-level would not suffice.
Auditor will: Will read every admin justification. Vague justifications = qualified finding. 'Required for on-call incident response and production deployment pipeline' = sufficient.
Last Review Date + Next Review Due
What it captures: When this row was last reviewed, and the auto-calculated date 90 days later (use =Q2+90 in Excel).
Why it matters: The 90-day cadence is the core CC6.3 quantitative control. Gaps over 90 days are automatic findings regardless of any qualitative explanation.
Auditor will: Will verify every review date falls within 90 days of the prior review. Will look at 3–4 quarterly cycles during a Type II audit — not just the most recent one.
Review Status + Reviewed By
What it captures: Approved / Revoked / Access Downgraded / Pending, plus the full name of the reviewer.
Why it matters: The reviewer name is as important as the date. If the same person reviewed their own access, that's a segregation of duties finding. The reviewer must be the system owner or a manager — not the IT provisioner.
Auditor will: Will sample reviewer names for segregation of duties. Will request proof of revocation for every 'Revoked' row — the spreadsheet entry alone is not sufficient.
Date Access Granted + Provisioned Via
What it captures: When access was first provisioned and how it was approved (ticket number, HR onboarding, etc.).
Why it matters: CC6.2 requires a formal approval chain before access is granted. Auditors test that access wasn't self-provisioned and that a documented approval existed at the time of provisioning.
Auditor will: May pull the original provisioning ticket and verify the manager approval predates the access grant date.
Last Login Date
What it captures: The most recent activity date pulled from the system's audit log.
Why it matters: Stale accounts (active but unused for 90+ days) are a CC6.1 risk. The last login date provides the evidence you used to assess whether access is still required — 'user hasn't logged in for 6 months' is grounds for revocation.
Auditor will: Will look for patterns: accounts marked 'Approved' with no recent login and no justification for continued access are a finding.
How a SOC 2 auditor tests CC6 controls
Understanding the testing procedure helps you build evidence that passes — not just evidence that looks complete.
1. Document inspection
The auditor requests all access review records for the audit period (typically 12 months). They check that reviews exist, cover all in-scope systems, and were completed within 90-day windows. Gaps between reviews are flagged immediately.
2. Sampling
For CC6.3, auditors select a random sample of 10–25 user-system rows from across the review period. For CC6.1, they focus specifically on admin-level rows. For CC6.2, they select recent provisioning events to trace the approval chain.
3. Testing each sampled item
For each sampled row: (a) reviewer name is present and appropriate — not the user reviewing their own access; (b) review date is within 90 days of the prior review; (c) decision is documented (Approved / Revoked / Downgraded); (d) for Revoked rows — the auditor requests system-level evidence the access was actually removed.
4. Admin concentration test
Auditors calculate the percentage of admin-level access grants and flag any system where >15–20% of users hold admin rights without adequate justification. Every admin row must have a specific written justification — 'IT staff member' is not acceptable.
5. Service account inspection
Unnamed service accounts, shared accounts, or service accounts without a documented human owner are a direct CC6.1 finding. Auditors specifically look for rows without an Employee ID or with generic names.
6. Completeness check
Auditors compare your system inventory against your review records. If a system appears in your inventory but has no access review records, it's a scope gap — a finding even if your reviewed systems are clean.
What good evidence looks like vs what gets findings
These are the most common gaps auditors identify in CC6 evidence — and what the correct version looks like.
How to complete this template in 6 steps
Set up the document header
Fill in your organisation name, review period (e.g. Q1 2025 — 1 Jan to 31 Mar), review owner's name, and the date you expect to complete it. This metadata is what auditors use to verify the review is current.
Export your user lists
Pull the current user list from each in-scope system: Google Workspace Admin, GitHub Org Settings, AWS IAM Console, Okta, Salesforce, etc. Paste one row per person-system pair. Don't forget service accounts and contractors.
Add the formulas
In the 'Next Review Due' column: enter =Q2+90 (adjust column letter to match your 'Last Review Date' column). In 'Days Since Last Review': =TODAY()-Q2. Apply conditional formatting: red if >90, amber if >60, green if ≤60.
Send rows to system owners
For each system, send the relevant rows to the system owner — the manager responsible for that system. Ask them: Is access still needed? Is the access level still appropriate? They fill in Status, Reviewed By, and Action Taken.
Revoke and document
For every Revoked row: remove the access from the system that day. Screenshot the disabled account. Add the revocation date and a reference to the offboarding ticket (if applicable) in the Notes column. The spreadsheet alone is not proof.
Close out and archive
No row should remain as Pending when you close the review. Escalate any unresolved rows to managers. Save as access-review-[system]-[YYYY-QN].xlsx and store in your audit evidence folder. Set a 90-day calendar reminder.
The most common SOC 2 access review finding (verbatim)
"Access reviews were performed; however, for a sample of [N] user-system pairs, the reviewer name was not documented, and for [N] items the review date exceeded the 90-day cadence required by management's access control policy. Additionally, for [N] admin-level accounts, the documented business justification was insufficient to support the level of access granted."
— Paraphrased from actual SOC 2 Type II Management Letter findings
This template is designed to prevent exactly this. But as your team grows past 20–30 people, keeping it current becomes a quarterly project of its own. AllowNow replaces the spreadsheet with a structured review workflow — every decision logged, every report exportable in one click.
Start your free reviewFrequently asked questions
How many rows should my access review cover?
One row per person-system pair, for every system that stores sensitive or customer data, or grants privileged access. A company with 30 people and 10 critical systems should have 200–400 rows. Auditors expect completeness — a short list raises questions. Start by listing all in-scope systems, then export the user list from each.
Can one person review their own access?
No. This is a segregation of duties violation and a direct finding under CC6.3. The reviewer must be the system owner (usually a manager) or another senior person — never the user themselves. If you're the only admin of a system, your access must be reviewed by your own manager or the IT Manager / CISO.
What if we have zero revocations across all reviews?
Zero revocations across multiple quarters is a red flag, not a clean record. Auditors interpret it as evidence that the review process isn't genuinely checking whether access is still needed. In any healthy access review over 6 months, you should expect some role changes, departures, or scope reductions to produce revocations. If your team is growing, a zero-revocation record is almost certainly incomplete.
Do service accounts need to be in the review?
Yes — explicitly. Service accounts, API bots, and integration users are specifically called out in CC6.1. They must have unique identifiers (not generic names like 'deploy-bot'), a documented owner (a named human accountable for that account), and a business justification. Their access keys must have a rotation date recorded. Auditors treat undocumented service accounts as unnamed accounts — a direct CC6.1 finding.
How do I prove a 'Revoked' access was actually removed?
The spreadsheet entry alone is not sufficient evidence. For each Revoked row you need at least one of: (a) a screenshot of the disabled account in the system; (b) a system export taken after the revocation date showing the user is absent; or (c) an audit log entry showing the account was deactivated. Store these as attachments alongside the completed review spreadsheet.
How many quarterly reviews do we need before a SOC 2 Type II audit?
A Type II audit covers a 12-month period. Auditors will typically request all access review records from that period and sample 2–4 of them. You should have at least 4 completed quarterly reviews (with no gaps larger than 90 days between any two) before your audit window opens. Starting your review programme 3 months before an audit is too late.
Download the template
Free CSV with 25 sample rows, formulas, and auditor notes — no sign-up.