# Third Party Risk Review

> Assess vendor and business associate risk for healthcare organizations by evaluating BAA compliance, security posture, data handling practices, regulatory compliance, and financial stability of third parties with access to protected health information. Use when onboarding new vendors, conducting periodic BA risk assessments, evaluating cloud and SaaS providers, investigating vendor security incidents, negotiating BAAs, or preparing for OCR audit of business associate management.

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

---


# Third-Party Risk Review

## Overview

Conduct comprehensive risk assessments of third-party vendors and business associates who create, receive, maintain, or transmit protected health information (PHI) on behalf of the covered entity. HIPAA requires covered entities to obtain satisfactory assurances from business associates that PHI will be safeguarded (45 CFR 164.502(e), 164.314(a)), and the HITECH Act extended direct HIPAA compliance obligations to business associates. With healthcare data breaches increasingly originating from business associates (accounting for approximately 30% of breaches reported to OCR), robust third-party risk management is critical for PHI protection, regulatory compliance, and organizational reputation.

## When to Use

- Onboarding a new vendor who will have access to PHI
- Conducting periodic risk reassessment of existing business associates
- Evaluating cloud/SaaS providers for PHI storage or processing
- Investigating a security incident at a business associate
- Negotiating or renewing business associate agreements
- Preparing for OCR audit of business associate compliance
- Assessing subcontractor risk (business associate's downstream vendors)
- Evaluating vendor responses to newly identified vulnerabilities or threats

## Required Inputs

| Input | Description | Format |
|-------|-------------|--------|
| `vendor_profile` | Vendor name, services provided, data access type and volume | Structured object |
| `baa_document` | Current or proposed Business Associate Agreement | Document reference |
| `security_questionnaire` | Vendor responses to security and privacy assessment questionnaire | Structured responses |
| `certifications` | Vendor certifications (SOC 2, HITRUST, ISO 27001, FedRAMP) | Array of certification records |
| `incident_history` | Vendor's history of security incidents and breach notifications | Array of records |
| `financial_data` | Vendor financial stability indicators | Structured object |
| `subcontractor_info` | Vendor's subcontractors who may access PHI | Structured array |
| `regulatory_history` | Any OCR enforcement actions, state AG actions, or consent decrees | Array of records |

## Methodology

### Step 1: Vendor Classification and Tiering

Classify the vendor by PHI access level and criticality:

**Risk Tier Classification:**

| Tier | PHI Access | Service Criticality | Assessment Rigor | Review Frequency |
|------|-----------|---------------------|-----------------|-----------------|
| Tier 1 — Critical | Creates, stores, or processes large volumes of PHI | Essential to operations (EHR, billing, HIE) | Comprehensive assessment | Annual |
| Tier 2 — High | Regular access to PHI for service delivery | Important but not essential | Detailed assessment | Annual |
| Tier 3 — Moderate | Limited or incidental PHI access | Supplementary service | Standard assessment | Biennial |
| Tier 4 — Low | Potential but minimal PHI exposure | Non-critical service | Basic assessment | Triennial or event-driven |

**PHI Access Categorization:**
- **Direct access**: Vendor employees directly access, view, or modify PHI (e.g., medical coding company, transcription service)
- **System access**: Vendor manages systems containing PHI but does not routinely view PHI (e.g., cloud hosting, IT managed services)
- **Incidental access**: Vendor may encounter PHI in the course of non-PHI services (e.g., facilities maintenance, shredding company)
- **No access**: Vendor does not access PHI (not a business associate — no BAA required)

### Step 2: Business Associate Agreement Validation

Evaluate the BAA for HIPAA-required provisions:

**Required BAA Elements (45 CFR 164.314(a)(2)):**

| Provision | Requirement | Status |
|-----------|------------|--------|
| Permitted uses and disclosures | Specific descriptions of allowed PHI use | Present/Adequate |
| Safeguard obligation | BA must use appropriate safeguards to prevent unauthorized use | Present/Adequate |
| Reporting requirement | BA must report unauthorized uses, disclosures, and security incidents | Present/Timeline specified |
| Breach notification | BA must notify CE of breaches without unreasonable delay (60 days max) | Present/Adequate |
| Subcontractor requirements | BA must ensure subcontractors agree to same restrictions | Present/Adequate |
| Individual rights | BA must make PHI available for individual access and amendment requests | Present/Adequate |
| HHS access | BA must make practices and records available to HHS for compliance determination | Present/Adequate |
| Return/destruction | BA must return or destroy PHI at termination | Present/Terms specified |
| Termination provisions | CE may terminate if BA violates material terms | Present/Adequate |

**BAA Red Flags:**
- BAA is expired or missing entirely
- BAA uses generic template without service-specific provisions
- Breach notification timeline exceeds 60 days or is undefined
- No subcontractor flow-down requirements
- No termination provisions for material breach
- BAA does not address return/destruction of PHI at contract end
- Liability caps that effectively nullify breach consequences

### Step 3: Security Posture Assessment

Evaluate the vendor's security controls relevant to PHI protection:

**Security Assessment Domains:**

| Domain | Key Controls | Assessment Method |
|--------|-------------|-------------------|
| Access control | MFA, RBAC, privileged access management | Questionnaire + evidence |
| Encryption | At-rest and in-transit encryption standards | Technical verification |
| Network security | Firewalls, segmentation, intrusion detection | SOC 2 / penetration test reports |
| Vulnerability management | Patch management, vulnerability scanning frequency | Policy + scan reports |
| Incident response | IR plan, testing frequency, notification procedures | Plan review + exercise records |
| Business continuity | Backup, disaster recovery, RTO/RPO commitments | DR test results |
| Physical security | Data center access controls, environmental protections | SOC 2 / site audit |
| Workforce security | Background checks, HIPAA training, sanction policy | Policy + training records |
| Data governance | Data classification, retention, disposal procedures | Policy + procedure review |
| Monitoring | Audit logging, SIEM, anomaly detection | Technical architecture review |

**Third-Party Certifications and Their Coverage:**

| Certification | Scope | HIPAA Alignment | Confidence Level |
|--------------|-------|-----------------|-----------------|
| HITRUST CSF | Comprehensive, HIPAA-mapped | High — directly maps to HIPAA requirements | High |
| SOC 2 Type II | Security, availability, processing integrity, confidentiality, privacy | Moderate — covers many but not all HIPAA requirements | Moderate-High |
| SOC 2 Type I | Same criteria, point-in-time | Low-Moderate — no operational evidence | Moderate |
| ISO 27001 | Information security management system | Moderate — general security, not HIPAA-specific | Moderate |
| FedRAMP | Federal cloud security | Moderate-High — rigorous but federal-focused | Moderate |
| None | Self-attestation only | Low — no independent verification | Low |

### Step 4: Data Handling Practices Evaluation

Assess how the vendor handles PHI throughout its lifecycle:

- **Data collection**: What PHI is collected, from where, and how? Minimum necessary principle applied?
- **Data storage**: Where is PHI stored (geography, cloud vs. on-premises)? At-rest encryption?
- **Data processing**: Who accesses PHI and for what purposes? Role-based access controls?
- **Data transmission**: How is PHI transmitted? TLS 1.2+ for data in transit?
- **Data retention**: How long is PHI retained? Retention aligned with organizational policy and HIPAA?
- **Data disposal**: How is PHI destroyed at contract end? Certificate of destruction provided?
- **Data sharing**: Does the vendor share PHI with subcontractors? Are downstream BAAs in place?
- **Cross-border**: Is PHI stored or processed outside the United States? (May trigger additional legal requirements)

### Step 5: Compliance and Regulatory Assessment

Evaluate the vendor's regulatory compliance posture:

- **HIPAA compliance program**: Does the vendor have a documented HIPAA compliance program?
- **Privacy Officer / Security Officer**: Are designated compliance roles established?
- **Risk analysis**: Has the vendor conducted its own HIPAA Security Rule risk analysis?
- **Training**: Does the vendor provide HIPAA training to all workforce members with PHI access?
- **Incident response**: Has the vendor experienced breaches? How were they handled?
- **OCR enforcement**: Any enforcement actions, resolution agreements, or corrective action plans?
- **State law compliance**: Compliance with applicable state privacy and breach notification laws
- **Litigation history**: Any privacy-related lawsuits or regulatory actions?

### Step 6: Risk Scoring and Decision Framework

Calculate a composite risk score:

**Risk Scoring Model:**

| Category | Weight | Scoring (1-5) |
|----------|--------|---------------|
| PHI volume and sensitivity | 20% | 1 = minimal → 5 = extensive/sensitive |
| Security controls maturity | 25% | 1 = robust → 5 = inadequate |
| BAA adequacy | 15% | 1 = comprehensive → 5 = missing/inadequate |
| Incident history | 15% | 1 = clean → 5 = recent/significant breaches |
| Financial stability | 10% | 1 = strong → 5 = unstable |
| Regulatory compliance | 15% | 1 = exemplary → 5 = enforcement actions |

**Composite Score Interpretation:**
- 1.0-1.5: Low risk — approve with standard monitoring
- 1.6-2.5: Moderate risk — approve with enhanced monitoring and contractual protections
- 2.6-3.5: Elevated risk — approve with risk mitigation requirements and increased oversight
- 3.6-4.5: High risk — remediation required before approval or engagement
- 4.6-5.0: Critical risk — do not engage or terminate relationship pending remediation

### Step 7: Ongoing Monitoring and Reassessment

Establish continuous vendor risk management:

- **Annual reassessment**: Repeat risk assessment for Tier 1 and Tier 2 vendors
- **Continuous monitoring**: Track vendor security posture through threat intelligence feeds
- **Compliance attestation**: Require annual compliance attestation from all business associates
- **Incident notification tracking**: Monitor for vendor security incidents in news and databases
- **Certification renewal**: Track certification expirations (SOC 2, HITRUST, ISO)
- **Contract renewal review**: Reassess risk and update BAA at each contract renewal
- **Subcontractor changes**: Require notification when vendor engages new subcontractors with PHI access
- **Termination planning**: Maintain PHI return/destruction procedures for each vendor

## Output Specification

```yaml
third_party_risk_assessment:
  vendor_name: string
  assessment_date: string
  risk_tier: string
  services_provided: string
  phi_access_type: string
  phi_volume: string
  composite_risk_score: number
  risk_level: string
  baa_status:
    exists: boolean
    current: boolean
    adequate: boolean
    gaps: array
  security_assessment:
    score: number
    certifications: array
    strengths: array
    weaknesses: array
  data_handling:
    storage_location: string
    encryption_at_rest: boolean
    encryption_in_transit: boolean
    cross_border: boolean
  compliance_assessment:
    hipaa_program: boolean
    risk_analysis_current: boolean
    incident_history: array
    enforcement_actions: array
  findings:
    - finding: string
      risk_level: string
      remediation: string
      deadline: string
  recommendation: string  # approve, approve with conditions, remediation required, reject
  monitoring_plan:
    review_frequency: string
    next_assessment_date: string
    ongoing_requirements: array
```

## Analysis Framework

### Vendor Risk Decision Matrix

| BAA Status | Security Posture | Recommendation |
|------------|-----------------|----------------|
| Current and adequate | Strong (HITRUST/SOC 2 Type II) | Approve — standard monitoring |
| Current and adequate | Moderate (SOC 2 Type I or self-attestation) | Approve — enhanced monitoring and remediation plan |
| Current but gaps | Any | Remediate BAA before continued engagement |
| Missing or expired | Any | Stop PHI sharing immediately; execute BAA before resuming |

## Examples

**Example: Cloud EHR Hosting Vendor Assessment**

- Vendor: MedCloud Services (hypothetical), cloud-based EHR hosting
- Risk tier: Tier 1 — Critical (hosts primary EHR with 500,000+ patient records)
- BAA: Current, comprehensive, includes 30-day breach notification and subcontractor flow-down
- Certifications: HITRUST CSF certified (current), SOC 2 Type II (current)
- Security: MFA enforced, AES-256 encryption at rest, TLS 1.3 in transit, 24/7 SOC monitoring
- Data handling: PHI stored in US-based AWS data centers; no cross-border processing
- Incident history: One minor incident 18 months ago (employee accessed staging environment with PHI remnants; no external exposure; self-reported within 5 days)
- Financial stability: 8-year operating history, Series C funded, positive revenue trajectory
- Composite risk score: 1.8 (Moderate — due to incident history and cloud concentration risk)
- Recommendation: Approve with standard monitoring; require annual attestation and disaster recovery test evidence
- Monitoring: Annual reassessment, quarterly compliance attestation, real-time security alert subscription

## Guidelines

1. **No BAA = no PHI sharing** — never share PHI with a vendor without a current, adequate BAA in place
2. **Certifications are not sufficient alone** — SOC 2 covers many controls but does not guarantee HIPAA compliance
3. **Assess subcontractors** — vendor's downstream suppliers may be your biggest risk
4. **Plan for vendor termination** — every vendor relationship should have a defined exit strategy including PHI return/destruction
5. **Verify, don't trust** — self-attestations should be validated through evidence review
6. **Monitor continuously** — annual assessment alone is insufficient for critical vendors
7. **Involve legal counsel** — BAA negotiation should involve healthcare privacy counsel

## Validation Checklist

- [ ] Vendor classified by PHI access level and assigned to appropriate risk tier
- [ ] BAA validated for all required HIPAA provisions (45 CFR 164.314(a)(2))
- [ ] Security posture assessed across all relevant control domains
- [ ] Third-party certifications verified for current validity and scope adequacy
- [ ] Data handling practices evaluated for PHI lifecycle (collection through disposal)
- [ ] Regulatory compliance history reviewed including OCR enforcement actions
- [ ] Subcontractor risk assessed with downstream BAA verification
- [ ] Composite risk score calculated with documented methodology
- [ ] Risk-appropriate recommendation issued (approve, conditions, remediate, reject)
- [ ] Ongoing monitoring plan established with defined reassessment schedule
- [ ] PHI return/destruction procedures verified for contract termination scenario

## HIPAA Compliance Notes

- Business associate management is a required administrative safeguard (45 CFR 164.308(b)(1))
- BAAs must contain all elements specified in 45 CFR 164.314(a)(2)
- Covered entities are responsible for obtaining satisfactory assurances from BAs (45 CFR 164.502(e))
- BAs are directly liable for HIPAA compliance under the HITECH Act (42 USC 17934)
- Subcontractor BAAs are required when BAs delegate PHI handling (45 CFR 164.314(a)(2)(i)(B))
- OCR may hold covered entities responsible for BA violations if the CE knew of violations and failed to act
- BA breach notification must be provided to the covered entity without unreasonable delay, no later than 60 days (45 CFR 164.410)
- Documentation of BA management activities must be retained for 6 years (45 CFR 164.316(b)(2)(i))