# Vendor Third Party Risk

> Performs third-party and vendor risk assessments for compliance programs—security questionnaires, SOC 2 report review, control inheritance, and ongoing monitoring—for LLM, cloud, MCP, and GRC tool vendors (Vanta/Drata alternative operational mindset). Trigger when onboarding vendors, annual vendor reviews, or assessing subprocessor risk for HIPAA, PCI, and SOC 2. Do not use for BAA clause legal analysis (use hipaa-baa-vendor-assessment) or MCP technical hardening (use mcp-compliance-integration).

- Skill: `vaquarkhan/vendor-third-party-risk` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vaquarkhan/vendor-third-party-risk`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vaquarkhan/vendor-third-party-risk/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: vaquarkhan (https://skillmd.com/u/vaquarkhan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vaquarkhan/vendor-third-party-risk

---


# Vendor Third-Party Risk

## Overview

This skill implements **third-party risk management (TPRM)** for compliance programs—operating with the rigor of GRC platforms (Vanta, Drata, Secureframe) but **without assuming a specific vendor tool**. It complements `hipaa-baa-vendor-assessment` (legal BAA focus) with **operational security assessment**:

- Inherent/residual **risk scoring**
- **SOC 2 Type II report** review (bridge letters, subservice orgs)
- **Security questionnaire** mapping (SIG Lite, CAIQ, custom)
- **Continuous monitoring** of vendor status (breach news, certification expiry)
- **Control inheritance** decisions for SOC 2 carve-out reports

Applies to LLM providers, cloud hosts, MCP operators, observability SaaS, and identity providers.

## When to Use

Use this skill when:

- **Onboarding** a new vendor processing customer data, ePHI, or CHD
- **Annual vendor recertification** in compliance calendar
- Reviewing vendor **SOC 2 report** for subservice organization reliance
- Completing **security questionnaires** sent to/from vendors
- Assessing **LLM/AI vendor** risk beyond BAA (model security, logging, subprocessors)
- Building **vendor risk register** for SOC 2 CC9.2 and HIPAA §164.308(b)
- Evaluating **GRC automation tools** themselves as vendors

Do **not** use this skill when:

- Drafting BAA legal clause analysis (use `hipaa-baa-vendor-assessment`)
- MCP OAuth configuration (use `mcp-compliance-integration`)
- Internal employee access reviews (use `access-control-identity-audit`)

## Core Process

Execute steps **in order**.

### Step 1: Vendor tiering

1. Classify vendors by **inherent risk**:

| Tier | Criteria | Review depth | Examples |
| --- | --- | --- | --- |
| T1 Critical | ePHI/CHD processing, production access | Full assessment + SOC 2 + annual onsite/virtual | LLM with BAA, cloud prod, MCP host |
| T2 High | Confidential data, internal network access | SOC 2 + questionnaire | SIEM, IdP, ticketing |
| T3 Medium | Limited data, no prod access | Questionnaire + certification check | Marketing SaaS |
| T4 Low | No sensitive data | Lightweight attestation | Office supplies |

2. Document tier in vendor risk register.

### Step 2: Due diligence data collection

For each in-scope vendor, collect:

1. **SOC 2 Type II report** (≤12 months old) + bridge letter if gap period
2. **ISO 27001/SOC 1** if relevant to service type
3. Completed **security questionnaire** (map to TSC controls)
4. **Pen test summary** or redacted executive summary
5. **Subprocessor list** and change notification process
6. **Insurance** (cyber liability) certificates where required
7. For LLM vendors: data retention, training policy, region, incident history

Store with SHA-256 hashes; redact customer references if sharing internally.

### Step 3: SOC 2 report review methodology

1. Verify report scope covers **services in use** (not just corporate IT).
2. Review **exceptions** and **management responses**—unresolved exceptions = gap.
3. Map **subservice organizations** (carve-out vs inclusive):
   - Carve-out: obtain subservice SOC 2 and map to your CC9.2 monitoring
4. Check **period of time** covers full examination window needed.
5. Document **complementary user entity controls (CUECs)** you must implement.

### Step 4: Control mapping and gaps

1. Map vendor controls to your TSC/HIPAA/PCI requirements:

| Your control need | Vendor evidence | Gap? |
| --- | --- | --- |
| CC6.1 MFA | SOC 2 CC6.1 no exceptions | No |
| HIPAA encryption | BAA + SOC C1 | Verify region |
| PCI segmentation | Not in vendor scope | **You** implement |

2. Gaps become **compensating controls** or **remediation conditions** before production use.

### Step 5: Risk scoring

1. Calculate **inherent risk** (data sensitivity × access level × criticality).
2. Calculate **residual risk** after vendor controls and your CUECs.
3. Score 1–5 or Low/Med/High; T1 vendors with High residual risk **block production** until remediated.
4. Privacy officer / security committee approval for T1 High residual.

### Step 6: Contractual and operational requirements

1. Ensure contracts include:
   - Right to audit / SOC 2 delivery annually
   - Breach notification SLA (≤24–72 hours to you)
   - Subprocessor notification and objection rights
   - Data return/destruction at termination
2. For LLM: no training on customer data, zero retention option documented.
3. Cross-reference `hipaa-baa-vendor-assessment` for BAA execution.

### Step 7: Ongoing monitoring (continuous TPRM)

1. **Quarterly** for T1: recheck SOC 2 expiry, subprocessor changes, breach news (RSS, CISA).
2. **Annually** for T2–T3: full reassessment refresh.
3. Integrate with `soc2-ccm-continuous-monitoring`:
   - Alert on vendor certification expiry 90 days out
   - Auto-create reassessment ticket
4. Off-boarding: verify access revoked, data deleted, tokens rotated.

### Step 8: Risk register and reporting

1. Maintain vendor risk register: tier, score, last review, next review, open gaps.
2. Executive dashboard: T1 vendor health, overdue reviews, open findings.
3. Export evidence for SOC 2 CC9.2 and auditor requests.

## Common Rationalizations

| Excuse the agent might generate | Required rebuttal |
| --- | --- |
| "Big vendor is safe—skip questionnaire." | T1 vendors require **evidence-based** assessment regardless of brand—SOC 2 exceptions happen at scale vendors too. |
| "SOC 2 report from 2 years ago is fine." | Reports **>12 months** without bridge letter fail freshness standards for T1 vendors. |
| "Carve-out means we ignore subservice risk." | Carve-out shifts **monitoring obligation** to you (CC9.2)—obtain and review subservice SOC 2. |
| "Questionnaire completed by sales engineer is sufficient." | Security assessments require **validated** responses mapped to controls—not marketing answers. |
| "We use Vanta/Drata—they manage vendors." | GRC tools **orchestrate** workflows—you still own risk decisions and evidence quality. |
| "LLM vendor passed our pen test." | Your vendor pen test ≠ **their** production security—require their SOC 2 and subprocessors review. |

## Red Flags

- T1 vendor in production without current SOC 2 or equivalent
- Unresolved SOC 2 exceptions for controls you rely on
- Subprocessor added with ePHI access and no review within 90 days
- Vendor breach in news with no impact assessment documented
- Residual risk High with no committee approval
- Vendor access still active after contract termination
- Security questionnaire answers contradict SOC 2 report scope

## Verification

- [ ] All vendors tiered T1–T4 in risk register
- [ ] T1/T2 due diligence package complete (SOC 2, questionnaire, subprocessors)
- [ ] SOC 2 reports reviewed for scope, exceptions, period, and CUECs
- [ ] Control gaps documented with compensating controls or blockers
- [ ] Inherent and residual risk scores calculated with approval for high residual T1
- [ ] Contractual security clauses verified (audit rights, breach SLAs, termination)
- [ ] BAA cross-reference completed for ePHI vendors
- [ ] Ongoing monitoring schedule configured with expiry alerts
- [ ] Off-boarding checklist defined and tested for sample vendor
- [ ] Risk register exported with evidence hashes for SOC 2 CC9.2