A SOC 2 readiness checklist for a 10-person startup
Decide the report type and scope Security only. Do the fast wins first — enforce MFA everywhere, deploy a password manager, require pull request review, remove stale access. Then write ten policies describing what you actually do. Then start the evidence clock: a first access review, fixed offboarding, a restore test, an incident log, a vendor inventory.
Budget one to three months of readiness, and six to twelve months to a first Type 2 report. The observation window is calendar time and cannot be shortened.
Written for the person who has just been told a deal depends on SOC 2 and has no compliance team, no security engineer, and a product to ship. Nothing here needs a consultant. Most of it is a founder and an afternoon.
Week 1 — decide the shape of it
- Ask the customer which report they accept. Type 1 or Type 2. This one question decides your timeline and can save you an entire audit fee. Most enterprise buyers mean Type 2.
- Scope Security only. Availability, Confidentiality, Processing Integrity and Privacy are optional and permanently expensive. Add one only if a signed contract names it.
- Get three audit quotes. The spread for identical scope is large. A small firm's report is signed by a licensed CPA firm exactly like a big firm's.
- Name one owner. Not a committee. One person who is accountable for the report existing.
Week 2 — the things that are pure win
Do these before writing a single policy. They are fast, they close the most commonly tested gaps, and they are worth doing whether or not you ever get audited.
- Enforce MFA everywhere. Email, code hosting, cloud console, password manager. Not "encouraged" — enforced at the identity provider, with the setting screenshotted.
- Deploy a password manager to everyone and stop credentials living in Slack messages and .env files people email each other.
- Turn on branch protection and require pull request review on anything that reaches production. This satisfies change management almost entirely.
- Remove access nobody needs. The contractor from last year. The founder's personal AWS root key. The shared login three people use.
- Check encryption. Database encryption at rest on, TLS enforced, no plaintext anything.
Week 3–4 — write the policies
Ten documents, each one to three pages, each with an approver and an approval date. Start with Information Security, Access Control, Incident Response and Change Management — those four carry most of the weight.
The rule that matters: describe what you actually do. Every sentence is a control an auditor may test. A template promising quarterly penetration tests will be tested against, and you will fail your own document. What each policy has to contain is here.
Month 2 — start the evidence clock
This is the step teams skip and later cannot fix, because recurring evidence only accumulates forwards.
- Do your first access review now. Export every user from every system, have someone review it, record the date, the reviewer, and what was removed. Imperfect and done beats perfect and later.
- Fix offboarding. A written checklist that ends with access revocation, and a record for each leaver. Auditors compare termination dates to revocation timestamps, and gaps are objectively provable.
- Fix onboarding the same way, including the confidentiality agreement and security training.
- Run one backup restore test. Actually restore something. Write down the date, who did it, and what broke.
- Start an incident log. Empty is fine. Missing is not.
- Inventory your vendors — what data each one touches, a risk rating, an owner — and collect their SOC 2 or ISO reports.
- Turn on vulnerability scanning and, more importantly, keep evidence that findings got fixed.
Month 3 onwards — make it recur
A Type 2 tests operation over time, so what you need now is a cadence rather than a push:
| Cadence | What happens |
|---|---|
| Every quarter | Access review, with a date, a reviewer and the removals recorded |
| Every quarter | Vulnerability scan, and evidence that findings were remediated |
| Annually | Policy review and re-approval, risk assessment, vendor review, restore test, security training |
| Per event | Onboarding and offboarding records, incident write-ups, change approvals |
If these live in somebody's head they will be missed in a busy quarter, and a missed quarter is an exception in the report. This is precisely the work SOC2Starter's recurring tasks and reminders exist to carry.
The five mistakes that cost the most
- Adopting an enterprise policy template unedited. You commit to controls you do not operate and fail against your own document.
- Scoping more criteria than a customer asked for. Permanent recurring cost for no commercial benefit.
- Starting the observation window before the controls work. The window covers whatever was actually happening, including the two months you were still fixing things.
- Leaving evidence to the end. Recurring evidence cannot be backdated, and trying is the one genuinely serious mistake on this list.
- Making it one person's secret project. Offboarding, training and vendor reviews are done by other people. If they do not know, it does not happen.
A realistic schedule
From nothing to a first Type 2 report: 6 to 12 months. Roughly one to three months of readiness work, then a three-to-twelve-month observation window that no amount of money shortens, then two to four weeks of fieldwork and report drafting.
Which is why the answer to "when should we start?" is almost always "before a customer asks", and the second-best answer is today.
Questions people ask
How do I prepare for a SOC 2 audit as a small startup?
Decide the report type and scope Security only, then do the fast wins: enforce MFA everywhere, deploy a password manager, require pull request review, remove stale access and confirm encryption. Next write and approve ten policies describing what you genuinely do. Then start the evidence clock with a first access review, fixed offboarding, a backup restore test, an incident log and a vendor inventory, and put those on a recurring cadence.
How long does SOC 2 readiness take?
One to three months of preparation for a small startup with a focused owner. A Type 1 report follows a few weeks later. A first Type 2 report takes six to twelve months in total, because the observation window is calendar time that cannot be compressed.
What should a startup do first for SOC 2?
Enforce MFA on email, code hosting, the cloud console and your password manager, and capture the enforcement settings as evidence. It is the highest-impact, lowest-effort control, and it is tested in every audit.
Do I need a compliance consultant for SOC 2?
Not usually, at 5 to 50 people with Security-only scope. The work is a defined list, and the auditor is independent of whoever helped you prepare. Consultants earn their fee on complex environments, multiple frameworks, or when nobody internally can own it.
When should a startup start SOC 2?
Before a customer asks, because the Type 2 observation window is calendar time and cannot be bought down. If a deal is already blocked, start now and ask the customer whether a Type 1 unblocks the contract while the Type 2 window runs.
See this against your own company. SOC2Starter turns 19 questions into a personalised list of what you are missing, drafts the policies, and files the evidence against the requirement it proves. Fourteen days free, no card.