HIPAA Compliance Requirements for Software Vendors and SaaS Platforms

Software vendors handling patient data under HIPAA face a compliance regime that never stays still: rules interlock, contracts chain across subcontractors, and a proposed 2025 rewrite is about to turn "best practice" into "mandatory." This piece walks through each layer, from the four rules that govern Business Associates to the enforcement actions that show what actually happens when the layers fail.

HIPAA runs on two categories of parties: Covered Entities (the providers, hospitals, and health plans everyone pictures when they hear "HIPAA") and Business Associates, the vendors, contractors, and platforms that touch patient data on a Covered Entity's behalf. Since the 2013 Omnibus Rule, Business Associates carry the same compliance obligations and the same penalty exposure as Covered Entities. That's worth sitting with for a second, because a lot of vendors still operate as if BA status is some kind of watered-down, secondary tier of responsibility. If a company qualifies as a BA, HHS holds it to the same standard as the hospital down the street.

The definition of a Business Associate is broad by design: any person or organization that creates, receives, maintains, or transmits electronic protected health information (ePHI) on behalf of a Covered Entity. Working through those four verbs, "maintains" is the one that seems to trip vendors up most. Storing ePHI on a server, even encrypted, even if the vendor never holds the decryption keys, triggers BA obligations. A company running an AWS S3 bucket full of encrypted patient records is a Business Associate regardless of who can actually open the files.

Three assumptions come up again and again, and none of them hold up once you test them against the actual rule. "We only process, we don't store" doesn't work, because ePHI passing through memory during processing still counts. "Our customer controls the data" is irrelevant, since BA status is a question of access, not ownership. And "we're not in healthcare" falls apart the moment an HR platform, an analytics tool, or a marketing SaaS product gets adopted by a hospital system or health plan. Health-adjacent doesn't mean exempt. The first real step for any vendor sorting this out is mapping every data flow and asking, at each point, whether ePHI touches the system. The compliance question follows from that answer; it doesn't precede it.

The four HIPAA rules that govern what BA obligations actually look like in practice

HIPAA is four separate rules, each applying to Business Associates differently than to Covered Entities, and each doing a distinct job.

The Privacy Rule applies to BAs mainly through the minimum necessary standard: use only the data needed for the task at hand, nothing more. When a vendor's platform stores patient data directly, it also has to support patient access and amendment requests, the same rights patients have with their own doctor. The Security Rule is the heavier lift: full responsibility for administrative, technical, and physical safeguards protecting ePHI. This isn't optional, and a vendor can't quietly hand it off to a subcontractor and call it done.

The Breach Notification Rule sets the clock: BAs must notify the Covered Entity of a breach without unreasonable delay, and no later than 60 days after discovery. Discovery, not confirmation. That distinction has burned more than one vendor who waited to notify until an internal investigation wrapped up, only to find out the 60-day window started the moment someone noticed something was wrong. Then there's the Enforcement Rule, which applies penalties directly to the BA, not just the Covered Entity that hired the vendor.

Line these four up and a pattern shows: the BAA is the legal contract required under the Privacy Rule, the Security Rule spells out what that contract has to promise, the Breach Notification Rule sets the timeline for when things go wrong, and the Enforcement Rule prices out the cost of failure. Compliance is a legal posture built from contracts, technical controls, written policy, and processes that keep running long after the sales deal closes.

Business Associate Agreements: what they must contain, who must sign them, and where the chain breaks

Without a signed Business Associate Agreement, sharing PHI with a vendor isn't legally permitted under HIPAA, no matter how airtight that vendor's security setup looks on paper. The BAA does two jobs at once: it satisfies a regulatory requirement, and it creates direct contractual liability between the Covered Entity and the vendor. Skip it, and both sides sit exposed to federal enforcement, security posture aside.

The dollar figures make the stakes concrete. Missing BAAs can contribute to penalties reaching $2,190,294 annually, and BAA deficiencies showed up as a contributing factor across numerous of OCR's 22 enforcement actions in 2024, actions that together collected over $9.9 million.

A valid BAA needs to spell out the permitted uses and disclosures of PHI (anything not explicitly allowed is treated as prohibited), require Security Rule compliance from the BA, and set breach notification terms. Most BAAs contractually shrink that 60-day window down to 24 to 72 hours, which sounds like a small detail until it's 2 a.m. during an actual incident and legal counsel is arguing over whether the clock started at "we noticed something odd" or "we confirmed the breach." It also needs a subcontractor clause requiring the BA to sign its own BAAs with anyone downstream who touches PHI, plus termination terms covering what happens to the data when the contract ends: return it, destroy it, or if neither is feasible, keep protecting it indefinitely.

