What Documentation Does SOC 2 Actually Require?

"SOC 2 documentation" covers three distinct things that are often confused:

Policies — Written statements of intent ("we will encrypt data at rest")

Procedures — Written descriptions of how policies are implemented ("here is how we configure S3 bucket encryption")

Evidence — Proof that controls are operating as described (the actual AWS Config output showing encryption is enabled)

All three are required. Many teams write thorough policies and procedures but fail audits because their evidence is sparse, stale, or manually collected. Others have excellent automated evidence but lack formal policy documentation. SOC 2 requires both.

SOC 2 Documentation by Trust Services Criterion

CC1 — Control Environment

Required documentation:

• Information security policy — the foundational document describing your security program, ownership, and governance structure
• Acceptable use policy — rules governing employee use of company systems and data
• Employee onboarding / background check records — evidence that background checks are conducted per policy
• Security training completion records — evidence that all employees completed annual security awareness training
• Organizational chart — demonstrates accountability structure

What auditors test: They will pull a sample of employees hired in the observation period and verify background checks were conducted. They will pull training completion logs and verify no employees are past due.

CC2 — Communication and Information

Required documentation:

• Internal communication records — evidence that security policies were distributed to employees (e.g., email distribution logs or policy acknowledgement records)
• External communication policy — how you communicate security information to customers and stakeholders
• Incident notification procedures — documented process for notifying affected customers of security incidents

CC3 — Risk Assessment

Required documentation:

• Risk register — a maintained list of identified risks, with likelihood, impact, risk owner, treatment, and acceptance decisions
• Risk assessment methodology — how risks are scored and prioritized
• Risk acceptance log — formal sign-off records for risks that are accepted rather than remediated
• Annual risk assessment records — evidence the risk assessment is performed at least annually

What auditors test: They review the risk register for completeness and recency. A risk register last updated 18 months ago is a finding.

CC4 — Monitoring Activities

Required documentation:

• Penetration test report — from a qualified third-party vendor
• Pen test remediation tracking — evidence that findings were remediated or formally accepted, with timelines
• Continuous monitoring records — logs showing that automated control checks ran throughout the observation period
• Management review records — evidence that monitoring results were reviewed by management, not just collected

CC5 — Control Activities

Required documentation:

• Control matrix — a mapping of every SOC 2 control to the system or process that implements it
• Automated control test results — the output of technical scans (IAM checks, CloudTrail status, S3 encryption) with timestamps
• Control exception log — documentation of any control failures, how they were detected, and how they were remediated

This is where continuous monitoring tools earn their value. Manual control testing produces evidence that's accurate once per quarter. Automated testing produces evidence that's accurate continuously.

CC6 — Logical and Physical Access Controls

Required documentation:

• Access control policy — rules governing who can access what, and how access is provisioned and deprovisioned
• User access list — current inventory of all users with access to systems in scope
• Access review records — evidence of periodic reviews (at minimum quarterly) of user access across all systems
• Terminated user deprovisioning evidence — for every employee terminated in the observation period, evidence that system access was revoked
• MFA enrollment records — evidence that MFA is enforced for all users with privileged access
• Privileged access logs — record of administrative actions taken by privileged users

CC7 — System Operations

Required documentation:

• Incident response plan — written procedures for detecting, classifying, investigating, and resolving security incidents
• Incident log — a record of all security incidents during the observation period, including date, severity, timeline, and resolution
• Post-incident review records — for significant incidents, a written review of what happened and what changed as a result
• System monitoring configuration — evidence that alerting is configured and operational (GuardDuty, CloudWatch, SIEM alerts)

CC8 — Change Management

Required documentation:

• Change management policy — rules governing how changes to production systems are approved, tested, and deployed
• Change request records — a log of production changes during the observation period, with approver, test evidence, and rollback plan
• Code review evidence — pull request records showing required reviewer approval before merge
• Deployment records — evidence linking approved change requests to production deployments

The GitHub branch protection and CI/CD audit trail satisfy most of this automatically, but the policy document must exist and the records must be organized and accessible.

CC9 — Risk Mitigation

Required documentation:

• Vendor management policy — process for evaluating, onboarding, and monitoring third-party vendors
• Vendor inventory — list of all third-party vendors with access to your systems or data, including their risk tier
• Vendor security assessments — evidence that vendors were assessed (security questionnaires, SOC 2 reports reviewed)
• Subprocessor register — for SaaS companies, a list of all subprocessors shared with customers

Evidence Retention Requirements

SOC 2 does not specify a mandatory retention period, but the standard expectation is:

• Type II observation period evidence — retained for the length of the observation period plus at least 3 years
• Policy versions — retain superseded versions so auditors can verify policies were in place during the observation period
• Access review records — retain for at least 2 years
• Incident records — retain for at least 3 years, or longer if legal holds apply

Store evidence in a tamper-evident system. A Google Drive folder where files can be edited after the fact is not acceptable. Evidence that can be changed retroactively has no evidentiary value.

Organizing Documentation for Your Auditor

Auditors approach evidence collection by control. The most efficient way to organize SOC 2 documentation is by Trust Services Criterion:

/CC1-Control-Environment/

  information-security-policy-v3.pdf
  background-check-records-Q3-2026.csv
  training-completion-log-2026.csv
/CC3-Risk-Assessment/
  risk-register-2026-Q3.pdf
  risk-assessment-methodology.pdf
/CC6-Logical-Access/
  access-control-policy-v2.pdf
  user-access-review-Q2-2026.pdf
  user-access-review-Q3-2026.pdf
  mfa-enrollment-report-2026-09-30.csv

Alternatively, use a compliance platform with a dedicated auditor workspace where controls, policies, and evidence are linked and the auditor can navigate by criterion without needing a folder structure explanation.

The Difference Between Documentation and Evidence

A common SOC 2 audit finding is "control documented but not operating effectively." This means the policy exists but the evidence shows the control isn't actually running as described.

Example:

• Policy: "All AWS IAM users with console access must have MFA enabled"
• Documentation gap: The IAM MFA check is failing for 3 users, but there is no record of these users being identified, notified, or remediated

The policy alone is not enough. You need evidence that the policy is enforced, monitored, and that exceptions are tracked and resolved.

This is why continuous automated monitoring matters more than documentation quality — it's what converts a policy document into an operating control with auditable evidence.