HIPAA Compliance Requirements for Software Development Teams

HIPAA compliance for a dev team comes down to a specific set of architectural, operational, and legal obligations, and most teams never sit down to figure out which ones actually apply before they start writing code. That's the gap I want to close here. I've watched this mistake play out at three different companies now, and it always costs more to fix after the fact than it would have to just do right the first time.

Start with the two-part test, because everything downstream depends on it. Your software is in scope if two things are both true: it's used by a covered entity or a business associate, and it creates, receives, stores, or transmits PHI (protected health information). Miss either half and you're out of scope. Hit both, and you owe the government a specific set of protections, whether you knew it going in or not.

Inside that scope sits a distinction almost nobody talks about early enough: transient access versus persistent access to PHI. If your system just passes PHI through, say a messaging layer or an API gateway that routes data without storing it, your minimum bar is protecting confidentiality, integrity, and availability of that data in transit, plus supporting whatever administrative safeguards your end users need on their side. Real work, but bounded.

Persistent access is a different animal entirely. Storing PHI, querying it, running analytics against it, that means the full program: physical safeguards on every device that touches it, BAAs (business associate agreements) running both upstream and downstream, and administrative controls that get documented and followed, not written once and forgotten in a shared drive somewhere.

Here's the part that trips people up more than anything else: there is no HIPAA certification. HHS doesn't approve software. Nobody hands you a badge. Compliance is a posture you maintain continuously, and I've watched that reality catch founders off guard mid-pitch. Not mid-stride, mid-pitch, in front of a prospect. I was on a call a couple years back where an enterprise buyer asked point-blank whether the vendor had BAAs in place with their subprocessors, and the founder just froze for a second too long before admitting the team hadn't touched it. Product was six months old. That pause cost them the meeting's momentum, and probably the deal.

The four HIPAA rules and what each one actually demands of engineers

HIPAA breaks into four rules, and each does a different job that shapes engineering work differently.

The Privacy Rule defines what PHI and ePHI (electronic PHI) actually are, governs the rights patients have over their own health information, and sets limits on how records can be shared. For engineers, this shapes product design. What data you're allowed to collect. What you can expose in a UI. What a patient can request you delete or hand over on demand.

The Security Rule is where most of your engineering hours go, and I'll get into the weeds of it in the next section. It covers administrative, physical, and technical safeguards for ePHI, whether it's sitting in a database, moving across a network, or being used live in an application. This is the rule that actually dictates your architecture.

The Breach Notification Rule sets a legal clock. Something goes wrong, you have a defined deadline and a defined format for telling affected parties, and in bigger breaches, the media and HHS directly. Engineering owns detection here, and just as important, engineering owns the evidence trail that determines whether notification even gets triggered. No proof of what happened means no way to argue against the strictest reading of the incident.

The Enforcement Rule is the one that gives the other three teeth, since OCR's (Office for Civil Rights) penalty authority lives here. Without it, the first three are just guidance nobody has to follow.

So the shape of it is this: Security governs your engineering decisions, Privacy governs your product design, Breach Notification governs how you respond when things break, and Enforcement sets the stakes for getting any of it wrong.

The Security Rule's three safeguard categories broken into engineering tasks

The Security Rule splits into technical, administrative, and physical safeguards. Most engineers think about the first bucket and skip the other two. That's exactly how audits go sideways.

Technical safeguards feel native to engineering work: encryption in transit and at rest, unique user IDs (no shared logins, ever), role-based access control, automatic session timeout, and audit logs retained for six years. Six years isn't a typo. It's a long window, and storage cost planning needs to account for that from day one, not get discovered mid-breach-investigation when someone's frantically calculating what six years of logs actually costs to keep.

Administrative safeguards center on one document: the risk analysis. This is the centerpiece of the entire Security Rule. Every other safeguard you implement should trace back to a risk you wrote down somewhere. Beyond that, you need a designated security officer, workforce training people actually sit through and not a slide deck nobody reads, and access management procedures spelling out who can grant, review, and revoke access.

