Who this is for
This checklist is for founders, CTOs, IT leads and operations managers at small and mid sized companies that are preparing for a first SOC 2 audit. You may already have a security program that works. The gap is usually documentation: approved policies that describe what you do and evidence that people follow them.
It also fits finance and sales teams who field customer security questionnaires. Those questionnaires ask for policy names and dates before the audit starts. A clean policy set shortens the back and forth.
The advice assumes Security is in scope, because that category is always required. If you add Availability, Confidentiality, Privacy or Processing Integrity, you need policies and evidence for those commitments too. The same policy can cover several criteria, so do not write one document per line item.
Before you begin
Collect every policy, procedure and standard you already use, even if it lives in a wiki, a shared drive or an onboarding packet. List the owner, last approval date and where people find it. You will likely find gaps and duplicates, which is normal.
Pick one policy owner for the set, usually the person who runs security or IT. That person keeps the index, schedules reviews and chases approvals. Individual policies still need a named owner who knows the subject.
Decide how policies will be approved and stored. A dated PDF in a read only folder is enough for many auditors. A wiki page with version history also works if you can show who approved each version and when. Set a review cadence before writing, usually once a year and after a major change such as a new cloud provider or a new office.
Separate policy from procedure. Policy states what must happen and who owns it. Procedure or runbook gives step by step instructions. Auditors ask for both, but a policy should not read like a setup guide.
The checklist
Use this list as a coverage check. The names do not have to match exactly, and you can combine topics when the sections stay clear. What matters is that each policy has an owner, an approval date, a review date and a link to the controls it supports.
A small SaaS company might keep access control, acceptable use and asset management in one security handbook. A company that runs its own network will need more detail on physical security, backups and change management. Write for the systems you actually run, not for a generic enterprise.
If Privacy is in scope, add a privacy policy and a public notice that match how you collect, use and delete personal data. If you manage your own encryption keys, add a key management standard. Those documents sit alongside the list below, not instead of it.
- An information security policy that states the program scope, security objectives, named owner, review cadence and the process for approving exceptions.
- An acceptable use policy that covers company laptops, email, internet access, SaaS accounts and the rules for putting customer data in new tools.
- An access control policy that defines account provisioning, role changes, multi factor authentication, password rules, quarterly access reviews and removal of access on the last day.
- A change management policy that requires a ticket, testing, approval and a rollback plan before a production change, with an emergency path for fixes.
- An incident response policy with severity levels, an on call contact list, customer communication steps and a post incident review that produces action items.
- A risk management policy that sets a risk register, a scoring method, treatment choices and a review schedule tied to business changes.
- A vendor management policy that covers due diligence before signing, contract review, a vendor list, annual reassessment and subservice organizations that support your service.
- A backup, business continuity and disaster recovery policy that lists systems covered, backup frequency, encryption, recovery time and recovery point targets, restore tests and test results.
- A data classification, retention and disposal policy with labels for public, internal, confidential and restricted data, plus storage, sharing and deletion rules for each label.
- A human resources security policy that covers onboarding checks where you use them, security training, confidentiality terms and an offboarding checklist.
- A physical security policy for offices and any server rooms, including badge access, visitor logs, alarm checks and reliance on a cloud provider's controls.
- An asset management policy that records hardware, software, data stores and owners, with a process for retiring or losing an asset.
- A logging and monitoring policy that states what is logged, who reviews alerts, how long logs are kept and how clocks are kept in sync.
- A vulnerability and patch management policy with scan frequency, severity based fix windows and a written exception process.
What good looks like
A good policy is short enough that staff can find the rule they need. It names the roles and tools you actually use. It states what must happen and who approves exceptions. It also says how the policy is reviewed. It does not repeat a vendor template with controls you do not run.
Approval and review records matter as much as the text. The auditor will ask who approved the policy, when, and what changed at the last review. Keep old versions so you can show the history. If the policy says annual review, put the date on the document and keep the calendar invite or ticket.
The strongest evidence is operating proof. If the policy requires quarterly access reviews, show the reviews, the reviewer names and the tickets for removed access. If it requires restore tests, show the test date and result. A policy that describes practice is credible. A policy that describes an ideal you cannot show creates findings.
What to do next
Build a policy index with columns for document name, owner, approver, last review, next review and related controls. Mark each item as current, draft or missing. Share it with the people who will approve the work.
Fill the gaps in order of risk and audit impact. Access control, change management and incident response usually come first because they touch daily work and many criteria. Then handle vendor management, backups and the rest of the list. Get each policy approved before you publish it, and collect acknowledgements from staff.
Put review dates on a calendar and assign one person to run the cycle. If you want outside help, one option among others is Cloudverg's SOC 2 readiness assessment at a fixed price of $7,500. It takes three weeks and covers scoping, a gap assessment against the Trust Services Criteria, a policy and evidence inventory and a remediation roadmap. You can also use a consultant, a template library or an internal owner.
Frequently asked questions
Does SOC 2 require a fixed set of policies?
No. SOC 2 does not publish a mandatory policy list. The auditor expects policies that support the Trust Services Criteria in scope, and Security is always in scope. Your set should match the systems and commitments in your report.
How often should SOC 2 policies be reviewed?
At least once a year is the common baseline, and sooner after a major change such as a new cloud platform, a merger or a new office. The policy should state the cadence, and you should keep approval records for each review. If you miss a review, document the reason and complete it before the audit.
Can we use templates for SOC 2 policies?
Yes, as a starting point. Templates save time on structure and headings. Then edit each section to match your tools, roles and actual process, and remove controls you do not run. An approved policy with real evidence beats a long template with no proof.