Here's a conversation that's playing out at startups right now, almost word for word, regardless of what the product does:

Sales gets a verbal yes from an enterprise buyer. Champion is bought in. Budget is approved. Then procurement sends over a security questionnaire, or asks for a SOC 2 report, or asks to see the ISO 27001 certificate — and the deal stalls. Not because the buyer stopped wanting the product. Because a document that doesn't exist yet is now sitting between "verbal yes" and "signed contract."

If you've lived this, you already know the specific flavor of frustration involved: it's not a sales problem, not a product problem, not really even a security problem in the sense most engineers think about security. It's closer to a paperwork bottleneck wearing a security costume — and it's becoming a standard, almost unavoidable stage of the enterprise sales motion rather than an edge case.

There used to be a rough sequencing: build product, find product-market fit, sell to smaller and less risk-averse customers, and only start worrying seriously about formal compliance certifications once you were far enough upmarket that it was clearly warranted.

That sequencing is compressing. A few forces are pushing it earlier:

Enterprise buyers are more risk-averse than they used to be, partly because their own compliance obligations have gotten heavier — the NIS2/DORA dynamic from a couple of weeks ago means your enterprise customer may themselves be under new regulatory pressure to vet vendors more rigorously, and that pressure flows downhill onto you regardless of your company's size.

Security questionnaires have become standardized and automated on the buyer's side, which sounds like it should make things easier, but mostly means every deal above a certain size now includes one by default, rather than only the security-conscious buyers asking. It stopped being a signal of a particularly cautious customer and became table stakes.

Smaller companies are increasingly buying from other small companies who serve regulated industries, which pulls compliance requirements further down the size curve than founders expect — you don't need to be selling to a bank directly to end up needing DORA-adjacent answers; you just need to be one hop away in the vendor chain.

The net effect: the moment a startup starts closing its first meaningfully-sized deals is now often the moment compliance stops being optional, well before the company would have chosen to prioritize it on its own timeline.

It's worth being precise about what's actually happening in these stalled deals, because the instinctive framing — "we have a security gap" — is usually wrong, or at least incomplete.

Most of the time, the underlying security posture isn't the blocker. The company has reasonable practices; the engineers aren't doing anything obviously reckless. What's actually missing is proof — a certificate, a report, evidence packaged in a form the buyer's procurement process recognizes. The gap isn't "are we secure," it's "can we demonstrate it in the specific artifact format this deal requires, on this deal's timeline."

That reframing matters because it changes what the fix looks like. "We have a security gap" suggests you need to change what you're doing. "We can't prove what we're already doing, fast enough, in the right format" suggests a completely different kind of problem — one that's about evidence and process, not fundamentally about risk.

Which is exactly why this tends to surprise founders. Nobody built the product carelessly. Nobody was ignoring security. The company just never had a reason to formalize proof of it — until a deal worth six or seven figures made that formalization suddenly, urgently, load-bearing.

Faced with this, the instinctive paths are both expensive in different ways:

Option one: throw a compliance hire or consultant at it under deal pressure. This works, eventually, but "eventually" is doing a lot of work in that sentence — a rushed SOC 2 or ISO 27001 process under deal pressure often takes months, and the deal clock rarely waits politely. It also tends to produce exactly the kind of compliance-as-theater outcome we've written about before: policies written to satisfy an auditor's checklist rather than to reflect how the company actually operates, which becomes its own liability later.

Option two: pull engineering off the roadmap to manually assemble evidence. This is the more common default at smaller companies, and it's corrosive in a specific way — it's not that the work is impossible, it's that it's unpredictable and recurring. The evidence goes stale the moment infrastructure changes again, so the same scramble repeats for the next deal, and the one after that, each time pulling engineers away from the actual product.

Neither option is irrational. They're just both responses to the same underlying condition: not having continuous, ready-to-show proof of your actual security posture, so every deal that needs it becomes a fire drill instead of a formality.

This is the sales-motion version of a point from a couple of weeks back about NIS2 and DORA not having a single scheduled audit day. The revenue-blocker version of the same problem is arguably worse, because it's less predictable than a regulatory audit, not more.

A SOC 2 audit, at least, is usually something you schedule yourself, on your own timeline, once you've decided to prioritize it. A procurement-triggered security review isn't like that — it shows up whenever a deal reaches a certain stage, on the buyer's calendar, not yours. You don't get to pick a good week to have your evidence in order. The deal picks it for you.

Which means "we'll get compliant before we need to" is a strategy that only works if you can predict exactly when a large enough deal will show up — and if you're a startup actively trying to close larger deals, the honest answer is you're trying not to be able to predict that, because unpredictable upside is the whole point of the sales motion working.

The founders who navigate this best, in my experience so far, are the ones who stop treating compliance readiness as a project with an end date and start treating it as a standing property of how the company operates — closer to "we always basically know where we stand" than "we did a compliance sprint last quarter."

That's a genuinely different posture than most startups default into, and it's not free — it requires some amount of continuous visibility into your own infrastructure and controls, rather than periodic point-in-time effort. But the alternative is paying the cost of the fire drill, repeatedly, at the exact moments when the cost of a slow response is highest: in the middle of your best deals.

That's the practical version of the thesis from the very first post in this series — that compliance should be a continuously observable property of your infrastructure, not a document someone assembles before a deadline. Here it's the same idea, just measured in a currency every founder understands immediately: not "audit pass or fail," but "deal closes on time or doesn't."