# Vendor Security & Compliance Risk Review

Systematically evaluate a third-party vendor or tool for security, data privacy, and compliance risk before integrating it into your business.

## Prompt

Act as a security and compliance reviewer evaluating a third-party vendor for adoption. Here is information about the vendor and how we intend to use it:
{{vendor_and_use_case_info}}

Conduct the review using this structure:

1. Data exposure assessment — identify exactly what data would flow to this vendor given our intended use case, and classify its sensitivity (public, internal, confidential, regulated/PII).
2. Compliance relevance — based on the data classification, identify which regulations or standards are likely relevant (e.g. GDPR, HIPAA, SOC 2, PCI-DSS) and what questions we should ask the vendor to confirm compliance.
3. Access and blast radius — assess what this vendor's access could affect if compromised (e.g. read-only vs. write access, scope of systems touched), and whether the access requested exceeds what's needed for the stated use case.
4. Red flags to verify — list specific, concrete things to check before signing (e.g. 'confirm they have a documented incident response process', 'confirm data residency/location', 'check for a recent SOC 2 report') rather than vague reassurances.
5. Contractual safeguards — recommend 2-3 specific contract or DPA (data processing agreement) clauses to request based on the risk identified.
6. Overall risk rating — provide a Low/Medium/High risk rating with a one-sentence justification, and note what would need to change to lower it.

Be specific and avoid generic security advice not tied to this particular vendor and use case.

## Best for

Founders, IT/security leads, and operations teams evaluating whether to adopt a new SaaS tool or vendor, especially where customer or employee data is involved.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Describe the vendor, what data it would access, and your intended use case in {{vendor_and_use_case_info}} — be specific about data types.
- Use the red flags and compliance sections as an actual checklist to send to the vendor's sales or security team before signing.
- Bring the contractual safeguards recommendations to whoever handles your contracts or legal review.
- Re-run the assessment if the vendor's answers reveal something different from your original assumptions (e.g. they do train on customer data).

## Customization tips

- If you operate in a specific regulated industry (healthcare, finance, government), mention it explicitly so the compliance relevance section is accurate to your actual obligations.
- Ask for the output reformatted as a vendor questionnaire you can send directly to their team.
- This is not a substitute for legal or professional security review — use it as a first-pass framework, then involve qualified legal/security counsel for anything rated Medium or High risk.

## Example input

Act as a security and compliance reviewer... Vendor: a customer support chatbot tool that would have access to our customer support ticket history, including names, emails, and order details, to generate suggested responses. Use case: integrating it into our helpdesk to reduce response time.

## Example output

1. Data exposure assessment: this vendor would receive customer names, emails, and order details — classified as confidential and likely regulated PII depending on jurisdiction (e.g. under GDPR if any EU customers are included).
2. Compliance relevance: GDPR is likely relevant if any customers are in the EU/UK; a signed Data Processing Agreement (DPA) should be required. SOC 2 Type II report should be requested to confirm the vendor's own security controls, given they'll be handling customer PII.
3. Access and blast radius: the vendor needs read access to ticket history to generate suggestions, but confirm it does not require write access to your helpdesk or the ability to directly send messages to customers without human review, since that would significantly increase blast radius if compromised.
4. Red flags to verify: confirm data residency (where customer data is actually stored and processed), confirm whether ticket data is used to train the vendor's own models on other customers' data (a common and risky practice), confirm they have a documented breach notification process with a specific timeframe commitment.
5. Contractual safeguards: require a DPA with an explicit sub-processor disclosure clause, require a clause prohibiting use of your data for model training without explicit opt-in, and require a breach notification clause with a maximum 72-hour disclosure window.
6. Overall risk rating: Medium — the data sensitivity is meaningful (PII) but the access scope can likely be limited to read-only with human-reviewed responses; risk would drop to Low if the vendor confirms no model training on your data and provides a current SOC 2 report.