Vendor security review for small teams: 12 questions before you sign

Every vendor you sign becomes part of your incident response, whether you planned for that or not. The payroll SaaS holds every employee's bank details, the ticketing system holds every customer conversation, and the little browser extension the ops person swears by holds an OAuth grant to your whole Google Workspace. When the vendor gets breached, your name ends up in their disclosure — and your first-24-hours plan runs on facts you never collected. The checklist below is the 12 questions worth asking before you sign, in the order to ask them, with the red-flag answers that should slow the deal down. It is sized for a small team: one afternoon, a spreadsheet, and no procurement department.

1. Why you inherit their breach

• Your data is their attack surface. Attackers follow the data. A 5-person vendor aggregating customer records from 400 small businesses is a better target than any one of its customers — and their compromise exposes your records without anyone touching your network.
• Third parties are a standard sentence in breach notices. "A supplier we use was compromised" now headlines a large share of disclosures — and your customers read it as your breach, because it was their data.
• Your contracts often make you the messenger. Many vendor terms put notification duties on you: if their breach affects your customers, you may be the one holding the clock. You cannot run that clock without knowing who your vendors are and what they hold. This is also exactly what cyber insurance applications now ask about.

2. The 12 questions, in the order to ask them

1. What exact data will you hold, and where? Not "customer data" — the field-level list: emails, addresses, payment tokens, credentials, health fields. Where it is stored (region, cloud provider) and whether backups leave that region.
2. Have you had a breach or material security incident in the last 24 months? The right answer is not "no," it is an honest account — what happened, what was exposed, what changed. Vendors who say "never" to everything are either lucky or not looking, and the second is worse.
3. Do you enforce MFA for your staff accessing customer data — and for our admin account? Their internal MFA matters; yours is a control you can verify today. The same rollout you should run on yourself →
4. How do we authenticate to your product? SSO/SAML availability, API key scoping and rotation, session timeouts. If your integration uses a long-lived API key, ask how that key gets rotated when it leaks — their answer should match the runbook you would run.
5. Who are your sub-processors, and how are we notified when they change? The SaaS is rarely the whole chain: hosting, email delivery, support tooling, AI features. A published, versioned sub-processor list with a change-notification commitment is the mature answer.
6. What is your breach notification commitment to us — in the contract, in hours? "Without undue delay" is a vibe; "72 hours from confirmation, to named contacts" is a term. Get it written into the contract or order form, not just the trust page.
7. What is your encryption posture at rest and in transit? Standard now; the differentiator is key management — who holds the keys, whether they can be customer-managed, and what happens to your data on cancellation.
8. Do you have SOC 2 / ISO 27001 — or a substitute? A full report under NDA beats a badge on the homepage. No report at all is not automatically disqualifying for low-risk tooling, but it should move the vendor down a tier (§4), not up.
9. How is our data deleted on exit? The offboarding question. Deletion timeline, certificate of deletion, backups included. The same thinking as your staff offboarding, pointed at them →
10. What access will your support staff have to our data, and is it logged? "Break-glass access, logged, with a named approver" is the adult answer. "Support can log in as any customer" is a finding, not a feature.
11. When were your penetration tests, and will you share results under NDA? Annual external testing plus a fixes-verified statement is the baseline. A vendor who tests but cannot share anything is asking you to trust a logo.
12. Who is legally responsible if their breach becomes our notification event? Indemnification, liability cap, and whether the cap covers regulatory fines. This one is for whoever signs, armed with the answers from the first eleven.

3. Red-flag answers (slow the deal, or price the risk)

• "Security information is available on request" — then nothing arrives. The trust page with no substance behind it. One written follow-up before signature; if it is ignored before signature, it will be ignored during an incident.
• "We've never had any incidents and we don't do testing." No incidents and no testing means no detection. That is not a clean history, it is an unread one.
• "MFA is available on enterprise plans." MFA on your admin account held behind the most expensive tier is a pricing decision, not a security control — budget for it or tier the vendor down.
• Breach notification: "we'll comply with applicable law." Applicable law to them may not match your obligations to your customers. The number you need lives in your contract, not theirs.
• Sub-processors: "we use industry-standard providers." A versioned list with change notification — or the answer is a shrug with extra words.

4. Tier it: not every tool needs the full questionnaire

• Tier 1 — full 12 questions. Holds customer PII, employee PII, credentials, payment data, or production access: payroll stack, CRM, identity provider, cloud accounts, backup tooling.
• Tier 2 — light-touch. Internal-only tooling with no PII: five questions (data inventory, MFA, notification term, deletion, sub-processors), five minutes, asked on the same call as pricing.
• Tier 3 — register and move on. Zero-data utilities. The only requirement is that they are on the vendor list, because the list itself is the deliverable: when their breach notice lands, you need to know in minutes whether you are affected, and a tiered spreadsheet answers that faster than memory.
• Re-review on change, not calendar alone. New AI features (new sub-processors), acquisition, plan changes — any of these re-opens the file. The vendor outage runbook should point at the same spreadsheet: the vendor list is shared infrastructure between security and ops.

5. Make it a one-afternoon process, not a project

• Template the ask. One email with the 12 questions, sent at contract-drafting stage, not after signature. Vendors with a real trust page answer in a day; vendors without one tell you something by the delay.
• One spreadsheet, four columns beyond the vendor's name: data held, tier, notification term (hours), last reviewed. That sheet is also your evidence for the insurance application's vendor-risk question and your auditor's third-party question.
• Attach the review to onboarding, not enthusiasm. It happens between verbal-yes and signature, when you still have leverage. After the data is in, you are negotiating from dependency.
• Store the answers where incidents run. The vendor sheet, signed DPAs, and sub-processor lists belong in the same drive as your incident plan — because the 2am question is "which of our vendors just had a breach, and what did they hold?"

The pattern across all twelve: you are not auditing their security, you are collecting the facts your own incident will need. A small team that knows what each vendor holds, how fast it must be told, and how the data leaves turns somebody else's breach notification from a Monday-morning panic into a ten-minute lookup — and that lookup is the entire point.