An enterprise security questionnaire arrives late in a deal, usually after you have already won on substance, and it is not really a security document. It is a test of whether anybody at your company owns security.
The uncomfortable part is that the answers almost always exist. Encryption is configured. Access is controlled. Backups run. The information is sitting in the environment. What is missing is a person who can assemble it into a set of answers a buyer's security team will accept, and while nobody can, the deal sits.
The usual assumption is that the managed provider will handle it. They will answer the questions that fall inside their contract, which is a smaller set than most people expect and does not include anything about your application, your development process, or your own staff. That is one more version of why an MSP is not a security program.
The cost is not the deal. It is the quarter.
At a company where I was the VP of Technology, we got several of these. Our answers were, honestly, mostly some version of control not implemented.
The customer still wanted to use us. They ended up putting a set of mitigations in place on their own side to get comfortable, and the deal happened. But it went from a sure thing to a we will have to think about it, and that transition is the actual cost. A signature became a review. A review means meetings we did not control, on a calendar we did not control, with people who had not met us.
What would have changed the outcome was not a security program. It was having basic written policies, ideally mapped to a recognized framework, so that the gaps had a shape and a trajectory. There is an enormous difference between "we do not have that" and "we do not have that yet, here is the policy that governs it, here is what compensates in the meantime, here is when it lands." The first answer stalls a deal. The second one is a conversation.
That is my own gap, from my own seat, and I did not close it in time.
The technical questions got a lot cheaper
Some of this got genuinely easier in the last couple of years, and it is worth knowing which parts.
The technical questions - is data encrypted at rest, is TLS enforced, how long are logs retained, is MFA required - used to mean chasing down whoever configured the thing two years ago. Now you can point an AI tool at the codebase and the configuration and ask directly whether this application encrypts its data, and get an answer you can verify. That work has gone from days to something closer to an afternoon.
Same for the drafting. Once you have the underlying facts, generating the first pass at two hundred answers is not the bottleneck it used to be. Have a security person review before it goes out - a confidently wrong answer to a buyer's security team costs you more than a blank one - but the labor has genuinely collapsed.
The expensive questions are not IT questions
The ones that still hurt are the organizational ones, and this is the part that surprises engineering leaders.
I filled out a CAIQ at that company. The technical sections were long but tractable. TLS, encryption at rest, that class of thing, is either configured or it is not, and you can go look. The hard part was everything requiring a documented human process.
Take a typical item: provide your procedure ensuring that an offboarded employee or contractor has their privileges revoked. There is no codebase to point at. That answer requires HR to have a process, Legal to have language in the contractor agreements, IT to be a step in that process, and somebody to own the whole thing end to end. If those pieces do not exist, you cannot write the answer, and you cannot manufacture it in the two weeks before the deal is supposed to close.
Offboarding, access reviews, vendor management, incident response, security awareness training, background checks. None of it is technically difficult. All of it crosses departments, and cross-department processes are exactly what a growing company has not built yet.
The other real work is crafting the partial answers. Most of my time went into constructing responses of the form we do not have this, but we do have this other thing that addresses the same risk. Those take judgment. You have to actually understand what the control is for in order to argue that something else covers it.
"No" is an answer. "We don't know" is not.
I have not seen a deal lost over an honest no.
What happens instead is that the buyer comes back and says they have to have a particular control. That is not a rejection, it is a negotiation, and it deserves deal math rather than compliance math. If the control only serves this one customer, weigh the build against the value of the deal. If it is going to show up on the next five questionnaires from the same market, it is not a concession, it is infrastructure, and the arithmetic changes completely.
What does damage is the unanswerable question. "No" gives a buyer's security team something to assess and mitigate. Silence, or an answer that arrives three weeks later after somebody finally tracks down a former contractor, tells them something about your company that is worse than the missing control.
The same dynamic runs through a penetration test report you cannot disposition: buyers and regulators are considerably more tolerant of a documented gap than of an organization that does not know its own state.
Answer it once
We used to keep a giant spreadsheet of answers. That was the right instinct and the wrong medium, because it went stale silently and nobody owned it.
The current version is a proper answer library, with each response carrying its evidence and the date it was verified, plus an AI agent that drafts a new questionnaire against it and flags where it had to guess. Your staff prefill. Your security reviewer signs off. What used to take a week takes a day, and more importantly the second questionnaire from the same market costs almost nothing.
That is the actual return. The first questionnaire is going to be painful whatever you do. The point of doing it properly is that you never pay full price again, and that your sales team stops discovering in week eleven of a deal that nobody can answer question 47.
Where to start if one just landed
Answer the technical items first, from the environment, and get them verified rather than remembered. Identify the cross-department items early, because those need HR and Legal on a calendar and that is the long pole. Write honest gaps with a compensating control and a date. Map what you do have to a recognized framework so a buyer can place you.
Then keep the answers. The company that nobody senior is watching the whole estate for will do this from scratch every single time, and pay for it in sales cycles rather than in a line item anybody ever sees.