How SOC 2 policies actually work
SOC 2 doesn't come with a required policy list. The AICPA's Trust Services Criteria describe what your controls need to accomplish — not what your documents need to be named. This gives organizations flexibility, but it also means there's no definitive checklist to download and check off.
What auditors do in practice is map your policies against the applicable criteria and ask two questions: does a policy exist that addresses this control area, and is there evidence the policy is actually followed? A policy that exists but lives in a folder no one has opened is not a control — it's a document.
The policies listed here are organized by Trust Services Criteria. The Security (CC) criteria are mandatory for every SOC 2 audit. Availability, Confidentiality, Processing Integrity, and Privacy are optional — include them if your service commitments or customer contracts require it. Most SaaS companies include Security plus Availability or Confidentiality at minimum.
Template warning: Downloaded policy templates are a starting point, not a finish line. Auditors routinely identify policies that reference systems, job titles, or processes that don't exist at the organization. Every policy must describe what you actually do. Generic boilerplate is one of the most common causes of audit findings.
All SOC 2 policies at a glance
Security (Common Criteria) — required for every SOC 2
These 13 policies are the foundation. Every SOC 2 audit, regardless of which additional TSCs you include, requires credible coverage of the Common Criteria. These policies map to the CC1 through CC9 control categories.
Information Security Policy
The top-level governance document. States management's commitment to information security, defines the overall security framework, and establishes that all other policies flow from it. This is the first document auditors request and the one that sets the tone for your entire program.
- Management commitment and policy owner
- Scope of the security program
- Reference to subordinate policies
- Annual review requirement and approval process
- Consequence of non-compliance
Acceptable Use Policy
Defines how staff may use company systems, networks, devices, and data. Should explicitly address AI tool usage — auditors are now routinely asking whether AUPs cover AI. If yours doesn't, it's a gap.
- Permitted and prohibited uses of company systems
- Personal device (BYOD) rules if applicable
- AI tool usage — approved tools, prohibited data inputs
- Password and authentication expectations
- Monitoring acknowledgment
Access Control Policy
Governs how access to systems and data is granted, reviewed, modified, and revoked. This is one of the most heavily tested areas in any SOC 2 audit — expect evidence requests for access review logs, provisioning records, and offboarding tickets.
- Least privilege and need-to-know principles
- Role-based access assignment process
- Access review frequency (typically quarterly)
- Provisioning and deprovisioning procedures
- Privileged access and admin account rules
- Offboarding access revocation timeline
Password and Authentication Policy
Often rolled into the Access Control Policy, but can stand alone. Should cover MFA requirements — auditors expect MFA on all production systems and any system processing customer data. No MFA exceptions without documented compensating controls.
- Minimum password complexity and length requirements
- MFA requirements — where mandatory (all production, VPN, cloud consoles)
- Password manager guidance or requirement
- Service account and API key credential handling
- Password rotation on suspected compromise
Encryption Policy
Defines encryption requirements for data at rest and in transit. Auditors test this through configuration evidence — expect requests for screenshots of S3 bucket settings, database encryption flags, and TLS certificate records, not just the policy itself.
- Encryption standards (AES-256 at rest, TLS 1.2+ in transit)
- Which systems and data stores are in scope
- Key management approach and ownership
- Laptop disk encryption requirements
- Prohibition on transmitting sensitive data via unencrypted channels
Change Management Policy
One of the most evidence-intensive SOC 2 policies. Auditors will sample your change tickets, deployment logs, and code review records. If your policy says all changes require peer review but your git history shows direct pushes to main, you have a finding.
- Change types: standard, normal, emergency
- Approval requirements per change type
- Testing and staging environment requirements
- Code review and peer approval process
- Rollback procedures
- Emergency change process and post-implementation review
Vulnerability Management Policy
Defines how you discover, prioritize, and remediate security vulnerabilities. Must include defined SLAs by severity — a critical vulnerability with no documented remediation timeline is a finding. Penetration testing should also be referenced here.
- Vulnerability scanning frequency and tooling
- Severity classification (Critical/High/Medium/Low)
- Remediation SLAs by severity (e.g. Critical: 72 hours, High: 30 days)
- Patch management process and cadence
- Annual penetration test requirement
- Exception and risk acceptance process
Incident Response Policy
Defines how security incidents are identified, triaged, escalated, contained, and documented. Must be tested — a policy with no evidence of tabletop exercises or real incident handling will not satisfy auditors. Customer notification timelines matter here too.
- Incident definition and classification criteria
- Detection and reporting channels
- Escalation path and roles (who declares an incident, who is on-call)
- Containment, eradication, and recovery steps
- Customer and regulatory notification timelines
- Post-incident review requirement
- Annual testing requirement
Vendor Management Policy
Governs how third-party vendors are assessed, onboarded, monitored, and offboarded. Frequently cited as the most commonly incomplete policy in SOC 2 audits — organizations either don't have one, or have one that isn't followed. See the commonly missing section below.
- Vendor risk tiering and classification criteria
- Security review requirements per risk tier
- Contract requirements (DPAs, security terms, breach notification)
- Ongoing monitoring frequency
- Critical vendor review cadence
- Vendor offboarding and data return/destruction requirements
Risk Assessment Policy
Defines how the organization identifies, assesses, and treats information security risks. The policy itself is the governance document — auditors also want to see the actual risk register and evidence that it's updated at least annually.
- Risk assessment methodology and scoring approach
- Risk owner assignment
- Risk treatment options: accept, mitigate, transfer, avoid
- Risk register ownership and update frequency
- Risk acceptance approval process
- Trigger events for out-of-cycle assessments
Security Awareness and Training Policy
Governs the security training program for all staff. Auditors request training completion records — typically screenshots from your LMS or completion reports. If you use an external training vendor, have the completion data exportable and dated.
- Training frequency (typically annual + new hire onboarding)
- Topics covered (phishing, data handling, acceptable use, AI risks)
- Completion tracking and documentation requirements
- Role-specific training for privileged users
- Consequences for non-completion
Asset Management Policy
Defines how company assets — hardware, software, cloud resources, and data — are inventoried, classified, and tracked. In 2026 this must include AI tools and cloud SaaS subscriptions. An asset inventory that's a year out of date is a common audit observation.
- Asset types in scope (hardware, software, cloud, data)
- Asset owner assignment
- Asset inventory update frequency
- End-of-life and decommissioning process
- Hardware return and wipe requirements on offboarding
Data Classification Policy
Defines how data is categorized by sensitivity and what handling rules apply to each tier. This policy is the linchpin for several others — your encryption policy, AUP, and vendor management policy all depend on clear classification tiers to be meaningful.
- Classification tiers (e.g. Public, Internal, Confidential, Restricted)
- Definition and examples of each tier
- Handling rules per tier — storage, transmission, sharing, disposal
- Labeling requirements (if any)
- AI tool input rules per classification tier
The CC6 cluster matters most. Logical and physical access controls (CC6) and system operations (CC7) account for the majority of SOC 2 evidence requests in a typical audit. Policies in these areas need to be precise, current, and matched by operational evidence — logs, access review records, ticket histories, and configuration screenshots.
Find Out Which Policies You're Missing
Our free SOC 2 gap assessment identifies policy gaps alongside control gaps — so you know exactly what to fix before your auditor asks.
Start Free Assessment →Availability TSC — include if you have uptime commitments
Include the Availability TSC if your service commitments, SLAs, or customer contracts make guarantees about uptime or system performance. Most SaaS products should include it. The policies required are focused on resilience and recovery.
Business Continuity Policy
Establishes the organization's approach to maintaining critical business functions during a disruption. Must reference the BCP itself (the actual plan document) — the policy is the governance wrapper around the operational document.
- BCP scope and objectives
- Business impact analysis requirements
- Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO)
- Testing frequency (annual minimum)
- BCP owner and review cadence
Disaster Recovery Policy
Governs the technical recovery of IT systems following a significant outage or data loss event. Auditors request evidence of DR testing — a policy with no tested recovery procedures is commonly flagged. RTO and RPO values must be specific and achievable.
- Defined RTO and RPO for in-scope systems
- Backup frequency, retention, and geographic redundancy
- Backup restoration testing cadence (at minimum annual)
- Failover procedures and documentation
- DR owner and escalation path
Capacity Management Policy
Often overlooked but required for Availability. Defines how you monitor and manage system capacity to ensure service performance. Cloud-native organizations should reference auto-scaling capabilities and the monitoring thresholds that trigger scaling events.
- Capacity monitoring tools and metrics
- Alerting thresholds and escalation process
- Capacity planning review frequency
- Scaling procedures (manual or automated)
Confidentiality TSC — include if you handle confidential customer data
The Confidentiality TSC applies when your service commitments include protecting data designated as confidential by your customers. Most B2B SaaS companies should include it — if your contracts promise to protect customer data, you need this coverage.
Confidential Data Handling Policy
Defines what constitutes confidential information in your service context and how it must be handled. Works in conjunction with your data classification policy — the classification policy defines tiers, this policy defines the handling rules specific to the Confidential tier.
- Definition of confidential data in your service context
- Storage, access, and transmission requirements
- Third-party sharing restrictions and approval process
- Confidentiality obligations for staff (ties to employment agreements)
- Breach escalation requirements
Data Retention and Disposal Policy
Defines how long different categories of data are retained and how they're securely disposed of at end-of-life. Auditors request evidence of actual disposal — media destruction certificates, cloud resource deletion logs, or equivalent. This policy also matters for GDPR compliance if EU data is in scope.
- Retention periods by data category
- Legal hold process that overrides standard retention
- Secure disposal methods — media destruction, crypto-erasure, certified wiping
- Customer data deletion on contract termination
- Disposal documentation and audit trail
Processing Integrity TSC — include if accuracy of processing is a service commitment
Processing Integrity applies when your customers rely on the accuracy, completeness, and timeliness of your data processing. This TSC is most common for financial services, data processing platforms, and any service where processing errors have direct downstream consequences.
Processing Integrity Policy
Establishes controls to ensure data is processed completely, accurately, and in a timely manner. Auditors will test this with evidence of reconciliation procedures, input validation controls, and output monitoring logs.
- Input validation requirements
- Processing completeness monitoring
- Reconciliation procedures and frequency
- Tolerance thresholds for processing errors
- Escalation when anomalies are detected
Error Handling and Correction Policy
Defines how processing errors are detected, documented, escalated, and corrected. For organizations using AI in their processing pipeline, this policy must also address how AI-generated outputs are validated before use.
- Error logging and monitoring requirements
- Error severity classification
- Correction and reprocessing procedures
- Customer notification for errors affecting their data
- Root cause analysis requirements for significant errors
Privacy TSC — include if you collect or process personal data
The Privacy TSC is based on the AICPA's Generally Accepted Privacy Principles and is required if personal information is collected, used, retained, or disclosed in the course of your service. It overlaps significantly with GDPR and CCPA requirements — if you're addressing those regulations, your Privacy TSC policies are largely already there.
Privacy Notice / Privacy Policy
The external-facing document that notifies individuals what personal data you collect, how you use it, who you share it with, and how they can exercise their rights. This is both a legal requirement and a SOC 2 Privacy TSC evidence item.
- Categories of personal data collected
- Purposes for collection and use
- Third parties data is shared with
- Retention periods
- Data subject rights and how to exercise them
- Contact information for privacy inquiries
Personal Data Handling Policy
The internal policy governing how staff handle personal data. Complements the public-facing privacy notice with internal rules and procedures. If you're subject to GDPR, this policy should reference your legal bases for processing.
- Data minimization requirements
- Purpose limitation — data only used for stated purposes
- Cross-border transfer controls
- Processing records (RoPA) maintenance
- Staff handling rules for sensitive categories of personal data
Data Subject Rights Policy
Defines the process for handling data subject requests — access, correction, deletion, portability. Must include response timelines that meet regulatory requirements (GDPR requires 30 days). Auditors request evidence of actual requests handled and response times.
- Rights covered: access, correction, deletion, portability, objection
- Request intake process and verification
- Response timelines (aligned to GDPR/CCPA where applicable)
- Internal fulfillment procedures
- Tracking and documentation of requests
The 4 most commonly missing policies in 2026 audits
These aren't obscure policies — they're ones that organizations consistently fail to have in adequate shape when the auditor arrives.
1. Vendor Management Policy (or a vendor list that's actually maintained)
The Vendor Management Policy is listed above under Security, but it deserves special attention. The most common finding isn't the absence of the policy — it's the absence of a working vendor risk program behind it. The policy says vendors are assessed. The evidence shows a spreadsheet last touched 18 months ago with a handful of vendors on it. Your production stack has 30 more. That's a finding.
Fix: Before your audit, do a real vendor audit. Pull your credit card statements, your AWS Marketplace subscriptions, your GitHub integrations. Build the actual list. Then tier it by risk and document which ones you've assessed.
2. AI Acceptable Use Policy (or AI coverage in the AUP)
As covered in our guide to AI governance controls for SOC 2 and ISO 27001, auditors are now routinely asking whether policies address AI tool usage. Most AUPs written before 2024 are silent on this. The fix is either a standalone AI AUP or an explicit AI section added to the existing AUP covering: approved tools, prohibited data inputs, and accountability for AI-generated outputs.
3. Data Retention and Disposal Policy (or evidence it's followed)
The policy exists. The disposal process doesn't. Auditors ask for evidence that customer data is actually deleted when required — on contract termination, on retention period expiry, on request. Organizations that can't produce deletion records or disposal certificates for decommissioned hardware will receive a finding here.
4. Change Management Policy (or git history that matches it)
The policy says all changes require peer review and testing in staging before production deployment. The git history shows 40 direct pushes to main over the audit period by four different engineers. This mismatch — policy says X, evidence shows Y — is a finding even if your environment has never had an incident. The policy must reflect how you actually operate.
The audit trap: Having policies is necessary but not sufficient. Auditors test whether policies are followed by sampling evidence — tickets, logs, records, screenshots. A policy that exists but isn't practiced is worse than no policy, because it creates a provable gap between what you claim and what you do.
What every SOC 2 policy must include
Regardless of the specific content area, every policy in your SOC 2 program needs these elements to survive auditor review:
| Element | Why auditors care | Common failure mode |
|---|---|---|
| Policy owner | Accountability — someone is responsible for this policy being accurate and enforced | Generic "Security Team" ownership with no named individual |
| Effective date and version | Auditors need to confirm the policy was in effect during the audit period | No version history; can't prove when the policy was adopted |
| Management approval | CC1 (Control Environment) requires top-level commitment — policies must be management-approved | Policies drafted by security team but never formally approved |
| Scope | Auditors need to know what systems, data, and people the policy covers | Scope so broad ("all company systems") that it's meaningless |
| Exception process | Controls that allow no exceptions are unenforceable — having a documented exception process shows maturity | No exception process; policy treated as absolute |
| Review cadence | Policies must be current; annual review with documented evidence is the standard expectation | Policy dated 3 years ago with no evidence of review |
| Staff acknowledgment | Policies distributed but not acknowledged are not effective controls | Policy sent in an email; no acknowledgment tracking |
For organizations pursuing a full SOC 2 compliance program, policies are just one layer of the required documentation. Your policies describe your controls — but auditors also need your System Description, your risk assessment, your vendor inventory, and operational evidence collected throughout the audit period.
If you're deciding between Type I and Type II, policies are evaluated in both — but Type I only assesses whether they're suitably designed, while Type II tests whether they're actually operating. Type II is where policy-practice mismatches surface as findings.
Know Exactly Where Your SOC 2 Gaps Are
Our free assessment covers policy coverage, control implementation, and evidence readiness — so you go into your audit knowing what's solid and what needs work.
Start Free Assessment →Frequently Asked Questions
How many policies do you need for SOC 2?
Most SOC 2 programs require 15 to 25 policies depending on which Trust Services Criteria you include. The Security TSC alone drives roughly 12–15 required policies. Each additional TSC adds 2–4 more. Quality matters more than quantity — auditors evaluate whether policies are implemented and followed, not just whether they exist.
Do SOC 2 policies need to be written in a specific format?
No — there is no required format. What matters is that policies are written, approved by management, distributed to staff, and acknowledged. Each policy should state its purpose, scope, the rules it establishes, roles and responsibilities, and exception handling. A two-page policy that staff actually follow is better than a twenty-page document no one reads.
What is the most commonly missing SOC 2 policy?
Vendor Management Policy and AI Acceptable Use Policy are the two most commonly missing or inadequate policies in 2026 audits. Vendor Management is frequently either absent or so out of date it doesn't reflect the actual vendor stack. AI Acceptable Use is new but increasingly expected — if your staff uses AI tools and your AUP doesn't address it, that's a gap auditors are now flagging.
Can I use downloaded SOC 2 policy templates?
Templates are a useful starting point but must be customized to reflect your actual environment, tools, and processes. Auditors frequently identify policies that were copied from templates without modification — the tell is when a policy references systems, job titles, or processes that don't exist at the organization. The policy must describe what you actually do.
How often do SOC 2 policies need to be reviewed?
Most SOC 2 programs require annual policy review with documented evidence — typically a management-approved review record and updated effective date. Reviews triggered by significant changes (a new product, a major vendor addition, a security incident) should be documented separately. The annual cadence is a minimum; high-risk areas may warrant more frequent review.
Do my SOC 2 policies also satisfy ISO 27001?
Mostly yes, with some additions. ISO 27001 requires a formal ISMS policy structure and documented Annex A controls, which goes beyond SOC 2's policy requirements in a few areas. But if your SOC 2 policy set is solid and your risk register is documented, you have the majority of what ISO 27001 needs. Our guide to ISO 27001 vs SOC 2 covers the gaps and overlaps in detail.