HIPAA and Vendor Risk: What Healthcare IT Leaders Need From a Technology Partner

A signed BAA is a starting point, not proof of compliance

Any vendor that creates, receives, maintains, or transmits protected health information (PHI) on a covered entity's behalf needs a Business Associate Agreement — that includes cloud services with persistent access to ePHI, even when the data is encrypted. But a signed BAA documents an obligation; it doesn't verify the vendor is actually meeting it. Treating the BAA itself as the compliance check is one of the most common — and most consequential — mistakes in healthcare vendor onboarding.

What the agreement actually needs to contain

A properly structured BAA specifies permitted uses and disclosures of PHI, safeguard requirements against unauthorized access, incident and breach notification obligations with defined timeframes, support for patient rights requests flowing through the vendor, data return or destruction terms at termination, and — critically — subcontractor flow-down provisions ensuring any downstream vendor the business associate uses is held to the same restrictions. Missing subcontractor language is a common gap: it leaves a fourth-party vendor with PHI access that no direct agreement actually covers.

What to verify beyond the signature

Independent evidence of security controls

Request the vendor's own risk assessment, security policies, and breach history rather than accepting "we're HIPAA compliant" as a self-certification. HIPAA has no official third-party certification body, so due diligence has to come from documentation review, not a badge on the vendor's website.

Specific technical safeguards, not baseline defaults

Confirm multi-factor authentication, encryption standards for data at rest and in transit, and access logging meet the organization's own risk tolerance — not just whatever the vendor's default configuration happens to be.

Where PHI actually gets used outside the "in-scope" system

A common failure mode isn't the primary system — it's PHI leaking into personal email, unmanaged file-sharing, or support tickets outside the systems the BAA actually covers. Ask specifically how the vendor prevents this, not just how the core platform is secured.

Regular re-verification, not a one-time check

Vendor risk profiles change — a vendor that was adequately secured at onboarding can drift. Annual reassessment of security posture and BAA compliance should be built into vendor management, not treated as a one-time gate.

Where this gets missed

Healthcare IT teams are frequently stretched across clinical system support and security simultaneously, which makes ongoing vendor verification the first thing to slip. An independent, vendor-neutral review of the technology vendor portfolio against these specific requirements — separate from the vendors' own self-certifications — is exactly the kind of assessment MALA runs. Talk to an advisor about your current vendor risk posture.