What a "yes" on a security questionnaire actually commits you to

You're 40 questions into a SIG Lite. The deal is worth more than anything you've closed this year. And you hit this:

Does the organisation perform annual penetration testing by an independent third party?

You had a pen test 18 months ago. You're planning another one. You know what the buyer wants to see.

The honest answer is no. The tempting answer is yes.

Here's what most people don't realise about that choice. The tempting answer isn't just optimistic. It's often a contractual statement, and it survives the deal.

Your answers usually end up in the contract

Read the MSA your buyer sends after the questionnaire clears. A lot of them contain a clause that incorporates your security responses by reference, or a warranty that says your representations during due diligence were accurate. Sometimes the completed questionnaire is literally attached as an exhibit.

That changes what a wrong answer is. It stops being a mistake in a form. It becomes a misrepresentation in an agreement you signed.

Nobody checks this on the way in. It surfaces later, in one of three ways:

1. The buyer's auditor asks for the pen test report you said existed
2. You have an incident, and the post-incident review compares what happened to what you claimed
3. You get acquired, and the acquirer's diligence team reads every questionnaire you ever returned

I'm not a lawyer and this isn't legal advice. But read your own MSAs and check whether your questionnaire answers are referenced in them. Most founders have never looked.

The three answers that cause the problem

The aspirational yes. You're doing it next quarter. It's on the roadmap. The control is 80% there. You answer yes because it'll be true soon. It isn't true now, and the questionnaire asks about now.

The inherited yes. Someone answered this question 8 months ago and you copied the response across. The infrastructure has changed since. The person who wrote it has left. Nobody has re-checked it against anything.

The borrowed yes. The question asks whether data at rest is encrypted. AWS encrypts it, so you answer yes. That's often fine. But some questions ask about your controls, not your provider's, and the distinction matters when the buyer maps your answer to their own obligations.

All three share one root cause. You answered from memory or from pressure, not from a document.

Answer from the document or don't answer

Here's the discipline that fixes this. For every answer, you should be able to point at the line in your SOC 2 report, your ISMS policy, or your infrastructure config that supports it.

If you can point at it, answer and cite it.

If you can't point at it, you have four honest options, and none of them is a no that kills the deal.

Option 1. Yes, with the source named.

Yes. Data at rest is encrypted using AES-256. See SOC 2 Type II report, CC6.1, page 34.

Naming the source does two things. It shortens the buyer's review, because they don't have to come back and ask. And it forces you to check before you claim.

Option 2. Not yet, with the date.

Not currently. Independent penetration testing is scheduled for Q1 2027 with [firm]. Our most recent test was completed in March 2025 and the report is available under NDA.

A dated commitment reads as a company that runs a plan. An undated "we're working on it" reads as a company that's stalling.

Option 3. We do this differently, here's how.

We don't operate a formal SIEM. We centralise logs in [tool] with alerting on authentication anomalies and privilege escalation, reviewed weekly. Happy to walk through this on a call.

Buyers accept compensating controls more often than founders expect. What they won't accept is finding out later that your yes meant something different from what they assumed.

Option 4. Not applicable, with the reason.

Not applicable. We don't process cardholder data. Payments are handled entirely by Stripe and card data never touches our infrastructure.

Bare "N/A" gets flagged and comes back to you. "N/A because X" usually doesn't.

Why "not yet" loses fewer deals than you think

The fear is that one honest no sinks the whole review. In practice, a security reviewer is building a risk picture, not a pass or fail score. They expect gaps at your size. What they're really testing is whether you know where your gaps are.

A questionnaire with 3 honest "not yet" answers and clear dates tells them you have a functioning security programme.

A questionnaire with 100% yes from a 30-person company tells them either you're unusually mature or you're not reading the questions carefully. They'll find out which during the follow-up call, and you don't want that to be the moment they find out.

The real deal-killer isn't the gap. It's the contradiction. You said yes to annual pen testing, and then the SOC 2 report you attached doesn't mention one. Now every other answer is suspect and the review takes three more weeks.

Build the thing that makes this easy

The reason people guess is that checking is slow. The SOC 2 report is a 60-page PDF. The policies live in Notion. The last questionnaire is in someone's downloads folder.

So do this once:

1. Put your SOC 2 report, ISO certificate, policies and pen test summary in one place
2. Keep a single answer library, with a source reference on every answer
3. Record the date each answer was last verified
4. Re-check anything older than 6 months before you reuse it
5. Keep a short list of your known gaps and their target dates, so "not yet" answers write themselves

That's the whole system. It's unglamorous, it takes an afternoon to build, and it works.

The next time a question arrives that you can't honestly answer yes to, you'll have a document to point at, or a date to commit to. Both beat a guess you have to defend later.