Two Documents, Two Very Different Purposes
First-time SOC 2 clients often confuse the System Description (Section 3 of the report) with the Information Security Policy. They're both long documents about how a company approaches security. But they serve fundamentally different purposes, have different audiences, and require different levels of detail in different areas.
| Dimension | System Description (Section 3) | Information Security Policy |
|---|---|---|
| What it is | Management's description of the system audited, published as part of the SOC 2 report | Internal governance document that establishes security requirements for the organisation |
| Who reads it | Enterprise customers doing vendor due diligence, auditors scoping their testing | Employees, auditors requesting evidence, ISO 27001 assessors, SOC 2 auditors |
| Author | Management (must be management's representation — not the auditor's) | Security/compliance team; approved by leadership |
| Scope | The specific system under audit — one product/service | The entire organisation — all systems, teams, and processes |
| What it describes | What the system is (architecture, components, data, people, procedures, controls) | What people must do (requirements, rules, responsibilities, prohibited actions) |
| Level of detail | High on system architecture, data flows, specific tools used | High on rules, requirements, responsibilities; lower on specific implementation details |
| When created | Drafted before audit fieldwork; finalised before report issuance | Should exist before the SOC 2 examination period starts (auditors test for it) |
| Lives in | The SOC 2 report (distributed to customers with an NDA) | Internal policy repository; shared as SOC 2 audit evidence |
| Regulatory basis | AICPA DC Section 200 | SOC 2 CC1.2/CC2.1, ISO 27001 A.5.1, NIS2 Art. 21(2)(a) |
What the SOC 2 Auditor Uses Each Document For
SOC 2 auditors request the Information Security Policy as a piece of evidence in the prepared-by-client (PBC) list. It demonstrates that management has documented its security requirements — this satisfies SOC 2 CC1.2 (communication of values and standards) and CC2.1 (information and communication).
The System Description is different — the auditor doesn't just receive it. The auditor tests it. Their job is to determine whether the System Description is fairly presented (i.e., whether the description accurately describes the system and controls as they actually exist). Every claim in the System Description is potential evidence that the auditor will verify.
Example: if your System Description says "all production access requires MFA," the auditor will sample production access logs and user accounts to verify MFA is actually enforced. If they find a production admin account without MFA, the System Description has a material misstatement — which is an exception in the report.
The Relationship Between the Two Documents
Your Information Security Policy sets the rules. Your System Description describes how those rules are implemented in the specific system under audit. They should be consistent — if your InfoSec Policy requires annual penetration testing, your System Description should describe that a penetration test is conducted annually and when the last one was performed.
Inconsistencies between the two documents create audit findings. Common examples:
- InfoSec Policy requires quarterly access reviews; System Description doesn't mention access reviews (the auditor will check)
- System Description says encryption at rest uses AES-256; InfoSec Policy doesn't specify an encryption standard
- InfoSec Policy requires MFA for all privileged access; System Description doesn't describe how MFA is enforced
Before finalising either document, cross-reference them. Your legal team or compliance consultant should review both together — the System Description is management's public representation, and discrepancies with the InfoSec Policy signal control gaps.
What Each Document Covers That the Other Doesn't
System Description only:
- Specific infrastructure components named (AWS eu-west-1, RDS PostgreSQL 15, CloudFront CDN)
- System boundary (what's in scope vs. out of scope)
- Subservice organisations with carve-out/inclusive treatment
- Complementary User Entity Controls (CUECs) — what customers must do
- Principal service commitments (availability SLA, security commitments)
- Management's assertion and signature
Information Security Policy only:
- Employee security requirements and prohibited actions
- Acceptable use provisions
- Policy violation consequences (disciplinary framework)
- Policy governance (version control, review cycle, approval authority)
- Requirements for non-production systems (dev/staging)
- Physical security requirements
Both documents cover:
- Access control requirements (though at different levels of detail)
- Encryption requirements
- Incident response
- Change management
- Vendor/third-party management
- Monitoring and logging
When to Create Each Document
The Information Security Policy should exist before the SOC 2 examination period starts. The auditor will check that the policy was in place throughout the period. If you're doing a 12-month Type II with an examination period starting January 1, your InfoSec Policy must be approved and distributed by January 1. Backdating is fraud.
The System Description is typically drafted in the 4–8 weeks before or at the start of fieldwork. Most companies draft it collaboratively between the compliance lead, CTO/head of engineering, and the auditor's readiness team. It's reviewed and revised during fieldwork as the auditor requests clarifications, and finalised before the report is issued.
Generate Both Documents
Use the SOC 2 System Description Generator to draft a complete AICPA DC Section 200-aligned Section 3, and the Information Security Policy Generator to draft your internal InfoSec Policy. Both are free.
Related: SOC 2 Management Assertion Letter, SOC 2 Gap Assessment, SOC 2 Evidence Pack, Change Management Policy.
Related reading: SOC 2 System Description Guide, SOC 2 Evidence Collection Guide, Management Assertion Letter Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or compliance advice. Both documents should be reviewed by your CPA firm and legal counsel before use in an audit engagement.