What are the 7 documents your SOC 2 auditor actually needs?

The Seven Core Documents

Auditors don't want a hundred documents. They want a focused set that covers the Trust Services Criteria in your scope. Here are the seven that every SOC 2 audit requires:

#	Document	Maps To	What It Covers
1	Information Security Policy	CC1.1-CC1.5	Overall security program, roles, responsibilities
2	Access Control Policy	CC6.1-CC6.8	Who gets access, how, and approval process
3	Change Management Policy	CC8.1	How code changes are approved and deployed
4	Incident Response Plan	CC7.3-CC7.5	How you detect, respond to, and recover from incidents
5	Risk Assessment	CC3.1-CC3.4	Identified risks and how you mitigate them
6	Vendor Management Policy	CC9.1-CC9.2	How you evaluate and monitor third-party vendors
7	System Description	Section 3	Your infrastructure, data flows, and boundaries

What Each Document Needs

Every document should include: the purpose of the policy, who it applies to, the specific controls you follow, how you monitor and enforce the controls, and when the policy was last reviewed.

The most critical thing: each document must describe your actual systems and processes. If your change management policy says "all deployments require two reviewer approvals" but your GitHub repo allows one, the auditor will flag that mismatch.

Common Mistakes

• Too many documents: Some consultants create 20-30 policies. Auditors don't need that. Seven well-written documents cover the criteria.
• Too generic: Policies that say "the company uses industry-standard encryption" without specifying which encryption. Name your systems.
• Outdated: Policies written six months ago that don't reflect current infrastructure. Review before audit.

Where Screenata Helps

Screenata generates these seven documents by reading your codebase and cloud infrastructure. Each policy references your actual tools and configurations, so they match what the auditor will observe during testing.