Skip to main content
INS // Insights

SOC 2 Access Review Evidence Auditors Actually Sample

Updated September 2026 · 8 min read
SOC 2 Access Review Evidence Auditors Actually Sample

A SOC 2 access review is not a meeting invite. It is a control that has to survive sampling across the observation period. Type II reports cover a window — commonly twelve months — and the auditor will pick people, systems, and dates. If quarter two is a screenshot folder and quarter four is a half-finished spreadsheet, the finding is not "try harder next year." It is a failed or qualified control.

Rutagon builds the evidence pack, not the opinion letter. We do not hold a SOC 2 attestation. We build the ingest, decision log, and revoke trail that lets your auditor sample CC6.2 without a guided tour of tribal knowledge.

What a SOC 2 Access Review Has to Prove

The AICPA Trust Services Criteria address logical access in the CC6 family. CC6.2 is the one GRC leads feel every quarter: the entity removes access when it is no longer required, and it has a process to review remaining access. The related provisioning story lives in CC6.1; removal after termination often shows up as CC6.3. Treat them as one engineering problem with three evidence shapes.

Auditors typically sample:

  • Completeness: did the review population include the in-scope systems, not just the IdP?
  • Occurrence: did reviews actually run in each period you claim?
  • Accuracy: does the snapshot match the system on the sample date?
  • Follow-through: when the reviewer said revoke, did the entitlement disappear?

NIST SP 800-53 Rev. 5 AC-2 and AC-6 give the same control intent in federal language — account management and least privilege — which is why commercial SOC 2 programs and FedRAMP-aligned builds keep colliding on access evidence (NIST SP 800-53 Rev. 5). Alignment is not authorization. If you need a FedRAMP package later, the same snapshot-and-revoke loop is the part that transfers. Rutagon does not hold a FedRAMP authorization.

Why Screenshots Fail the Sample

Screenshots fail for mechanical reasons.

They have no population completeness. A picture of an Okta group list does not prove GitHub org-owners were in scope. They have no integrity. A PNG can be cropped. They have no remediation. A red X in a cell is not an API response. They have no time series. Four quarters of "we did it" need four independent snapshots, not one recycled export.

The failure mode we keep seeing: the GRC tool's native Okta or Google connector is green all year, so the team assumes access review is automated. Then the auditor asks for production AWS console users, the internal admin panel, and the support impersonation tool. Those three are still a spreadsheet. That is the finding.

The CC6.2 Evidence Pack We Build

We treat each quarter as a sealed artifact, not a vibe.

def seal_quarter(campaign):
    snapshot = hash_snapshot(campaign.rows)  # who-had-what at open
    decisions = hash_decisions(campaign.decisions)
    remediations = hash_remediations(campaign.revoke_results)
    return {
        "period": campaign.period,           # e.g. Q3 of the observation window
        "systems": sorted(campaign.systems),
        "row_count": len(campaign.rows),
        "snapshot_sha256": snapshot,
        "decision_sha256": decisions,
        "remediation_sha256": remediations,
        "open_exceptions": campaign.open_exceptions,
        "sealed_at": campaign.closed_at,
    }

Each sealed quarter lands in object storage with immutability settings you already use for logs, and a copy is attached to the custom test in your GRC platform. The auditor can request Q1–Q4 and receive four hashes plus the readable decision CSV. If someone "fixes" a spreadsheet after the fact, the hash no longer matches the sealed object.

This is the same evidence discipline as SOC 2 CC6.2 access recertification evidence and the continuous pattern in continuous access review for Type II. The engineering lives under security automation.

Sampling Without a War Room

When the auditor picks "Jane in engineering, July," we should be able to answer from artifacts:

  1. Jane was in the Q3 population because she had a role in systems X and Y on the snapshot date.
  2. Her manager retained the GitHub write role and revoked the AWS AdministratorAccess permission set.
  3. The revoke API returned 204 at a recorded timestamp.
  4. A follow-up snapshot 24 hours later no longer lists that permission set.

If Jane was a contractor whose HR end date passed mid-quarter, the joiner-mover-leaver automation should have already removed IdP access. The quarterly review is the backstop for everything the event-driven path missed — GitHub org membership, standing IAM users, local app accounts. See access deprovisioning automation.

Four Quarters, One Pipeline

Type II pain is consistency. Teams sprint before the first audit and then skip a quarter because "nothing changed." Something always changed. The pipeline we ship runs on a calendar, not on panic:

  • Campaign opens on a fixed day.
  • Snapshots fail the job if a connector errors — we do not silently drop GitHub.
  • Reminders go to reviewers from the GRC tool you already pay for.
  • Unreviewed items block close; they do not get auto-retained.
  • Sealed artifacts are written even if the only news that quarter is "all retain."

All-retain quarters are valid evidence. Missing quarters are not.

How This Plugs Into the GRC Tool You Already Run

We map each sealed quarter to whatever custom test or evidence request the platform exposes. We do not rip out the vendor. We do not pitch a cheaper substitute. The platform is good at reminders, auditor users, and the catalog of standard SaaS. The pack we build is the 30 percent it cannot see: custom entitlements, revoke proofs, and a year of sealed periods.

If you are still deciding whether to automate the campaign itself, start with user access review automation and come back here for the evidence shape the auditor will ask for.

See what an Access & Credential Governance Diagnostic finds in your environment →

907-841-8407 · contact@rutagon.com

Frequently Asked Questions

Does a Type I vs Type II change the SOC 2 access review design?

Type I is a point-in-time design review. Type II is operating effectiveness over a period. The pipeline is the same; Type II simply requires sealed artifacts for every period in the window, not a single heroic export the week fieldwork starts.

Can we run reviews continuously instead of quarterly?

Yes, and some teams do for privileged roles. Auditors still want a defined frequency and proof it ran. Continuous revoke plus a quarterly completeness seal is a common pattern. Daily noise without a seal is not a substitute.

What if a system cannot produce a machine snapshot?

We record that limitation in the system inventory, put a compensating manual procedure on it, and keep it off the "automated" list so the auditor is not told a story the evidence cannot support. Then we put engineering time on a read path.

Will this make Rutagon our auditor?

No. Rutagon is the engineering layer. Your CPA firm still issues the report. We make the sample boring.

Do you claim SOC 2 certification for Rutagon?

No. We build SOC 2-aligned evidence pipelines for clients who are obligated to the criteria. That is not the same as Rutagon holding an attestation.