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:

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

• [ ] The risk tier is driven by data sensitivity × access × criticality — not vendor size or reputation
• [ ] Diligence depth matches the tier (no rubber-stamping high-risk; no over-auditing low-risk)
• [ ] High/Critical vendors are required to provide independent evidence (SOC 2 Type II / ISO 27001 / pen test), not self-attestation
• [ ] A DPA + sub-processor disclosure is required where the vendor handles personal data
• [ ] The recommendation is explicit (approve / conditional / reject) with conditions and a re-review date

Anti-Patterns

• [ ] Do not size diligence by the vendor's brand — a small vendor with privileged access to PII outranks a famous one with none
• [ ] Do not accept a SOC 2 Type I as equivalent to Type II — Type I is a point-in-time design check, not operating effectiveness
• [ ] Do not skip the sub-processor question — your data may flow to fourth parties you never assessed
• [ ] Do not approve high-risk vendors on a promise — require evidence and bind it in the contract (DPA, breach notice SLA)
• [ ] Do not treat the review as one-and-done — set a re-review cadence tied to the tier

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."