We were three weeks into a mid-market deal. The product fit was strong. The buyer's team had run a pilot. Their engineering lead said, unprompted, "This is what we've been looking for."
Then their security team sent a questionnaire. Forty-seven questions. Standard stuff — encryption, access control, incident response, data retention, subprocessors. We answered every one honestly and accurately.
We lost the deal anyway.
Not because our answers were wrong. Because they didn't sound like answers the buyer's security team was trained to hear.
Most founders think compliance is binary. You either have the SOC 2 badge or you don't. If you don't, you lose the deal. If you do, you win it.
That's not how it works.
Plenty of companies with a SOC 2 Type II report still fumble security reviews. Plenty without one close mid-market deals every quarter. The difference isn't the certificate. It's whether you can explain your security posture in the language your buyer already speaks.
Security reviewers at mid-market companies see dozens of vendor questionnaires a month. They pattern-match. They look for signals that you take this seriously — not just that you checked boxes, but that you understand why the boxes exist.
When we filled out that questionnaire, we wrote answers that were technically correct but structurally unfamiliar. We described what we did, but not in terms the reviewer recognized. Like showing up to a French oral exam and answering in correct Spanish.
After the deal fell through, we asked the buyer's CISO for a post-mortem. She gave us fifteen minutes. Here's what she said, paraphrased:
"Your answers were fine. But I couldn't tell if you had a program or just a collection of practices."
That distinction matters. A collection of practices is ad hoc — it could disappear when one engineer leaves. A program is durable. It has an owner, a review cycle, and a paper trail. Security reviewers aren't evaluating whether you encrypt data at rest. They assume you do. They're evaluating whether your organization will still encrypt data at rest in eighteen months when half your team has turned over.
Our mistake was treating the questionnaire as a technical exam. It was a trust interview.
After that loss, we rewrote our approach. Not our infrastructure — our explanation of it.
We built a security narrative: a short document, in plain language, that describes our security program as a program. It covers five things:
Scope. What data we handle, where it lives, who can touch it.
Controls. What we do to protect that data — described at the policy level, not the implementation level.
Governance. Who owns security decisions, how often we review them, and what triggers an out-of-cycle review.
Incident response. What happens when something goes wrong, how fast we communicate, and what our obligations are to the customer.
Evidence. What artifacts we can share on request — enough to let a reviewer verify our claims without taking our word for it.
This document isn't a SOC 2 report. It's not a replacement for one. But it does something a SOC 2 report often doesn't: it tells a story a security reviewer can follow in ten minutes, in vocabulary they already use.
Writing a security narrative is uncomfortable. It forces you to say, clearly, "Here is what we do and here is what we don't do yet." Most founders would rather stay vague and hope the reviewer doesn't probe the gaps.
Vagueness is the worst strategy in a trust conversation. Reviewers notice what you don't say. An honest gap — "We don't yet have a formal business continuity plan, but here's our current approach and our timeline for formalizing it" — reads as maturity. Silence reads as ignorance or evasion.
The founders who close these deals aren't the ones with the most controls. They're the ones who can describe their controls like someone who actually chose them on purpose.
Two months later, we entered a similar process with a similar buyer. Same type of questionnaire. This time we sent the questionnaire answers and the narrative document, unprompted.
The security review took four days instead of four weeks. The reviewer told our champion: "They clearly have a program. We're comfortable."
Same infrastructure. Same team. Same controls. Different outcome — because we changed the explanation, not the engineering.
If you're an early-stage founder losing mid-market deals at the security review stage, you probably don't have a security problem. You have a translation problem.
A SOC 2 badge on your footer is a signal, and eventually worth getting. But the thing that closes deals is a clear, honest description of your security program — written for the person who has to approve you, in the language they already think in.
Do the work of writing it down. Not for the auditor. For the human across the table who needs a reason to say yes.
Be the first to comment.
0 comments
Loading comments...