HIPAA compliance for SaaS: BAAs, safeguards, and the honest path

A hospital customer emails your sales team asking you to sign a BAA. Your product stores customer data in Postgres on AWS. Nobody at your company has ever read 45 CFR Part 164. The deal is worth six figures and the security questionnaire attached to the email is thirty pages long.

This is the moment most SaaS founders discover that HIPAA compliance is their problem now. Here is what that actually means, what you have to build, and what you do not.

The short answer

A SaaS company becomes a HIPAA business associate the moment a covered entity customer asks you to sign a Business Associate Agreement covering electronic protected health information your product touches. Signing the BAA is the trigger. From that signature forward, the HIPAA Security Rule applies to you directly, and the Office for Civil Rights (OCR) can investigate and fine your company without going through your customer first.

You do not opt in to HIPAA by reading about it. You opt in by agreeing, in a contract, to handle ePHI on behalf of a customer that is itself subject to HIPAA. Before that signature you are a software vendor. After it, you are a regulated entity.

One thing to get out of the way: there is no HIPAA certification. OCR does not certify anyone, HHS does not run a registry, and no private body can issue a certificate that binds a federal regulator. Anyone selling you "HIPAA certification" is selling an attestation or a training badge, not a government stamp.

What a BAA actually is

A Business Associate Agreement is the legal instrument that extends HIPAA downstream from a covered entity to its vendors. The required contents are spelled out in 45 CFR § 164.504(e). Every compliant BAA obligates the business associate to:

• Use and disclose ePHI only as the BAA or law permits.
• Implement the safeguards required by the HIPAA Security Rule.
• Report security incidents and breaches to the covered entity on defined timelines.
• Make its internal practices, books, and records available to HHS on request.
• Flow the same obligations down to any subcontractor that touches ePHI.
• Return or destroy ePHI when the BAA terminates, to the extent feasible.

That is the contract. It is short, usually four to eight pages, and boring to read until the day after an incident, when it is the most important document in the company. Read every BAA you sign before you sign it, and keep a single register of them.

The 2013 Omnibus Rule made business associates directly liable to OCR, which is why enterprise healthcare customers started insisting on BAAs around that time. Before Omnibus, they were nice to have. After, they are the customer's shield and your leash. HHS publishes sample BAA provisions you can use as a starting point when a customer sends you their paper.

When SaaS is not subject to HIPAA

Not every product that touches health-adjacent data is HIPAA-regulated. A few categories that sit outside:

Consumer wellness apps with no covered-entity contracts. A direct-to-consumer sleep tracker, period tracker, or fitness app that signs up individuals off the street is outside HIPAA, even though the data is sensitive. The FTC Health Breach Notification Rule and state laws can still reach these products.

De-identified data. PHI that has been de-identified under the Safe Harbor method or the Expert Determination method at 45 CFR § 164.514 is no longer PHI. Aggregate analytics built on properly de-identified data are outside the Security Rule. Do not assume your hashing scheme qualifies as Safe Harbor, because it almost certainly does not.

Products with no covered-entity customers. If your customers are all employers handling their own employee wellness programs, life insurers, or workers' comp carriers, none of whom are covered entities under HIPAA, then no BAA gets you in scope. That can change the day you sign your first clinic or payer.

Being outside HIPAA is not the same as being outside the law. State privacy statutes, the FTC Act, and sector rules can all reach health data that HIPAA does not. It is just a different conversation.

The minimum technical safeguards

Once you are a business associate, the HIPAA Security Rule applies to you in full — HHS publishes a useful summary of the Security Rule if you want the regulator's own framing. The technical safeguards at 45 CFR § 164.312 are the section most SaaS engineers will actually operate against. Five standards, in plain terms:

Access control. Unique user identification, automatic logoff, and encryption of ePHI where reasonable. In practice: no shared accounts, session timeouts on admin interfaces, encryption at rest on any datastore holding ePHI.

Audit controls. Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. In practice: application audit logs, database audit logs, cloud control-plane logs, with retention long enough to investigate an incident six months later.

Integrity. Controls that ensure ePHI is not improperly altered or destroyed. In practice: backups, change management, database constraints, and tamper-evident logging.

Person or entity authentication. Verify that a person or entity seeking access is who they claim to be. In practice: password policy, MFA for workforce members, SSO for customer users when available.

Transmission security. Guard against unauthorized access to ePHI transmitted over a network. In practice: TLS 1.2+ everywhere, no plain HTTP endpoints, secure email or a portal for anything containing ePHI that leaves your network.

The rule is technology-neutral. It tells you what to protect, not which vendor to buy. Every implementation specification is either required or addressable. "Addressable" does not mean optional. It means you either implement it, implement an equivalent, or document in writing why it is not reasonable for your environment. Skipping an addressable spec without the written rationale is the single most common finding in OCR investigations.

