SOC 2 Type II Policy Requirements: The Complete Checklist

Meeting SOC 2 Type II policy requirements is one of the most concrete, actionable steps a SaaS company can take toward enterprise sales readiness. SOC 2 Type II policies aren't optional documentation — they are the evidentiary backbone of every control your auditor will test over a 6-to-12-month observation period. Without them, you don't have a compliance programme; you have a gap finding waiting to be written.

This guide breaks down exactly which policies you need, how they map to each of the five Trust Service Criteria (TSC), what auditors actually look for when they review your policy programme, and the most common reasons organisations fail their first SOC 2 Type II audit. Whether you're starting from scratch or hardening an existing programme, use this as your authoritative checklist.

What Is SOC 2 and Why Do You Need It?

SOC 2 is a voluntary auditing framework developed by the American Institute of Certified Public Accountants (AICPA). It evaluates whether a service organisation's controls adequately protect the security, availability, processing integrity, confidentiality, and privacy of customer data. The resulting report — issued by a licensed CPA firm — is the standard trust artefact in B2B SaaS sales cycles.

Enterprise buyers don't just want SOC 2 — they increasingly require it. Security questionnaires, vendor risk assessments, and procurement processes at mid-market and enterprise organisations almost always include a request for your most recent SOC 2 report. Without one, deals stall at the security review stage.

SOC 2 Type I vs Type II: The Critical Distinction

A SOC 2 Type I report is a point-in-time assessment. An auditor visits your organisation (or reviews documentation remotely), evaluates whether your controls are suitably designed, and issues a report as of a specific date. It answers: "Do the controls look right on paper today?"

A SOC 2 Type II report assesses whether those same controls operated effectively over a defined period — typically 6 or 12 months. It answers: "Did the controls actually work, consistently, across the observation window?" Auditors will test a sample of actual events: access provisioning logs, change tickets, incident records, vendor reviews. This is why policies must not only exist but be followed.

The 5 Trust Service Criteria

SOC 2 is built around five Trust Service Criteria. Security (Common Criteria) is mandatory for every SOC 2 report. The remaining four are optional and selected based on what commitments your organisation makes to customers in its system description and service agreements.

Mandatory Policies for SOC 2 Security (Common Criteria)

The Security criteria — formally called the Common Criteria (CC) — contains 33 control points organised across nine categories (CC1 through CC9). Every one of them requires documented policies as the foundational evidence layer. Here are the 12 core policies every SOC 2 audit will scrutinise.

1. Information Security Policy

This is your top-level policy: it establishes management's commitment to security, defines the scope of your information security programme, assigns ownership, and references all subordinate policies. Without a coherent Information Security Policy, auditors cannot establish that your organisation treats security as a governance matter rather than a technical afterthought. It must be reviewed and reapproved at least annually.

2. Access Control Policy

Covers CC6 (Logical and Physical Access Controls) — one of the most heavily tested areas in any SOC 2 engagement. Your Access Control Policy must address: principle of least privilege, role-based access control (RBAC), user provisioning and deprovisioning procedures, privileged access management, multi-factor authentication requirements, and periodic access reviews. Auditors will pull a sample of user accounts provisioned or deprovisioned during the observation period and verify the policy was followed.

3. Change Management Policy

Maps to CC8 (Change Management). This policy defines how changes to production infrastructure and applications are planned, tested, approved, and deployed. Critical elements: change request process, approval gates (including separation of duties between developer and approver), testing requirements before deployment, emergency change procedures, and post-implementation review. Auditors will sample production deployments and verify each followed the documented process.

4. Risk Assessment Policy

Underpins CC3 (Risk Assessment) and CC4 (Monitoring of Controls). This policy must define how often formal risk assessments are conducted (at minimum annually), the methodology used (e.g., likelihood × impact scoring), how risk treatment decisions are documented, and who owns the risk register. The policy must also address how new risks identified during the year are escalated and tracked.

5. Vendor Management Policy

