The SOC 2 Policy Checklist: 15 Policies Every Company Needs

Why Policies Are the Foundation of SOC 2

SOC 2 auditors evaluate your controls against the Trust Services Criteria, and controls start with policies. A policy defines what your organization commits to doing. A control is the mechanism that enforces or implements that commitment. Without written policies, there is no baseline for the auditor to evaluate — and no way to demonstrate that your team knows what is expected.

Policies must be formally approved, communicated to all relevant personnel, and reviewed at least annually. Auditors will check approval dates, distribution records, and review history. A policy that was written two years ago and never updated is almost as bad as having no policy at all.

The 15 Essential Policies

The following policies cover the Trust Services Criteria that most SOC 2 audits assess. Depending on your scope, you may need additional policies, but these fifteen form the baseline that auditors expect to see.

• Information Security Policy — The overarching policy that establishes your security program, defines roles and responsibilities, and sets the tone for all other policies.
• Acceptable Use Policy — Rules for how employees may use company systems, devices, and data. Covers personal use, prohibited activities, and consequences for violations.
• Access Control Policy — Defines how access is granted, reviewed, and revoked. Covers least privilege, role-based access, and segregation of duties.
• Password Policy — Minimum complexity requirements, rotation schedules (if applicable), MFA requirements, and rules for password storage and sharing.
• Change Management Policy — How changes to production systems are requested, reviewed, approved, tested, and deployed. Covers emergency changes and rollback procedures.
• Incident Response Policy — Procedures for detecting, reporting, responding to, and recovering from security incidents. Includes severity classifications and escalation paths.
• Data Classification Policy — Categories for data sensitivity (public, internal, confidential, restricted) and handling requirements for each classification level.
• Data Retention Policy — How long different categories of data are retained, when and how data is destroyed, and legal or regulatory retention requirements.
• Encryption Policy — Requirements for encryption at rest and in transit, approved algorithms and key lengths, and key management procedures.
• Vendor Management Policy — How third-party vendors are evaluated, approved, monitored, and offboarded. Covers due diligence, contractual requirements, and ongoing risk assessment.
• Business Continuity Policy — Plans for maintaining operations during disruptions, including disaster recovery procedures, backup strategies, and recovery time objectives.
• Risk Assessment Policy — Methodology for identifying, evaluating, and treating information security risks. Covers risk registers, assessment frequency, and risk acceptance criteria.
• Remote Work Policy — Security requirements for employees working outside the office, including device security, network requirements, and physical workspace controls.
• Security Training Policy — Requirements for security awareness training, including frequency, content, completion tracking, and role-specific training for developers and administrators.
• Privacy Policy — How personal data is collected, used, stored, and shared. Covers data subject rights, consent mechanisms, and regulatory compliance requirements.

Tips for Writing Policies Auditors Will Accept

Write policies that reflect what you actually do, not what you aspire to do. Auditors test controls against policies — if your policy says you conduct monthly vulnerability scans but you actually scan quarterly, that is a finding. It is better to have a policy that commits to quarterly scans and actually does them than a policy that promises monthly scans you cannot deliver.

Every policy should include: a purpose statement, scope definition, roles and responsibilities, the actual policy requirements, exception process, enforcement provisions, and a version history with approval dates. Keep language clear and specific. Avoid vague commitments like "we will use reasonable security measures." Instead, specify exactly what measures you use.

Review and re-approve every policy at least once per year. Auditors check the approval date, and a policy last approved eighteen months ago is a finding. Schedule annual policy reviews in your calendar and treat them as a recurring compliance task.

Using AuditKit's Pre-Built Policy Templates

AuditKit provides professionally drafted templates for all fifteen policies. Each template is written in plain language, mapped to the relevant Trust Services Criteria, and includes placeholders for company-specific details. You customize the template to match your actual operations, get it approved by leadership, and distribute it to your team.

The templates save weeks of drafting time and ensure you do not miss critical sections that auditors expect. They are regularly updated to reflect current best practices and auditor expectations. Combined with AuditKit's policy management features — version control, approval tracking, and distribution records — you have everything you need to satisfy the policy requirements of your SOC 2 audit.

Key Takeaways

• Fifteen policies form the baseline that SOC 2 auditors expect — from Information Security to Privacy.
• Write policies that match your actual operations, not aspirational goals.
• Every policy needs purpose, scope, roles, requirements, exceptions, enforcement, and version history.
• Review and re-approve all policies at least annually — stale policies are audit findings.
• AuditKit's pre-built templates save weeks of drafting and are mapped to Trust Services Criteria.