Anatomy of a SOC 2 Evidence Room: What Auditors Expect to Find and How to Organize It

Why Evidence Organization Matters More Than Evidence Quantity

Most companies approaching their first SOC 2 Type II audit focus on whether they have enough evidence. The more common problem, in practice, is that they have evidence scattered across Google Drive folders, Jira tickets, email threads, and screenshots in various formats — and no clear mapping between what they have collected and which control it satisfies.

When a Big Four auditor begins fieldwork, they typically have a list of evidence requests (PBCs — Provided By Client items) that maps to specific Trust Services Criteria. If your evidence is not organized by control family, the auditor spends time asking follow-up questions: "Where is the access review for CC6.3?" "Which document is the change management policy covering CC8.1?" "Can you show me the CloudTrail logs that correspond to this IAM event?"

Every unanswered question adds time. A well-organized evidence room can be navigated by an auditor who has never seen your environment. A poorly organized one requires your team to answer questions all day during fieldwork, compressing the time available for other work.

The Trust Services Criteria Structure

SOC 2 is organized around five Trust Services Criteria (TSC) categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for all SOC 2 engagements. The others are elective. Most SaaS companies pursuing SOC 2 for the first time include Security and Availability, and sometimes Confidentiality.

Within the Security category, the Common Criteria (CC) are the controls your auditor will evaluate in detail. They range from CC1 (Control Environment) through CC9 (Risk Mitigation). The bulk of evidence collection work falls on CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC8 (Change Management).

An evidence room organized by these criteria categories lets auditors find what they need without asking. The structure should be:

• Top level: One folder per Trust Services Criteria category (CC1 through CC9, A1 if Availability is in scope).
• Second level: One folder per individual criterion within the category (CC6.1, CC6.2, CC6.3, etc.).
• Third level: Individual evidence items with clear filenames and timestamps.

What Belongs in Each Control Family

CC1 — Control Environment

CC1 covers organizational oversight, ethical values, and the management structure that supports the control environment. Evidence here includes your organizational chart, board meeting minutes (or investor meeting notes for private companies), employee code of conduct acknowledgment records, and documentation of your compliance oversight process. For smaller companies, this often means demonstrating that someone with decision-making authority is actively involved in compliance — not just the engineering team.

CC6 — Logical and Physical Access Controls

CC6 is the most evidence-intensive category for most SaaS companies. CC6.1 requires evidence that access is only granted to authorized users — this typically includes IAM user lists with roles, Okta or SSO provisioning logs, and your access request approval process. CC6.2 requires evidence of prior authentication — multi-factor authentication configuration exports and enrollment records. CC6.3 covers the principle of least privilege — IAM policy reviews, role definitions, and access review records showing that excess permissions have been revoked.

CC6.6, which covers network access restrictions, requires security group configurations, firewall rules, and evidence that unauthorized access attempts are detected. This is where configuration drift becomes particularly relevant, as we discussed in our article on how configuration drift creates compliance gaps.

CC7 — System Operations

CC7 covers monitoring, vulnerability management, and incident response. CC7.1 requires evidence of a formal incident response policy and training. CC7.2 requires evidence of security monitoring — SIEM alerts, CloudTrail review logs, or documentation showing that someone is actually reviewing security events on a regular schedule. CC7.3 covers how you evaluate and respond to security vulnerabilities — scan results from Snyk or AWS Inspector, evidence of patch application, and records showing vulnerabilities were addressed within your stated remediation timelines.

CC8 — Change Management

CC8.1 covers the authorization and documentation of infrastructure changes. Evidence includes your change management policy, Jira or GitHub pull request records showing code review approvals, and deployment logs. Auditors look for evidence that changes are authorized before deployment — not just that a process exists on paper.

CC9 — Risk Mitigation

CC9 covers business continuity, vendor management, and risk assessment. Evidence includes your risk assessment document, business continuity plan, disaster recovery test results, and vendor security reviews. CC9.2 specifically covers vendor management — this requires evidence that you have assessed the security posture of your key vendors and monitored it over time.

Evidence File Naming Conventions