Addresses CC9 (Risk Mitigation with Vendors and Business Partners). SaaS companies typically have dozens of sub-processors and infrastructure vendors. Your Vendor Management Policy must define: vendor security assessment criteria, due diligence requirements before onboarding, contractual security requirements (including data processing agreements), ongoing monitoring procedures, and annual vendor reviews. Auditors will review your vendor inventory and sample vendor assessments.

6. Incident Response Policy

Covers CC7 (System Operations) and the incident-related elements of CC2. This policy must define incident classification categories, detection and escalation procedures, containment and eradication steps, notification obligations (including customer notification thresholds), post-incident review requirements, and who has authority to declare an incident. Auditors will ask for evidence of at least one incident response exercise or tabletop simulation during the observation period.

7. Business Continuity & Disaster Recovery Policy

Addresses the resilience-related elements of CC9 and, when Availability TSC is included, A1. This policy defines Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), the steps for activating the continuity plan, DR testing cadence, and roles during a crisis. Critically, the policy must be tested — a documented DR test result is mandatory evidence.

8. Acceptable Use Policy

Addresses CC1 (Control Environment) by establishing that employees understand their security obligations. Covers approved and prohibited use of company systems, data handling expectations, personal device use, software installation rules, and consequences for violations. Must be acknowledged by all employees — auditors will request evidence of acknowledgement records.

9. Encryption Policy

Part of CC6 (Logical Access Controls). Defines minimum encryption standards for data in transit and at rest, key management procedures, approved cryptographic algorithms, and certificate lifecycle management. Common failure point: policies that say "we use encryption" without specifying standards (e.g., TLS 1.2 minimum, AES-256 for data at rest) are considered insufficient.

10. Vulnerability Management Policy

Addresses CC7 (System Operations). Defines vulnerability scanning cadence (typically weekly or monthly for infrastructure, with continuous scanning tools), severity classification (CVSS scoring), remediation SLAs by severity (e.g., Critical: 15 days, High: 30 days), penetration testing frequency, and the process for tracking remediation to closure. Auditors will request vulnerability scan reports from the observation period and verify remediation timelines were met.

11. Data Classification Policy

Underpins multiple CC controls and is foundational for Confidentiality and Privacy TSC. Defines data classification tiers (e.g., Public, Internal, Confidential, Restricted), handling requirements for each tier, labelling standards, and approved storage and transmission methods per classification. Without a Data Classification Policy, it is impossible to demonstrate consistent data handling across your organisation.

12. Logging & Monitoring Policy

Addresses CC7 (System Operations) and CC4 (Monitoring of Controls). Defines what events are logged, log retention periods, alerting thresholds, log integrity controls, and the process for reviewing security alerts. Log retention is a common gap — auditors will ask for logs from the beginning of the observation period, and organisations without a defined retention policy often discover they've been overwriting logs after 30 days.

Additional Policies for Availability (A) Criteria

If your service commitments include uptime guarantees — and for most SaaS products they do — include the Availability TSC. It adds three primary control areas (A1.1 through A1.3) focused on capacity, environmental threats, and recovery. In addition to the Business Continuity policy above, you will need:

Availability & Capacity Management Policy

Defines how you monitor system capacity, forecast growth, and provision resources to meet performance commitments. Includes thresholds that trigger capacity reviews, processes for handling traffic spikes, and how uptime is measured and reported to customers. Auditors will request infrastructure monitoring dashboards and any capacity review records from the observation period.

Backup & Recovery Policy

Defines backup frequency (e.g., daily full, hourly incremental), retention schedules, storage locations (including geographic separation requirements), restore testing cadence, and RPO targets. Backup policy without backup testing evidence is a near-automatic finding — auditors will ask for documented restore tests, not just backup job logs.

Additional Policies for Confidentiality (C) Criteria

The Confidentiality TSC (C1.1 and C1.2) requires you to identify confidential information and protect it through its lifecycle. If your Data Classification Policy already covers confidential data tiers comprehensively, it may satisfy much of this criteria with an addendum. However, most organisations also need:

Data Handling & Disposal Policy

