For a SOC 2 Type 1 you need written policies for security governance, access, change management, risk assessment, incident response, vendor management, continuity, data handling and people practices. Each must state purpose, scope, owner, the rules, exceptions and review cycle, and it must describe what you really do on the report date.
Why policies matter more in Type 1
A Type 1 report describes the design of your controls at a point in time and carries no opinion on operating effectiveness. A Type 2 covers a period and includes the auditor's tests of whether controls operated. So for Type 1, the auditor reads your policies and procedures and checks that the described controls exist. Weak or fictional policies fail the one thing a Type 1 tests.
The Trust Services Criteria do not hand you a policy list. They set criteria, and CC5.3 expects control activities to be deployed through policies that establish what is expected and procedures that put them into action. The list below is a practical reading, not a mandated set.
The policies, and what each must say
Information security policy (CC5.3, CC1.1 to CC1.5). States management's commitment, who owns security, how responsibilities are assigned and how people are held accountable. Must name the owner, the approval authority and where exceptions go.
Access control policy (CC6.1 to CC6.3). Says how access is requested, approved, changed and removed, with least privilege and role-based rules. Include MFA expectations, a review cadence for access rights, and a removal deadline for leavers. Pick a deadline you can meet.
Change management policy (CC8.1). Describes how changes are authorised, designed, tested, approved and released, including emergency changes and who may approve. Say how code review and separation between author and approver work in your tooling.
Risk assessment policy (CC3.1 to CC3.4). Defines how you identify risks, rate them, decide treatment, consider fraud, and reassess after significant change. Name the cadence and keep the register it produces.
Incident response policy (CC7.3 to CC7.5). Defines what counts as an incident, severity levels, roles, escalation, communication and post incident review. It should describe how security events are evaluated and how recovery happens.
Vulnerability and monitoring procedure (CC7.1, CC7.2). States scan frequency, how findings are rated and the remediation targets you commit to. Choose targets you can evidence, because the report will say what you committed to.
Vendor management policy (CC9.2). Says how you inventory, tier and assess vendors, what you collect (for example their reports or questionnaires) and who owns each relationship.
Business continuity and backup policy (CC9.1, A1.2, A1.3). Covers recovery objectives, backup scope and how recovery plans are tested. Only needed in full if you include Availability.
Data classification and retention policy (C1.1, C1.2). Defines classes, handling rules, retention and disposal. Needed if you include Confidentiality.
Encryption and key management (CC6.1, CC6.7). States what is encrypted at rest and in transit and who manages keys.
People policies (CC1.4, CC6.2). Background checks where lawful, onboarding and offboarding steps, security awareness training, acceptable use and sanctions.
Three rules that save you in the audit
- Policies must match reality. If the policy says quarterly access reviews and you do annual ones, fix the practice or fix the policy before the audit window, and be honest about the change date.
- Every policy needs an owner, an approval date and a version history.
- Employees must be able to find the policies and you must be able to show they acknowledged them.
What to do
- Decide your categories first: Security is required, and Availability, Confidentiality, Processing Integrity and Privacy are optional choices.
- List the policies above that apply and assign an owner for each.
- Draft each from a one page template: purpose, scope, owner, rules, exceptions, review.
- Cross check every rule against a real system setting or process.
- Get management approval and record it.
- Collect employee acknowledgments.
- Put review dates on the calendar.
Quick check
How many policies does SOC 2 require?
The criteria do not set a number. You need enough written policies and procedures to cover the criteria in your scope. Some teams merge several topics into one document.
Can I copy a template?
You can start from one, but every statement must be true for your company. An auditor tests what you do against what you wrote.
How Safeguard helps automate this
Policies are the easy half; proving they are followed is the hard half. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously, leaving your team time for other work. For the change management and vulnerability policies, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests; it is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. The report is issued by an independent auditor, and Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo or book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus), criteria IDs cited above. Paraphrased, not reproduced.
Last reviewed: 18 October 2026.
