TL;DR

If you’re an ISV trying to sell into a Fortune 1000, a regulated industry, or anyone with a serious procurement team — SOC 2 isn’t a nice-to-have. It’s the first checkbox on the security questionnaire that decides whether your deal moves forward or dies in legal review. This post kicks off a 5-part series on what SOC 2 really is, why it matters, and how to get there without burning your engineering team.

Introduction

I’ve been on enough enterprise sales calls — sitting next to founders, watching procurement send back a 200-question security questionnaire — to know exactly where most ISVs lose the deal. It’s not the demo. It’s not the pricing. It’s slide 4 of the vendor security review, where the buyer asks: “Do you have a current SOC 2 Type II report?”

If the answer is “no” or “we’re working on it,” the conversation changes. Sometimes it ends. Sometimes it gets parked for six months while you scramble. Either way, you’ve just learned an expensive lesson: trust isn’t something you claim, it’s something you can hand over in a PDF.

What SOC 2 actually is (in one paragraph)

SOC 2 is an attestation report — not a certification — produced by an independent CPA firm that evaluates how a service organization handles customer data against the AICPA’s Trust Service Criteria. The five criteria are Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy (you pick which apply). There are two flavors: Type I is a point-in-time snapshot (“your controls are designed correctly today”), and Type II is the one enterprises actually want — it observes those controls operating over a period, typically 3 to 12 months. We’ll go deeper into the criteria in Post 2.

Why enterprises won’t budge on this

Big companies have legal exposure. When they buy your software, they’re effectively extending their security perimeter to include you. Their CISO, their privacy officer, and their procurement team all need a defensible paper trail showing they did due diligence. SOC 2 is the lingua franca for that.

Here’s what happens in practice when you don’t have one:

  • You get stuck in security review for months. The buyer’s team has to manually evaluate your controls, often via a custom questionnaire (CAIQ, SIG Lite, or a homegrown 300-question spreadsheet). This eats your engineering time and slows the deal.
  • You get downgraded in vendor tiering. Many enterprises classify vendors by data sensitivity. No SOC 2 often means you can’t access PII, PHI, or production data — which may be the exact thing your product needs to do its job.
  • You lose to a competitor who has it. This is the quiet killer. You’ll never see the email that says “we went with the other vendor because their compliance posture was further along.”
  • You take on contractual risk to compensate. Without a SOC 2 report, buyers often demand more aggressive indemnification, audit rights, and breach notification terms. You end up signing things your insurance doesn’t cover.

The medical-software example

I worked with a medical-domain ISV running on both AWS and GCP — a fairly common setup for healthcare-adjacent products that need to integrate with diverse hospital systems. They had a strong engineering culture and good-enough security hygiene, but they had grown up product-first. SOC 2 hadn’t been on the radar until a major health system put it on the table as a hard requirement.

What surprised the founders wasn’t the technical work — it was the evidence burden. Logging existed, but wasn’t centralized in a way an auditor could sample. Access reviews happened, but weren’t documented. Backups ran, but no one had tested a restore in months. The controls weren’t broken; the proof was missing.

That gap — between “we do this” and “we can prove we do this, repeatably, across a 6-month window” — is the entire game.

What you do vs What an auditor sees

You can’t audit yourself, and you can’t pen-test yourself

Two things that catch first-timers off guard:

You need an independent CPA firm to issue the report. SOC 2 is governed by the AICPA, and the report only carries weight if it’s signed by a licensed auditor with no conflict of interest. You also typically work with a compliance partner — a platform or consultancy — to help you frame your controls, map them to the Trust Service Criteria, and prepare your evidence so the audit itself goes smoothly. That partner is not the auditor; mixing those roles defeats the purpose.

Penetration testing must be performed by an independent third party. Internal security testing is great hygiene, but for SOC 2 evidence you need an external firm with no skin in the game. Most ISVs run an annual pen test scoped to their production environment, with a remediation cycle for any high-severity findings before the audit window closes.

These two requirements are non-negotiable, and budgeting for them early — both money and calendar time — is one of the biggest unlocks for a smooth first audit.

The cost of not doing it

Founders often ask me: “How much does SOC 2 cost?” The honest answer is that the audit itself is the cheapest part. Expect the compliance platform, the auditor, and the pen test to add up to roughly $30K–$80K in year one for a small ISV, with internal engineering effort on top.

Now compare that to the cost of not having it: one stalled enterprise deal worth $250K ARR, multiplied by the number of buyers who quietly walked away. The math gets uncomfortable fast.

Series navigation

Conclusion

SOC 2 is sometimes dismissed as compliance theater — a tax you pay to satisfy procurement. That framing misses the point. Done well, the controls SOC 2 demands are the same ones that prevent the 2 a.m. incident, the data leak, the awkward customer email. The audit just forces you to actually finish the work.

If you’re an ISV with enterprise ambitions, the question isn’t whether to pursue SOC 2. It’s whether you’d rather start now, on your timeline, or six weeks before a major deal closes — when your engineers are already heads-down shipping the feature that won the deal in the first place.