Why Access Reviews Are Non-Negotiable for SOC 2

CC6.1 of the SOC 2 Trust Services Criteria requires that logical access to systems is restricted to authorized users, that access is periodically reviewed, and that access is removed when no longer needed. Quarterly access reviews are the standard mechanism for proving this over a Type II audit period.

This is the control that most teams either skip entirely or document poorly. "We reviewed access" without a record of who reviewed what, what was found, and what was changed is not evidence — it's an attestation. Auditors sample access review records across the full observation period. Missing or undocumented reviews are among the most common SOC 2 findings.

What an Access Review Must Cover

A complete access review for SOC 2 covers at minimum:

AWS IAM users — who has console access, what policies are attached, when they last logged in

AWS IAM access keys — who has active keys, when they were last rotated, when they were last used

Production application access — who has access to your production database, admin interfaces, or sensitive customer data

Third-party tool access — GitHub org membership, cloud provider consoles, CI/CD tools, monitoring platforms

Privileged access — anyone with administrator or owner-level access anywhere in the stack

Step 1 — Pull the Input Data

Generate your IAM Credential Report — this is the canonical source for AWS access review:

aws iam generate-credential-report
# Wait ~30 seconds, then:
aws iam get-credential-report --query 'Content' --output text | base64 --decode > credential-report.csv

The credential report contains: every IAM user, password enabled/disabled, MFA status, access key ages, last access times, last password use.

Also pull your GitHub organization members list (via GitHub API or the Organization Members page) and any other access lists specific to your stack.

Step 2 — Run the Review

Open the credential report and work through it systematically. For each user, verify:

• Is this person still employed? (Cross-reference with HRIS)
• Is their access still required for their current role?
• Do they have more access than their role requires?
• Is MFA enabled?
• If they have access keys — are they within rotation policy? Were they used recently?

Document your findings in a structured format: a Google Sheet, a Jira epic, or a markdown document works — what matters is that the document has a date, the name of the reviewer, and explicit notes per finding.

Step 3 — Assign and Track Remediation

For every access item that needs action, create a tracking item:

|---|---|---|---|---| Track each item to closure. Auditors will ask to see the review AND the resulting changes — demonstrating that access was reviewed and acted upon, not just reviewed.

Step 4 — Document the Completed Review

After all actions are taken, close the review with a summary document. Minimum required documentation:

• Date of review
• Reviewer(s) name(s)
• Systems reviewed (AWS IAM, GitHub, application admin, etc.)
• Total accounts reviewed
• Findings count (how many needed action)
• Actions taken (list or link to tickets)
• Reviewer attestation — the reviewer confirms the review is complete and accurate

Store this document in a location that can be shared with auditors. SecureSpect's evidence vault can hold these documents alongside automated control evidence.

Quarterly Cadence

Run access reviews on a quarterly schedule — January, April, July, October works well. Put it in a recurring calendar event with a designated reviewer and all source materials linked. A review that doesn't happen on schedule is a gap in your observation period evidence.

For SOC 2 Type II with a 12-month observation period, you need evidence of at least four access reviews. For a 6-month period, two reviews. Each one documented per the structure above.

Common Access Review Failures

Too broad: "We reviewed all access and everything looked fine" is not evidence. Be specific — list what was reviewed and what was found.

No follow-through: Review completed but orphaned access keys were never rotated. The review record and the change record must both exist.

Reviewer isn't neutral: The person reviewing their own access is a conflict of interest. Engineering managers review individual contributor access; a C-suite member reviews engineering manager access.

Not enough frequency: Annual reviews don't satisfy the quarterly expectation in SOC 2 Type II for most auditors.