A vendor security review evaluates whether a third-party service meets your security and privacy requirements before you sign a contract.
A vendor security review (also called third-party risk assessment or TPRA) is the structured process of evaluating a prospective vendor's security, privacy, and operational posture before you sign a contract to send them data. Third-party incidents — Okta 2022, MOVEit 2023, SolarWinds 2020 — now account for a majority of high-impact breaches, and vendor review programs are how mature companies manage the exposure. Every enterprise you sell to has one; if you don't have one, you're accepting whatever risk your vendors bring, sight unseen.
Not every vendor deserves the same scrutiny. Tier reviews by data sensitivity and access. (1) Critical — access to customer PII, production infrastructure, or code (databases, cloud, identity providers). Full review: SOC 2 Type II, pentest report, DPA, questionnaire, architecture review. (2) High — access to internal systems or aggregated data (analytics, monitoring, error tracking). SOC 2, DPA, questionnaire. (3) Medium — internal tools with no sensitive data (design tools, project management). SOC 2 attestation, DPA. (4) Low — marketing sites, one-off tools. Automated attestation collection, no manual review. Tiering prevents drowning security in low-risk reviews while paying real attention to what matters.
Every enterprise has their own security questionnaire; answering each from scratch is a full-time job. Two standards reduce the pain: SIG (Standardized Information Gathering, Shared Assessments) — 800+ questions across security, privacy, and BC/DR; the enterprise favorite. CAIQ (Consensus Assessments Initiative Questionnaire, Cloud Security Alliance) — cloud-specific, 300 questions, publicly accessible via CSA STAR registry. Best practice as a vendor: prepare answers to both once, store centrally (Vanta, Drata, SafeBase, Whistic), reuse across every customer questionnaire. Best practice as a buyer: accept SIG/CAIQ + SOC 2 rather than requiring your own custom questionnaire.
Documents most vendors have: SOC 2 Type II report (read the exceptions section, not just the cover), pentest attestation letter, DPA, privacy policy, sub-processor list, business continuity plan, insurance certificates. Beyond documents, questions that matter: incident response history (any breaches in last 24 months, resolution), authentication controls (do they support SSO/MFA for admins), data residency options, encryption at rest and in transit, backup and DR capabilities, offboarding process (how you get your data out and confirm deletion). A vendor that can't provide SOC 2 and DPA has usually not done enterprise sales, which is signal in itself.
Onboarding review is a snapshot; vendor posture drifts. Annual reassessment for critical vendors — pull fresh SOC 2, review sub-processor changes, check breach disclosures. Continuous monitoring tools (SecurityScorecard, BitSight, UpGuard) provide external observability of vendor security posture. Contract clauses should include: notification of security incidents within 24-72 hours, notification of sub-processor changes with objection rights, right to audit or receive audit results, defined data return/deletion on termination. Vendor contracts written without security terms leave you with no recourse when things go wrong.
Some vendors won't meet all requirements — a small startup with no SOC 2, a specialized tool with limited controls. Have a documented exception process: risk assessment, compensating controls (limit data sent, isolate access, extra monitoring), executive approval, review date. Exceptions logged and reviewed quarterly; renewed or revoked based on updated posture. Ad-hoc exceptions granted verbally and forgotten are how 'we don't allow vendors without SOC 2' becomes 'somehow we're depending on 12 non-SOC-2 vendors.'
Investor directory · Fundraising library · Articles A–Z · Company funding database