Free resource
SOC 2 policy templates
15 editable, auditor-aware policy templates — each mapped to the Trust Services Criteria and structured the way an auditor expects (purpose, scope, policy statements, roles, enforcement, review, and acknowledgment). Download the pack, or read every policy in full below.
Read this first. There is no AICPA-mandated policy list — SOC 2 says what must be true and you choose the controls. This is the near-universal core; a template only becomes evidence when its words match how you actually operate, it has an owner and an approval date, and your team has acknowledged it. Pair these with the compliance checklist and the guide on which policies you actually need.
The 15 policies
1. Information Security Policy
CC1.1, CC1.2, CC2.2, CC5.3Establish [Company]'s overall commitment to protecting the confidentiality, integrity, and availability of information, and to serve as the umbrella under which all other security policies sit.
Key policy statements
- Management is committed to protecting information assets and provides the resources needed to operate the security program.
- The security program is owned by [the CISO / Head of Security], who is accountable for its design, operation, and this policy.
- Security objectives are aligned to business objectives and to the SOC 2 Trust Services Criteria the company has elected.
- All personnel must comply with this policy and the supporting policies it references; violations are handled under the Enforcement section.
- This policy and its supporting policies are reviewed at least annually and after any material change to the business or its systems.
2. Access Control Policy
CC6.1, CC6.2, CC6.3Ensure access to [Company] systems and data is granted on a least-privilege basis, reviewed regularly, and removed promptly when no longer required.
Key policy statements
- Access is granted on the principle of least privilege and, where practical, through predefined roles rather than individual grants.
- Every user is assigned a unique account; shared or generic accounts are prohibited except where technically unavoidable and formally approved.
- New access requires the approval of the relevant resource or data owner, recorded through the access-request process, before it is provisioned.
- Access is reviewed at least quarterly by system owners, and any access no longer required is revoked.
- Access is removed within [five] business days of an employee or contractor leaving or changing roles, tracked through the offboarding process.
- Privileged and administrative access is restricted to named individuals, justified, and logged.
3. Password and Authentication Policy
CC6.1Define minimum standards for authentication credentials so that access to [Company] systems is protected against unauthorized use.
Key policy statements
- Passwords must meet minimum length and complexity requirements of at least [12] characters and be unique to [Company] systems.
- Multi-factor authentication (MFA) is required for all remote access, administrative access, email, and the identity provider.
- Passwords must not be shared, written down in plaintext, or reused across systems; a company-approved password manager is provided.
- Where [Company] controls credential storage, passwords are stored using a strong, salted one-way hash and never in plaintext.
- Default vendor credentials must be changed before a system is placed into production.
- Accounts are locked after [ten] consecutive failed authentication attempts.
4. Change Management Policy
CC8.1Ensure changes to [Company] production systems are requested, reviewed, tested, approved, and documented before deployment.
Key policy statements
- Changes to production must be recorded as a change request that captures the change, its purpose, and its risk.
- Changes are peer-reviewed and require approval from an authorized reviewer before being merged or deployed.
- Development, test, and production environments are separated, and changes are tested before reaching production.
- Each change includes a rollback or remediation plan in case of failure.
- Emergency changes may bypass the standard sequence but must be documented and reviewed retrospectively within [two] business days.
- A record of changes is retained to support audit and troubleshooting.
5. Risk Assessment and Management Policy
CC3.1, CC3.2, CC9.1Establish how [Company] identifies, analyzes, treats, and monitors risks to its information and systems.
Key policy statements
- A formal risk assessment is performed at least annually and when significant changes to the business or its systems occur.
- Risks are documented in a risk register and scored by likelihood and impact using a consistent methodology.
- Each risk is assigned an owner and a treatment decision: mitigate, transfer, accept, or avoid.
- Mitigation plans are tracked to completion and reviewed by management.
- The risk assessment considers fraud, vendor, and business-disruption risks in addition to technical threats.
6. Incident Response Policy
CC7.3, CC7.4, CC7.5Define how [Company] detects, reports, responds to, contains, and learns from security incidents.
Key policy statements
- Personnel must report suspected security incidents immediately, and no later than [24] hours after discovery, through the defined channel.
- Incidents are triaged and assigned a severity that determines response time and escalation.
- The incident response team follows defined steps to contain, eradicate, and recover from incidents, preserving evidence throughout.
- Affected customers, regulators, and other parties are notified in line with contractual and legal breach-notification requirements.
- A post-incident review is conducted after significant incidents to capture root cause and corrective actions.
- The incident response plan is tested at least annually through a tabletop exercise or a real incident retrospective.
7. Vendor and Third-Party Management Policy
CC9.2Manage the security risk introduced by vendors and subservice organizations that access or process [Company] data.
Key policy statements
- A vendor inventory is maintained that records each vendor, the data it accesses, and its risk tier.
- Before onboarding, critical vendors undergo security due diligence, such as review of their SOC 2 report or a security questionnaire.
- Contracts with vendors that handle sensitive data include appropriate security and data-processing terms.
- Critical vendors are re-reviewed at least annually or when their risk profile changes.
- Vendor access is removed promptly when a relationship ends.
8. Business Continuity and Disaster Recovery Policy
CC7.5, A1.2, A1.3Ensure [Company] can maintain critical operations during a disruption and recover systems and data after a disaster.
Key policy statements
- Critical business functions are identified along with their recovery time objectives (RTO) and recovery point objectives (RPO).
- Data is backed up on a defined schedule, encrypted, and stored so that a single failure cannot destroy both primary and backup copies.
- Backup restoration and disaster-recovery procedures are tested at least annually, and results are documented.
- A communication plan defines how personnel and customers are informed during a disruption.
- Roles and responsibilities for continuity and recovery are assigned and kept current.
9. Data Classification Policy
CC3.2, CC6.1Define how [Company] classifies data by sensitivity so that protection is applied in proportion to risk.
Key policy statements
- Data is classified into defined tiers, for example Public, Internal, Confidential, and Restricted.
- Handling, storage, transmission, and disposal requirements are defined for each classification tier.
- Data owners are responsible for classifying their data and ensuring it is handled accordingly.
- Confidential and Restricted data must be encrypted in transit and at rest.
- Classification is considered when granting access, so that more sensitive data receives tighter controls.
10. Data Retention and Disposal Policy
CC6.5Define how long [Company] retains data and how it is securely disposed of when no longer required.
Key policy statements
- Retention periods are defined by data type based on business need and legal or regulatory requirements.
- Data that has reached the end of its retention period is securely disposed of unless subject to a legal hold.
- Disposal uses methods appropriate to the media, such as cryptographic erasure, secure deletion, or physical destruction.
- Logical and physical protections over data are discontinued only through this controlled disposal process.
- Evidence of secure disposal is retained where practical.
11. Encryption and Cryptography Policy
CC6.1, CC6.7Define where and how [Company] uses encryption to protect data in transit and at rest.
Key policy statements
- Data in transit over public or untrusted networks is encrypted using current TLS versions and strong cipher suites.
- Confidential and Restricted data at rest is encrypted using industry-standard algorithms and key lengths.
- Deprecated or weak algorithms and protocols must not be used.
- Cryptographic keys are stored securely, access to them is restricted, and they are rotated on a defined schedule.
- Exceptions to encryption requirements must be formally approved and risk-assessed.
12. Logging and Monitoring Policy
CC7.1, CC7.2Define what [Company] logs, how logs are protected and retained, and how they are monitored to detect issues.
Key policy statements
- Security-relevant events, including authentication, access changes, and administrative actions, are logged.
- Logs are centralized, protected against tampering, and retained for at least [one year] or as required by contract.
- System clocks are synchronized to a common time source so that events can be correlated.
- Alerts are configured for defined security conditions and are reviewed and actioned by [Security].
- Monitoring coverage is reviewed periodically to confirm it still reflects the environment.
13. Acceptable Use Policy
CC1.1, CC6.7Define the acceptable use of [Company] systems, networks, devices, and data by personnel.
Key policy statements
- Company systems and data are used for legitimate business purposes and in compliance with law and company policy.
- Users must protect their devices and credentials, lock unattended screens, and not disable security controls.
- Only sanctioned services and approved removable media may be used to store or transfer company data.
- Personnel are notified that use of company systems may be monitored to the extent permitted by law.
- Personal use, if permitted, must not interfere with work or introduce undue risk.
14. Vulnerability Management Policy
CC4.1, CC7.1Ensure vulnerabilities in [Company] systems are identified, prioritized, and remediated in a timely manner.
Key policy statements
- Vulnerability scanning is performed on a defined schedule against production systems and endpoints.
- Identified vulnerabilities are prioritized by severity and remediated within defined SLAs, for example critical within [30] days.
- A penetration test is performed at least annually, and findings are tracked to remediation.
- Operating systems and software are patched on a defined cadence.
- Remediation is tracked to closure and reported to management.
15. Human Resources Security Policy
CC1.4Embed security across the employment lifecycle, from hiring through termination.
Key policy statements
- Background checks are performed on new hires where legally permitted and appropriate to the role.
- Personnel sign confidentiality or non-disclosure agreements before accessing sensitive data.
- Security awareness training is completed by new hires and refreshed at least annually and when policies change.
- A disciplinary process addresses violations of security policy.
- Onboarding and offboarding follow the Access Control Policy so that access is granted and removed appropriately.
What auditors flag on policies
The templates handle structure; these are the mistakes that turn a policy into an audit exception regardless of how it is written:
- Policies that exist but nobody follows — auditors catch this in walkthroughs when staff can't describe the process. The words must match what you actually do.
- No review date or a stale policy. Auditors expect review at least annually and after material changes.
- No named owner or approval. Every policy needs an accountable owner and a management sign-off with a date.
- No employee acknowledgment or training records — no proof people read and accepted the policy.
- Generic copy-paste describing controls you don't actually run. A template is a first draft, not evidence.
Frequently asked questions
Are these SOC 2 policy templates free?
Yes — download the Word or Markdown pack with no signup or email required. They're editable starting templates you adapt to your company.
How many policies do I need for SOC 2?
There is no AICPA-mandated policy list. This pack covers the 15 near-universal policies most auditors expect for the Security (Common Criteria) scope. You add situational policies — Privacy, Confidentiality, Processing Integrity, Availability, SDLC, physical/datacenter, remote access — based on which Trust Services Criteria you elect and how you operate.
Can I just use these templates as-is to pass my audit?
No. A SOC 2 auditor tests whether your controls operate as written, so every template must be edited to reflect your real practice, given an owner and approval, and acknowledged by staff. A policy you don't follow becomes an audit exception.
Do these count as legal advice?
No. These are practical starting templates, not legal advice. For contractual, regulatory, or privacy-law obligations, have counsel review your final policies.
Policies drafted? Get matched with three auditors.
Tell us your stage, framework, and timeline once. We match you with three firms that fit — one short call, not five sales pitches.
Free for buyers · No spam · Independent of every firm listed