name: vendor-security-review
description: "Run a third-party / vendor security review and assign a risk tier with required controls. Use when asked to assess a vendor's security, run a third-party risk assessment, complete a security questionnaire about a vendor, or decide what due diligence a new tool needs. Produces a vendor risk assessment — a data/access-driven risk tier, the questionnaire focus, required evidence (SOC 2, pen test, DPA), residual risk, and an approve/conditional/reject recommendation."
Vendor Security Review Skill
You inherit the security posture of every vendor that touches your data — and the right level of scrutiny
depends on what they touch, not on how big their logo is. This skill tiers a vendor by data sensitivity
and access, scopes the diligence to that tier (so a low-risk tool isn't over-audited and a high-risk one
isn't waved through), and lands on a defensible approve / conditional / reject call.
Required Inputs
Ask for these only if they aren't already provided:
- What the vendor does and the data they'll access (none / internal / customer PII / sensitive / regulated).
- Access level — no system access, limited, or privileged/admin to your environment.
- Criticality — would an outage or breach of this vendor materially hurt you?
- Evidence available — SOC 2 / ISO 27001 reports, pen-test summary, DPA, security questionnaire responses.
Output Format
Vendor Security Review: [vendor] — [service]
1. Risk tiering — the tier (Low / Medium / High / Critical) driven by data sensitivity × access × criticality, with the reasoning. The tier sets how much diligence is warranted.
2. Diligence scope — what to require at this tier: e.g. Low = self-attestation; High/Critical = SOC 2 Type II or ISO 27001, pen-test summary, DPA/sub-processor list, incident-response and breach-notification terms.
3. Findings — a table of assessed areas and status:
| Area | Expectation | Finding | Risk |
|---|
| Encryption | At rest + in transit | TLS + AES-256 | 🟢 |
| Compliance | SOC 2 Type II | Type I only | 🟡 |
| Sub-processors | Disclosed + DPA | Not disclosed | 🔴 |
4. Residual risk & recommendation — what's left after compensating controls, and a clear Approve / Approve with conditions / Reject with the conditions and a re-review date.
Programmatic Helper
scripts/vendor_risk.py (stdlib only) computes the risk tier and the baseline required evidence from
the vendor's data/access/criticality profile, so tiering is consistent across reviewers:
# vendor.json: {"name":"Acme","data_sensitivity":"customer_pii","access":"privileged","criticality":"high","certs":["soc2_type1"]}
python3 scripts/vendor_risk.py vendor.json
python3 scripts/vendor_risk.py vendor.json --json
Quality Checks
Anti-Patterns
Based On
Third-party / vendor risk management practice — data-and-access-driven tiering, evidence-based diligence, and contractual risk transfer.
Example Trigger Phrases
- "Assess a vendor's security."
- "Run a third-party risk assessment."
- "Complete a security questionnaire about a vendor."
- "Decide what due diligence a new tool needs."