Vendor Risk Assessment and Tiering
Concept
Every third-party dependency — an auth provider, a payment processor, a hosting platform, an npm package with a maintainer nobody's vetted — is an extension of your own attack surface and your own uptime. Vendor (third-party) risk management is the discipline of assessing that exposure before committing to a dependency, then re-checking it on a cadence afterward, rather than discovering the vendor's actual security posture during an incident involving their systems. Two standards anchor most formal programs: ISO 27036-2, which specifies information-security requirements across the full supplier relationship lifecycle (procurement through exit — including exit requirements like certified data destruction and credential revocation when a vendor relationship ends), and NIST SP 800-161, which governs supply-chain risk at the program level, often paired with NIST CSF for assessment design and NIST 800-53 for control-level detail on the highest-risk vendors.
The practical output of a mature program is tiering: not every vendor gets the same scrutiny. A vendor with no data access and no availability dependency (a marketing analytics widget) needs a lighter check than one holding customer PII or sitting on your critical path (a payments processor, an auth provider). Tiering is what keeps vendor risk assessment from becoming either a rubber stamp (everything gets the same shallow questionnaire) or an impossible bottleneck (everything gets a full audit).
Tradeoffs (assessment method by vendor tier)
| Method | Benefit | Cost |
|---|---|---|
| Self-attestation questionnaire | Cheap, fast, scales to dozens of low-risk vendors | Self-reported, unverified — a vendor can answer accurately about controls that don't actually work in practice |
| SOC 2 report review (see SOC 2 Trust Services Criteria) | Independently audited by a CPA firm; a real baseline for Security and any other in-scope Trust Services Criteria | Point-in-time (Type 1) or period-bounded (Type 2, usually 12 months); says nothing about the months after the report's period ends; exceptions require your own likelihood/impact scoring — SOC 2 reports don't grade risk for you |
| Full onsite/technical audit | Highest assurance; verifies claims directly rather than trusting a report | Expensive in both vendor and reviewer time — only justified for the highest-risk tier (deep data access, critical-path availability, regulated data) |
| Continuous security-rating monitoring (e.g. BitSight/SecurityScorecard-style external scanning) | Catches posture drift between formal reviews — a vendor that was fine at onboarding but has since had exposed credentials or unpatched CVEs | External/outside-in signal only — doesn't see internal controls a SOC 2 report or audit would catch, and ratings can false-positive on things that don't reflect real risk |
The pattern that shows up across mature programs: cheap methods for low tiers, SOC 2 report review as the default mid-tier baseline, and audits reserved for the small set of vendors where a failure would be genuinely severe — plus continuous monitoring layered on top of any tier as a cheap way to catch drift a point-in-time review would miss entirely.
When to use / when not to
- Run a real assessment — at minimum a questionnaire, ideally a SOC 2 report review — before adopting any vendor with access to customer data, production credentials, or a critical-path dependency (auth, payments, hosting). Do this before the integration ships, not after, since renegotiating access or migrating off a vendor post-adoption is far more expensive than saying no upfront.
- Reserve full audits for the highest tier only — vendors holding regulated data (PCI, PHI) or sitting fully on the critical path where an outage or breach on their end is an outage or breach on yours.
- Skip formal assessment for genuinely low-exposure vendors (no data access, no availability dependency, easily replaceable) — a lightweight questionnaire or even none at all is proportionate; treating every SaaS signup as a governance event is how vendor risk programs get bypassed entirely by teams working around them.
- Re-assess on a cadence, not just at onboarding — a vendor's SOC 2 report expires (typically annual), and a vendor that was low-risk at signup can become higher-risk as your integration with them deepens (more data shared, more critical-path dependence added over time).
Common pitfall
Treating vendor risk assessment as a one-time gate at procurement rather than an ongoing relationship. The two most common failure modes: reviewing a SOC 2 report once at signup and never checking whether the next year's report still exists or still passes, and letting the scope of a vendor relationship expand (more data, more criticality) without re-tiering it — a vendor onboarded as "low-risk analytics widget" that quietly becomes the system storing customer PII a year later is now on the wrong assessment cadence, but nothing forces a re-check unless the program has a trigger for scope changes, not just a calendar for time.
Engineering Lens
The engineering-relevant question a vendor risk review should answer isn't "did they pass a checklist" — it's the same question a circuit breaker or bulkhead design answers for an internal dependency: what happens to us when this vendor fails, and is that blast radius one we've actually designed for? A SOC 2 report tells you about their controls; it says nothing about your own exposure if they have an outage or a breach anyway. The strongest vendor risk practice pairs the assessment (their controls) with your own architectural mitigation (can you fail over, degrade gracefully, or rotate credentials fast if this vendor is compromised) — treating a vendor's security posture as a complete substitute for your own resilience design is the same mistake as assuming a well-tuned circuit breaker means you never needed a fallback path at all.