What Policies Does SOC 2 Require? A Documentation Checklist

Quick Answer: SOC 2 does not publish a mandatory list of policies, since auditors test your controls against the AICPA Trust Services Criteria (TSC). This means you need written policies, standards and procedures that cover applicable TSC. Most organizations cover this with a core set of security policies, procedures and other evidence for each TSC requirement.

Why is there no official SOC 2 policy list?

SOC 2 is an attestation report, not a checklist standard. The Trust Services Criteria (TSC) describe what your controls must accomplish, such as restricting logical access or managing changes, and leave the design to you. That flexibility is useful, but it means you must show the auditor how your documentation covers each criterion.

Security, also called the Common Criteria, is in every SOC 2 report. Availability, Processing Integrity, Confidentiality and Privacy are added only when they are relevant to your services. This leads to the unforunate situation where one company's SOC 2 report is likely not the same as another company's SOC 2 report, since the requirements are not standardized.

Are policies enough for a SOC 2 audit?

No. Policies state intent, but auditors test controls. You also need standards that define measurable requirements and procedures that show how each control operates. For a SOC 2 Type II report, you need evidence that the procedures ran throughout the review period. The policies vs standards vs controls vs procedures guide explains how these layers fit together.

How do you check your documentation against the criteria?

1. List the Trust Services Criteria categories in scope for your report.
2. For each criterion, point to the policy and standard that set the requirement.
3. Point to the procedure that shows how the control operates and who owns it.
4. Identify the evidence the procedure produces and where it is stored.
5. Record any gaps with an owner and target date before fieldwork begins.

Pay particular attention to how policies are approved and reviewed. Auditors often ask who approved each policy, when it was last reviewed and how employees were told about changes. Keep a simple review log with dates and approvers so those questions take minutes, not days.

A crosswalk makes this easier. The Secure Controls Framework (SCF) maps its controls to many frameworks, including the Trust Services Criteria. ComplianceForge's SCF-based policies and standards follow that mapping rather than inventing new requirements, so one set of documents can support SOC 2 alongside ISO 27001 or NIST. See the TSC and SOC 2 compliance resource center for related resources.

TSC / SOC 2 Frequently Asked Questions (FAQ)

Does SOC 2 require a specific list of policies?

No. SOC 2 is based on the AICPA Trust Services Criteria, which describe what controls must achieve rather than naming required documents. Your auditor will expect written policies that cover the criteria in scope.

Which Trust Services Criteria category is always included?

Security, also called the Common Criteria, is included in every SOC 2 report. Availability, Processing Integrity, Confidentiality and Privacy are added based on the services you provide and what customers need.

What is the difference between a SOC 2 Type I and Type II report?

A Type I report looks at whether controls are suitably designed at a point in time. A Type II report also tests whether those controls operated effectively over a period, so it needs evidence collected across that period.

Can SOC 2 policies also support other frameworks?

Yes. If your policies and controls are mapped to a common control set such as the Secure Controls Framework, the same documentation can support SOC 2, ISO 27001 and NIST-based requirements.