Use this when you're evaluating a SaaS vendor, API provider, or third-party integration and need to assess their security posture -- before signing a contract, during a periodic review, or after a vendor has disclosed a security incident.

Related skills: Use /compliance-map for framework knowledge when evaluating vendor certifications. Use /decision-brief for vendor selection decisions. Use /vendor-evaluation for broader vendor evaluation beyond security. Use /build-vs-buy when vendor selection is part of a build-vs-buy decision.

Process

Step 1: Gather context

Collect from the user:

• Vendor name and what service they provide
• What data the vendor will access, process, or store
• Data sensitivity classification -- PII, PHI, financial, proprietary, public
• Integration points with your systems -- API, SSO, data sync, webhook, file transfer
• Contract timeline -- new procurement, renewal, or periodic review
• Any known concerns or prior incidents with this vendor

The depth of assessment should be proportional to risk. A logging SaaS that ingests application metrics gets a lighter review than a payment processor handling credit card data.

Step 2: Generate tailored questionnaire

Based on vendor type and data sensitivity, generate questions across these domains:

For all vendors:

• Data handling: Where is data stored? Is it encrypted at rest and in transit? What encryption algorithms and key lengths?
• Access controls: How is access to customer data controlled? Is there role-based access? How are privileged accounts managed?
• Incident response: What is the vendor's breach notification timeline? Do they have a documented incident response plan?
• Business continuity: What is the RTO/RPO? Where are backups stored? Has DR been tested?
• Compliance: What certifications does the vendor hold (SOC 2, ISO 27001, etc.)? When was the last audit? Can they share the report?

For vendors handling sensitive data (add):

• Subprocessor management: Who are the subprocessors? How are they vetted?
• Data residency: In which regions is data stored? Can data residency be contractually guaranteed?
• Vulnerability management: What is the patching cadence? Is there a bug bounty program?
• Employee security: Background checks? Security training frequency? Least-privilege access enforcement?
• Data lifecycle: How is data deleted on contract termination? Is deletion certified?

For infrastructure/platform vendors (add):

• Network security: Network segmentation? DDoS protection? WAF?
• Logging and monitoring: What audit logs are available to customers? Retention period?
• Multi-tenancy isolation: How is customer data isolated? Shared or dedicated infrastructure?

For vendors with AI/ML capabilities (add):

• AI training data: Is customer data used to train or improve models? Can customers opt out? Is training data shared across customers?
• AI failure transparency: Does the vendor document known failure modes, false positive/negative rates, and confidence thresholds? Can the customer tune sensitivity?
• Baseline requirements: What telemetry quality, log coverage, and tag consistency does the vendor need from the customer's environment to build accurate AI baselines (e.g., for UEBA or anomaly detection)?
• AI explainability: When the AI flags an anomaly or makes a recommendation, can it trace back to specific events, identities, and resources -- or is it a black-box score?
• Model update cadence: How often do detection or analysis models update? Are updates tested against customer-specific baselines before deployment? Can the customer pin a model version?
• AI-specific incident handling: If the AI produces a false positive that triggers an incident response, what's the vendor's process for tuning and preventing recurrence?

Questionnaire length should be proportional to risk. Don't send 200 questions to a low-risk vendor.

Step 3: Define scoring criteria

Build a weighted evaluation with clear pass/fail thresholds:

| Domain | Weight | Pass/Fail Items | Scored Items |
|---|---|---|---|
| Data Encryption | {{weight}}% | Encryption at rest (AES-256 or equivalent) -- MUST PASS | Key management maturity |
| Access Controls | {{weight}}% | MFA for admin access -- MUST PASS | RBAC granularity, access review cadence |
| Incident Response | {{weight}}% | Documented IR plan -- MUST PASS | Notification timeline, testing frequency |
| Compliance | {{weight}}% | SOC 2 Type II or equivalent -- MUST PASS (for sensitive data) | Audit recency, scope coverage |
| Business Continuity | {{weight}}% | None | RTO/RPO, DR testing frequency |

Pass/fail items are non-negotiable. If a vendor fails any pass/fail item, that's a disqualifier unless compensating controls exist.

Step 4: Score vendor responses

Evaluate each response with a risk-rated assessment:

| Domain | Question | Vendor Response | Rating | Notes |
|---|---|---|---|---|
| {{domain}} | {{question}} | {{response_summary}} | Red / Yellow / Green | {{risk_note}} |

Rating definitions:

• Red flag -- immediate disqualifier or critical gap. Example: no encryption at rest for PII, no incident response plan, SOC 2 report expired 18+ months ago.
• Yellow flag -- acceptable with conditions. Example: SOC 2 Type I only (not Type II), patching cadence is quarterly rather than monthly, no dedicated security team but outsourced to reputable firm.
• Green -- meets or exceeds requirements.

Distinguish between what a vendor claims and what they can evidence. "We encrypt everything" without specifying algorithms, key management, or providing a SOC 2 report is a yellow flag.

Step 5: Generate risk assessment

Produce an overall risk profile:

## Vendor Risk Assessment -- {{vendor_name}} -- {{date}}

**Overall Risk Rating:** Low / Medium / High / Critical

**Red Flags:** {{count}}
{{list_red_flags}}

**Yellow Flags:** {{count}}
{{list_yellow_flags}}

**Residual Risks:**
- {{risk_description}} -- Likelihood: {{L}}, Impact: {{I}}

**Compensating Controls (your organization should implement):**
- {{control_description}} -- addresses {{residual_risk}}

Step 6: Produce recommendation

One of three outcomes:

1. Approve -- vendor meets security requirements. Proceed with procurement.
2. Approve with conditions -- vendor is acceptable if specific conditions are met. List each condition, the timeline for the vendor to meet it, and monitoring requirements.
3. Reject -- vendor has critical gaps that cannot be mitigated. Document the specific disqualifiers.

For conditional approval, define:

• Reassessment triggers (vendor incident, contract renewal, material change in data handling)
• Monitoring cadence (quarterly check-ins, annual reassessment)
• Conditions the vendor must meet and by when

Step 7: Generate contract security clauses

Based on findings, draft security-specific contract terms:

## Recommended Contract Clauses

### Data Processing Agreement
- Vendor shall process data only for the purposes specified in {{agreement}}
- Data residency: {{region_requirements}}

### Breach Notification
- Vendor shall notify Customer within {{hours}} hours of discovering a security incident
- Notification shall include: nature of the breach, data affected, remediation steps taken

### Audit Rights
- Customer may audit vendor's security controls {{frequency}} or upon reasonable notice
- Vendor shall provide updated SOC 2 reports within {{days}} days of issuance

### Security SLAs
- Uptime: {{percentage}}
- Critical vulnerability patching: within {{hours}} hours
- Incident response time: {{hours}} hours

### Data Deletion
- Upon contract termination, vendor shall delete all Customer data within {{days}} days
- Vendor shall provide written certification of deletion

Contract clauses should be specific and enforceable. "Vendor will maintain reasonable security" is not a useful clause.

Step 8: Review

Ask the user:

• Are there industry-specific requirements we should add (HIPAA BAA, PCI SAQ)?
• Does legal need to review the contract clauses before they go to the vendor?
• What's the reassessment cadence -- annual, semi-annual, or triggered by vendor incidents?
• Are there existing vendor management policies this assessment should align with?
• Is there a vendor risk register where this assessment should be recorded?

Output location

Deliver as a markdown document. Suggested filename: vendor-assessment-{{vendor-name}}-{{date}}.md. The recommendation section should be extractable for procurement review.