The first five security policies a startup needs before SOC 2

A customer asks for your security policies, or an auditor asks what you have written down, or you decide to start on SOC 2 and do not know where to begin. The answer is the same each time: write the policies first. This guide covers why, which five to write, what makes a policy “tailored” and not just a template with your name pasted in, and how the SOC 2 criteria relate to all of it.

Why policies come first

A policy is where a company says, in writing, what it requires of itself. Everything else in a security program is measured against that statement. Access reviews, incident tickets, and training records only mean something once you have said what should happen.

The SOC 2 criteria say something similar. As we read them, criterion CC5.3 ties controls to writing in two layers: policies set the standard, and procedures say how the work gets done. An examiner testing your controls needs something to test them against, and the policy is usually it. Two other things push the same way:

• Buyers ask. Vendor security questionnaires commonly ask which policies you have, who owns them, and when each was last reviewed. A missing policy is a visible gap, and it is one of the cheapest to close.
• Later work depends on them. You cannot show that a quarterly access review happens until a policy sets the quarter, the reviewer, and the record. The policy comes first, and the evidence follows from it.

The five core policies

There is no official list of five. This is the set we would write first, because each one answers a question that buyers and auditors ask early, and the later policies build on them.

1. Information Security Policy

The master document. It sets who owns security, how you assess risk, how you manage assets and personnel, and how often you review the whole set. The other four hang off it. If you write only one this month, write this one.

2. Access Control Policy

Who gets access to what, and how it is granted, reviewed, and removed. It should state your real rules: multi-factor authentication, least privilege, how quickly a departing employee’s access ends, and how often someone reviews who has access. The criteria in this area include CC6.1 through CC6.3.

3. Incident Response Policy

What happens when something goes wrong: how staff report a problem, how you rank its severity, who leads, when customers are told, and how you review it afterward. The matching criteria are CC7.3 through CC7.5. A company that has never had an incident still needs this one, because the first incident is a bad moment to be inventing a process. Our guide to an incident response plan a five-person team will follow covers the plan that goes with it.

4. Acceptable Use Policy

What every employee and contractor agrees to when they use company devices and accounts: disk encryption, screen locks, personal devices, remote work, and increasingly which AI tools may touch company data. It is the policy people actually read, so it should be short and specific.

5. Data Classification Policy

The tiers your data falls into, and the handling rules for each: storage, encryption, sharing, retention, and disposal. It gives every other policy something to point to when it says “confidential data.” It also supports the criteria on confidential information (C1.1) if you include that category in a SOC 2 scope.

What “tailored” means, and what a template is

A template is a starting point, and there is nothing wrong with starting from one. The trouble comes when a company adopts one unchanged. A generic policy promises things you do not do: quarterly access reviews when you have never run one, a security team when you have three engineers, a tool you have never bought. That creates a problem worse than having no policy, because now your own document contradicts how you run.

A tailored policy is one you can follow on Monday. In practice:

• It names your actual systems: your identity provider, cloud provider, logging tool, ticketing tool, and the place people report incidents.
• Its roles are the roles you have. At fifteen people, the same person may own three of them, and the policy should say so.
• Its numbers are ones you will meet: the review interval, the deprovisioning window, the response target tied to the hours you really cover.
• Sections that do not apply are removed, not left in as promises.
• It agrees with your questionnaire answers and your privacy notice, because a reviewer can lay them side by side.

We start from a written scaffold. The work is the fitting: your stack in, the false promises out, and every statement checked against what you can do today.

How the Trust Services Criteria fit in

The Trust Services Criteria are published by the AICPA, the American Institute of CPAs. Its Assurance Services Executive Committee set them as a yardstick for how well an organization protects its information and systems, and they come in five categories: security, availability, processing integrity, confidentiality, and privacy. The current version dates from 2017, with points of focus revised in 2022.

The common criteria (CC1 to CC9) apply to all five categories, and they are all the Security category needs. Which categories go in scope is a decision for you, your customers, and the CPA firm.

Two things to know about how the criteria relate to policies:

• The criteria are outcomes, not a document list. They do not say “write these five policies.” They say what your controls must achieve, and policies are the usual way to show what you decided. The AICPA calls the points of focus “important characteristics of the criteria”, says they may be customized, and says that using the criteria does not mean assessing every one of them. In our reading, that makes them not a checklist.
• Mapping is many-to-many. One policy supports several criteria, and one criterion may rest on several policies. Citing the criteria inside each policy makes the link visible to a reviewer.

What policies do not do

Policies are one part of SOC 2 readiness. An independent CPA firm examines your controls and issues any SOC 2 report, and it tests whether you do what you wrote. Blank Slate does readiness and documentation only. We do not perform audits or attestations, and no policy set can promise that an examiner or a customer will approve it. Nothing here is legal advice.

A sensible order for this week

1. Write down the facts first: identity provider, cloud provider, device rules, logging, and where incidents get reported.
2. Draft the Information Security Policy, then Access Control and Incident Response.
3. Add Acceptable Use and Data Classification, and give every policy an owner and a review date.
4. Read each one against how the company runs. Change the policy or change the practice, but do not leave a gap between them.

If you would rather hand it off

Blank Slate Creative, LLC writes these five policies for you.

• Tailored to your stack. We ask about 35 intake questions on your tools, team, and hours (10 to 15 minutes), and write to that.
• Criteria references included. Policy sections cite the SOC 2 criteria they support.
• Delivered as Markdown, Word, and PDF. The core five-policy set is scoped for three business days after the day a complete intake arrives.
• A flat fee, $85, published up front. Order the five policies, $85.
• See it first. The home page has two full sample policies, written for a fictional company. We have no client work to show yet, and would rather say so.

Sources

All read on 2026-09-30.

• AICPA & CIMA, 2017 Trust Services Criteria (With Revised Points of Focus – 2022) (the five categories, what the criteria are for, and the 2022 revision to the points of focus). The download needs a free AICPA account. We have read this edition. We quote none of the points of focus and make no claim about specific ones.