Why SMB vendor risk management is its own problem
If you work in security for a 50-to-500-person company, you've probably been handed a vendor risk questionnaire template that looks like it was built for a Fortune 100 bank: 300 questions, an inherent-vs-residual-risk scoring matrix, a "vendor governance committee" that meets monthly. You've filled it out twice, abandoned it, and gone back to running vendor due diligence out of a Google Doc.
The problem isn't that vendor risk management doesn't matter at your size — it does, and breach trends make clear that third-party compromise is how most small companies get hit. The problem is that the frameworks available were designed for organizations with a dedicated third-party risk management (TPRM) team. When you have one person covering all of security, the 300-question CAIQ-lite is the wrong tool for the wrong scale.
This is a baseline that works at SMB scale: 20 questions across 5 categories. Short enough that a practitioner can actually run it, sharp enough that it surfaces the risk that matters, defensible enough that auditors, cyber insurance carriers, and customers accept it as a real program.
The five categories that actually matter
Most enterprise TPRM questionnaires bury the signal in volume. Strip the noise and every vendor risk question belongs in one of five buckets.
1. Identity and access. Whose identity system touches yours? How do they protect it? If a vendor's employee gets phished and logs into your environment, you're compromised.
2. Data protection. How does the vendor handle your data at rest, in transit, and at end-of-life? Who do they share it with (subprocessors)? Where does it live geographically?
3. Security program maturity. Do they have one? How do you know? Third-party validation (SOC 2, ISO 27001) is the faster path than trying to audit them yourself.
4. Incident response. When something goes wrong, how fast do they tell you? How do they handle it? Have they had incidents you'd want to know about?
5. Business and legal controls. The "kill switch" category — contract terms that let you exit cleanly, audit their controls, and have someone underwrite the residual risk.
Four questions per category. Twenty questions total. That's the program.
The 20 questions
Identity & access (questions 1-4)
Q1. Is all access to our data behind SSO + MFA? Applies to employees AND service accounts that authenticate to your tenant. The answer should be "yes, with enforcement," not "yes, most users." If they rely on password-only access anywhere, that's a material gap.
Q2. How do they handle privileged access? Is there a PAM solution? How are admin credentials rotated? Are privileged sessions logged? "Shared in a password manager" is a red flag.
Q3. How frequently do they conduct access reviews, and what was the last one's outcome? Quarterly minimum, with evidence. Ask for the last review's revocation count — vendors who actually do access reviews can produce the number; vendors who don't, can't.
Q4. What's their offboarding SLA for removing access when their employees leave? Same-day is the right answer. Industry median is worse than people admit — 30+ days of residual access is common.
Data protection (questions 5-8)
Q5. Is our data encrypted at rest (AES-256+) and in transit (TLS 1.2+)? This should be trivial. If a vendor can't confirm this in one sentence, keep digging.
Q6. Who are their subprocessors, and how are we notified of changes? Ask for the current list and the change-notification process. If they use AWS, fine; if they use three random analytics tools you've never heard of, each becomes a transitive risk.
Q7. Where is our data stored and processed geographically? Matters for GDPR, state data residency laws, and whether an adversary-state actor can subpoena the data. "US and EU" is fine; "a mix of regions per workload, but we can't tell you which" is a risk.
Q8. What's the data deletion process when we terminate? Should include: written confirmation of deletion, timeline (30 days is standard), what backups retain the data for how long afterward.
Security program (questions 9-12)
Q9. Do they have a current SOC 2 Type 2 or ISO 27001 certification? Ask for the report or certificate, plus scope. Type 1 is a point-in-time assessment and is weaker than Type 2 (operating effectiveness over months). If neither, the remaining questions in this category carry more weight.
Q10. When was their last third-party pentest, and can they share the executive summary? Annual minimum for anyone holding your sensitive data. Quarterly for vendors handling payment data or PHI at scale. "We don't share our pentest results" is a partial red flag — the executive summary should be shareable under NDA.
Q11. What's their vulnerability management SLA? Critical = 7 days or faster, High = 30 days. Ask for evidence of current backlog.
Q12. Do they have a Chief Information Security Officer (or equivalent) and a security team? Not "is security someone's part-time job?" — is there an owner with authority. For very small vendors the answer may be "our CTO owns security" and that's acceptable; "nobody owns it" is not.
Incident response (questions 13-16)
Q13. What's their notification SLA when they detect an incident affecting customer data? 72 hours is the modern standard (GDPR-aligned). Some contracts go shorter. Anything over a week is a gap.
Q14. Have they had a security incident in the last 24 months that required customer notification? Ask directly. Public record via state AG notices is often more accurate than what they'll volunteer.
Q15. Can they share their incident response runbook, or a summary of it? Even a one-page summary showing stages, roles, and escalation indicates maturity. Absence indicates they haven't planned.
Q16. Do they carry cyber insurance, and what are the coverage limits? Not because you want to collect on it, but because insured vendors have typically passed their insurer's controls audit. It's a useful third-party validation signal.
Business & legal controls (questions 17-20)
Q17. Is there an executed DPA, BAA, or equivalent data-protection addendum in place? GDPR requires DPAs for data processors handling EU personal data. HIPAA requires BAAs for business associates handling PHI. PCI requires specific pass-through contractual terms. If you're subject to any of these and the addendum isn't signed, you're out of compliance.
Q18. Does the contract include a right-to-audit clause? You probably won't exercise it often, but it exists as a lever for serious disputes. If the vendor refuses, that's a data point.
Q19. What are the termination clauses, and what's the data handoff process? Specifically: can you get your data out in a usable format, on what timeline, and what happens to residual copies.
Q20. What's their financial runway — and will they still be operating in 24 months? For smaller vendors especially. A vendor going out of business mid-contract is a material risk. Ask for funding status or a Dun & Bradstreet reference.
How to tier vendors so you're not running 20 questions on everyone
Running all 20 questions on every SaaS tool your company uses is a waste of time and trust. Tier the vendors first:
Tier 1 (full 20 questions + annual re-assessment): Vendors that process regulated data (PHI, PCI), handle authentication or identity, or have system-critical access (IdP, EDR, cloud provider, payments processor). Typical count for an SMB: 8-15 vendors.
Tier 2 (abbreviated 8-10 questions + biennial re-assessment): Vendors that access non-regulated customer data but aren't system-critical. Marketing tools with PII, collaboration suites, analytics platforms. Typical count: 20-40 vendors.
Tier 3 (single "yes/no on SOC 2 or ISO" gate): Vendors that don't touch customer data meaningfully. Office software, travel tools, adtech. If they have a SOC 2 or ISO, move on. If they don't and they don't touch sensitive data, the residual risk is usually acceptable.
A good tiering pass on a typical SMB vendor portfolio (100-200 SaaS tools) yields ~15 Tier 1 vendors that get the full treatment, ~30 Tier 2 getting abbreviated, and ~100+ Tier 3 getting fast-gate treatment. That's the proportion that's sustainable with one person running the program.
What to do with the responses
The single biggest failure mode in SMB vendor risk is treating the questionnaire as the end state. You get responses, you file them, you never look at them again.
What matters is what you do with gaps:
- Track each vendor's questionnaire responses in a risk register. Not a spreadsheet that dies in two months — an actual register with renewal dates, gap status, and escalation workflow. (This is what our risk register software was built to handle; Radius360 pulls vendor questionnaire responses directly into the register.)
- Tie gaps to contract renewal. A vendor with three unremediated material gaps should have the contract flagged for renewal review. Leverage compounds when you're making a renewal decision, not six months into a contract.
- Set alerts on assessment expiration. A SOC 2 report covers the previous 12 months. If you assessed a vendor in January 2025 based on their 2024 SOC 2, that assessment is stale by mid-2026. Most SMBs never refresh.
- Flag material changes. Vendor sells to private equity? CISO departs? Subprocessor list changes? Each is a trigger for re-assessment, not a year-out problem.
When the 20-question baseline isn't enough
Two cases where you'll need to go deeper than the baseline:
Regulated data at scale. If you're handling PHI for millions of records or processing payment data at PCI Level 1 volume, the baseline is the floor, not the ceiling. You'll layer on industry-specific assessments (HITRUST for healthcare, RoC-aligned questionnaires for PCI) and more frequent cadence.
Strategic dependency. When a single vendor represents an existential dependency (e.g., your entire product runs on one cloud provider, one database vendor holds all your customer data), the question isn't just "are they secure?" but "what's our continuity plan if they fail?" That's closer to vendor concentration risk than vendor security risk, and the questions expand accordingly.
For everyone else running security for an SMB: the 20-question baseline is the viable program. It's what auditors expect to see, what cyber insurance carriers accept, and what customers reviewing your own security questionnaire will be satisfied with when you reference it. More importantly, it's the size of program that one practitioner can actually run without burning out.
Where Radius360 fits
Radius360's Vendor Risk module implements this exact baseline natively. The 20-question questionnaire is a template you can send to a vendor via a public self-serve link (no login required on their side). Responses flow into a vendor risk register with tier-based scoring, BAA/DPA tracking, assessment expiration alerts, and gap escalation workflows. Cross-mapped to SOC 2 CC9, ISO 27001 A.15, and HIPAA Security Rule §164.308(b)(1), so the work satisfies multiple frameworks at once.
For vCISOs and MSSPs running vendor risk across multiple clients, the same template runs across every client tenant, and vendor responses are tenant-isolated so one vendor's answers to Client A don't leak to Client B. That's what turns "TPRM for twelve clients" from twelve separate programs into one coordinated one.
The point isn't the tool. The point is that SMB vendor risk doesn't need to be a 300-question apparatus — it needs to be twenty sharp questions, tiered so you're running the right depth on the right vendors, and a register that stays current instead of dying after the first quarter.
Want the 20-question template as a CSV? support@radius360.co — happy to share it.
See how Radius360 helps
Put these ideas into practice with the right tooling.
Run the 20-question baseline in Radius360