HIPAA and software vendors — BAAs done properly.

HIPAA in the software estate.

The Health Insurance Portability and Accountability Act (HIPAA) and its implementing regulations — the Privacy Rule, the Security Rule, the Breach Notification Rule, and the Omnibus Rule — impose obligations on Covered Entities (health plans, healthcare providers and clearinghouses) and on their Business Associates. The intersection with software licensing is that any vendor providing software that creates, receives, maintains, or transmits Protected Health Information (PHI) is a Business Associate, and the relationship must be governed by a Business Associate Agreement (BAA). The BAA modifies the standard software licence in specific, non-negotiable ways.

Across the engagements we run with health systems, payers and life-sciences companies, the most common HIPAA-compliance gap is not the security controls (which most enterprises run reasonably well) but the licensing documentation that supports the controls. The Office for Civil Rights (OCR) does not audit licence agreements directly, but in a breach investigation OCR will request the BAA, the underlying software contract, the entitlement evidence, and the access logs — in that order. Buyers who cannot quickly produce these four artefacts pay materially higher penalties.

What the Business Associate Agreement actually changes.

A BAA is a contractual instrument that imposes HIPAA obligations on the vendor (Business Associate) and creates downstream obligations on any subcontractor (sub-Business Associate). The required provisions are set out in 45 CFR 164.504(e). The practical effect on the software contract: the standard limitation of liability has to be carved out for HIPAA-related breaches, the data-handling provisions have to align with HIPAA Security Rule requirements (164.308–164.312), and the audit-rights clause has to permit the Covered Entity to inspect the Business Associate's safeguards.

Vendor-standard BAAs are typically vendor-protective. The Salesforce, AWS, Microsoft and Google standard BAAs are reasonable starting points; the standard BAAs from smaller SaaS vendors are not. Three provisions to always review and frequently revise: breach notification timing (vendor-standard is often "without unreasonable delay" — require a specific number of business days), subcontractor flow-down (require the Covered Entity's right to receive a list of all sub-Business Associates), and termination (require return or destruction of PHI within a specific period after termination, with attestation).

Administrative, physical, technical safeguards.

The HIPAA Security Rule organises required safeguards into three categories. The licensing-relevant requirements:

Administrative safeguards (164.308)

Includes the requirement for a security management process, workforce security, information access management, security awareness, security incident procedures, and contingency planning. Two specifications pull on licensing: the access authorisation process (which has to match the licensing entitlement) and the contingency plan (which determines whether your DR licensing is compliant).

Physical safeguards (164.310)

Less licensing-relevant but worth noting: workstation use and device controls touch on endpoint software, including the BYOD policies that many SaaS contracts implicitly permit.

Technical safeguards (164.312)

Includes access control, audit controls, integrity controls, transmission security, and authentication. Each is a control area where the software vendor's product configuration matters. The Security Rule does not mandate specific technologies but does require addressable specifications around encryption and audit logging.

What happens when something breaks.

A breach of unsecured PHI triggers notification obligations: to affected individuals within 60 days, to the Secretary of HHS, and (for breaches of 500+ individuals) to media. The OCR investigation that often follows examines whether the Covered Entity and Business Associate had appropriate safeguards in place, including contractual safeguards. The licensing evidence requested typically includes: the executed BAA, the underlying software contract, current entitlement evidence, access logs covering the breach window, and any prior risk assessments touching the affected system.

In our experience across 340+ engagements, the most common cause of elevated penalty is missing or stale documentation. A BAA executed five years ago and never refreshed is treated as evidence of inattention. A risk assessment older than 12 months is treated as inadequate. The mitigation is mechanical: review BAAs at every contract renewal, refresh risk assessments annually, and maintain entitlement evidence current to the most recent quarter. A periodic software license compliance assessment keeps the BAA, entitlement evidence and access logs reconciled before OCR ever asks for them.

The cloud-vendor BAA landscape.

All three hyperscalers (AWS, Azure, GCP) execute BAAs covering specific services, with the in-scope service list updated periodically. The buyer's obligation is to ensure that PHI never flows into out-of-scope services. The most common compliance failure is configuration drift — a service was in scope at procurement but the workload migrated to a related service that is not. Continuous monitoring of service usage against the BAA scope list is the only reliable control. Microsoft, Salesforce, ServiceNow, Workday and most other major SaaS vendors execute BAAs for their healthcare-eligible products. Smaller SaaS vendors vary widely.