Every enterprise sends a 100-question security questionnaire — how do we survive it at four people?

You will usually get the questionnaire after you have won. The evaluation is over, your champion has said yes, and the file has gone to a team that never met your champion. Founders assume the form is the obstacle. The form takes a morning the second time. The first one is how you pay for all the rest.

It arrives after the win.

You have been taught to treat the questionnaire as paperwork to get through once. It is a recurring process with its own clock, and it starts after the sales decision rather than before it. Large companies separate the commercial yes, the legal review, the security review, and the final approval so that no one person can commit the firm. Three of those four gates open after the deal looks won, and the security review belongs to people who have no reason to hurry.

The fix is in your forecast, not in the form. Pipeline stages defined by what the seller has done predict almost nothing. Stages defined by what the buyer's organization has done predict almost everything, and we have watched the forecasts of companies that made that change stop missing. Ask your champion to walk you through their approval path, who owns each step, and which risk tier they filed you in. Make that list your forecast, put the security review on it as its own line with the champion's date, and count the deal at countersignature.

Your champion will also leave. That is the normal case in a sale that runs across quarters, and the next person inherits none of the credibility the last one built. Learn the approval path from two people in different reporting lines.

You are scored, not read.

You are not writing for a reader. The buyer's program sorts you into a risk tier before a single question is asked, and the tier picks the form. A product that installs an agent, sits inline, or holds privileged credentials is high risk by definition. The architecture that makes you valuable gets you the long form.

Once the form is in, software parses your answers against a control framework, flags what it does not recognize, and reads your free text only where a flag fires. A scanner checks you from outside, looking at certificates, open ports, patch cadence, and leaked credentials, whether or not you answer. A yes that the scan contradicts is a finding, not a gap. So write for the scorer. Give a clear yes, no, or not applicable. Name a control the framework recognizes. Attach evidence a reviewer can file. A paragraph with no control behind it scores as nothing.

A security vendor's no is louder.

You are held to two standards, and they are not the same. The product standard is about what you ship: multi-factor authentication, no default passwords, patching, a disclosure policy, an honest vulnerability record. A security vendor clears that standard in the product. The corporate standard is what most of the form asks about, and it is where a no reads as a verdict rather than a gap. If you sell the control, the reviewer expects you to run it. A detection company that answers no to running endpoint protection on its developers' machines has not failed a public standard. It has told a security team that it does not run its own product.

Where you genuinely lack a control, write the no, the control that compensates for it, and the date by which you will fix it. Never write a hopeful yes. Never write planned for next quarter on its own, which scores as a no without the compensating control. The buyer's software cross-checks the form against your SOC 2 and the scan, and regulated buyers write your answers into the contract. What reopens a closed review is rarely a gap. It is an answer that contradicts your SOC 2 report, your security addendum, or your trust page. Diff the four before you send anything.

Refuse the wrong form.

You will be sent a form written for hosted, multi-tenant software. If you install an agent, run inside the customer's environment, sit inline, or hold no data at rest, whole sections do not describe you. Forcing a yes and leaving a blank are both flags. Writing not applicable, followed by the reason, the deployment model, and the control that does apply, is a scored answer, and the standard forms leave room for it.

Describe your architecture once, at the top, on the same page you give every buyer: what the product touches, what privileges it needs, what data it sees and stores, where it runs, the tenant boundary, how it fails, and what the buyer must run themselves. The reviewer re-tiers you on those facts rather than on the category name. Your champion can ask for the lighter form. You cannot.

The AI section is now standard. It asks which models are embedded, where the training data came from, whether customer data is used to fine-tune anything, and what defends against prompt injection. Answer it once, before anyone asks.

Build the corpus on the first form.

You build your answer set, the corpus, on the first form, and that is why every later form is cheap. It is not a folder of returned spreadsheets. It has these fields:

• The architecture paragraph.
• The answer for every control, keyed to a framework the buyer's software recognizes.
• The evidence documents, and where each one lives.
• A version and a date on every answer.
• One named owner.
• The deployment-model answer, written once, because most of your not-applicable answers hang off it.
• The AI section, answered before anyone asks.
• The documented gaps, each with its compensating control and its dated commitment, which you will be asked to prove you kept.
• The map from what your product claims to the controls you run, which is the cross-check a security buyer makes.

The answer you gave in March is the answer they lock in September.

Publish the free layer before you are asked.

You can answer most first requests without a tool or a hire, and the layer that does it costs nothing but care. Register a CSA STAR Level 1 self-assessment on the Cloud Security Alliance's public registry. Claim your company's profile on the external security ratings services, SecurityScorecard and Bitsight, and fix what they see. Complete the MVSP checklist, the minimum baseline that enterprise security teams wrote for vendors. Put up a trust page with your policies, your AI answers, and your SOC 2 report available under NDA. The registry is public and permanent, so it carries only what you can stand behind for a year in front of competitors. The honest gaps and the dated commitments stay in the corpus, behind an NDA.

None of that publishing transfers into a buyer-hosted portal. Someone re-keys your answers into their own control set, and neither the trust page nor the registry crosses that boundary. Evidence documents do, and so does the architecture paragraph. Ask the champion for an upload path.

Answering in advance removes your delay from the queue. It does not move the buyer's queue, which runs on the sponsor's urgency. Buy the automation tool when the alternative is hiring a second person to answer forms, and not before.

It comes back.

The review comes back on two clocks. Every year by rule, because self-assessments renew and the buyer's software reopens your file without anyone deciding to. And within days of a peer's incident. When a vendor in your category is compromised, your customers and your board audit you the same week. We have watched it happen inside seventy-two hours. Each incident leaves a new question behind, such as staged rollouts after a bad content update or the scope of every OAuth grant after a compromised sales tool. The incident sends questionnaires, not orders. Plan capacity for the re-audits, and never plan revenue on the inbound.

One more thing the form will not tell you. Contract friction tracks the buyer's urgency, not the quality of your paper. The deals that close with no redlines are the ones signed while the buyer is worried. Better paper does not speed anything up. A worried sponsor does.