Sooner or later a deal stalls on one line of a security questionnaire: "Do you have a SOC 2 report?" The answer decides how fast you get a first report. If a buyer needs proof now, start with Type I. If their procurement team requires Type II, begin collecting evidence today, because the observation period cannot be shortened. This guide covers how to choose, what an auditor will ask your engineers to prove, and what to do first.
What SOC 2 is, and what it is not
SOC 2 is a report, not a certificate. An independent CPA firm examines your controls against the AICPA's Trust Services Criteria and gives an opinion on them. There is no score and no pass mark, and the report belongs to you, so you decide whom to share it with, usually under an NDA.
The criteria come in five categories: security, availability, confidentiality, processing integrity and privacy. Security is the only one every report includes. Most startups begin with security alone and add others when a customer asks.
It is also not law. Nobody is legally required to have a SOC 2 report. You need one because customers write it into their buying process, and that is why it shows up as a sales blocker before it shows up as a security project.
Type I or Type II
| Question | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| What it examines | Whether controls are designed and in place on one date | Whether controls operated effectively over a period |
| Preparation | Shorter, mostly policies and setup | Longer, needs evidence collected over time |
| Observation period | None | Commonly three to twelve months |
| What a buyer reads into it | You have the right controls | You actually follow them |
Choose by the next deal you need to win:
| Your situation | Start with |
|---|---|
| A buyer needs something this quarter and accepts a Type I | Type I, then roll straight into a Type II period |
| A buyer's procurement requires Type II | Type II, and begin the observation period as soon as controls are in place |
| No buyer has asked yet, but you sell to larger companies | Type I as an early signal, so you are ready when they do |
| You are unsure what your buyers accept | Ask two or three of them which type they require before you spend anything |
That last row saves the most money. A Type I that your buyer does not accept is a delay, not a result.
What engineering has to prove
Much of SOC 2 sits with engineering. The security criteria include logical access, system operations and change management, and an auditor tests each by asking for evidence. They typically work from samples, so the same behavior has to show up consistently.
| Area | What an auditor typically asks | Evidence engineering can provide |
|---|---|---|
| Change management | Are code changes reviewed and approved before release? | Pull requests with required reviews and branch protection settings |
| Access control | Who can reach production, and is access removed when people leave? | Access lists, SSO and MFA settings, offboarding tickets |
| Vulnerability management | Do you find vulnerabilities in code and dependencies, and fix them on a schedule? | Scan results on pull requests, fix dates against your own deadlines |
| Monitoring and incidents | Can you detect problems and respond to them? | Alerting configuration, an incident plan, records of past incidents or exercises |
| Environments | Is production separated from development? | Separate accounts and credentials for staging and production |
The vulnerability row is where code security meets the audit. Whatever scanner you use, make sure it runs on every pull request, and that its results and the dates findings were fixed are kept somewhere an auditor can read. Orbis AppSec, our own product, scans pull requests and opens fix pull requests, which leaves that record as a by-product. Evaluate any tool against your own repositories first.
The rule that trips teams
The auditor tests you against your own policies. If your policy says critical dependency findings are fixed within seven days, the auditor will look for seven-day fixes, and every miss is an exception in the report. Write down only what you can keep. A realistic policy followed every time beats an ambitious one followed most of the time.
A realistic path
- Scope. Decide which systems, which category (usually security only) and which report type.
- Gap assessment. Compare what you do today with what the criteria expect. A good auditor or readiness partner will do this with you.
- Fix the gaps. Most are small: missing policies, shared credentials, no offboarding record, scanning that only runs sometimes.
- Start collecting evidence. Begin as soon as controls are live. For Type II, the observation period starts here.
- Audit. The auditor samples your evidence and writes the report.
- Repeat. Reports are usually renewed every year, so build the evidence habit into normal work rather than a yearly scramble.
The part you cannot compress is step 4. Time spent not collecting evidence is time added to the Type II.
Questions to ask an auditor or a compliance platform
- Which report type do your customers in our market usually need?
- What does your report cover, and can we see a sample, with names removed?
- What evidence will engineering be asked for, and how often?
- What happens if we miss a control during the observation period?
- Who owns the work on our side, and how many hours a week should we plan for?
Common mistakes
- Starting without asking buyers which report type they accept.
- Writing policies that describe an ideal company rather than yours.
- Treating the audit as a documents project and leaving evidence collection to the last month.
- Having no named owner, so the work waits for a quiet week. See who owns security at a startup.
- Assuming a report means you are secure. It shows that controls exist and operate, not that no one can get in.
Frequently asked questions
Is SOC 2 required by law? No. It is a customer expectation that appears in contracts and questionnaires.
Can we skip Type I and go straight to Type II? Yes, if your buyers accept it and you can wait for the observation period. Many companies take Type I first because it gives them something to show sooner.
Do we need all five categories? No. Security is the only one every report includes. Add availability, confidentiality, processing integrity or privacy when a customer or your product calls for it.
How long does a first report take? It depends on how many gaps you start with and how long your observation period is. Get a timeline from your auditor after the gap assessment rather than relying on a general number.
Does SOC 2 replace a penetration test? No. They answer different questions, and buyers often ask for both. For the wider set of starting controls, read the Series A security guide.
Sources
- AICPA SOC 2 and the Trust Services Criteria: the basis for SOC 2 reports.
This guide is general guidance, not legal or audit advice. Timelines, scope and report requirements vary by auditor and by customer, so confirm them with your auditor before planning around them.