The first enterprise security questionnaire arrives about a week after the deal starts looking real, it has between 80 and 300 questions, and it is due in five business days.
The instinct is to answer everything "yes" and move on. Do not. Security questionnaires get read by people who compare your answers to your documentation, and a yes you cannot evidence turns a procurement step into a trust problem. The teams that clear these fastest are not the most secure ones — they are the ones who prepared five artefacts in advance and are comfortable writing "no, and here is the compensating control."
Strip the formatting and nearly every questionnaire — SIG Lite, CAIQ, a bank's bespoke spreadsheet, a one-page startup version — is asking the same six things.
1. Who can reach our data, and how do you know? Access control, offboarding, least privilege, and whether anyone reviews the list. The follow-up is always "how often do you review it", and the honest answer for most small teams is "never", which is why this is the first thing to fix.
2. What happens when you are breached? An incident response plan, a notification commitment with a number of hours in it, and who the contact is. Buyers care less about your plan being sophisticated than about it existing and having a name attached.
3. How do you find and fix vulnerabilities? What you scan, how often, and your remediation windows by severity. Increasingly they ask for the numbers, not the policy — your on-time closure rate. See remediation SLAs.
4. How does code get to production? Review requirements, branch protection, separation of environments, whether anyone can push straight to main.
5. Where does the data live and who else touches it? Hosting regions, encryption at rest and in transit, your subprocessor list, and your data processing agreement.
6. Do you have a certification? SOC 2 Type II, ISO 27001, or a credible date by which you will. This one question routes the rest: a valid report often collapses a 250-question spreadsheet into "please send the report."
Build these once and most questionnaires become an afternoon rather than a week.
A trust page. One public URL listing hosting, subprocessors, encryption, certifications and status. Half of what a buyer asks is already public information about your stack — let them self-serve it. This also gets read by the next buyer, who never files a ticket at all.
A subprocessor list with a change policy. Every third party that touches customer data, what they process, and where. Keep it in version control so its history is the evidence for "how do you notify us of changes."
A four-document policy set. Information security, access control, vulnerability management (with the severity table in it), incident response. Two pages each. The set answers perhaps 40% of a typical questionnaire on its own.
A current access list. Every human with production access, per system — including the ones nobody thinks of as production: the error tracker, the analytics tool, the CI provider, the DNS registrar.
A dated vulnerability record. For a sample of findings: when detected, who owned it, when closed. Not a screenshot of a dashboard — a record with dates in it. This is the artefact almost nobody has, and the one that turns a soft "yes we scan regularly" into something a reviewer can verify.
Most questionnaires have a comment field next to every question. It exists precisely so you can answer honestly, and reviewers read it.
The structure that works: no, here is what we do instead, here is when that changes.
Do you enforce SSO with SAML for all workforce applications?
No. We are a seven-person team on Google Workspace with mandatory 2FA and hardware keys for anyone with production access. Application access is provisioned individually and reviewed quarterly; the current list is maintained in version control. SAML SSO is on our roadmap for Q2 2027, driven by headcount rather than by this review.
That answer will pass at most companies. "Yes" — from a seven-person team that plainly does not run an identity provider — will not, because the reviewer's next question is for evidence.
Two rules:
Never claim a certification you do not hold. "SOC 2 compliant" means nothing; "SOC 2 Type II report, observation window January–June 2026, available under NDA" means something. Reviewers know the difference and treat the first as a warning sign.
Never claim a control you cannot evidence. If a question asks whether you scan for vulnerabilities and you cannot produce dated detection and closure records, the honest answer is what you actually do and when it started.
From what small teams get stuck on, roughly in order:
| Question | The realistic answer |
|---|---|
| Do you have SOC 2 Type II? | If not: name the target window and what you have already collected. A credible date beats a vague yes |
| Do you perform annual penetration testing? | Most small teams do not. Say so, and describe continuous automated scanning plus your remediation windows as the compensating control |
| Do you enforce SSO/SAML? | Usually no below ~20 people. Describe 2FA enforcement, hardware keys for production access, and quarterly reviews |
| Do you have a documented incident response plan? | Write it — two pages. There is no acceptable substitute and it is a day of work |
| What is your breach notification timeline? | Commit to a number. 72 hours is the common contractual standard; do not promise 24 unless you have on-call |
| Do you encrypt data at rest? | Almost certainly yes via your database provider. Name the provider and the mechanism rather than just ticking the box |
| Do you maintain an audit log of administrative actions? | Say whether it is append-only. A log an admin can edit is a log a reviewer will discount |
| Do you review access quarterly? | If you have never done one, do one this week, then answer yes with a date |
The compounding move is to keep every answer you have ever written, keyed by the question's meaning rather than its wording. The same six themes come back phrased forty different ways; a bank of 60–80 canonical answers covers most of a new 200-question spreadsheet by search-and-adapt.
Two disciplines keep it from rotting:
Being precise, because the honest scope here is narrower than most vendors imply.
It helps with: the vulnerability-management questions, which are the ones where reviewers increasingly ask for numbers rather than prose. Dated detection and closure records, remediation windows by severity, an on-time rate you can state. Also the "do you monitor your external attack surface" family — TLS configuration, security headers, exposed credentials, publicly readable data stores.
It does not help with: access reviews, incident response, HR controls, vendor management, business continuity, or your risk register. Those are writing and process. Any tool implying otherwise is selling you a checklist with a logo on it.
For the part it does cover, what CheckVibe gives a team is the record rather than the dashboard: SLA policies with due dates materialised at first detection, shared triage with assignment and an activity trail, and an append-only audit log the database refuses to update — 180 days on Team Basic, a year on Team Advanced. Team Advanced adds SOC 2 and ISO 27001 evidence reporting, with reports frozen and hashed at generation, and controls it cannot evidence marked as unsupported rather than quietly omitted.
Team plans start at $25 per seat per month with a five-seat minimum. The pricing page has the split, and SOC 2 evidence for small teams covers what an auditor asks for in more detail.
The first one takes three to five working days for a small team, because you are writing the policies as you go. With a trust page, a four-document policy set, an access list and an answer bank prepared, subsequent ones take two to four hours. That gap is the entire argument for preparing the artefacts before a deal depends on them.
Yes, and it is usually the right move when it is true. Use the comment field: no, here is the compensating control we run instead, here is what would change that. A documented no with a real alternative passes review at most companies; an unevidenced yes fails it, because the reviewer's next step is to ask for proof.
Not always, but it shortens everything. Without a report you get the long questionnaire and a security review call; with one, many buyers accept the report plus a short supplemental set. Below roughly $50k annual contract value, buyers are often willing to accept a credible target date and a strong questionnaire. Above it, the report usually becomes a hard requirement.
SIG (Standardized Information Gathering) is a Shared Assessments questionnaire, widely used in financial services, with a shorter SIG Lite variant. CAIQ (Consensus Assessments Initiative Questionnaire) comes from the Cloud Security Alliance and maps to their Cloud Controls Matrix; a completed CAIQ can be published to the CSA STAR registry. Both ask the same underlying six things, so an answer bank organised by theme serves either.
Hosting provider and regions, encryption at rest and in transit, your subprocessor list, certifications and their status, your security contact and disclosure policy, and a link to a live status page. Keep it public and current. It answers a meaningful share of most questionnaires before anyone files one, and the buyers who read it and never ask are the point.
State it plainly, then describe what you do instead: continuous automated scanning of the deployed application with a stated frequency, remediation windows by severity, and your on-time closure rate. Add whether a pen test is planned and when. Reviewers accept compensating controls far more readily than they accept a yes that unravels when they ask for the report.
The vulnerability-management section of a questionnaire is the one you can answer with a number. CheckVibe records detection and closure dates, SLA windows and an append-only audit trail on both team tiers. See what teams get, or scan your app free.
Paste your URL and get a security report in 30 seconds — 100+ automated checks with AI-ready fix prompts.
Related articles
What a SOC 2 auditor actually asks a five-person engineering team for, which controls you can evidence automatically, and which ones need a human.
How to set remediation deadlines by severity, when the clock should start, and why measuring from triage instead of detection inflates every number.
A short, enforceable policy for Copilot, Cursor and Claude Code on a real codebase: what to allow, what to gate in review, and which rules to skip.