The 20 Policies You Need for SOC 2 (and What Goes in Each)

For SOC 2, most SaaS and service companies need about 20 written policies covering governance, access, data protection, engineering, operations, resilience, vendors and people. The Trust Services Criteria do not publish a mandatory list. Auditors expect approved, communicated policies behind every control they test, and they test against what those policies say.

Key facts

• The AICPA criteria describe outcomes, not a policy list; 15 to 20 policies is typical for a first SOC 2.
• Security (CC1 to CC9, 33 criteria) drives most policy content; Availability, Confidentiality and Privacy add specific requirements.
• Auditors check approval, communication, review frequency and consistency with practice.
• Criteria IDs below are our typical mapping; your auditor may map some differently.

Does SOC 2 require specific policies?

No. SOC 2 requires that controls exist and operate, and written policies are how you show they are designed, assigned and communicated. The list below reflects what auditors commonly expect to see for a typical cloud software company.

You can merge policies if that suits your size. What matters is that the content is complete, approved and true. If you later add Confidentiality or Privacy, you extend existing policies rather than starting over.

Criteria IDs in this article refer to the AICPA Trust Services Criteria. The descriptions are our own summaries, not AICPA text.

Which governance policies does SOC 2 need?

Governance policies set tone, ownership and risk method. They cover the COSO-based criteria CC1 to CC5 that many engineering-led teams underestimate.

• 01 Information Security Policy (CC1.1, CC1.3, CC2.2, CC5.3): the umbrella document. Security objectives, who owns what, how policies are approved and reviewed, and how exceptions are granted.
• 14 Risk Management Policy (CC3.1 to CC3.4, CC9.1): how you identify, score and treat risk, including fraud risk and risks from significant change, and how often you repeat the assessment.
• 20 Code of Conduct (CC1.1, CC1.5): ethics, conflicts of interest, how to raise concerns without retaliation and the consequences of breaches.

Which access and asset policies does SOC 2 need?

Access and asset policies explain who can reach what and how you know what you own. They support CC6, the most heavily tested series in many audits.

• 02 Access Control Policy (CC6.1 to CC6.4): joiners, movers and leavers, least privilege, MFA, privileged access, access review frequency and physical access to offices or equipment.
• 03 Acceptable Use Policy (CC1.1, CC2.2, CC6.8): what staff may and may not do with company devices, accounts, software and data, including installing unapproved software.
• 04 Asset Management Policy (CC6.1, CC6.5): inventory of devices, systems and data stores, asset owners, and secure wiping or destruction at end of life.

Which data protection policies does SOC 2 need?

Data protection policies define how sensitive information is labelled, protected, kept and destroyed. They matter most if you add the Confidentiality or Privacy categories.

• 07 Data Classification and Handling Policy (CC6.1, CC6.7, C1.1): three or four classes, such as public, internal, confidential and restricted, with storage, sharing and transfer rules for each.
• 08 Data Retention and Disposal Policy (CC6.5, C1.2, P4.2, P4.3): retention periods by data type, customer deletion requests and how deletion is confirmed.
• 09 Encryption and Key Management Policy (CC6.1, CC6.7): encryption at rest and in transit, approved algorithms and protocols, and who manages and rotates keys.

Which engineering and operations policies does SOC 2 need?

Engineering and operations policies govern how code and infrastructure change, and how you watch for trouble. CC7 and CC8 evidence comes straight from these.

• 05 Change Management Policy (CC8.1, CC5.2): how changes are requested, reviewed, tested, approved, deployed and rolled back, including emergency changes.
• 06 Secure Software Development Policy (CC8.1, CC7.1): secure design, peer review, dependency and secret scanning, and separation of development, test and production.
• 17 Logging and Monitoring Policy (CC7.2, CC7.3, CC4.1): what is logged, how long logs are kept, which alerts exist and who reviews them.
• 18 Vulnerability and Patch Management Policy (CC7.1, CC6.8, CC4.1): scanning scope and frequency, severity ratings, fix deadlines and penetration testing.
• 19 Network and Cloud Security Policy (CC6.1, CC6.6, CC6.7): network segmentation, firewall and security group rules, secure cloud configuration and remote access.

