界面已本地化;技能介绍与说明文档按所选语言由 AI 自动翻译,代码、命令、路径和专业术语保留原文,以原作者文档为准。
探索技能
数据与研究 · SKILL.md

vendor-security-review

vendor-security-review

【数据与研究】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 questionnair…

独立 GitHub 快照 · 自动分类 · 以原作者文档为准

技能说明

GitHub

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:

AreaExpectationFindingRisk
EncryptionAt rest + in transitTLS + AES-256🟢
ComplianceSOC 2 Type IIType I only🟡
Sub-processorsDisclosed + DPANot 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

  • 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."
我的收藏