SOC 2 Policies List: The 19 Core Policies and What Each One Covers

A first SOC 2 audit usually calls for 19 core policies: written rules covering security, access, change, incidents, risk, vendors, data, and people, each approved by management and followed in practice. No AICPA document names a required list of policies (soc2auditors.org). The Trust Services Criteria describe what your controls must achieve, and your policies are where you write down how you achieve it (AICPA).

That is why two companies can pass the same audit with differently named documents. An auditor does not count files. They read each policy, check that it covers the criteria in your scope, and then test whether your team does what the policy says. A policy you do not follow is worse than a missing one, because it turns into an exception in your report.

The list below is the set SimpleAudit drafts for a security-only audit, the scope most first reports use. It maps each policy to the Common Criteria it supports, so you can see why the auditor will ask for it. Smaller teams sometimes combine several of these into one document, and that is fine as long as every topic is covered and the combined document stays readable.

If you are still deciding what kind of report to buy, start with the SOC 2 compliance guide, then come back here when you are ready to write.

Each line gives the policy, what it covers, and the Common Criteria (CC) it supports. The criteria run from CC1, the control environment, to CC9, risk mitigation (BARR Advisory).

1. Information Security Policy: your overall security commitments, who owns the program, and how often each policy is reviewed (CC1.1, CC2.1, CC5.3).
2. Access Control Policy: how accounts are requested, approved, reviewed every quarter, and removed when someone leaves (CC6.1, CC6.2, CC6.3).
3. Change Management Policy: how code and infrastructure changes are reviewed, tested, approved, and deployed (CC8.1).
4. Configuration Management Policy: the approved baseline settings for servers, cloud accounts, and laptops, and how drift from them is caught (CC7.1, CC8.1).
5. Incident Response Policy: how you detect, report, contain, and learn from a security incident, and who does what (CC7.3, CC7.4, CC7.5).
6. Risk Assessment Policy: how often you list and rate risks, who owns each one, and how you decide what to do about it (CC3.1, CC3.2, CC3.4).
7. Vendor Management Policy: how you tier vendors by risk, collect their security reports, and review them each year (CC9.2).
8. Acceptable Use Policy: what staff may and may not do with company devices, accounts, and data (CC2.2, CC5.3).
9. Business Continuity and Disaster Recovery Policy: the commitments behind your two recovery plans, including how much data you can afford to lose and how fast you must be running again (CC7.5, CC9.1).
10. Business Continuity Plan: how the business keeps serving customers when people, offices, or key vendors are unavailable (CC9.1).
11. Disaster Recovery Plan: the steps to restore systems and data after an outage, and how often you test a restore (CC7.5, CC9.1).
12. Code of Conduct Policy: the standards of integrity and behavior every employee and contractor agrees to (CC1.1).
13. Data Classification Policy: the categories of data you hold, such as public, internal, and confidential, and the handling rules for each (CC6.1, CC6.7).
14. Encryption Policy: where data must be encrypted at rest and in transit, the minimum standards, and how keys are managed (CC6.1, CC6.7).
15. Network Security Policy: how networks are segmented, which traffic is allowed in, and how firewalls and remote access are controlled (CC6.6).
16. Physical Security Policy: who can enter offices and equipment areas, and how devices and media are protected and disposed of (CC6.4, CC6.5).
17. Security Awareness Training Policy: the training every person completes at onboarding and each year, and how completion is tracked (CC1.4, CC2.2).
18. Vulnerability Management Policy: how often you scan for weaknesses and how quickly each severity level must be fixed (CC7.1).
19. Data Retention and Disposal Policy: how long you keep each type of data and how you delete it when that time is up (CC6.5).

One policy many teams now add is an AI governance policy, which sets rules for how your product and your staff use AI models and the data sent to them. It is not one of the core 19, but if your product uses AI, expect buyers to ask about it.

Auditors look at policies in two passes. First they read them. They check that each one has an owner, a version, and an approval date from management, and that the approval falls before your audit period starts or, for a Type 1, before the date the report covers. They also check that every employee acknowledged the policies that apply to them, usually when they joined and again each year.

Second, they test whether you do what the policies say. If your access control policy promises quarterly access reviews, the auditor asks for the review record from each quarter in the window. If your change management policy says every change gets a second reviewer, they pull a sample of merged changes and look for the approval on each one. A policy that promises more than you do is the most common way a well-written document turns into an exception.

That second pass is why the best policy is a short, honest one. Write down what your team does today, tighten it where it falls short of the criteria, and leave out promises you cannot keep. In a Type 2 audit, every promise has to hold for the whole audit period, not just on the day you wrote it.

Start from your real environment, not a template written for a bank. A 10-person team on one cloud provider needs a network security policy that describes its cloud firewall rules, not a data center it does not have.

Give every policy the same skeleton: purpose, scope, roles, the rules themselves, how exceptions are approved, and the review schedule. Auditors read dozens of these, and a consistent shape makes yours quick to check.

Name owners by role, not by person, so a departure does not leave a policy without an owner. Set review dates you will meet. Once a year is the norm for most policies, while your risk assessment and access reviews run on their own schedules, which the policies should state.

Keep the evidence in mind as you write. Every rule should point to a record that proves it happened: a ticket, a log, a signed form, a screenshot. If you cannot think of the record, the rule is either too vague or not something you do. The SOC 2 checklist lists the evidence auditors ask for first.

Finally, get management approval and employee acknowledgment before your observation window or Type 1 date. A policy approved halfway through the window covers only half of it. SimpleAudit drafts all 19 policies from your company profile and records approvals and acknowledgments as you go, so the dates are in order when the auditor looks.

Security is the one Trust Services Criterion every SOC 2 report must include (BARR Advisory), so the 19 core policies above are written for it. If a customer contract adds another criterion, add the policies that go with it.

Availability puts more weight on the business continuity and disaster recovery documents you already have, and adds capacity planning and uptime monitoring commitments. Confidentiality leans on data classification and retention, and usually adds rules for how confidential customer data is identified and destroyed when a contract ends. Processing Integrity adds policies for input validation, processing, output, and data storage controls, which matter most when your product calculates or moves money or records. Privacy adds a privacy notice and procedures for consent, access requests, and disclosure to third parties.

For a first report, add none of these unless a customer asks. You can add a criterion at renewal, and the policies you already have will cover much of the ground. For B2B SaaS companies with uptime commitments in their contracts, Availability is the usual first addition.