The administrative safeguards you have to document

Technical controls are not enough on their own. The administrative safeguards at § 164.308 are the paperwork layer, and OCR reads the paperwork first when it comes knocking. The baseline every SaaS business associate needs:

• A designated Security Official, named in writing, with accountability for the program.
• A current risk analysis identifying where ePHI lives, what could go wrong, and how likely each scenario is. This is the anchor document; every settlement OCR publishes mentions it.
• A risk management plan that tracks remediation of findings from the risk analysis.
• Workforce training on HIPAA obligations, at hire and annually.
• A sanction policy for workforce members who violate the program.
• An incident response procedure with breach notification timelines that match the HHS Breach Notification Rule.
• Access management procedures for granting, reviewing, and terminating access to ePHI.
• A BAA register tracking every upstream and downstream BAA you have signed.
• A contingency plan covering backups, disaster recovery, and emergency operations.

Most of these live as policies and logs in the same wiki or GRC tool where your SOC 2 evidence lives. The goal is one evidence library, not five.

The risk analysis is the one document OCR always asks for. Date it, sign it, refresh it when your architecture changes.

Physical safeguards: what you inherit from the cloud

The physical safeguards at § 164.310 cover facility access, workstation security, and device and media controls. For a cloud-native SaaS, the facility piece is almost entirely inherited from your hosting provider.

AWS, Azure, and GCP all sign BAAs with customers and publish lists of HIPAA-eligible services. If you are building on HIPAA-eligible services under an active BAA with your cloud provider, the datacenter-level physical controls are theirs to operate and yours to rely on. The SOC 2 Type II reports those providers publish are how you evidence that reliance.

Inheritance is not abdication. You still have to:

• Sign the cloud provider BAA (AWS's BAA is in AWS Artifact, Azure's is in the Service Trust Portal, GCP's is in the Cloud Console).
• Keep ePHI on the HIPAA-eligible services list, not on the non-eligible ones.
• Document the inheritance in your own policies and risk analysis.
• Run the workstation and endpoint pieces yourself, because no cloud provider controls your laptops.

The inheritance question is where most SaaS BAs get tripped up in diligence. Have a one-page map that names each cloud service you use, whether it is HIPAA-eligible, and which BAA covers it.

How SOC 2 maps to HIPAA

Most SaaS business associates end up running SOC 2 and HIPAA as one program, because the control overlap is roughly 70% to 80%. The SOC 2 compliance requirements — access control, audit logging, encryption in transit and at rest, incident response, change management, vendor oversight, workforce training, and business continuity — all show up in both the Trust Services Criteria and the Security Rule. The test evidence is largely the same. What differs is the opinion on the cover page.

A SOC 2 Type II report does not, by itself, prove HIPAA compliance. HIPAA has specific requirements around BAAs, breach notification, and the risk analysis that SOC 2 does not automatically test. But a SOC 2 Type II plus a documented HIPAA program plus signed BAAs is the package most enterprise healthcare buyers accept in lieu of a standalone HIPAA audit. What a SOC 2 report actually tells your buyer walks through how procurement reads the report.

The shape of the program we recommend for SaaS BAs is:

1. Run a SOC 2 Type II with Security as the base criteria.
2. Layer a HIPAA policy set, risk analysis, and training on top of the SOC 2 evidence library.
3. Keep a clean BAA register, both upstream (your customers) and downstream (your subprocessors).
4. Have your auditor note the HIPAA-relevant controls in the SOC 2 description, which buyers can map themselves.

That combination has cleared enterprise healthcare procurement for most of the SaaS clients we work with.

When HITRUST becomes the right next step

At some point a specific buyer, usually a large hospital system or payer, will ask for HITRUST certification instead of or on top of SOC 2. HITRUST is a private framework that produces a prescriptive, testable control set with a certificate issued by a HITRUST-authorized External Assessor. It is the heaviest healthcare ask in the US market.

Three tests for whether it is time:

1. A named buyer, in writing, has made HITRUST a condition of the contract, or your ICP has uniformly moved to requiring it.
2. The deal or pipeline justifies a six- to seven-figure program.
3. You already have a mature SOC 2 and HIPAA program to build on, so HITRUST is a layer rather than a greenfield build.

Below roughly $20M ARR, most healthcare SaaS companies do not need HITRUST. Above that line, whether you need it depends on who your customers are, not on where you want to be seen. Start with SOC 2 plus a documented HIPAA program, and upgrade when a real deal forces the question.

---

If a covered-entity customer is asking for a BAA and you are trying to figure out what you actually have to build, get in touch. We are a licensed CPA firm, we do the SOC work, and we help SaaS clients stand up HIPAA programs on top of it. See our services for what we do and do not cover.