What a defensible answer looks like, the confident answer that quietly overstates it, and what each gap actually costs to close. Written for the five-to-fifty-person software company whose first enterprise deal just stalled on a spreadsheet.
A vendor security questionnaire is not a test you pass by scoring highly. It is a disclosure you sign. Whatever you write becomes a statement of fact in someone else's vendor file, referenced at renewal, and quoted back at you if anything ever goes wrong.
Which changes the strategy completely. Founders assume the goal is to answer yes to everything, so they stretch: single sign-on becomes "MFA enforced", a backup schedule becomes an RPO, a code review becomes a security review. Every one of those is a small false statement with a long shelf life.
The thing nobody tells you at this stage.
An honestly disclosed gap with a remediation date attached tends to survive procurement better than a sheet of confident yeses. Reviewers are assessing whether you are a competent, candid counterparty — not whether you are a bank. Two "not yet, here is when" answers read as maturity. One overstated yes that unravels in a follow-up call reads as something much worse.
Where these claims come from, and where they don't.
Everything below about standards, prices and vendor behaviour is cited — follow the source line under each fix. Everything about how reviewers react — what passes, what gets bounced, what a reviewer will probe — is my own judgement from 35 years on both sides of these assessments. There is no published research on procurement reviewer decision-making, so treat those parts as informed opinion rather than established fact, and weigh them accordingly.
Below are seventeen controls that recur across questionnaire formats — SIG, CAIQ, HECVAT, or a procurement team's own spreadsheet. For each: what they are really asking, the answer that overstates, the answer you can defend, and what closing the gap costs if you cannot.
Ranked by cost to close, not by importance. Sixteen of the seventeen cost time rather than money — only the penetration test carries a real invoice.
| # | Control | Cost to close | Why it is worth doing first |
|---|---|---|---|
| 03 | Offboarding checklist | 2 hours | Writing down what you already do makes it a control. |
| 04 | Encryption & key management | 2 hours | Mostly finding out what key type you actually have. |
| 02 | Access review | half a day | Run one, record it, schedule the next. Now it exists. |
| 06 | Recovery objectives & tested restore | half a day | You already have backups. This makes them answerable. |
| 11 | Subprocessors & DPAs | half a day | Also a GDPR obligation you may already be missing. |
| 17 | Data deletion & return | half a day | Universally asked, almost never prepared for. |
| 13 | Attestation status & roadmap | half a day | Usually question one. Answer it deliberately, not defensively. |
| 07 | Log retention & security alerting | 1 day | 30-day logs sit below what most buyers ask for. |
| 08 | Vulnerability SLAs | 1 day | You scan already. Write down the deadlines. |
| 15 | Awareness training & screening | 1 day | Cheap, evidenceable, and on nearly every questionnaire. |
| 01 | MFA on admin access | 1 day | Check what is genuinely federated before you answer. |
| 05 | Incident response plan | 1–2 days | The highest-value day and a half on this list. |
| 10 | Static analysis in the pipeline | 1–2 days | Converts a vague answer into evidence. |
| 12 | AI & LLM data handling | 1–2 days | Fastest-growing section. Start the provider paperwork now. |
| 14 | Policy set & named owner | 1–2 days | Every framework asks who owns security. Name someone. |
| 16 | Endpoint & device security | 2–5 days | The one most small teams genuinely cannot evidence. |
| 09 | Third-party penetration test | 6–12 wks · $5k–$50k | The expensive one. Often negotiable as a commitment. |
Add the sixteen time-only estimates together and you get roughly sixteen person-days — about three weeks for one person, or a single hard week if three people split it. That is a real project, not an afternoon. But it is finite, it is cheaper than the deal you are trying to close, and it is a far better use of the time than drafting careful language around gaps you could simply have closed.
"Is multi-factor authentication enforced for all administrative and privileged access to production systems?"
"Yes — we use SSO."
Single sign-on is an authentication path, not a second factor. If your identity provider does not require MFA, and the console can still be reached with a password, the answer is no. In my experience this is the most common false yes on any questionnaire.
"Yes. MFA is enforced organisation-wide at the identity provider, and production console access is federated through it, so no administrative path bypasses it."
If a break-glass root account exists, say so, and describe how it is stored and monitored. Reviewers expect one; hiding it is worse than disclosing it.
Enforce MFA at the identity provider for all staff, then verify no direct console login bypasses the federation. Inventory service accounts and long-lived API keys separately — they are the usual gap, and they are what a reviewer will ask about second.
"Are user access rights formally reviewed at least annually, and is the review documented?"
"Yes — only three people have production access and we all know who they are."
Knowing is not reviewing. The question asks for a repeatable process with an artefact. A small team makes the review easy, not unnecessary.
"Yes. Access to production systems is reviewed quarterly by the CTO against current role assignments, with the CTO's own access attested by the CEO. The review is recorded and removals are actioned within one business day."
That second clause matters. At your size the person running the review is usually the person who grants access, and a reviewer will ask who reviews the reviewer.
List every system holding customer data, list who has access to each, confirm each person still needs it, remove what is stale, save the list with a date. That is a compliant access review. Put the next one in the calendar before you close the file.
"Describe your process for revoking access when personnel leave or change roles. What is the target timeframe?"
"Access is removed immediately on departure."
"Immediately" is a claim you will be asked to evidence. If offboarding is one person remembering, the honest word is "same day, manually" — which most reviewers accept far more readily than an "immediately" you cannot demonstrate.
"Departures follow a documented offboarding checklist covering identity provider, code repository, cloud console and third-party tools. Target is same business day, executed by the COO, with completion recorded."
The checklist is the control. Naming the owner is what makes it credible.
Write the checklist. Every system, in order, with a tick box and a date field. It takes an afternoon and converts an informal habit into a documented control you can evidence for years.
"Describe your encryption of data at rest and in transit, including key management and rotation frequency."
"All data is encrypted at rest with AES-256, keys are rotated regularly, and we use TLS 1.2 or above."
"Regularly" with no schedule configured means never. "Or above" is the vague hedge this whole document argues against — it tells the reviewer nothing about whether TLS 1.3 is offered or whether weak 1.2 cipher suites are disabled. And the question has three parts; key handling is where most people quietly fail.
"At rest: AES-256 via AWS KMS using AWS-managed keys, which AWS rotates on its own schedule; customer-managed and bring-your-own keys are not currently offered. In transit: TLS 1.3, with TLS 1.2 retained as a floor for legacy clients; TLS 1.0/1.1 and non-forward-secret cipher suites are disabled. Internal service traffic stays within a private VPC."
Say which key type you have. The two cases have genuinely different answers, and mixing them is the tell.
First find out what you actually have — that is the real hour of work. AWS-managed KMS keys rotate automatically about every year and you cannot enable, disable or configure it. Customer-managed keys are the only ones where rotation is yours to turn on, and since April 2024 the period is configurable anywhere from 90 to 2,560 days. Note that KMS rotation rotates key material only; it does not re-encrypt existing data, so do not imply more than it delivers. Then check your storage buckets and database snapshots are actually encrypted — snapshots are frequently missed.
AWS KMS key rotation documentation · NIST SP 800-52 Rev. 2 (TLS 1.3 required for federal servers since 1 Jan 2024)"Do you maintain a documented incident response plan? How frequently is it tested, and what is your customer notification commitment?"
"Yes, we have an incident response process."
A process that exists only in your head is not documented, and a request for a copy usually follows quickly. Note too that the notification-timeframe half of this question is contractual — it belongs to your lawyer, not to you.
"Yes. A documented incident response plan covering detection, escalation, containment, customer notification and post-incident review is maintained, with named owners. It was last exercised in [month]. Contractual notification timeframes are addressed in our DPA."
Splitting the technical answer from the contractual one is exactly what a good reviewer wants to see.
One page is enough: who declares an incident, who they call, how you contain it, when and how customers are told, and what you do afterwards. Then run a thirty-minute tabletop against a plausible scenario and note the date. Highest-value day and a half on this list — the control is asked for constantly and costs nothing but attention.
"What are your RTO and RPO for the production environment, and when did you last test a restore?"
"We take automated daily backups retained for 30 days."
That answers a different question. A backup schedule is not a recovery point objective, and an untested backup is a hypothesis. Relevant evidence, wrong answer — and in my experience the most common category error on any questionnaire.
"RPO is 15 minutes, based on point-in-time recovery on the production database; snapshots are retained 30 days as a secondary. RTO is 4 hours. A restore into a non-production environment was performed and timed in [month] at 47 minutes, excluding detection and DNS failover."
If you have never tested one, say the objectives are defined but not yet validated. Never imply a tested capability you do not have.
Time a restore into staging. That number is your Recovery Time Actual — your evidence, not your objective. Set the RTO deliberately above it with headroom, as a business decision about what outage you can tolerate, and state what the test excluded: detection time, declaration, DNS and failover, cache warm-up, and production data volume. For the RPO, your snapshot interval is worst-case data loss — but if point-in-time recovery is enabled, which it is by default on most managed databases, your true recovery point is minutes, not a day. Do not understate a capability you already have.
"What security-relevant events are logged, how long are logs retained, and how are they monitored for suspicious activity?"
"We use a monitoring tool with alerting configured."
Performance alerting is not security monitoring. If nothing pages anyone on a failed-login spike or an unexpected privilege change, the monitoring half of this answer is no.
"Authentication events, privilege changes and administrative actions are logged centrally and retained for 12 months, with the most recent 3 months immediately searchable. Alerts fire on authentication anomalies and privilege escalation, routed to an on-call engineer. We do not currently operate a SIEM."
Naming what you do not have stops the reviewer imagining something worse.
Extend retention on security-relevant log groups to twelve months — cold storage makes this cheap. Then add two or three alerts that actually page someone: repeated failed logins, a new admin role granted, root account used.
Be precise about why twelve months. PCI DSS 4.0 requirement 10.5.1 is the only mainstream framework that names a period — twelve months retained, three immediately available for analysis. SOC 2, ISO 27001 and NIST SP 800-53 (AU-11) set no fixed period and leave it to you to define and defend. Twelve months is the number that stops the follow-up question, not a universal legal minimum.
PCI DSS v4.0 req. 10.5.1 · NIST SP 800-53 AU-11 (organisation-defined)"How do you identify vulnerabilities, and what are your remediation timeframes by severity?"
"We have automated dependency scanning enabled. Managed infrastructure is patched by the provider."
Scanning is detection; the question asks about deadlines. And the second sentence is a shared-responsibility error: you schedule RDS maintenance windows, you run major-version upgrades before end of life, you upgrade EKS control planes and node images, you migrate off deprecated Lambda runtimes. That sentence invites "show me your engine-version currency report."
"Dependency and container scanning run on every build. Remediation targets: vulnerabilities on the CISA Known Exploited Vulnerabilities catalogue or internet-exposed criticals, 14 days; other criticals, 30 days; high, 60 days; medium, 90 days. Exceptions require documented sign-off. Managed services are patched by the provider within maintenance windows we schedule; we track engine and runtime versions against provider end-of-support dates."
Pick timeframes you will actually meet. A missed SLA you set yourself is worse than a longer one you hold.
Write the severity tiers and deadlines, agree them with whoever does the work, then triage the existing backlog so the policy is not false on day one.
Two anchors worth knowing. PCI DSS 4.0 requirement 6.3.3 requires critical and high-risk security patches within one month. CISA Binding Operational Directive 26-04, issued 10 June 2026, replaced the old CVSS-tiered approach with a risk matrix — as short as 3 days where a known-exploited vulnerability yields total system control, 14 days for most KEV entries, 60 days for lower-risk combinations. It binds federal agencies, not you, but it is where enterprise reviewers' expectations are drifting, and an exploitation-based override is increasingly what they look for.
PCI DSS v4.0 req. 6.3.3 · CISA BOD 26-04 (10 June 2026) · NIST specifies no fixed timeframes"Do you undergo annual third-party penetration testing? Provide the most recent report or executive summary."
"Yes — we run regular automated security scans."
An automated scanner is not a penetration test, and the evidence request that follows exposes it immediately. Having tried costs you credibility on every other answer on the sheet.
"Not yet. An external application penetration test is scheduled for [quarter] with [firm]. In the interim, all code is peer-reviewed before merge and dependencies are continuously scanned. We will share the executive summary when available."
A dated commitment with a named firm is a real answer, and many reviewers will accept it as a contractual condition rather than a blocker.
Scope a test against your production web application and API — you do not need an enterprise-wide engagement. Published 2026 ranges run roughly $5,000 to $50,000 for web application testing depending on scope and firm, with API-only work at the lower end.
Budget the calendar honestly: 2–6 weeks to scope, contract and get a slot, 1–2 weeks of testing, 1–2 weeks for the report, then your remediation and a retest. Six to twelve weeks end to end. Book it before you answer, so the date in your answer is real.
Published 2026 penetration testing price surveys"Describe your secure software development lifecycle, including code review and application security testing."
"All code is peer-reviewed before merge, and we follow secure coding practices."
Peer review catches bugs; it is not a security review unless someone is looking for security defects specifically. "Secure coding practices" with nothing behind it is a phrase experienced reviewers discount.
"All changes require peer review before merge to main. Static analysis runs on every pull request and blocks on critical findings. Dependencies are scanned continuously. We do not currently run dynamic application security testing or maintain a formal threat modelling process."
Two concrete controls plus an honest omission beats four vague claims.
Wire static analysis into the pipeline as a required check — and budget for it honestly, because "it's free" is only true for public repositories. GitHub CodeQL is free on public repos; on private repos it requires GitHub Code Security at roughly $30 per active committer per month. GitLab's free tier runs SAST but the merge-request gating and vulnerability management are Ultimate-only, so you can scan but not block.
Free options that do work in a private pipeline: Semgrep OSS, language-native security linters, and Trivy for containers. Dependency scanning genuinely is free almost everywhere — do not confuse that with SAST.
GitHub Code Security pricing · GitLab SAST tier documentation"List all third parties that process customer data, and confirm data processing agreements are in place with each."
Listing the obvious three — cloud host, payment processor, email — and stopping.
The list is almost always incomplete. Error tracking, session replay, support chat, analytics and any AI provider all touch customer data. An omission found later reads as concealment rather than oversight.
"A current subprocessor list is maintained and published at [URL], covering hosting, monitoring, error tracking, payments, support tooling and AI services. A data processing agreement is executed with each."
Do not add a notice commitment here without counsel. Thirty days' notice of new subprocessors is a common market term, but GDPR Article 28 requires authorisation and an opportunity to object without setting any period — so it is a contractual promise, not a security fact, and it belongs in the DPA.
Open your billing statements and your application's outbound integrations, and write down everything that could see customer data. Check you have a DPA with each — most vendors publish one you can accept online. Publish the list; it answers this question permanently and pre-empts the next three.
"Do you use AI or large language model services to process customer data? Describe retention, training use, human review, and your governance framework."
"We use AI features, no customer data is used for training, zero-retention terms are in place and no human review occurs."
This is the most dangerous answer on the whole sheet in 2026, because it is the one most likely to be false without the person writing it knowing. Provider retention and safety-review policies have moved, and several of them now override customer zero-retention terms. Writing all four clauses as flat absolutes is exactly the failure this document exists to prevent.
"Yes. [Feature] sends customer content to [provider]'s API under our commercial agreement. Inputs are not used for model training. Retention is [N] days under the provider's current safety-retention policy; zero-retention terms apply to [endpoints / are under application]. Human review occurs only where the provider's automated safety systems flag content, per their published policy. The provider is listed as a subprocessor and the feature can be disabled per tenant on request."
Per-tenant disablement is often what unblocks a reviewer who is uncomfortable. And check the provider's current policy the week you answer — this is the fastest-moving section of any questionnaire.
Read your provider's current retention and safety-review policy before writing anything, and note the date you read it. Zero data retention is not a checkbox at any major provider: at OpenAI it is a sales-gated eligibility approval that is scoped to particular endpoints; at Google it is a per-project approval, and grounding with Search or Maps can never be zero-retention. Anthropic's policy for covered models, effective 9 June 2026, retains inputs and outputs for 30 days and permits human review of safety-flagged content, and that supersedes pre-existing zero-retention agreements — including through cloud resellers.
Then write down which data actually leaves your environment, add the provider to your subprocessor list and DPA, and build the per-tenant kill switch. Note that AI is now a named risk domain in the SIG standard and CSA publishes a dedicated AI Controls Matrix, so this section will keep growing.
Anthropic covered-model retention policy (eff. 9 June 2026) · OpenAI ZDR eligibility documentation · Google Gemini ZDR documentation"Do you hold a current SOC 2 Type II report or ISO 27001 certification? Please attach."
"We are SOC 2 compliant." Or worse, "SOC 2 in progress" with no dates.
There is no such thing as being SOC 2 compliant — there is a report, for a named period, by a named auditor, with a scope and possibly exceptions. "In progress" without dates is the phrase reviewers have learned means nothing has started. This is usually the first question on the sheet and it sets the tone for how carefully the rest gets read.
"Not yet. Our SOC 2 Type II observation period runs [dates] with [auditor], and the report is expected [month]. A Type I report is available now under NDA. We can share our control matrix and evidence of the controls in this questionnaire in the meantime."
Or, with genuinely nothing started: "No current attestation. We have scoped a Type II for [quarter]. Below is what we do have." Then answer the rest well — that is the argument.
Decide, and put dates on it. Published 2026 figures for a small startup's Type II audit fee vary widely by source — roughly $8,000 to $50,000 for the audit alone, with total first-year cost including tooling, a penetration test, internal time and remediation typically two to three times that. Know your own number before a reviewer asks when you will have one.
Half a day here is writing the roadmap, not doing the audit. A dated plan is answerable; "we're looking into it" is not.
Multiple published 2026 SOC 2 cost surveys; ranges differ materially by source"Do you maintain a documented information security policy? Who is accountable for security, and when were policies last reviewed and approved?"
"Yes, security is everyone's responsibility and our policies are documented internally."
"Everyone's responsibility" answers the opposite of what was asked. The question wants a name and a date. Undated policies are treated as no policies.
"Yes. An information security policy set covering access control, acceptable use, data classification, incident response and vendor management is maintained, owned by [name, role], and reviewed and approved annually — most recently [date]. All staff acknowledge it on joining and at each annual review."
One named accountable person is worth more here than a thick document. Reviewers are checking that security has an owner, not that you have prose.
Name the accountable person first — that costs nothing and is half the answer. Then write short policies rather than long ones: two pages each, covering what you actually do, dated and approved. A five-page policy set that is true beats a fifty-page one lifted from a template that describes a company you are not.
"Do all personnel receive security awareness training at hire and annually? Are background checks performed prior to employment?"
"Yes, the team is security-aware — we're a security-conscious company."
Neither half of the question was answered. Both halves want evidence: a completion record and a screening policy. This is one of the cheapest controls to close and one of the most commonly left blank.
"Yes. All staff complete security awareness training at onboarding and annually, with completion recorded; the most recent cycle completed [date] at [N]% completion. Background screening appropriate to jurisdiction is performed before start date for all employees; contractors are screened under the same standard."
If screening is not performed, say which jurisdictions make it impractical rather than leaving it blank. A blank reads as no.
Run one training cycle — an hour of content and a signed acknowledgement is a legitimate answer at your size — and record who completed it and when. Write a one-paragraph screening policy stating what you check and for which roles. Both are evidenceable the same week.
"How are company and personal devices with access to customer data secured? Address disk encryption, screen lock, endpoint protection, patching and remote wipe."
"Everyone's on Macs, so disks are encrypted."
FileVault is not on by default on every machine, and without device management you cannot attest to it, evidence it, or remotely wipe a laptop that leaves the building in someone's bag. This is, in my experience, the control small remote teams are least able to evidence and most confident about.
"All devices with access to production or customer data are enrolled in mobile device management, with full-disk encryption enforced, screen lock at 5 minutes, endpoint protection deployed, OS patching enforced within [N] days, and remote wipe available. Personal devices are not permitted access to customer data."
If you allow personal devices, say so and describe the compensating control. Reviewers dislike surprises far more than they dislike BYOD.
This is the one genuinely multi-day item that is not the penetration test. Roll out device management across the fleet, enforce encryption and screen lock centrally, and produce a device inventory. Two to five days depending on how many machines and how much resistance. Do it before a laptop goes missing, not after.
"On contract termination, how is customer data returned or destroyed, within what timeframe, and how is destruction evidenced?"
"Customer data is deleted immediately on request."
Almost never true, and it contradicts your own backup answer. If snapshots are retained 30 days, deleted data persists in backups for 30 days — a reviewer who reads both answers will notice, and an inconsistency found by the reviewer costs more than the gap itself.
"On termination, data is exported in [format] on request within [N] days. Primary-store deletion occurs within [N] days of the request; residual copies in encrypted backups expire on the standard 30-day cycle and are not restorable to production. Written confirmation of destruction is provided on request."
Naming the backup lag is what makes this answer credible rather than clever.
Work out what deletion actually does in your system — primary store, replicas, backups, logs, analytics, and any third party you send data to. Write the timeframes down, including the backup tail. Then check you can actually produce an export in a usable format, because that half of the question is usually the one that fails in practice.
Take every yes and ask what evidence you would produce if it were requested tomorrow. Any yes without an artefact behind it is a flag, not an answer.
Questionnaires ask the same thing three different ways on purpose. Contradicting yourself between question 40 and question 190 is, in my experience, the most common reason a submission comes back — and it costs you another week.
Indemnification, breach-notification windows, insurance limits, right-to-audit and data-residency guarantees are commitments for your counsel. But where data is stored and processed, including by every subprocessor, is a factual question and squarely yours. Do not punt the technical half to a lawyer who cannot answer it.
Most of the list above is days rather than dollars. Close what you can, and give every remaining flag an owner and a date. A questionnaire with four dated commitments reads very differently from one with four blanks.
I spent 35 years as a senior network security analyst inside a bank — firewalls, access control, SIEM and the audit cycle across a six-country footprint, under continuous regulator scrutiny. CISSP and CCSP certified.
Send me the questionnaire and whatever evidence exists, and you get it back completed in their format. Every answer your evidence does not support comes back flagged rather than invented, with the honest answer, the smallest fix, and the effort estimate — the same structure as the seventeen above, applied to your actual environment.
This page is free and stays free. Use it, send it to whoever on your team drew the short straw, and close what you can before you submit.
On the figures. Standards and prices move, so each is version-pinned rather than stated as permanent. In the 2025 SIG release, the Lite, Core and Detail presets contained 128, 627 and 1,936 questions respectively; the current release is SIG 2026 (September 2025), for which Shared Assessments has not published counts. Treat all of these as scoping presets rather than fixed properties — Shared Assessments' own guidance is that you select risk domains and mix scope levels, so a "SIG" can be almost any length. The SIG carries 21 risk domains, including a dedicated Artificial Intelligence domain added in the 2024 release. For CAIQ, v4.1 (January 2026) is current at 283 questions mapped to CCM v4.1's 207 controls across 17 domains, superseding v4.0.x's 261; CAIQ-Lite is 138 questions. CSA also publishes a separate AI Controls Matrix. HECVAT is maintained by EDUCAUSE and, since version 4, the former Full, Lite and On-Premise editions are consolidated into a single conditional workbook.
On the estimates. Effort figures assume a small engineering team on managed cloud infrastructure and are planning figures, not commitments. Penetration testing and SOC 2 prices are drawn from published 2026 surveys that differ materially from one another; both are given as ranges for that reason.
On what is opinion. As stated at the top: the claims about how reviewers react are my professional judgement, not published research. Nothing here is legal advice — the contractual questions flagged above genuinely belong with your counsel.
Last verified: 26 August 2026. Provider AI retention policies in control 12 in particular are moving quickly; check the provider's current published policy the week you answer.