Your Enterprise Customer Just Asked for SOC 2. Here's What to Actually Do.

You were on a sales call. It was going well. The buyer loved the demo, asked smart questions, and started talking about implementation timelines. Then the procurement person leaned in: "Can you share your SOC 2 report?"

You said "we're working on it."

Now you need to actually work on it. Because that deal is probably $80K-$200K in ARR, and you have maybe 8-10 weeks before the buyer's internal security review stalls out and they move to a competitor who already has their report ready.

Here's what to do. Week by week. With real costs and the things auditors actually care about.

Week 1-2: Understand What You're Actually Dealing With

Don't panic-buy a compliance platform. Don't hire a consultant on day one. First, get oriented.

Pick Your Trust Service Criteria

SOC 2 has five Trust Service Criteria. Most startups think they need all five. You almost certainly don't.

The five criteria are: Security (always included, mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Security alone covers roughly 80% of what enterprise buyers actually care about. Adding Availability makes sense if you sell SaaS with uptime commitments. The other three are rare for startups.

Every extra criterion adds 20-30% more scope, time, and cost. Start narrow.

Run a Gap Assessment

Walk through the SOC 2 Security criteria and document what you have vs what's missing. Most startups on AWS, GCP, or Azure already have more coverage than they realize. Default encryption in transit, some access controls, basic monitoring. Those count.

The gaps that catch almost every startup:

• No formal access reviews. Who has access to production? When was the last time anyone checked? Most companies have 2-4 ex-employees or ex-contractors who still have access to things they shouldn't.
• No change management documentation. Code review happens informally, but there's no evidence trail. Auditors want to see that code can't go to production without a second set of eyes.
• No incident response plan. If your database leaked right now, what would you do? Who would you call? In what order? Write it down.
• No vendor management. You use 15-20 SaaS tools. Which ones touch customer data? What's their security posture? Do you have a list?
• No security awareness training. Even a 30-minute annual session counts. Zero training is a finding.

Pick an Auditor

SOC 2 audits must be performed by CPA firms. The price range is enormous. Big Four firms charge $150,000 or more. Boutique firms that specialize in startups charge $8,000-$18,000 for a Type 1.

Get three quotes. Ask each firm: "How many startup SOC 2 audits did you complete last year?" If the answer is under 20, move on. You want a firm that has seen a hundred 15-person SaaS companies, not one that usually audits Fortune 500 banks.

The Tooling Decision: Platform vs Manual

This is where startups overspend. The compliance automation market is loud. Vanta, Drata, Secureframe, Thoropass. They all want you to believe you need them right now. Let's look at this honestly.

My honest opinion: if you're under 50 employees and going for Type 1, do it manually. You'll have evidence items to collect across your controls (the number varies, but it's manageable with a well-organized folder). That's a well-organized Google Drive folder, not a $15,000/year platform.

Where the platforms earn their money is Type 2. Continuous evidence collection over 6-12 months is genuinely painful to do by hand. Plan to evaluate platforms before your Type 2 observation period starts. But don't pay for one during Type 1.

Week 3-8: Building Evidence

This is where the real work happens. You're implementing controls and creating evidence that they work.

What Auditors Actually Care About

I've seen founders spend weeks perfecting their password policy document while leaving 4 ex-employees with production database access. Auditors care about controls that are actually in place, not beautifully formatted policy PDFs.

High priority (auditors check these first):

• Access controls. MFA enforced everywhere? Role-based permissions? Regular access reviews documented? This is the number one finding in startup SOC 2 audits. Fix it first.
• Change management. Pull request reviews, CI/CD pipeline, separation between development and production. The auditor wants to see that no single person can push unreviewed code to production.
• Incident response. A written plan that's been tested. Even a 45-minute tabletop exercise ("what would we do if X happened?") with notes counts as a test.
• Risk assessment. A spreadsheet listing 15-20 risks, their likelihood, their impact, and what you do about each one. It doesn't need to be elaborate.
• Vendor management. A list of subprocessors, what data they access, and evidence that you've reviewed their security. Most SaaS vendors will share their SOC 2 report if you ask.

Lower priority (auditors check but aren't picky about):

• Your specific tech stack. React vs Vue doesn't matter. Your deployment pipeline matters.
• Perfect documentation. Two pages of incident response plan that your team has actually read beats 50 pages that nobody's opened.
• Zero vulnerabilities. They want to see a vulnerability management process, not a clean bill of health. Having Dependabot or Snyk running and evidence that you fix critical findings is enough.

The Audit Itself

The audit is less intimidating than people expect. For Type 1, the auditor checks that your controls exist and are properly designed at a specific point in time. They pick a date. They verify that on that date, everything was in place.

Here's how it works:

1. Evidence request. The auditor sends a list of documents and evidence they need. Policies, access lists, configuration screenshots, training records. For a startup, expect 100-150 items across all your controls.
2. Fieldwork. The auditor reviews your evidence, asks follow-up questions, and interviews 2-3 people on your team. This takes 1-2 weeks on their end.
3. Draft report. They share preliminary findings and give you a chance to respond. Common findings include incomplete access reviews, missing vendor documentation, or a policy that doesn't match how things actually work.
4. Final report. You address the findings, the auditor verifies, and the final SOC 2 Type 1 report is issued. Usually 30-50 pages.

Most of your time is spent in preparation. The audit itself is mostly waiting for the auditor to review what you've already assembled.

SOC 2 Type 1 vs Type 2

This distinction confuses almost everyone. Here's the short version.

Type 1 checks that your controls are properly designed at a single point in time. Think of it as a photograph. "On January 15th, these controls existed and were designed to work."

Type 2 checks that your controls actually operated effectively over a period. Usually 6-12 months. Think of it as a documentary. "From January to July, these controls were consistently followed."

Type 1 is enough to close the deal right now. Enterprise procurement teams accept Type 1 reports from startups regularly. They'll usually ask you to commit to a Type 2 timeline, something like "we'll have our Type 2 report within 12 months." That's reasonable and expected.

After your Type 1 is issued, you start the Type 2 observation period immediately. Keep following your controls consistently. After 6-12 months, the auditor comes back, reviews the entire period, and issues the Type 2 report.

The Real Cost Breakdown

Let's put specific numbers on this. Two paths, side by side.

DIY path (recommended for first Type 1):

Consultant-assisted path:

The gap is real. And the more expensive path doesn't guarantee a better outcome. A consultant writes policies for you. But those policies still need to describe what your systems actually do. If a consultant writes that you "perform quarterly access reviews" and nobody on your team has ever done one, the auditor will flag it.

The engineer-led approach works because the same person implementing the controls is documenting them. There's no translation gap. The policy says "AES-256 encryption at rest via AWS KMS" because that's what was actually configured that morning.

What Happens After You Get the Report

You get a PDF, typically under NDA. SOC 2 reports are not public documents. You share it with the enterprise customer's security team, they review it, and they either approve the vendor relationship or send follow-up questions.

Most of the time, the report is enough. Sometimes they'll ask about specific exceptions or qualified findings. Having someone technical who can explain the controls in plain language makes those conversations go much faster.

Then you keep going. The Type 2 clock is running. Same controls, same evidence collection, just over 6-12 months. If you did Type 1 right, Type 2 is mostly about not letting things slip. This is where a compliance platform starts to make sense, because automating continuous evidence collection for half a year is genuinely tedious to do manually.

The Honest Takeaway

SOC 2 is not the beast that compliance vendors want you to think it is. It's a structured way of proving that you take security seriously. For a well-run startup on modern cloud infrastructure, most of the technical controls are already partially in place. The work is in formalizing what you already do, fixing the gaps, and creating evidence that it's all real.

The deal on the line right now is the motivation. But the controls you put in place will protect your business long after that customer signs. Every enterprise customer after this one will ask the same question. Having the report ready turns a sales blocker into a competitive advantage.