Security Questionnaires 
How to Stop Losing Two Weeks Per Deal 

A deal that has been moving for two months arrives at procurement and a spreadsheet appears. Three hundred and forty questions, a two-week turnaround, and a set of answers that only your engineers can write. Your CTO loses a fortnight, the close date slips into the next quarter, and the same thing happens again six weeks later with a different spreadsheet asking eighty percent of the same questions in a different order. This is one of the most reliably underestimated costs of selling to enterprises, and unlike most sales friction it is almost entirely fixable with engineering discipline rather than with sales effort.

What the questionnaire is actually doing

It helps to understand the mechanism, because it changes how you answer. The security team on the other side is not trying to determine whether you are secure in any deep sense — they cannot, from a spreadsheet. They are managing their own risk and their own accountability: they need a defensible record that they asked, that you answered, and that the answers were consistent with your certifications. That has three consequences. Consistency matters more than sophistication, because an answer that contradicts your SOC 2 report or your public documentation creates work for them and doubt about everything else you said. Speed is itself a signal, since a vendor who answers a standard questionnaire in three days looks like a vendor with its controls in order, and one who takes three weeks looks like a vendor assembling them. And 'no, and here is our compensating control and our timeline' is an entirely acceptable answer in most cases, while a 'yes' that unravels under a follow-up question is far worse than the honest 'no' would have been. Teams routinely over-claim on questionnaires out of fear of losing the deal, and it is the single most damaging thing you can do at this stage.

Build the answer library once

The reason each questionnaire costs two weeks is that each one is answered from scratch by people reconstructing the same facts from memory. The fix is unglamorous: a single maintained repository of answers, written once, kept current, and owned by a named person. Every question you have ever been asked goes in it, with the canonical answer, the evidence that supports it, the date it was last reviewed, and any caveat that matters. The overlap between questionnaires is enormous — the standard frameworks such as SIG and CAIQ cover much of the same ground, and even bespoke enterprise spreadsheets are largely permutations of the same forty topics — so the second questionnaire typically reuses seventy percent of the first, and the fifth reuses almost all of it. The discipline that makes this work is refusing to answer anything ad hoc: if a question is not in the library, the answer goes into the library first and then into the spreadsheet. Within a quarter, a two-week exercise becomes a two-day one, and the person doing it no longer has to be your CTO.

The forty topics you will always be asked about

• Access control: who can reach production, how access is granted and revoked, whether it is time-bound, and how you evidence the review. This one is asked in every questionnaire and answered badly by most companies — see production access.
• Authentication for your own staff and for your customers: MFA enforcement, SSO support, session handling, password policy.
• Encryption in transit and at rest, key management, and who holds the keys.
• Data handling: where data is stored geographically, what sub-processors touch it, retention and deletion, and whether customer data is used for training anything.
• Logging and monitoring: what is logged, how long it is kept, whether the customer can get their own audit trail.
• Software development lifecycle: code review, testing, separation of duties, dependency and vulnerability scanning, how changes reach production.
• Vulnerability management: scan cadence, remediation SLAs by severity, and the date of your last penetration test.
• Incident response: your plan, your notification commitment and timeline, and evidence you have exercised it.
• Business continuity: backups, restore testing, RTO and RPO, and when you last actually restored something.
• Sub-processors and fourth-party risk: your own vendor list and how you assess it.
• Compliance artefacts: SOC 2 or ISO 27001 report, penetration test summary, insurance certificate, and your policy set.

A trust center moves the work upstream

The highest-leverage change is to publish as much of this as you can before anyone asks. A trust center — a page carrying your certifications, sub-processor list, architecture summary, data handling description, uptime history, and a gated route to request the full report under NDA — does three things at once. It answers a meaningful share of questions before the spreadsheet arrives, and in a growing number of enterprises it removes the questionnaire entirely for lower-risk purchases. It shortens the sales cycle by letting a security team do their initial assessment on their own schedule rather than through your account executive. And increasingly it feeds AI-assisted vendor review, where the buyer's tooling reads your public documentation directly, which means a well-structured public page is now doing work that used to require a human on both sides. The cost is real but bounded: a page, a document set, an NDA workflow, and someone accountable for keeping it accurate. The failure mode to avoid is publishing aspirations — a trust center that overstates your controls is a liability with a URL, because it will eventually be read next to your audit report.

The questions where teams lose deals

A handful of items derail more deals than the rest combined, and they are worth knowing before you meet them. Enterprise SSO and SCIM provisioning: procurement frequently treats this as non-negotiable, and if the answer is 'on our roadmap' the deal stalls, which is why identity work tends to pay for itself in one contract. A customer-accessible audit log, for the same reason. Data residency, where the answer 'we run in one US region' ends conversations with European buyers regardless of your GDPR posture. Sub-processor transparency, which is where the AI question now lands hardest: buyers want to know exactly which model providers see their data, whether it is retained, and whether it trains anything, and vague answers here are treated as a red flag. Penetration testing, where 'we run automated scans' is not an acceptable substitute for a third-party test with a report. And the compliance artefact itself, since below a certain deal size a SOC 2 Type I plus a credible Type II timeline is usually enough, and above it the absence of a report is simply disqualifying. None of these are surprises, which is the point: you can decide deliberately which ones to build before a deal depends on them, or discover them one lost quarter at a time.

Running the process without burning your engineers

Even with a library, questionnaires need an owner and a route. Give one person accountability for the response — often a security-minded engineering lead rather than the CTO — with named subject-matter experts they can pull in for the handful of genuinely novel questions. Set an internal turnaround target of three to five business days and treat a miss as a process problem rather than an individual one. Push back, politely, on questionnaires that are wildly disproportionate to the deal, since offering your trust center plus your SOC 2 report in place of a three-hundred-item spreadsheet is accepted more often than teams expect. Track which questions you cannot answer well, because that list is the most honest security roadmap you will ever be handed — it is written by the people whose approval you need. And close the loop after every deal by folding the new questions into the library, so the cost curve keeps falling instead of resetting.

How Infiniti Tech Partners approaches this

This work usually reaches us attached to a stalled deal, and it splits cleanly into two halves. The first is process: standing up the answer library, drafting the trust center from your actual architecture rather than from a template, and assembling the evidence set so the next questionnaire is a retrieval exercise. That half is fast and its effect is immediate. The second half is the gaps the questionnaire exposed — the access controls that are not time-bound, the audit log the customer cannot see, the SSO you do not support, the penetration test you have not had — and those are engineering projects with real timelines, which we scope individually and run in the order that unblocks the most revenue rather than the order that reduces the most abstract risk. We would rather tell you that three of the fifteen gaps are worth fixing this quarter than sell you a programme to close all fifteen. If you have a spreadsheet on your desk right now and a close date attached to it, that is a well-bounded piece of work and the answer library outlives the deal that prompted it.