Which resilience policies does SOC 2 need?

Resilience policies describe how you respond to incidents and recover from outages. They are essential if you add the Availability category.

• 10 Incident Response Policy (CC7.3 to CC7.5, CC2.3): definitions, severity levels, response roles, customer and regulator notification, and post-incident reviews.
• 11 Business Continuity and Disaster Recovery Policy (CC7.5, CC9.1, A1.2, A1.3): recovery time and recovery point objectives, recovery plans and an annual test.
• 12 Backup Policy (A1.2, A1.3): what is backed up, how often, where copies are stored, how they are protected and how restores are tested.

Which vendor and people policies does SOC 2 need?

Vendor and people policies cover the humans and suppliers who can affect your security. Auditors often sample HR records against these.

• 13 Vendor and Third-Party Management Policy (CC9.2, CC2.3): vendor inventory, risk tiers, due diligence, security terms in contracts and annual review of critical vendors' reports.
• 15 HR Security Policy (CC1.1, CC1.4, CC1.5): background checks, confidentiality agreements, onboarding and offboarding steps, and disciplinary process.
• 16 Security Awareness and Training Policy (CC1.4, CC2.2): training at hire and annually, phishing awareness, role-specific training for engineers and completion records.

What should every SOC 2 policy contain?

Every policy needs the same core elements so an auditor can see who owns it, what it requires and how you know it is followed.

Element	Why auditors care
Purpose and scope	Shows which systems, people and data the rules apply to
Roles and owner	Links the control to an accountable person (CC1.3)
Requirements with frequencies	Defines what the auditor will test and how often
Exceptions process	Shows deviations are approved and tracked
Enforcement	Shows the policy has consequences
Approval, version and review date	Proves management approval and periodic review

How do you roll out SOC 2 policies?

Roll policies out in a fixed sequence: tailor, check against practice, approve, publish, acknowledge and schedule the review. Skipping the check against practice is where most problems start.

1. Tailor: replace placeholders, name owners and delete anything that does not apply.
2. Reality check: walk each "must" past the person who does the work and confirm it is true today, or set a start date.
3. Align with the control matrix: make sure every frequency and owner in the policy matches the matrix.
4. Approve: record the approver, date and version 1.0.
5. Publish: put policies where staff actually look, such as the company wiki.
6. Acknowledge: collect sign-offs from every employee and contractor with access.
7. Schedule review: add an annual review date to your evidence calendar.

Which SOC 2 policies can a small company combine?

A company of a few people can merge related policies as long as no required content is lost. Common combinations are Backup inside Business Continuity and DR, Encryption inside Data Classification, and Acceptable Use inside the Information Security Policy.

Keep Access Control, Change Management, Incident Response, Vendor Management and Risk Management as standalone documents. Auditors test them heavily, and a separate document with a named owner makes responsibility obvious. Fewer, longer documents are fine; missing topics are not.

How long should a SOC 2 policy be?

As long as it needs to be clear and testable, and no longer. Most work well at a few pages. Put step-by-step instructions in procedures or runbooks so the policy stays stable when a tool changes. A policy that tries to be a manual goes out of date the first time you switch tools, and outdated detail invites auditor questions.

What are the most common SOC 2 policy mistakes?

• Frequencies you cannot meet. "Monthly access reviews" turns every missed month into an exception. Quarterly and done beats monthly and missed.
• Tools that do not exist. Policies naming a system you replaced last year confuse auditors.
• No acknowledgments. Unread policies do not meet the communication criteria.
• Never reviewed. A policy dated three years ago signals an inactive program.
• One owner for everything. If the CTO owns all 20 policies, reviews slip. Give each policy to the person who runs that area.

If you want the full set ready to tailor, the SOC 2 Policy Templates Pack ($129) contains all 20 in editable Word. See the policy templates overview for the mapping table and a two-week adoption plan, or the SOC 2 guide for the wider picture. Templates help you prepare; they do not guarantee a clean report.

Last reviewed: 29 September 2026