SOC 2 Policies and Procedures: The Complete List for Small Companies

SOC 2 policies and procedures describe how your company protects customer data, and auditors test that you follow them. The AICPA does not publish a fixed list, but almost every SOC 2 audit expects the same core set of policies. This guide lists the policies a small company needs, maps each one to the Trust Services Criteria, and explains how to write policies that pass the audit.

Related guides: How to prepare for a SOC 2 audit · SOC 2 Trust Services Criteria · Free incident response plan template

Key takeaways

• SOC 2 does not prescribe exact policies, but auditors expect a core set of around 15 to 20 covering security, access, change, incidents, vendors, continuity and people.
• Policies state what you require. Procedures describe how you do it. Auditors test both against your actual practice.
• Each policy needs an owner, leadership approval, an annual review and staff acknowledgment.
• Short, accurate policies beat long templates nobody follows. A policy you do not follow causes an exception.

---

Policies vs procedures

A policy is a short statement of what the company requires, for example "All access to production systems requires MFA." A procedure explains how that is done: which tool, who approves, and what is recorded. Small companies often combine them in one document per topic, which is fine as long as both parts are clear.

The complete SOC 2 policy list

Policy	What it covers	Main criteria
Information security policy	Overall security program, roles, management commitment	CC1, CC2, CC5
Acceptable use policy	How staff may use devices, systems and data	CC1, CC5
Access control policy	Account provisioning, MFA, least privilege, access reviews	CC6
Password and authentication policy	Password rules, MFA, credential storage	CC6
Change management policy	Code review, testing, approvals, emergency changes	CC8
Incident response plan	Detection, response, communication, postmortems	CC7
Risk management policy	Risk assessment method, risk appetite, treatment	CC3, CC9
Vendor management policy	Vendor inventory, risk tiers, reviews, contracts	CC9
Business continuity and disaster recovery plan	Recovery objectives, backups, testing	A1, CC9
Data classification and handling policy	Data categories and how each is protected	C1, CC6
Data retention and disposal policy	How long data is kept and how it is destroyed	C1, P4
Encryption policy	Encryption at rest and in transit, key management	CC6
Logging and monitoring policy	What is logged, retention, alerting and review	CC7
Vulnerability management policy	Scanning, patching timelines, penetration testing	CC7
Asset management policy	Inventory of devices, systems and software	CC6
Secure development policy	Secure coding, dependency management, testing	CC8
Human resources security policy	Background checks, onboarding, training, offboarding	CC1
Physical security policy	Office access, visitors, equipment (lighter for remote teams)	CC6
Code of conduct	Ethics and expected behavior	CC1

If you include Privacy in scope, add a privacy policy and procedures covering notice, consent, data subject requests and disclosure.

What auditors check in your policies

1. Approval: signed or recorded approval by leadership, with a date.
2. Annual review: evidence the policy was reviewed in the last 12 months.
3. Communication: staff acknowledged the policies, usually at onboarding and once a year.
4. Consistency: the policy matches what you actually do. If it says access reviews are quarterly, the auditor samples quarterly reviews.
5. Coverage: every control in your system description is supported by a policy.

How to write SOC 2 policies that pass

• Start from your real process. Describe what you do today, then tighten it where needed.
• Use measurable commitments. "Critical vulnerabilities are remediated within 15 days" is testable. "Vulnerabilities are fixed promptly" is not.
• Keep them short. Two to four pages per policy is enough for most small companies.
• Name roles, not people. "The Head of Engineering approves production access" survives staff changes.
• Avoid copying templates blindly. Template promises you do not keep become exceptions.
• Version control them. Keep a change history so you can show what applied during the audit period.

Policy management through the year

When	Task
Onboarding	New staff read and acknowledge the policies
Quarterly	Check that procedures still match practice
Annually	Review, update and re-approve every policy; staff re-acknowledge
After major changes	Update affected policies, such as after a new cloud provider or an incident

Sample policy statements

Clear, testable statements make audits easier. Here are examples you can adapt:

Policy	Sample statement
Access control	Access to production systems requires single sign-on with MFA and is granted on a least-privilege basis with documented approval.
Access reviews	Owners review user access to in-scope systems every quarter and remove access that is no longer required within five business days.
Offboarding	All system access is revoked on or before an employee's last working day.
Change management	Every change to production code requires a pull request approved by at least one other engineer and passing automated tests.
Vulnerability management	Critical vulnerabilities are remediated within 15 days and high vulnerabilities within 30 days of detection.
Incident response	Security incidents are logged, triaged within one business day, and reviewed in a postmortem when rated high or critical.
Vendor management	Vendors that process customer data are risk-rated before onboarding and reviewed at least annually.
Backups	Production databases are backed up daily, and a restore is tested at least once a year.

Each statement names a requirement, a timeframe or frequency, and something the auditor can sample.

Reusing SOC 2 policies for other frameworks

Most SOC 2 policies also satisfy ISO 27001, HIPAA and GDPR requirements with small additions. ISO 27001 needs a few extra documents, such as the Statement of Applicability and the ISMS scope, and HIPAA needs specific sections on protected health information and business associate agreements. Writing policies once and mapping them through a common control framework avoids maintaining several versions of the same document. Our guide to ISO 27001 mandatory documents lists the extras.

Common policy mistakes

• Policies copied from a large enterprise template, promising controls a small team cannot run
• No evidence of annual review or leadership approval
• Staff who joined during the audit period never acknowledged the policies
• Different documents giving different timeframes for the same control
• Procedures that name former employees as approvers

How SecureSlate helps

SecureSlate includes a library of SOC 2 policy templates written for small companies, tracks approvals and annual reviews, and collects staff acknowledgments automatically as audit evidence.

FAQ

How many policies do you need for SOC 2?

Most small companies have 15 to 20 policies, though some combine related topics into fewer documents. The number matters less than covering every control area.

Does SOC 2 require specific policies?

No. The Trust Services Criteria do not list required policies, but auditors expect documented policies supporting each area of the criteria you include.

How often should SOC 2 policies be reviewed?

At least once a year, and whenever a significant change affects them. Keep a record of each review and approval.

Can we use policy templates for SOC 2?

Yes, as a starting point. Edit them so they describe what your company actually does, because the auditor tests your practice against the policy.

---

Who should approve SOC 2 policies?

A member of leadership with authority over the area, often the CEO or CTO for the information security policy, with approval recorded and dated.

Do contractors need to acknowledge SOC 2 policies?

Yes, if they have access to in-scope systems or data. Auditors often sample contractors as well as employees.

Can one document contain several SOC 2 policies?

Yes. Small companies often combine related topics, such as access control and passwords, in one document. Make sure each topic is clearly covered and easy for the auditor to find.

What happens if a policy is out of date during the audit?

The auditor may record an exception for the annual review control. Update and re-approve the policy, and make sure staff acknowledge the new version.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.