File naming is a detail that has an outsized impact on how quickly an auditor can navigate evidence. A consistent naming convention removes ambiguity. The pattern that works best in practice is: [CONTROL-ID]_[evidence-type]_[YYYY-MM-DD].[ext]

Examples:

• CC6.3_iam-access-review_2025-09-30.pdf
• CC7.2_cloudtrail-review-log_2025-10-15.csv
• CC8.1_deployment-approval-record_2025-11-01.pdf

The date in the filename should reflect when the evidence was collected or when the activity occurred — not when it was uploaded to the evidence room. An auditor comparing a CC6.3 access review to a CloudTrail event on the same date will immediately see the connection. One with inconsistent or missing dates will need to ask clarifying questions.

Chain of Custody and Authenticity

A frequently overlooked requirement in SOC 2 evidence is chain of custody — the ability to demonstrate that evidence was collected directly from the source system without modification. Screenshots are particularly vulnerable to this concern. An auditor cannot independently verify that a screenshot accurately represents what it claims to show.

Better evidence types for this reason include: direct exports from AWS Config or IAM with metadata preserved, API responses stored as JSON, log files with cryptographic hashes, and automated collection records with timestamps. When evidence is collected by a third-party monitoring tool rather than manually, the auditor can verify through the tool rather than relying on the screenshot.

CompliRun stores all collected evidence with a UTC timestamp and a SHA-256 hash at the time of collection. The evidence room shows auditors the hash alongside the evidence, and maintains an immutable collection log that shows when each item was pulled and from which source integration.

The PBC List: Working from the Auditor's Perspective

Rather than organizing your evidence room from the inside out (based on what you have), it is more efficient to work from the outside in — starting with your auditor's PBC list. Most Big Four firms have standard PBC templates for SOC 2 engagements. These lists are publicly available, and many compliance platforms maintain current versions.

A typical SOC 2 Type II PBC list for a SaaS company includes 60–120 line items. For each item, the PBC specifies the control criteria, the evidence requested, and sometimes the format. Mapping your evidence room to the PBC list before fieldwork begins means your auditor can check items off directly rather than searching for evidence that may or may not satisfy the request.

CompliRun's evidence room is structured around PBC item numbers, not just control criteria codes. This means when an auditor opens the shared view, they see evidence organized exactly as their own PBC list is organized.

What Auditors Flag as Missing (Consistently)

After hundreds of SOC 2 engagements, certain evidence gaps appear repeatedly. Being aware of them before fieldwork is more useful than discovering them during it.

Access review completeness: Companies document quarterly access reviews but have gaps — months where no review occurred, or reviews that were completed but not formally documented. CC6.3 requires evidence of regular reviews, not just the most recent one. The entire audit period matters.

Terminated employee access: CC6.2 requires that access is revoked promptly upon termination. This is one of the most commonly tested controls. Auditors will sample termination dates from your HR system and cross-reference against Okta deactivation timestamps. A delay of more than 24–48 hours is typically flagged.

Vendor security reviews: CC9.2 is consistently underprepared. Many companies have a list of vendors but no documented security assessment for each one. The assessment does not need to be exhaustive — reviewing the vendor's published SOC 2 report, SOC 2 attestation, or completing a standard security questionnaire is usually sufficient — but it needs to exist and be current.

Vulnerability remediation timelines: Pulling a vulnerability scan is not the same as showing that vulnerabilities were remediated within your stated timelines. CC7.3 requires both — the scan output and the evidence of remediation within the timeframe defined in your vulnerability management policy.

Sharing the Evidence Room with Your Auditor

The practical question of how to share evidence with your auditor is worth some consideration. Shared Google Drive folders work but create version control problems. Secure file sharing platforms create friction when auditors need to upload their own working papers. Purpose-built evidence rooms avoid both issues.

The key features that reduce fieldwork time are: read-only access for auditors (no accidental deletions), folder structure organized by control criteria and PBC items, version history that shows when evidence was added or updated, and a direct messaging channel for evidence requests.

Teams that have used a purpose-built evidence room for the first time consistently report that fieldwork is 30–40% faster compared to shared drive setups, primarily because auditors can navigate independently rather than submitting evidence requests and waiting for uploads.