The order of operations most small teams should follow, from scoping to evidence, without buying a five-figure platform first.
Most first SOC 2 conversations go wrong in the same place: a small team hears the words "SOC 2 Type 1" in a procurement email and starts googling compliance platforms before it has decided what the audit will even cover.
A Type 1 report is a point-in-time look at whether your controls are designed correctly. That makes it the more approachable first audit for a young SaaS. You are not yet proving months of operating history, you are proving the controls exist and make sense on a specific date. It still takes real work, but it is bounded work, and bounded work is something a team of five to twenty people can actually do.
Here is the checklist, in the order that avoids rework.
Confirm with the customer or prospect whether Type 1 is acceptable. Some contracts demand Type 2 with a defined observation window; a Type 1 report will not satisfy those, and no amount of prep changes that.
If Type 1 works, pick your "as of" date. Everything in the report describes your controls as they exist on that date. Working backward from a date gives you a deadline, which is worth more than any project management tool.
A Type 1 audit reports against the trust services criteria. The five categories are security, availability, processing integrity, confidentiality, and privacy. Security is mandatory; the rest are optional.
Small SaaS teams should almost always start with security only. Every additional category multiplies the controls, the evidence, and the audit fee. Availability in particular requires real commitments around monitoring and incident response that many small teams cannot yet evidence honestly.
Scope the system description to what you actually run: your production cloud account, your code repository, your identity provider, and the application itself. Do not include systems nobody asked about. Smaller scope, faster audit, lower bill.
Auditors do not need a policy library the size of a phone book. They need short documents that match reality. The core set for a security-only Type 1 usually looks like this:
The common failure mode is writing aspirational policies. If the document says quarterly access reviews but nobody has ever run one, the auditor will find the mismatch in an afternoon. Write what you do, then do what you wrote.
Every control in your matrix needs a named owner. In a small team this usually means a handful of people wear several hats, and that is fine. What is not fine is a control matrix where the owner column says "engineering" as a department.
Owners are the people the auditor will interview. They need to be able to explain how their control works without reading from a document. If nobody can explain a control, it does not exist yet.
Access control is where auditors spend the most time and where small teams have the most surprises. Before the "as of" date, work through this list:
Most of this is an afternoon of cleanup in GitHub and your cloud IAM console. Doing it yourself also produces the evidence: dated exports, screenshots, and access review notes that show the control operating.
Type 1 is point-in-time, but the auditor still wants to see that controls exist in a real system, not just on paper. A practical evidence set includes:
Put everything in one dated folder structure. Auditors charge for time spent hunting through email threads, and you pay that cost.
Even for a point-in-time audit, running one monthly security review before fieldwork is the cheapest credibility you can buy. Review open risks, re-run access checks, note what changed, save the notes.
That single documented cycle turns "we have a process" into "here is the process and here is the output." It is also exactly the habit you will need anyway if you go for Type 2 later, so nothing is wasted.
Get two or three quotes from licensed CPA firms that know SOC 2. Small-firm quotes for a security-only Type 1 often come in well under what the platform-led route assumes. Ask explicitly what they need and when, then work backward from your as-of date.
Expect the main drafting effort to be the system description, the narrative that explains what your service does and how it is structured. Your auditor will usually help shape it. It reads better when someone who knows the product drafts it, which is you.
If this list looks large, note that roughly half of it is documents you can draft and half is cleanup you can finish in a sprint. The hardest part for most teams is not any single item, it is knowing what the auditor will actually ask for and not reinventing the structure from scratch.
That is the gap the SOC 2 DIY Evidence & Controls Toolkit from Hardened Stack fills: a starter control matrix, gap analysis walkthrough, risk register, monthly review template, twelve editable policy templates, evidence checklists, and read-only scripts that pull real access and MFA evidence from GitHub and AWS. It is $179, a one-time purchase, and it does not certify anyone — it just stops you starting from a blank page. You can see it at hardenedstack.dev.
Affiliation note: this article is from Hardened Stack, the team that put the toolkit together.
Start smaller
If you are still at the "what do we do this week?" stage, take the free starter pack first. It includes the first-week checklist, access review checklist, and risk register CSV.