Menu
On this page
- How do a policy, a procedure and evidence connect for one control?
- Which 12 policies does a SOC 2 audit expect, and which criteria does each support?
- What documents does the auditor request, by control area?
- How do you map documents to criteria in a control matrix?
- What changes in your documents for a Type 2 report?
- Can you start from a policy template?
What documentation does a SOC 2 audit require? Each control needs three layers: a policy (the written rule), a procedure (how people carry it out), and evidence (records showing it happened). The AICPA publishes no required document list. Criterion CC5.3 of the AICPA Trust Services Criteria expects the entity to deploy control activities “through policies that establish what is expected and in procedures that put policies into action.” A Type 2 report adds one demand: records from across the whole examination period, not from one date.
This page indexes the documents and shows how they connect. For what to pull from each system, use the SOC 2 evidence request list. For the controls behind the documents, see the SOC 2 controls list. For the order of work across the whole audit, see the SOC 2 compliance checklist.
How do a policy, a procedure and evidence connect for one control?
Write down all three layers for each control, because an auditor tests the chain, not any single document. Take new-user access under CC6.2, which says the entity registers and authorizes new users before issuing credentials. The access policy sets the rule, the request workflow carries it out, and a dated ticket proves it ran.
| Layer | New-user access example | What the auditor looks for |
|---|---|---|
| Policy | Access control policy: access is granted only after recorded approval from the manager or system owner, at the level the role needs | An approved, current version with an owner and a review date |
| Procedure | Access request workflow in your ticketing tool: request, approval, role-based provisioning, ticket closed | Steps that match what staff actually do |
| Evidence | For one named hire, the approved ticket dated before the account-creation time in the identity provider | A sample drawn from the complete list of accounts created in the period |
Our controls library (AC-03) records the usual failure: accounts created before approval is logged, or access granted over chat with the ticket written afterward. Offboarding (AC-04) follows the same chain, with a removal deadline in the policy and the HR termination record as the trigger. The internal control procedure guide shows how to write the middle layer, which is the layer a policy template does not give you.
Which 12 policies does a SOC 2 audit expect, and which criteria does each support?
Auditors expect written policies that cover your controls, but the AICPA names no required set. These twelve are the common set for a Security-scope report, matched to the criteria our controls library cites for the same topics and checked against the AICPA criteria text. Availability, Confidentiality, Processing Integrity and Privacy add policies only when you put those categories in scope.
| Policy | Criteria it supports | Library controls | Guide or template |
|---|---|---|---|
| Information security policy | CC5.3, CC2.2, CC1.3 | PL-01, PL-02, GV-03 | Controls list |
| Acceptable use policy and code of conduct | CC1.1, CC1.5, CC2.2 | GV-01, HR-03, PL-02 | Controls list |
| Access control policy | CC6.1, CC6.2, CC6.3 | AC-01 to AC-07 | Access control policy template |
| Change management policy | CC8.1 | CM-01 to CM-06 | Change management controls |
| Risk assessment policy | CC3.1, CC3.2, CC3.3, CC3.4 | RA-01 to RA-04 | Risk assessment template |
| Vendor management policy | CC9.2, CC2.3 | VR-01 to VR-03 | Vendor management requirements |
| Incident response policy | CC7.3, CC7.4, CC7.5, CC2.3 | IR-01 to IR-04, LG-02 | Security controls, CC7 section |
| Business continuity and disaster recovery | CC9.1, A1.2, A1.3 | BC-01 to BC-05 | Business continuity controls |
| Data classification and handling | C1.1, CC6.7 | DP-02, NS-03 | Controls list |
| Data retention and disposal | C1.2, CC6.5 | DP-03, AM-02 | Controls list |
| Encryption policy | CC6.1, CC6.7, C1.1 | DP-01, NS-03 | Encryption requirements |
| Personnel security (screening, training, offboarding) | CC1.4, CC1.5, CC2.2 | HR-01 to HR-03 | Security awareness training |
The criteria with an A prefix apply only when Availability is in scope, and those with a C prefix only when Confidentiality is. Where the last column says “Controls list”, the SOC 2 controls list gives the control statement, the evidence an auditor may ask for, and the common gap for each library ID. The mapping follows how our library cites each policy and is a starting point, not an AICPA requirement. Your auditor decides what satisfies each criterion for your system.
What documents does the auditor request, by control area?
This table groups the usual requests by control area, with the person who typically owns each and a gap our controls library records for it.
| Control area | Documents requested | Typical owner | A gap the library records |
|---|---|---|---|
| Foundational | System description, org chart and role descriptions, asset inventory | Engineering, HR, IT | Nobody is formally named as security owner, so approvals come from people with no assigned authority (GV-03) |
| HR and personnel | Signed acknowledgments, background checks, training records, onboarding and offboarding checklists | HR, IT | Checks finish after production access is granted, and training reports omit contractors (HR-01, HR-02) |
| Logical access | Access control policy, request tickets, quarterly access reviews, privileged access list | IT, system owners | Reviewers approve the whole list without checking permissions, and decided removals never happen (AC-06) |
| Change management | Change policy, approved pull requests, deployment records, emergency change procedure | Engineering | Admins bypass branch protection, and hotfixes ship with no ticket (CM-01, CM-04) |
| Risk and vendor | Annual risk assessment, vendor inventory and reviews, continuity and recovery plans, recovery test | Security, procurement, operations | A risk register that never changes year to year (RA-01), and backups that run but have never been restored (BC-03) |
| Monitoring and incident response | Incident response plan, alert triage records, tabletop results, penetration test report | Security | A tabletop that happened but records neither attendees nor follow-up actions (IR-02) |
The system description is management’s narrative of the system under examination, and it appears in the report itself. The SOC 2 audit report guide covers how it fits. To collect the same records by source system instead of by control area, use the evidence request list. Compliance platforms can gather much of it on a schedule, and SOC 2 automation covers what they do and do not replace.
How do you map documents to criteria in a control matrix?
A control matrix lists each control with its criterion ID, the document or record that proves it, its owner, and when it was last reviewed. With it, an auditor can move from a criterion to its evidence without asking you. Building it also exposes gaps, such as a vague policy or a missing record, before fieldwork starts.
Our free control-to-evidence matrix is a starting version. It maps 82 example controls to the criteria, with the evidence an auditor may request and the Type 2 evidence they may sample. Tailor each row to your environment and confirm applicability with your CPA firm. The same data is available as Excel and PDF.
What changes in your documents for a Type 2 report?
The policies and procedures are the same for Type 1 and Type 2. The evidence differs. A Type 1 shows controls designed and in place on one date. A Type 2 shows them operating throughout the period, so you need dated records from the whole window. You agree the window with your auditor, and the observation period guide covers how short it can be. SOC 2 Type 1 vs Type 2 compares the two.
Auditors test samples, not every record, and the AICPA sets no mandatory sample sizes. SOC 2 sample size explains how firms choose. You still need to retrieve any record from the period, so keep every policy version and acknowledgment: if a policy changed mid-period, staff who acknowledged only the old version are a gap our library flags (PL-02).
The Trust Services Criteria name no retention period for your records. Keep them long enough that the start of the period is still retrievable when the auditor samples, and longer where contracts or law require. Your retention schedule is itself a document an auditor can ask for.
Can you start from a policy template?
Yes, if you rewrite it to match what your team does. The test compares the written rule with practice, and our library names the usual failure: templates that describe tools, cadences or roles the company does not use (PL-01). A shorter policy you follow every time passes more easily than an ambitious one you regularly skip.
Start from the access control policy template, the risk assessment template and the internal control procedure guide. Give each finished policy an owner, an approval date and a next review date, and have the people who do the work read it before approval. To find which documents are missing, take the SOC 2 readiness assessment. When you are ready to compare audit firms on price and timeline, start from the auditor directory.
More in Audit Preparation