Physical safeguards are where software teams most often get the scope wrong entirely. This covers workstations, servers, server rooms, and any device that touches PHI, including developer laptops and CI/CD runners. An engineer pulls production PHI onto a laptop to debug something? That laptop is now in scope, full stop. I've seen a team realize this halfway through a SOC 2 audit and spend a frantic week retrofitting device policies they should've had on day one.

One more nuance worth getting right: the difference between "addressable" and "required." Addressable doesn't mean optional, and teams that read it that way are building a liability into their own product. It means you either implement the safeguard, or you document, in writing, why you implemented something else that achieves the same protection.

BAAs carry real legal weight, by the way. You need one with every covered entity customer and every subcontractor that touches PHI. Without a signed BAA, you have no legal basis to handle that data.

The risk analysis sits at the center of all of this, and it has to be accurate, documented, and revisited every time your environment changes. Not filed away once and forgotten.

Why the proposed January 2025 Security Rule update changes the engineering calculus

In January 2025, HHS published a Notice of Proposed Rulemaking that amounts to the biggest proposed overhaul of the Security Rule in roughly two decades. It isn't law yet, but if you build healthcare software, you need to know what's coming.

The catalyst was a ransomware attack in February 2024 that became the largest healthcare data breach in U.S. history. The entry point was almost embarrassingly mundane: a credential-protected portal with no MFA (multi-factor authentication). One missing control, behind one of the biggest breaches on record.

The proposed rule responds directly to that. Encryption moves from addressable to mandatory. MFA becomes required for most access scenarios. Annual penetration testing gets mandated, vulnerability scanning has to happen on a regular cadence, and critical vulnerabilities need patching within days, not whenever the team gets around to it. The addressable category, that whole "document your alternative" escape hatch, goes away entirely under the new draft.

As of early 2026, none of this is final. A regulatory freeze paused the rulemaking process back in January 2025, so the current Security Rule, addressable categories and all, is still what's legally in effect today.

Build to the proposed standard anyway. I'll say that plainly because I think it's right, not because it's a safe hedge. A large share of the healthcare software market already operates at that level, because enterprise customers require MFA and encryption as a condition of doing business regardless of what the letter of the law says this year. Waiting for the rule to finalize before building the controls means optimizing for the wrong timeline, and you'll end up building it twice.

What enforcement actually looks like and where OCR finds violations

Look at OCR's enforcement history and one pattern shows up again and again: no risk analysis on record. PHI gets breached, there's no documented risk analysis behind it, penalties compound fast. This is the single most common failure point, more common than any specific technical gap you could name.

OCR launched its Risk Analysis Initiative in late 2024, and by early 2026 it had already produced a meaningful number of enforcement actions, every one targeting organizations that never did an adequate risk analysis. In 2026, OCR confirmed it's expanding that initiative to cover risk management too, which means documenting a vulnerability isn't enough anymore. You have to show you're actually fixing what you find, not just tracking it in a spreadsheet that never gets revisited.

Penalties scale with culpability. Unknowing violations sit in the low four figures; willful neglect can hit seven-figure annual caps per violation category. Wide range, and where you land on it depends almost entirely on whether you can produce documentation the day someone asks for it.

Recent enforcement actions span company size. A health technology company got fined for risk analysis and risk management violations. A billing software provider got penalized after a ransomware incident. Both cases share the same thread underneath them: an absent documented process in the run-up to the breach.

Healthcare data breaches remain the most expensive of any industry, and ransomware incidents carry daily downtime costs that dwarf what most compliance programs would've cost to build in the first place. That's the argument I make to founders who treat compliance as a tax on product work. Retrofitting it into a finished product costs a lot more than building it into the first sprint ever did.

How HIPAA, SOC 2, and HITRUST relate to each other in a healthtech sales cycle

HIPAA is law. SOC 2 is a voluntary attestation framework built by the AICPA. In practice, a hospital running vendor security review is going to ask for your SOC 2 report anyway, because HIPAA itself doesn't produce a document a third party can independently verify. There's no HIPAA report to attach to an email and send along.

