GUIDE · TRUST
What buyers ask in a vendor security questionnaire
A vendor security questionnaire is the spreadsheet, portal or PDF between a small vendor and a signed contract. This guide lists the twelve questions behind almost every version, shows what a passing answer contains and what a failing one hides, and gives both sides a way to test answers against evidence. Buyers can score with it; vendors can build one folder from it.
The short answer. Almost every questionnaire reduces to twelve questions about access, data, patching, backups, incidents and people. Answer them once, publish the stable answers, and reuse the evidence: an access matrix, a patch log sample, a restore test record, a subprocessor list and an incident runbook.
What the questionnaire is actually measuring
Not whether you are secure in the abstract. It measures whether you describe your controls the same way twice, and whether anything behind them exists. A buyer sending forty questions needs a risk file they can defend to a committee, and vague answers read as risk. The NIST Cybersecurity Framework covers the same ground in other words.
The twelve questions, and what a passing answer looks like
1. Data classification and where it lives
Why. Their privacy notice depends on what you touch and where it lives.
Passing. Named categories, the systems holding each, the regions, retention, and what you never access.
Failing. “All client data is confidential” with no inventory, or “we store nothing” from a vendor with database access.
2. Access control and MFA
Why. A reused password on an admin panel is the shortest path into a client's store.
Passing. MFA on every account reaching production or client data, one per person, named owners.
Failing. “MFA available” on the admin login, a shared inbox password, or a second factor on email only.
3. Least privilege and offboarding
Why. They are measuring your blast radius, and what happens when a contractor leaves.
Passing. Role-based access, admin per task, a scheduled review, removal within a stated window.
Failing. Everyone has admin because it is easier, and nobody can say who could still log in.
4. Patching cadence
Why. Known-vulnerable plugins are the cheapest way into a small site.
Passing. A fixed schedule, a shorter window for critical releases, staging first, a rollback path.
Failing. “We update when we remember”, or automatic updates with no idea what breaks next.
5. Backup and restore testing
Why. A backup never restored is a hope, and an incident tests it before you do.
Passing. Frequency, retention, a copy outside the hosting account, a restore test with a date and a name.
Failing. “The host handles backups”, or a backup on the same server as the site.
6. Encryption in transit and at rest
Why. Credentials and order data cross networks you do not control; stored copies outlive the project.
Passing. TLS 1.2 or higher with HSTS, no legacy protocols, encrypted disks, and a named key owner.
Failing. “HTTPS is on” as the answer, with nothing about stored data.
7. Logging and monitoring with retention
Why. Detection is the difference between an incident and a discovery six months later.
Passing. Which events are logged, where logs go, retention, who reads them, how alerts reach a person.
Failing. Host logs only, one-week retention, or “we would notice” with no alert path.
8. Incident response and notification timelines
Why. Their breach notification clock starts when they learn, so your timeline becomes theirs.
Passing. A runbook, a named contact, an acknowledgement time, an update cadence and a post-incident report.
Failing. “We would call you”, 24/7 cover the team cannot staff, or no notification window.
9. Subprocessors and vendor management
Why. Their data sits inside your hosting, email and CDN, and they inherit those risks.
Passing. A published list with purpose, data category and region, notice before changes, a DPA with each.
Failing. “We use AWS, it is secure” as the answer, and changes made silently.
10. Software development and change control
Why. Many compromises arrive as a code, plugin or configuration change rather than a break-in.
Passing. Version control, review before merge, staging, a tested deploy, a rollback, secrets out of the repository.
Failing. Edits made live over FTP, no repository, or a plugin from a licence reseller.
11. Vulnerability management and testing
Why. They want evidence you look for your own holes before someone else does.
Passing. Recurring scans, an independent test annually, triage by reachability, map findings to the OWASP Top Ten, fix windows, retest. A scan is not a penetration test.
Failing. A plugin scan described as the programme, a PDF with no owners, findings never retested.
12. Security training and background checks
Why. People are the control that answers the other eleven.
Passing. An onboarding briefing, an annual refresher, a phishing exercise, and what you can lawfully check for contractors.
Failing. “Our team is experienced”, or a background-check claim with no provider or consent.
Build the folder once, then answer from it
Six artifacts carry most of the twelve answers, and none needs a consultant. Keep them in one folder, date each filename, and send the file instead of a paragraph.
| Artifact | Question | What buyers check |
|---|---|---|
| Access matrix | 2 and 3 | Every account, its privilege and owner. Shared logins and default admin go first. |
| Patch log sample | 4 | Three months of dates and versions, and whether critical releases waited for the monthly window. |
| Restore test record | 5 | Date, person, backup used, time to recover. Older than a quarter is a finding. |
| Subprocessor list | 9 | Service, purpose, data category, region, and whether it matches the DPA. |
| Incident runbook | 8 | Who is called, in what order, within what time, and whether the team can staff it. |
| Insurance certificate | Outside the twelve | The limit, the exclusions and the expiry. Cyber cover has to be named on it. |
Put the stable answers on one page
A security page does the repetitive work. Publish the answers that do not change per deal: access model, patch schedule, restore testing, subprocessor categories, incident timelines, and the certifications you do not hold. Date the page, name an owner, add a contact address.
Our version is the trust and security page. It says we do not hold ISO 27001 or SOC 2, that access is revoked within 30 days of project close, and that support runs 09:00–18:00 GMT+8, not a 24/7 rota. Those lines lose deals early and make the rest believable.
After that, a questionnaire is a link plus two or three deal-specific answers. Updates and restore checks are part of care from $129 a month if you would rather not run the schedule, and managed security versus in-house prices the build-or-buy choice at 20 people.
How to read the answers
Score evidence, not confidence: 0 for a claim, 1 for a policy, 2 for a dated artifact with a name and outcome. Two 2s on access and incident response beat twelve 1s.
“We take security seriously” is not a lie. It is an absence: the person has no artifact and is filling the gap with tone. Strong answers are boring — a version number, a date, an owner, a stated gap with a fix date.
Three follow-ups expose a paper programme:
- Send last quarter's restore test: the date, who ran it, how long recovery took. A paper programme cannot produce a date.
- Who reviewed the last change to a production system, and what did it catch? A named reviewer and a caught defect are hard to fake twice.
- Which control failed in the last year, and what changed? A programme with no failures is one nobody tests.
Say what is true, and what is planned
A small vendor cannot claim ISO 27001 without holding it. The claim has a shape: a certificate number, a scope statement, an accredited auditor. Procurement asks for all three; the check takes one email. Inventing it is the fastest way to lose the deal: the lie survives into the contract.
ISO 27001 is a management system before it is a certificate: risk register, internal audit, management review, corrective actions. That is months of work and an audit fee. SOC 2 is a report written after an observation window, so a Type II report cannot exist on day one. If a buyer requires either, answer “not held” and offer the artifacts, a site audit with a retest from $490, and a signed DPA.
Do not soften it with “SOC 2 aligned” or “ISO 27001 ready”; both mean nothing to a reviewer. If a certificate is planned, name the framework and a date, because an undated plan is a slogan.
Our position. We do not hold ISO 27001 or SOC 2 and we say so on the trust page. What we can evidence is narrower: MFA on every account, backups with a tested restore, and access removed within 30 days of project close. If procurement requires a certificate, we are not the vendor for that deal.
FAQ
Questions buyers ask before they email
What is a vendor security questionnaire?
How long should it take to complete one?
Do we need ISO 27001 to pass a security review?
Should sales or engineering answer the questionnaire?
What if the honest answer is a gap?
Keep reading
The next question buyers ask
Security
Managed Security vs In-House
A cost comparison of managed security and an in-house hire at 20 people, the coverage neither gives you, and the hybrid most teams land on.
Read the guideSecurity
Pentest vs Vulnerability Scan
The practical difference between a vulnerability scan, a security audit and a penetration test: depth, evidence, market cost and when to buy each.
Read the guideNEXT STEP
Ask the question you cannot answer from the page.
Send a questionnaire and we will answer in writing, with the gaps named.