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

Methodology

Step 1: Vendor Classification and Tiering

Classify the vendor by PHI access level and criticality:

Risk Tier Classification:

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)):

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:

Third-Party Certifications and Their Coverage:

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:

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

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

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))