How to answer a security questionnaire without stalling the deal or overpromising
Most security questionnaires show up as a spreadsheet in someone’s inbox, or as a portal link with a hard date attached. Nobody is grading your prose. They want answers you can stand behind, in the file they already built.
So how do you answer a security questionnaire without stalling the deal or inventing controls you do not have? Run it as a small response process: gather what you already know, draft from that, get a human to sign off on the risky rows, then hand back the buyer’s workbook.
Speed alone is not the win. A quick “yes” can create commitment risk. That is when an answer promises a timeline, scope, service level, or operational practice the company may later be expected to honor. Deals slip for the scramble too. More on that in why security reviews kill revenue.
What is a security questionnaire?
Buyers use these forms to decide whether you are a safe vendor. The rows jump around: access control one minute, retention the next, then subprocessors, incident response, encryption, business continuity.
Sometimes it is a homemade Excel file. Sometimes it is a Shared Assessments SIG. Cloud-heavy buyers often send a CSA CAIQ. The wrapper changes. Your job does not. Answer from evidence you trust, watch the rows that sound like contract language, and return the thing they sent you.
How do you answer a security questionnaire step by step?
You do not need a platform to start. A lean team can get through this with a shared Drive folder, email, Slack, and one person who owns the deadline. The stages below are ordinary ops work, not product features.
1. Intake: freeze the ask
Write down the basics before anyone starts typing answers.
Who is the buyer. Who owns the deal on your side. When is it due, and what is your internal cutoff (usually a day or two earlier). Is this an xlsx, a portal, or a PDF someone will have to turn into a working sheet. Which product or environment is in scope.
If “all products” and “this SKU only” would produce different truths, ask once. Then stop renegotiating scope in Slack three days later.
2. Triage: sort rows before you draft
Skim the whole file first. Do not start at row one and hope.
Some rows you have answered before: encryption, SSO, logging. Some need a named owner in legal, privacy, eng, or security. Some are N/A for a SaaS company (physical cage questions, mainframe leftovers). Mark those with a short why.
Then flag the commitment-risk rows. Fixed SLAs. “All data.” Absolute timelines. Anything that sounds like it could get pasted into an MSA later. Those are the ones that blow up if someone fills them under deadline pressure.
3. Gather current evidence first
Open the docs before you open a blank cell.
Policies with versions. The SOC 2 you are willing to share under NDA. A data-flow or architecture note for the product in scope. Subprocessor list. DPAs. The last questionnaire a human actually approved, not the random copy in Downloads.
If the “source of truth” is six folders named final_v3, you will re-answer last year’s guess and call it progress.
4. Draft from evidence, not from memory
Check approved policies and prior responses before inventing new wording. Already have something signed off? Reuse it. Starting fresh? Keep the draft short. Name the system in scope. Point at a source.
While the team is still working, leave the messy stuff visible on the inside. Missing evidence. Two docs that disagree. A system nobody has verified yet. That is fine in a working copy. It is not fine in the file you send.
Do not submit a row until someone has resolved that state. The buyer should get the verified current posture, not a mid-investigation note.
5. Review with the right owners
Send the hard questions to the person who actually knows. Keep one coordinator. Otherwise sales ends up pinging five threads and still missing the due date.
Before sending, have a second pair of eyes scan for absolutes, timelines that sound contractual, answers that contradict another tab, and big claims with no evidence next to them. That pass is dull. It is also how you avoid shipping a promise ops cannot run.
6. Complete and return the buyer’s file
Put the approved answers into their workbook or portal. Keep their structure, required fields, and formatting. Then do the unglamorous check: no empty required cells, no missing tabs, no forgotten attachment, no comment thread left hanging.
You are not rewriting their questionnaire in Notion and attaching a PDF. You are finishing their file.
7. Save what you learned
Drop the approved answers and the evidence you used into a shared place other people can find. Add enough context that the next person is not guessing which policy version you meant.
The next questionnaire gets easier because that material can be reused. Not because anyone typed faster.
What does a good security questionnaire answer look like?
For yes-or-no questions, start with Yes, No, Partial, or Not applicable. Then add scope. Then point at evidence.
That pattern matches the judgment in evidence before eloquence. Narrow and cited beats polished and fuzzy.
Hypothetical question
“Do you delete all customer data within 30 days of contract termination?”
Weak answer under deadline pressure
“Yes. All customer data is deleted within 30 days of termination.”
Here is where that labeled hypothetical falls apart.
Policy v3.1 of Data Retention and Deletion says production tenant data is deleted within 90 days of a verified termination request. Backups follow a different schedule. Analytics exports can stick around for up to 180 days. And last year’s sheet already said “30 days / yes” because someone needed the cell filled, not because the posture matched.
Safer cited answer
“No. Production tenant data is deleted within 90 days of a verified termination request, per Data Retention and Deletion Policy v3.1, §5. Backups follow the applicable retention schedule, and analytics exports may be retained for up to 180 days.”
The weak answer can clear the spreadsheet today and still create a redline, an ops mess, or a deletion request you cannot meet. The safer answer states what is actually true. That is usually cheaper than cleaning up an accidental promise.
What if you cannot say yes?
Say what is true.
No, plus what you do instead and what evidence exists. Partial, with clear coverage and clear outs. Not applicable, with a one-line reason tied to how you deliver the product.
If nobody can verify the current state yet, leave the row open on your side until someone can. Do not invent a certificate date to calm sales. If the gap is real and known, a short remediation note in the returned file can be fair. “We still need to check” belongs in internal review, not in what the buyer gets.
Which formats show up most often?
| Format | What it is | How to treat it | |---|---|---| | Custom Excel / Google Sheet | Buyer-built rows and tabs | Triage N/A early; keep their structure | | SIG / SIG Lite | Shared Assessments vendor risk questionnaire | Reuse domain answers; watch narrative commitment language | | CAIQ | CSA questionnaire mapped to cloud controls | Map to your cloud posture; keep scope tight | | Portal forms | Same questions in a web UI | Same review bar; still need owners and evidence |
You do not need a different religion for each format. Keep one shared set of approved answers by domain. Adapt the wording. Move on.
Habits that make the next questionnaire easier
Put approved answers and evidence somewhere shared, with owners and review dates. Name a coordinator even if the company is twelve people. Keep a short “always escalate” list: incident SLAs, insurance, subprocessors, AI data use, deletion timelines.
You do not need a full GRC suite for that. You do need to stop treating every questionnaire like a surprise fire drill.
Where software helps (and where judgment still wins)
Everything above is a manual method. Spreadsheets and folders can carry a light load. When the volume climbs, software can make the same process less painful: keep the project in one place, draft from sources you already approved, keep risk visible during review, and export completed answers into the buyer’s original format.
Someone still has to decide whether the answer is true, scoped, and safe to send.
That is the workflow Sorila is being built around. See how we are applying it as the product takes shape, or join the design partner program if you want early access.
Sources
- Shared Assessments, About Shared Assessments / SIG
- Cloud Security Alliance, Cloud Controls Matrix and CAIQ