That subcontractor chain is where most compliance programs quietly fall apart. A SaaS vendor running on AWS, sending messages through Twilio, or piping data to an analytics partner needs a signed BAA with every single one of those companies if PHI passes through them. Nobody hands these out by default. Microsoft offers a HIPAA BAA for Microsoft 365 in healthcare contexts, and Google does the same for Workspace, but a vendor has to actually request it. Standard consumer email doesn't offer BAAs at all, which is exactly why healthcare-specific encrypted email services build one into the product from day one. Miss a link in that subcontractor chain, and the liability reaches back to the Covered Entity too. Review the BAA at least once a year, and update it any time a vendor adds a service touching PHI, brings on a new sub-processor, or a regulatory change shifts the requirements underneath everyone's feet.

Administrative safeguards: the policies, training, and risk analysis requirements that underpin everything else

Administrative safeguards are the least glamorous part of a HIPAA program and the part everything else depends on. They govern how people, written policy, and day-to-day procedure work together to protect ePHI, and they make up the largest single category of requirements inside the Security Rule.

Everything starts with the Security Management Process: an accurate, thorough assessment of the risks and vulnerabilities threatening the confidentiality, integrity, and availability of ePHI. Risk analysis has to be documented, reviewed, and updated as systems change and new threats show up, and a missing or incomplete risk analysis is one of the most commonly cited failures in OCR enforcement actions. Ask any compliance officer what keeps them up at night and this is usually the answer: the paperwork nobody updated after the last product launch.

Workforce training needs to happen regularly and get documented, meaning someone can point to a record showing who was trained, when, and on what. Access management requires formal procedures for granting and revoking system access, tied directly to employment status, so when someone leaves the company their access leaves with them, not three months later. Contingency planning covers backup, disaster recovery, and emergency procedures; the proposed 2025 rule would require systems to come back online within 72 hours, which is a tight window if a company hasn't rehearsed it. For SaaS teams specifically, none of this can stop at full-time employees sitting in an office. Policies need to cover remote work, personal devices, and contractors, because that's where most of the actual workforce lives now.

Technical safeguards: encryption, access controls, audit logging, and the standards vendors are expected to meet

Technical safeguards protect ePHI through the systems themselves, across four categories: access controls, audit controls, integrity controls, and transmission security.

Access controls start with unique user IDs; shared logins are a nonstarter. Add least-privilege, role-based permissions so people see only what their job requires, and multi-factor authentication, which is already expected practice and would become explicitly mandatory under the proposed 2025 rule. On the transmission side, data in transit needs HTTPS with TLS 1.2 or higher, and data at rest is widely encrypted with AES-256, though HIPAA itself doesn't name a specific encryption standard; it's a best practice, not a checkbox in the regulation's text. PHI in plaintext email is still one of the most common failure points, and it's an easy one to avoid.

Audit controls are the most operationally demanding piece of the whole framework. Systems have to record and let someone actually examine activity: who accessed ePHI, when, and what they did with it, including access events, deletions, exports, and even metadata changes. In cloud environments, this usually means turning on detailed logging services like AWS CloudTrail to capture API calls and user activity. HIPAA doesn't set a specific log retention period, but the six-year documentation minimum under 45 C.F.R. § 164.316(b)(2)(i) is the baseline most programs build around; California and Texas both require seven years, so any vendor serving patients in those states should plan for the longer window rather than get caught mid-audit explaining a gap.

Integrity controls exist to catch and prevent unauthorized changes to ePHI, and that includes metadata, not just the visible record itself. Physical safeguards work a bit differently: cloud-native vendors get to outsource the data center security question to AWS or Azure, but they're still on the hook for workstation security (the laptop an employee uses to access PHI from a coffee shop counts) and secure disposal of any media that ever held patient data.

What the proposed 2025 HIPAA Security Rule overhaul would require of software vendors

In January 2025, HHS published a Notice of Proposed Rulemaking for the HIPAA Security Rule, the first real overhaul since 2013. The headline structural change: it eliminates the old "required" versus "addressable" split. Controls that vendors previously had some flexibility to implement differently, or skip with the right documentation, would become flat mandates with no wiggle room.

