HIPAA for SaaS: what business associates actually need to do

HIPAA confuses SaaS founders because it is law, not certification, and because the regulatory text predates modern SaaS architecture by twenty years. There is no government-issued HIPAA certificate. Compliance is demonstrated by a continuous program, and the only formal third-party attestations are commercial alternatives like HITRUST CSF.

For a SaaS handling PHI on behalf of covered-entity customers, the obligations are concrete. Here is what business associates actually need to do, in plain language.

Are you a business associate?

Under HIPAA, a business associate is any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Covered entities are health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically in connection with covered transactions.

Practical test: if your customer is a hospital system, insurance company, or digital health platform, and you process patient data on their behalf, you are a business associate. If you sell fitness tracking directly to consumers and never to a healthcare provider, you may be outside HIPAA entirely.

Edge cases that often surprise:

• Cloud providers (AWS, GCP, Azure). Business associates of their healthcare customers; the CSPs sign BAAs with eligible customers.
• Email providers, video conferencing, ticketing tools. Business associates if used by a covered entity for PHI; the customer covered entity needs to confirm BAA availability.
• Direct-to-consumer health apps. Often outside HIPAA, but state laws (California CMIA, Washington My Health My Data) may apply.

The Business Associate Agreement

Before any PHI flows, a Business Associate Agreement signed under 45 CFR §164.504(e) is required. The BAA contains specific terms: permitted uses, safeguards, subcontractor obligations, breach reporting timelines, return or destruction of PHI on termination.

The agreement flows downstream. If you handle PHI through subprocessors (cloud providers, analytics, monitoring), each needs a BAA with you. Missing downstream BAAs is a common gap; OCR enforcement actions cite it routinely.

The Security Rule: technical and administrative safeguards

The Security Rule (45 CFR §164.302 to 318) governs ePHI. Safeguards split into three categories:

Administrative safeguards

• Risk analysis (§164.308(a)(1)(ii)(A)). The most-cited HIPAA control in OCR enforcement. Required, documented, environment-specific. Not a one-page form.
• Risk management (§164.308(a)(1)(ii)(B)). Plan to address risks identified in the analysis.
• Sanction policy (§164.308(a)(1)(ii)(C)). Workforce member discipline for HIPAA violations.
• Information system activity review (§164.308(a)(1)(ii)(D)). Regular review of audit logs, access reports, security incident records.
• Workforce security (§164.308(a)(3)). Authorization, supervision, termination procedures.
• Access management (§164.308(a)(4)). Role-based access, periodic review.
• Workforce training (§164.308(a)(5)). Security awareness; refresher training; phishing simulations or equivalent.
• Contingency plan (§164.308(a)(7)). Backup, disaster recovery, emergency mode operation.
• Evaluation (§164.308(a)(8)). Periodic re-assessment of compliance.

Physical safeguards

• Facility access controls: for cloud-native SaaS, largely satisfied by the cloud provider's SOC 2; document the inheritance.
• Workstation security: laptops in MDM, screen lock, encryption.
• Device and media controls: disposal procedures, media reuse policy.

Technical safeguards

• Access control (§164.312(a)). Unique user identification, automatic logoff, encryption and decryption (addressable).
• Audit controls (§164.312(b)). Logging of activity in systems containing ePHI.
• Integrity (§164.312(c)). Protect ePHI from improper alteration or destruction.
• Person or entity authentication (§164.312(d)). Verify identity before access.
• Transmission security (§164.312(e)). Integrity controls and encryption (addressable) for ePHI in motion.

“Addressable” is not optional. It means implement, or implement an equivalent, or document why the safeguard is not reasonable and appropriate. Treating addressable as optional is a frequent finding.

The Privacy Rule: what business associates do

The Privacy Rule (45 CFR §164.500 to 534) primarily binds covered entities, but the Omnibus Rule (2013) extended specific provisions directly to business associates. For business associates:

• Use and disclose PHI only as the BAA permits.
• Make PHI available for the data subject's access request as required by the covered entity.
• Track disclosures of PHI for accounting purposes.
• Notify the covered entity of breaches.
• Return or destroy PHI when the BAA terminates.

Breach notification

The Breach Notification Rule (45 CFR §164.400 to 414) requires:

• Business associates notify the covered entity without unreasonable delay and no later than sixty days after discovery.
• Covered entities notify affected individuals within sixty days, plus HHS and (for breaches of 500+ residents of a state) prominent media.

In practice, covered entities expect notification within hours to days. Sixty days is the legal ceiling, not the operational target. A documented runbook with severity levels, a tested tabletop exercise, and a clear contact list for the covered entity's security team are the practical needs.

What enforcement actually looks like

OCR enforcement comes in two shapes: complaint-driven investigations after a reported incident, and resolution agreements following high-impact breaches. The most-cited gaps in resolution agreements:

1. Inadequate or missing risk analysis.
2. Insufficient access controls.
3. Lack of audit controls or log review.
4. Missing or non-compliant BAAs with subcontractors.
5. Failure to encrypt ePHI on stolen or lost devices.

Penalties tier by culpability: 100 USD to 50,000 USD per violation for unknowing violations, escalating to 1.5 million USD per identical violation per year for willful neglect uncorrected. Settlements with OCR commonly fall in the 100,000 to 5 million USD range.

What customers actually ask for

Covered entity procurement teams typically request:

• Signed BAA on their template (or yours, if acceptable).
• Evidence of a recent risk analysis.
• Workforce training records.
• Audit log retention details.
• Encryption posture (at rest and in transit).
• Subprocessor list with BAAs.
• Breach notification process and contact path.
• Optionally, a HITRUST CSF certification or independent third-party attestation.

HITRUST CSF: when it is worth it

HITRUST CSF is the most-recognized commercial framework that maps to HIPAA. Certification is expensive (15,000 to 40,000 USD plus the assessor cost) and demanding, but customers may explicitly require it, especially large hospital systems and payers.

Without HITRUST, an independent attestation (often called a HIPAA attestation or HIPAA risk assessment letter) from a security firm can satisfy customers who do not specifically require HITRUST. Cheaper, faster, less rigorous.

The HSD playbook for HIPAA

For SaaS becoming a business associate for the first time:

1. Map every PHI flow. Where it enters, where it stores, where it leaves.
2. Conduct the §164.308(a)(1)(ii)(A) risk analysis. Document it. Update annually.
3. Roll out administrative safeguards: workforce training, access management, sanction policy, contingency plan.
4. Implement technical safeguards: unique user IDs, audit logs, encryption at rest and in transit, integrity controls.
5. Stand up the BAA flow: customer-facing template, subprocessor inventory with current BAAs.
6. Build the breach runbook and run a tabletop.
7. Decide on third-party attestation: HITRUST or lighter alternative based on customer asks.

For the full HIPAA program structure see the HIPAA pillar. Talk to HSD if you want a HIPAA gap assessment scoped to your environment.