HIPAA Vendor Due Diligence: What the BAA Doesn't Cover

The HIPAA Security Rule (§ 164.308(b)(1)) requires covered entities to obtain satisfactory assurances that Business Associates will appropriately safeguard PHI. The Privacy Rule (§ 164.502(e)) requires written agreements (BAAs) governing PHI use and disclosure. Together, these create two distinct obligations: a contractual obligation (the BAA itself) and a due diligence obligation (verifying the Business Associate actually has adequate safeguards). Most organizations fulfill the first and ignore the second. OCR enforcement actions have increasingly focused on whether covered entities performed adequate due diligence before and during Business Associate relationships — not just whether they signed a BAA.

Section 164.308(a)(1)(ii)(A) requires covered entities to conduct an accurate and thorough assessment of potential risks and vulnerabilities to PHI — including PHI held by Business Associates. This means evaluating: Does the vendor encrypt PHI in transit and at rest? What access controls does the vendor maintain? How does the vendor handle breach notification? What subprocessors does the vendor use, and do they have BAAs in place? Has the vendor experienced security incidents? Are the vendor's claimed certifications (SOC 2, HITRUST) verifiable? Each of these should be documented — the assessment itself is the evidence OCR looks for.

For each vendor that accesses PHI, document your assessment of:

Security posture. TLS configuration, security headers, known vulnerabilities, and infrastructure exposure. ThirdProof checks these automatically across 24 intelligence sources.

Compliance certifications. Does the vendor hold SOC 2, HITRUST, or other relevant certifications? Can these be independently verified, or are they self-attested on a trust page?

Breach history. Has the vendor appeared in HHS breach reports, adverse media, or regulatory enforcement actions? Past incidents inform current risk.

Subprocessor chain. Who does the vendor share PHI with? Do those subprocessors have BAAs? Can you identify the vendor's subprocessor list?

Business legitimacy. Is the vendor a registered, legitimate business entity? Are they on any sanctions or watchlists?

Document findings for each area with source citations. The BAA establishes the legal framework — your risk assessment establishes that you verified the vendor's ability to fulfill it.

HIPAA audit documentation for vendor due diligence should include: (1) a Business Associate inventory listing all vendors with PHI access, BAA status, and risk classification, (2) individual vendor risk assessments documenting security posture, certification verification, breach history, and subprocessor analysis, (3) BAA copies for all Business Associates, (4) periodic reassessment records showing ongoing monitoring, and (5) incident response documentation for any Business Associate security events. ThirdProof reports include HIPAA-specific formatting when the healthcare industry module is active — findings are mapped to Security Rule requirements and include PHI-relevant risk factors.

BAA without assessment. Signing a BAA without documented due diligence is the most common gap. OCR expects evidence that you evaluated the vendor's security before granting PHI access, not just after signing a contract.

Missing subprocessor oversight. If your Business Associate uses subprocessors that access PHI, you're responsible for ensuring BAAs flow down. Many organizations don't even know their vendors' subprocessors.

No periodic reassessment. A vendor assessed once in 2022 with no update creates risk. Security posture changes, breaches occur, and business relationships evolve. Annual reassessment of critical Business Associates is expected.

Certification claims taken at face value. Vendor trust pages listing SOC 2 or HITRUST without independent verification is insufficient. Request the actual SOC 2 report or HITRUST certificate, or use independent verification tools.

Missing breach monitoring. After signing a BAA, organizations should monitor for vendor breach notifications and adverse security events. This demonstrates ongoing oversight rather than point-in-time compliance.