SOC 2 fills that gap. It's the artifact that goes into the procurement package next to your BAA. Good news for engineering teams here: a large majority of the Security Rule's administrative and technical safeguards map directly onto SOC 2's Common Criteria. Build toward one, and you've done most of the work toward the other without much extra lift.

HITRUST is a step up from both. It's a certifiable assurance framework built specifically for healthcare, more rigorous than SOC 2 alone and more recognized in enterprise healthcare procurement circles. It requires external assessment and validation, not just a self-attestation you write yourself. The framework keeps moving, too; HITRUST CSF updated to version 11.7.0 in late 2025 with new compliance factor mappings, so it isn't a fixed target you hit once and forget.

My sequencing advice, for what it's worth: get your HIPAA posture solid first, since it's mandatory and everything else builds on top of it. Pursue SOC 2 next as your enterprise sales enabler. Save HITRUST for when your customer base specifically demands it or the deal size justifies the lift, because it's heavier than either of the other two by a wide margin.

One practical note. Compliance automation tools like Vanta, Drata, and Secureframe cut evidence collection and audit prep time down significantly. Auditors increasingly want continuous monitoring evidence, not a folder of six-month-old screenshots somebody dug up the night before, and these platforms are built for exactly that shift.

Cloud provider choice and what each platform actually gives you for HIPAA workloads

Here's a phrase that causes more confusion than almost anything else in this space: "HIPAA-eligible" is not the same thing as "HIPAA compliant." AWS, Azure, and GCP will all sign a BAA with you, but that BAA only covers the provider's slice of the shared responsibility model. Everything else, your configuration, your access controls, your logging, sits on you. Misconfiguration, not platform weakness, is a leading cause of HIPAA breaches, and that holds true across every provider I've worked with.

AWS has the largest catalog of HIPAA-eligible services of any provider and dominates U.S. healthcare infrastructure. Not everything is covered, though. Some widely used AWS services simply can't touch PHI, BAA or not, and it's easy to miss which ones. Raw AWS typically eats a real chunk of monthly engineering time just maintaining infrastructure-level compliance, before anyone's written a line of actual product code.

Azure is the strongest pick if you're already living inside Microsoft 365. Azure Health Data Services bundles FHIR, DICOM, and IoT ingestion into one HIPAA-eligible managed service, and Conditional Access plus Privileged Identity Management come native rather than bolted on. Azure also carries HITRUST CSF certification, which adds healthcare-specific assurance on top. Pricing runs more predictable, though it tends to sit higher at the base tier than the other two.

GCP wins for teams doing heavy analytics, ML, or AI work. Cloud Healthcare API natively supports HL7 v2, FHIR R4, and DICOM inside a HIPAA-eligible managed service. Encryption at rest and in transit is on by default rather than something you have to flip on yourself, and VPC Service Controls create a data exfiltration barrier the other two don't directly match. GCP also tends to be the price leader for HIPAA workloads generally.

None of that closes the shared responsibility gap. The provider's BAA doesn't configure your security groups. It doesn't manage your access policies, doesn't rotate your secrets, doesn't maintain your audit logs. Most teams underinvest exactly here, and it's the gap that platforms deploying into your own cloud account are built to close: infrastructure that's auditable and owned by your team without forcing anyone to manage every knob by hand.

What a HIPAA-ready CI/CD pipeline and deployment architecture look like in practice

If your CI/CD pipeline touches PHI, or even touches infrastructure that touches PHI, it's part of your compliance surface now. Secrets management, access controls on your pipeline runners, audit logs of what got deployed and when. None of that is negotiable, and none of it is optional just because it lives in a tool your ops team owns instead of your product code.

Automated vulnerability scanning in the build pipeline, catching CVEs before they reach production, is exactly the kind of practice the proposed Security Rule would formalize. Build it now and it costs you almost nothing, relative to bolting it on later under audit pressure with an auditor watching the clock.

Critical and high-severity vulnerabilities need documented remediation timelines. The proposed rule specifies exact patching windows measured in days. Treat those windows as your working standard today, even while the rule itself sits in regulatory limbo.