The list of specific proposed requirements reads like a current best-practices checklist finally getting teeth: mandatory encryption of ePHI in transit and at rest, mandatory multi-factor authentication, mandatory network segmentation, vulnerability scans twice a year, penetration testing annually, and a full technology asset inventory once a year. Add written incident response and disaster recovery plans built to restore systems within 72 hours, and a new requirement for BAs to verify, in writing, at least once every twelve months that technical safeguards are actually deployed, plus confirmation of safeguard adherence within 24 hours of a Covered Entity activating its emergency plan. The proposal also reaches toward AI, quantum computing, and virtual and augmented reality, a sign HHS wants this rule to hold up for a while rather than needing another rewrite in three years.

Public comment closed in March 2025 with nearly thousands of submissions, and a final rule is expected sometime in late 2025 or 2026, with a 180-day compliance window once it lands. There's a wrinkle, though: a January 2025 executive order froze new regulations pending review, so the actual finalization timeline is genuinely uncertain right now. Working through what that uncertainty actually means for a vendor deciding what to build this quarter, the practical advice doesn't change much either way. Most of what's proposed (MFA, encryption at rest, penetration testing, asset inventories) already reflects what a well-run security program should be doing anyway. Treating these as current requirements rather than waiting for the ink to dry reduces risk regardless of how the rulemaking shakes out.

How OCR and state AGs enforce HIPAA against vendors, and what recent actions reveal about actual risk

OCR's enforcement posture has shifted from reactive, waiting for breach reports to land on a desk, to proactive, with an active audit program that can pull in Covered Entities and Business Associates whether or not a breach has even occurred.

The 2025 penalty tiers, adjusted for inflation, run from $145 to $73,011 per violation at the low end (no knowledge) up to $73,011 to $2,190,294 per violation at the top end (willful neglect, uncorrected), with an annual cap of $2,190,294 per identical provision. OCR collected over $9.9 million across 22 enforcement actions in 2024, and BAA deficiencies showed up as a contributing factor in a good number of them.

The individual cases are where the abstractions turn into something concrete. Montefiore Medical Center reached a multimillion-dollar settlement in early 2025 after an employee illicitly accessed and sold the PHI of more than ten thousand patients; the citations included failures in risk analysis and activity monitoring, exactly the administrative and technical safeguards covered above. Solara Medical Supplies reached a multimillion-dollar settlement in January 2025 over a 2019 phishing attack that exposed the PHI of more than one hundred thousand people. Warby Parker picked up a seven-figure fine in 2025 tied to a breach stemming from credential attacks on customer accounts.

State attorneys general run a parallel enforcement track that a lot of BA compliance programs overlook entirely. California hit Blackbaud with a multimillion-dollar fine over a ransomware breach affecting millions of records. New York, New Jersey, and Connecticut jointly fined Enzo Biochem millions of dollars, and New York separately fined Albany ENT & Allergy Services seven figures while requiring millions in cybersecurity investment on top of it. A single incident, in other words, can trigger enforcement from multiple states at once, which is a genuinely uncomfortable math problem for any vendor's legal budget. Laying these cases side by side, the recurring failure modes are the same ones each time: unauthorized access, missing or thin risk analysis, delayed breach notification, improper disposal, phishing, and ransomware. Healthcare has been the most breached industry for the fourteenth consecutive year, with U.S. providers reporting roughly two large breaches a day to HHS in 2024. Enforcement is climbing right alongside that incident volume.

A practical compliance roadmap for SaaS vendors building or maturing a HIPAA program

None of the preceding sections mean much without a sequence to act on, so here's roughly where it starts: map every data flow to confirm where ePHI actually touches the system, then get signed BAAs in place with the Covered Entity and every subcontractor in the chain, from cloud hosting down to the email vendor. From there, complete (and document) a risk analysis, put administrative safeguards and training on a real schedule rather than a one-time onboarding slide deck, and implement the technical baseline: MFA, encryption in transit and at rest, role-based access, and audit logging that someone actually reviews rather than just collects.

Given the proposed 2025 rule, it's worth building toward penetration testing, vulnerability scans, and a 72-hour recovery plan now, rather than waiting for a final rule that may or may not land on the original timeline. Managing all of this gets genuinely complicated once a vendor's subcontractor list grows, since each new integration is another BAA to track, another sub-processor to audit, another contract renewal to remember. Platforms that handle content or data workflows touching PHI face the same obligation from the other direction: Letterstory, for instance, maintains and documents its own subprocessor BAAs as part of operating in this space, and any vendor evaluating a tool or partner that might touch PHI should expect, and ask for, that same level of documentation before signing anything.

The uncomfortable truth sitting underneath all of this, once you work through the layers one by one, is that HIPAA compliance was never a single checkbox to begin with, and treating it that way is precisely how vendors end up in an OCR settlement letter. It's a set of contracts, controls, and habits that have to keep running long after the demo ends and the deal closes.