HIPAA compliance for SaaS startups: How to negotiate a BAA that protects you

HIPAA compliance for SaaS comes down to one document more than any other: the business associate agreement (BAA). 

If your SaaS product creates, receives, maintains, or transmits protected health information (PHI) on behalf of a healthcare customer, you are almost certainly a business associate under HIPAA, and the BAA is the contract that defines your legal exposure. 

There is no such thing as “HIPAA certification,” so compliance is an ongoing program rather than a one-time stamp. To help you get HIPAA compliance for SaaS right, below we will look at when HIPAA applies, what a BAA must include, and where you can negotiate. None of this is legal advice, but it will leave you prepared for the conversation.

Key takeaways

• SaaS that handles PHI for a healthcare customer is a business associate and must sign a BAA.
• A BAA's required terms are fixed, but breach timelines, liability caps, subprocessor flow-down, and audit rights are negotiable.
• Signing is not the finish line: Security Rule safeguards and a documented risk analysis are what regulators check.

Are you a business associate?

The threshold question decides everything else. A business associate is any entity that handles PHI to perform a service for a covered entity, which covers most SaaS vendors, cloud platforms, and document storage providers whose software touches electronic PHI (ePHI). If your application stores patient records, processes claims, or even passes health data between systems with the ability to access it, you qualify as a business associate. Scheduling tools, claims analytics products, transcription services, and cloud storage for ePHI are common examples.

There is a narrow "conduit exception" for services that only transmit data without accessing it, such as an internet service provider or a postal carrier. It rarely applies to SaaS, because most software can technically access the data it processes. The bigger point for founders is direct liability. Since the HITECH Act of 2009, business associates can be penalized directly by regulators, not just sued by their customers, and the HHS Office for Civil Rights enforces the rules against both parties.

What a HIPAA BAA must contain

A BAA is not a boilerplate you can skip. Federal regulation (45 CFR 164.504(e)) sets out the elements every agreement must include, and a covered entity's legal team will check for them. 

At a minimum, the contract has to define how you may use PHI, require you to safeguard it, obligate you to report incidents and breaches, flow the same obligations down to any subprocessor, support individual rights, give HHS access to your records, and address PHI when the relationship ends. For reference language, HHS's sample business associate agreement provisions are a useful starting point.

Required elements of a HIPAA BAA

Here are the required elements, and what each one commits you to:

Where SaaS startups actually negotiate a BAA

The required elements of a BAA are fixed, but the commercial terms around them are not. This is the part of HIPAA compliance for SaaS where founders have the most leverage, so preparation pays off.

A few clauses deserve real attention:

• Breach notification timelines: Breach notification timelines are the most common sticking point. Covered entities often ask for notice within 24 hours of discovery. While that can sound reasonable on paper, agreeing to a clock you cannot realistically meet only sets you up to breach the contract itself. A better move is to counter with a window that reflects how long your team actually needs to triage an incident, and to spell out exactly when that clock starts running.
• Liability and indemnification: Liability and indemnification carry the largest financial stakes, which is why they are worth slowing down for. Many first drafts arrive with uncapped indemnification, which can create existential exposure for a startup. A reasonable counter is to cap liability at a multiple of the fees paid while carving out breaches caused by your own negligence. Since these caps are commercial norms rather than HIPAA requirements, they are genuinely negotiable, and most counterparties expect some back and forth before you land on a number.
• Subprocessor flow-down: Subprocessor flow-down deserves attention because you are required to bind every vendor that touches PHI to the same terms you have agreed to. If a customer wants to pre-approve each subprocessor individually, a workable compromise is a notice-and-object model backed by a subprocessor list you keep current. That gives the customer visibility without stalling your roadmap every time you add a tool.
• Audit rights: Rather than accepting on-site audits on demand, you can offer an annual third-party attestation, such as SOC 2. This gives customers assurance without creating open-ended operational disruption for your team.
• Data handling at termination: Rather than committing to destroy PHI immediately, negotiate a defined return-or-destruction window that your systems are actually able to honor. This gives both sides clarity and helps you avoid promising a timeline your infrastructure cannot support.

BAA negotiation: common ask vs. reasonable counter

Here are the asks you are most likely to see, and a counter for each that protects a startup without being unreasonable:

HIPAA compliance requirements for SaaS products beyond the BAA

The HIPAA compliance requirements for SaaS products do not end at signing. A signed BAA is a promise; the HIPAA Security Rule is what you must actually do to keep it. Its requirements fall into three categories: administrative safeguards (risk analysis, workforce training, access management), physical safeguards (facility and device controls), and technical safeguards (access controls, audit logging, transmission security). A documented risk analysis is the single most cited gap in OCR investigations, so it is the first artifact to get right.

Change is also on the horizon. In December 2024, OCR issued a notice of proposed rulemaking that would significantly update the Security Rule, making currently "addressable" measures mandatory: encryption of ePHI at rest and in transit, multi-factor authentication, asset inventories, network segmentation, and defined incident response timelines. As of June 2026, this is still a proposal, not a law. It could be finalized, modified, delayed, or withdrawn, and the current Security Rule remains in effect. You can follow the status on OCR's proposed Security Rule update page. The practical takeaway is that covered entities are increasingly writing these controls into BAAs regardless of the rule's fate, so expect them at the table. Knowing the penalties for noncompliance is a useful reality check: after the January 2026 inflation adjustment, the most serious tier reaches roughly $2.19 million per violation category in a single year.

How can SaaS companies become HIPAA compliant?

Becoming HIPAA compliant follows a clear sequence rather than a single action. It begins with confirming whether you are a business associate, then signing a BAA with every covered entity you serve and every subprocessor that touches PHI. 

From there, the work shifts to implementing the Security Rule's administrative, physical, and technical safeguards and, just as importantly, completing and documenting a risk analysis that you keep current rather than revisiting once a year. None of this is a one-time effort, because HIPAA compliance for SaaS is a program you maintain, and independent audits or frameworks such as SOC 2 help you prove it to customers.

A pre-signature BAA checklist for founders

Before you sign anything, run through these checks:

• Confirm you are actually a business associate, and not exempt under the conduit exception.
• Map every subprocessor that will touch PHI, and confirm each is covered by a downstream BAA.
• Make sure the breach-notification clock is one you can meet.
• Check whether liability is capped, and whether the cap has a breach carve-out.
• Confirm the mechanics for returning or destroying PHI at termination.
• Verify your risk analysis is current, documented, and dated.

If you are early in the process, set this work inside a broader HIPAA program for startups rather than treating the BAA as a one-off.

How Scrut simplifies HIPAA compliance for SaaS companies

A signed BAA is only the start of HIPAA compliance for SaaS, and the harder part, keeping the Security Rule safeguards running and being able to prove them, is where a GRC platform earns its place. Scrut supports HIPAA as one of its 60-plus built-in frameworks, with pre-mapped controls and ready-to-use policies that turn the administrative, physical, and technical safeguards into a structured program rather than a pile of disconnected documents. It also helps you run and document the risk analysis that OCR most often finds missing, and keeps it current rather than dusted off once a year.

The vendor and evidence side matters just as much. Scrut's vendor management helps you track which subprocessors touch PHI and whether each is covered by a downstream BAA, while its integrations collect evidence automatically and monitor your controls around the clock, so you stay audit-ready when a customer's security team comes asking. Book a demo to see how Scrut can support your HIPAA program end-to-end.

FAQs

Does a SaaS company need to be “HIPAA certified”?

No. There is no official HIPAA certification from HHS. Vendors can demonstrate diligence through independent audits and frameworks, but no certificate makes you “HIPAA certified.”

Who is liable if a subprocessor causes the breach?

You remain responsible for your subprocessors, and the subprocessor can also face direct liability. This is why flow-down BAAs matter.

Can we sign one BAA template for every customer?

You can start from your own template, but larger covered entities often require theirs. Expect to negotiate.

How fast must we report a breach to the covered entity?

The timing is set by your BAA. The law requires reporting without unreasonable delay, and many BAAs specify a tighter, fixed window.

Is encryption required under HIPAA?

Under the current Security Rule, encryption is "addressable," which means you must implement it or document a reasonable alternative that provides equivalent protection. In practice, most covered entities expect ePHI to be encrypted in transit and at rest, and the proposed 2026 update would make it mandatory if finalized. Encryption that meets HHS standards also matters because a breach of properly encrypted PHI generally does not trigger breach notification.

‍