Environment separation matters more than most teams think it does. PHI shouldn't flow into dev or staging environments unless those environments carry the same safeguards as production. This gap surfaces constantly during audits: a "test" database that quietly has real patient data sitting in it because someone needed to debug a production issue fast and took the shortcut instead of scrubbing the export first.

Access to production PHI needs to be logged, scoped by role, and reviewed periodically, with audit logs held for six years under the current rule. Incident response has to be tested too, not just written down somewhere. Tabletop exercises and runbooks that have actually been run through once are what auditors and OCR look for. A policy PDF nobody's ever executed doesn't hold up under real questioning.

For teams without a dedicated DevOps function, tools that automate CVE patching, cluster upgrades, and environment configuration remove a whole category of compliance drift before it even has a chance to start.

Why shared-tenant PaaS platforms create HIPAA problems that dedicated-infrastructure models solve

Shared-tenant PaaS platforms have a structural problem with HIPAA that has nothing to do with intent or security quality. It comes down to verification, plain and simple. In a shared-tenant environment, you can't independently confirm the isolation, logging, or access controls the Security Rule requires you to document, because that evidence lives inside the vendor's infrastructure, not yours.

A BAA from a shared PaaS provider doesn't fix this problem. OCR expects the covered entity or business associate itself to demonstrate its own controls, and pointing at a vendor's assurances isn't the same thing as producing your own audit trail when asked.

Heroku's situation is a useful case study here. As of February 2026, Heroku announced a transition that's pushed a lot of healthcare software teams to go evaluate alternatives, and compliance requirements show up as a leading reason cited in that evaluation process.

The architectural fix is straightforward, even if it takes real engineering time to execute: deploy production into your own cloud account, whether that's AWS, GCP, or Azure, so the audit trail, access controls, and configuration all belong to you and not a vendor's shared infrastructure. Porter works this way, deploying directly into the customer's own cloud account, which gives teams a real path to SOC 2 and HIPAA posture without needing a dedicated DevOps team to babysit the underlying infrastructure. One-click HIPAA and SOC 2 posture, automatic CVE patching, and support for GPU workloads come built into the platform rather than turning into a separate six-month implementation project on top of everything else.

If your customers are going to run a security review or attach a BAA to your contract, pointing to audit logs in your own cloud account, not a vendor's, is a real, material advantage in that conversation. Not a nice-to-have. A closer.

The minimum viable HIPAA posture a dev team can establish and maintain without a dedicated compliance team

You don't need a compliance department to get this right. You need a handful of steps, done in order, and done for real, not performed for the sake of a checklist.

Answer the two-part scope question formally, in writing, first. Every other step depends on that answer, so don't skip past it because you're eager to start building the actual product.

Run a risk analysis next. Document what PHI your system handles, where it flows, and what controls already exist around it. This single document matters more than anything else in an enforcement review, more than any individual technical control you'll implement.

Put in the core technical controls after that: encryption in transit and at rest, unique user IDs, role-based access control, session management, six-year audit log retention. Get BAAs signed with every covered entity customer and every subcontractor touching PHI, before any data actually flows between you and them.

Write the required policies too. Incident response, breach notification, workforce training, access review. They don't need to run long, but they need to exist, and your team actually needs to follow them when the moment comes, not just keep them in a drawer for the audit.

Bake ongoing maintenance into your normal engineering workflow after that: scheduled vulnerability scans, periodic access reviews, policy reviews triggered whenever your environment changes in a meaningful way. This is the part that quietly falls apart at most companies, not because anyone decides to skip it, but because nobody owns it once the initial push is over.

Realistically, you can reach a defensible posture in weeks, not months. The gap most teams underinvest in sits between defensible and audit-ready, and that gap closes through consistency over time, not one sprint of heroics right before a deal closes.

Build this in from the start and it's a lot cheaper than retrofitting it later, and there's a compounding payoff most teams don't expect going in. Once the HIPAA groundwork is laid, the road to SOC 2 gets a lot shorter. You've already done most of the work; you just haven't called it that yet.