Specifies how confidential data is handled during use (access controls, screen lock policies, clean desk), transmitted (approved channels, encryption requirements), stored (approved systems, encryption at rest), and disposed of at end of life (secure deletion standards for digital media, physical destruction for hardware). Disposal is a chronic gap — if you retire hardware without documented secure wiping, that's a finding.

Non-Disclosure & Confidentiality Agreement Policy

Defines when NDAs are required (employees, contractors, vendors, prospects), what confidentiality obligations they include, how executed agreements are stored, and the process for enforcing them. Auditors will ask for executed NDA records for any roles with access to customer data.

Additional Policies for Privacy (P) Criteria

The Privacy TSC has eight criteria (P1 through P8) derived from AICPA's Generally Accepted Privacy Principles. It is the most document-intensive optional TSC, and aligns closely with GDPR and CCPA obligations. Key policies required:

Privacy Policy (External-Facing)

Your public-facing privacy notice is itself an evidence artefact. It must accurately describe what personal data you collect, why, how it is used, who it is shared with, retention periods, and data subject rights. Auditors will compare your privacy notice against actual data flows documented in your data inventory.

Data Subject Rights Policy

Defines procedures for handling data subject requests: access, rectification, erasure, portability, and objection. Includes intake process, response timelines (must meet GDPR's 30-day standard for organisations serving EU data subjects), escalation procedures, and record-keeping requirements.

Data Retention & Deletion Policy

Defines retention periods for each data category, the legal basis for each retention period, deletion procedures (automated where possible), exceptions handling, and evidence of periodic purges. Cross-reference this against your Backup & Recovery Policy to ensure backup retention schedules don't inadvertently extend data retention beyond documented limits.

What Auditors Actually Look For

Writing policies is necessary but not sufficient. SOC 2 Type II auditors are testing operational effectiveness — they need to see that controls were actually followed across the full observation period, not just documented. Here is what experienced auditors examine most closely.

Policy Existence and Currency

Every policy must exist as a formal document with a title, version number, effective date, owner, and approval signature (or digital equivalent). Policies must have been reviewed and reapproved within the last 12 months. An undated Word document shared in a Slack channel is not an auditable policy.

Distribution and Acknowledgement

Auditors will request evidence that all relevant employees received and acknowledged key policies — at minimum the Information Security Policy and Acceptable Use Policy. They will typically sample 10-25% of the employee population and request acknowledgement records for each sampled individual. If you cannot produce acknowledgement evidence, the policy is treated as non-operative.

Policy-to-Control Mapping

Your policies must demonstrably address the control objectives they are meant to support. Auditors use your policies as a reference baseline: they read the policy, then test whether reality matches it. If your Access Control Policy states that all access provisioning requires manager approval within 5 business days, the auditor will pull a sample of access provisioning tickets and verify the approval timestamps.

Common Failure Points

The most frequent deficiency findings in first-time SOC 2 Type II audits are: missing or incomplete deprovisioning records (former employees whose access wasn't revoked or couldn't be proven to have been revoked); change management bypasses (emergency changes deployed without documentation); undocumented access reviews (quarterly access reviews required by policy but not conducted or recorded); and stale vendor inventory (vendors added mid-year without documented security assessments).

How to Structure Your Policy Programme for SOC 2

A coherent policy programme for SOC 2 has three tiers: a top-level Information Security Policy that sets strategic direction, a set of topic-specific policies (the 12-15 covered above) that operationalise each control domain, and supporting procedures or standards that give implementors step-by-step guidance.

Tier 1 — Policy (What and Why): Management-approved, reviewed annually, states objectives and obligations. Audience: all staff and auditors.

Tier 2 — Standards (How Much): Specifies measurable requirements — minimum password length, encryption algorithms, patching SLAs. Often part of the policy document itself or a direct attachment.

Tier 3 — Procedures (How): Step-by-step operational guides. Change the deployment process, update the procedure. Procedures change more frequently than policies and need not be reapproved by the board, but they must be consistent with the governing policy.

Before your observation period begins, every policy should be in its final approved form. Mid-observation policy rewrites raise questions about whether controls were in place from the start of the period. If you do need to revise a policy during the observation window, version it clearly and document the reason for the change.

Common Mistakes and How to Avoid Them

1. Generic Policies Without Operational Specificity

Policies downloaded from the internet and left unedited will not pass auditor scrutiny. Statements like "we use appropriate security measures" are not testable. Auditors need specific, measurable commitments: "All production access requires MFA. Privileged access is reviewed quarterly by the Head of Engineering." Write to your actual controls, not to aspirational ideals.

2. Policies That Don't Match Reality

The second most damaging scenario (after having no policy) is having a policy that describes a process you don't follow. If your Incident Response Policy says you conduct quarterly tabletop exercises and you haven't, that is an "exception" — a documented failure. Audit your actual practices before finalising policy language, and close gaps before the observation period starts.

3. No Acknowledgement Tracking

Distribution via email with no tracking creates an unauditable paper trail. Use a policy management platform that captures individual acknowledgements with timestamps and policy version numbers. During audit fieldwork, the difference between "we emailed everyone" and a downloadable acknowledgement report sorted by employee and policy is the difference between a smooth audit and a finding.

4. Forgetting Contractors and Third Parties

Access Control and Acceptable Use policies must extend to contractors and third-party users with access to your systems. Auditors will pull all accounts with access and will not distinguish between employees and contractors. If your contractor onboarding process doesn't include policy acknowledgement, you have a gap.

5. Treating SOC 2 as a One-Time Project

A SOC 2 Type II report is issued annually. The controls you implement must continue operating effectively year after year. Organisations that treat the first audit as a sprint and then let processes decay discover this painfully in their second audit. Build your policy programme as a living system: assign owners, schedule annual reviews, track acknowledgements continuously, and maintain your evidence repository throughout the year.

Frequently Asked Questions

How many policies do you need for SOC 2?

For SOC 2 Security (CC) criteria you need approximately 12-15 core policies. These include an Information Security Policy, Access Control Policy, Change Management Policy, Risk Assessment Policy, Vendor Management Policy, Incident Response Policy, Business Continuity Policy, Acceptable Use Policy, Encryption Policy, Vulnerability Management Policy, Data Classification Policy, and Logging & Monitoring Policy. If pursuing additional TSC (Availability, Confidentiality, Privacy), you will need 3-5 more policies per criteria.

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

A SOC 2 Type I report assesses whether your controls are suitably designed at a single point in time. A SOC 2 Type II report assesses whether those controls actually operated effectively over a defined period — typically 6 to 12 months. Type II is significantly more valuable to enterprise buyers because it demonstrates ongoing operational effectiveness, not just design intent. Most enterprise customers specifically require a SOC 2 Type II report before contract signature.

How long does SOC 2 Type II certification take?

SOC 2 Type II typically takes 12 to 18 months from start to issued report. The observation period alone is a minimum of 6 months (12 months is more common for first-time reports). Most organisations spend 3-6 months before the observation window implementing controls and writing policies. The audit fieldwork itself takes 4-8 weeks. Organisations using pre-mapped policy templates and a dedicated policy management platform can meaningfully reduce the preparation phase.

Are SOC 2 policies mandatory or just best practice?

SOC 2 policies are mandatory. Without documented policies, you cannot demonstrate that controls exist — auditors require written policies for every control area they test, and a missing policy is an automatic deficiency finding. Policies must also be distributed to all relevant staff and acknowledged: auditors will ask for evidence of policy awareness, training completion, and acknowledgement records for a sample of employees. A policy document that no one has seen is treated as non-operative.

Which Trust Service Criteria are required for SOC 2?

The Security (Common Criteria, CC) is the only mandatory Trust Service Criteria for all SOC 2 reports. The other four — Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P) — are optional and selected based on what commitments your organisation makes in its system description and customer agreements. Most cloud SaaS companies include Security and Availability. Companies handling sensitive personal data often add Confidentiality and Privacy. Processing Integrity is typically scoped only for financial transaction processors and data transformation services.

Further Reading

• ISO 27001:2023 Updated Policy Requirements Explained
• Policy Acknowledgement Best Practices
• More compliance articles
• AICPA SOC 2 Official Resources