“HIPAA compliant” isn’t a badge you buy, and the software either implements the safeguards or it doesn’t. The Security Rule spells out five technical safeguards for handling electronic protected health information at 45 CFR 164.312: access control, audit controls, integrity, person-or-entity authentication, and transmission security. On top of those, you need a signed business associate agreement with every vendor that can touch the data. That’s the whole substance of it. The rest is a marketing sticker.
We’re gmware, a custom software development firm in Austin, TX with engineering centers in Bangalore and Mohali, India, and healthcare builds are part of our delivery history. This is the conversation we have with founders who show up saying they need a “HIPAA-compliant app,” because half of them mean something different from what the rule actually requires, and a few of them don’t need HIPAA at all.
One opinion up front, and we’ll defend it. The word “compliant” does more damage than any missing control. It sounds like a state you reach and keep, like a certificate on the wall. It’s actually a list of specific things your code does on every request, plus a stack of signed contracts, plus a boundary you drew on purpose around where PHI is allowed to live. Treat it as a checklist, not a status.
The five technical safeguards (45 CFR 164.312)
What “HIPAA-compliant software development” actually means
It means the Security Rule’s technical safeguards are implemented in the thing you shipped, not described in a document. HHS wrote them into 45 CFR 164.312 as five standards, and each standard carries implementation specifications marked either “required” or “addressable.”
That word “addressable” trips up more teams than any other part of the rule. It reads like “optional.” It is not. Per HIPAA Journal’s breakdown of the safeguards, an addressable specification means you implement it, adopt an equally effective alternative, or document why implementation isn’t reasonable after a risk assessment. Almost nobody can write that third document honestly, so in practice you implement it. Encryption, famously, is classified as addressable, which some people misread as permission to skip it. Skip encryption on PHI and you’ll be explaining that choice to an investigator you’d rather not meet.
So a HIPAA-compliant build is a build where those five safeguards are wired into the request path and the data layer, where a signed BAA exists for every vendor that can see PHI, and where you can prove all of it after the fact. Marketing calls that “HIPAA compliant.” Engineering calls it “the parts of the app you don’t get to skip.”
The five technical safeguards, one clause at a time
Here’s what each of the five standards asks for, in the order the rule lists them. We’ve flagged the required specs versus the addressable ones, because that distinction is the one auditors actually check.
Access control is the biggest of the five. It carries four implementation specs: unique user identification and emergency access are required; automatic logoff and encryption/decryption are addressable. Unique IDs mean no shared logins, ever, because a shared account tells an audit log nothing about who did what. Emergency access means a break-glass path for a clinician who needs a record right now. Automatic logoff means the exam-room laptop nobody locked isn’t an open door. And encryption sits here too, addressable, which is the rule’s way of saying “encrypt it unless you can prove you shouldn’t.”
Audit controls is a required standard with no separate sub-specs: hardware, software, or procedural mechanisms that record access to and activity in systems holding PHI. The trap is that logging who edited a chart feels natural, while logging who merely read it feels like overhead, right up until an investigator asks who viewed a patient’s record and you can’t answer. Record the reads, not just the writes.
Integrity carries one addressable spec: a mechanism to corroborate that ePHI hasn’t been altered or destroyed in an unauthorized way. In practice this is checksums, versioning, or write controls that catch silent corruption. It’s the quietest of the five and the one people forget, because nothing visibly breaks when it’s missing.
Person or entity authentication is required, with no separate specs: verify that whoever is reaching PHI is who they claim to be. That’s real authentication tied to those unique IDs from the access-control standard, and for anything reaching PHI, multi-factor is where the whole industry has landed.
Transmission security carries two addressable specs: integrity controls and encryption over the network. TLS on every connection, no plaintext hops between services, and a guard that PHI didn’t get tampered with in transit. This is the easy half of encryption to get right, and it’s still the half a rushed build leaves half-open on an internal service call.
Required (R) vs addressable (A), by standard
What a BAA is, and when you actually need one
A business associate agreement is the contract that puts a vendor legally on the hook for the PHI you hand it. HHS requires a covered entity to obtain “satisfactory assurances,” in writing, that a business associate will safeguard the information it handles on your behalf. That written assurance is the BAA, and its required contents are specified at 45 CFR 164.504(e).
You need one for every vendor that can touch PHI. Not just the database host. The error-tracking tool that catches a stack trace with a patient ID in it. The transactional email service. The analytics SDK, the log aggregator, the queue, the support desk. Each is a link in the chain, and the chain is only as strong as the vendor nobody remembered to paper.
The subtlety that catches engineers off guard is the cloud host. You might assume that if your provider only stores encrypted blobs and can’t read them, no BAA is needed. Wrong. HHS is direct: a cloud service provider that stores or processes ePHI is a business associate even if it only holds encrypted data and lacks the decryption key. A no-view host still signs. The one detail that works in your favor: for no-view services, HHS allows some safeguards to be split between the parties, so the host may own encryption of the data at rest while you own who’s allowed to authenticate and view it. That split is a division of labor, not a discount on the contract.
HIPAA-compliant hosting is not a HIPAA-compliant application
This is the misunderstanding that costs the most, so read it twice. A founder signs a BAA with AWS, sees “HIPAA eligible” on the pricing page, and believes the app is now compliant. It isn’t, and AWS says so itself.
AWS is HIPAA eligible, will sign a BAA, and explicitly does not make you compliant by default. Under the shared-responsibility model, AWS secures the underlying cloud while you remain responsible for how you configure everything you run on it. The BAA covers AWS’s responsibilities, not yours. And PHI is only allowed to sit inside the 160-plus services designated HIPAA eligible, so drop it into a service outside that list and you’ve broken compliance under a perfectly valid agreement.
Think of it as the building versus the door. The host secures the building: physical security, the hypervisor, the encrypted disks it manages. You still have to lock your own door: the access controls, the audit logging, the authentication, the encryption settings on your data, and the discipline to keep PHI inside eligible services. “HIPAA-compliant hosting” gets you a secure building. It does nothing about your door. The architecture side of that split, where the PHI boundary actually gets drawn, is the whole subject of our HIPAA-compliant app architecture guide, and the migration version of it lives in what the 2027 Security Rule deadline changes.
A developer checklist for a HIPAA build
Here’s the artifact we hand engineers on day one. It’s keyed to the five safeguards plus the BAA and boundary work, phrased as things you can check off a build, not policies you file. If a line is unchecked at launch, it’s a gap, not a nice-to-have.
| Requirement | What it means in the build | Safeguard |
|---|---|---|
| Unique user IDs, no shared logins | Every actor is individually identifiable in the logs | Access control (R) |
| Multi-factor on anything reaching PHI | Real authentication, not a password alone | Authentication (R) |
| Break-glass emergency access path | A clinician can reach a record in a crisis, and it’s logged | Access control (R) |
| Automatic session logoff | Idle sessions on PHI screens time out | Access control (A) |
| Encryption at rest and in transit | TLS everywhere; encrypted DB, backups, replicas, caches, queues | Access + transmission (A) |
| Audit log of every read and write | Append-only, tied to a unique identity, queryable in near real time | Audit controls (R) |
| Integrity checks on stored PHI | Checksums or versioning that catch silent alteration | Integrity (A) |
| Signed BAA for every PHI-touching vendor | Host, logging, email, analytics, error tracking, queue, support tool | (BAA chain) |
| PHI boundary drawn before code | Which systems may hold PHI, enforced so the rest structurally can’t | (Segmentation) |
| PHI only in HIPAA-eligible cloud services | No PHI in a service outside your host’s eligible list | (Config) |
Two lines do the heaviest lifting and get skipped the most. The BAA chain, because nobody owns the vendor map and the logging SaaS was never anyone’s job. And the PHI boundary, because it’s the one thing you can’t retrofit cheaply: draw it after launch and you’re tracing where health data already leaked across a running system, which is the worst possible time to learn it’s everywhere.
Do you even touch PHI? The over-scoping test
Now the verdict most HIPAA vendors will never tell you, because they’d rather sell you the expensive build: a lot of “health” software isn’t governed by HIPAA at all, and paying for a HIPAA-grade build you don’t need is its own kind of waste.
HIPAA covers covered entities (most doctors’ offices, hospitals, and health plans) and the business associates that serve them. It does not automatically cover every app that touches health-adjacent data. The FTC has said this plainly: many companies that collect health information, from fitness trackers to diet apps to connected devices, aren’t covered by HIPAA, because a lot of health-related information falls outside it. A direct-to-consumer meditation app, a period tracker with no clinical connection, a step-counter that never links to a provider: usually not a HIPAA problem.
That doesn’t mean no rules apply. It means different ones do. Non-HIPAA health apps fall under the FTC’s Health Breach Notification Rule, which the FTC updated effective July 29, 2024 to explicitly cover health and wellness apps. So the honest test isn’t “does this involve health data.” It’s this: does your software create, receive, maintain, or transmit PHI on behalf of a covered entity? If yes, you’re in HIPAA’s world and everything above applies. If no, you may owe consumers strong privacy and the FTC breach-notification obligations, but not the full 164.312 apparatus.
Does HIPAA even apply to you?
We say this to clients regularly: if you don’t touch a covered entity, don’t pay the HIPAA premium to feel safe. Build strong privacy and honest breach handling, and put the money where your actual obligations are. Over-scoping compliance is real, and it’s expensive.
When the stakes are real, the arithmetic is unforgiving
For the builds that genuinely are under HIPAA, the reason to get the safeguards right up front is the penalty math. The 2026 civil-penalty tiers run from $145 per violation for a genuine lack of knowledge up to a $2,190,294 annual cap for an identical provision, with willful-neglect violations that go uncorrected starting at $73,011 each. A single structural flaw, an audit log that never recorded reads, an unencrypted backup, can count across a lot of records. That’s what makes retrofitting the most expensive order of operations. The same “build it in, don’t bolt it on” logic drives cost on the payment side too, which we broke down in PCI-DSS-compliant software development.
How gmware builds to the Security Rule
We design the PHI boundary before the first sprint and wire the five safeguards into the request path, through our healthcare software development and cybersecurity practices. Austin-based leads own the architecture, the threat model, and the BAA chain on US hours, while our Bangalore and Mohali teams build to it. HIPAA governs how the software handles PHI, not where the engineer sits, so a blended US-India team meets the identical bar. If you want the budgeting side of a regulated healthcare build, our HIPAA telehealth cost guide shows where the money actually goes.
We run production data systems ourselves. Shield Suite tracks retail intelligence across 60,000+ beverage-alcohol storefronts, so encryption, access control, and audit trails aren’t a compliance theory we read about. They’re how we operate.
And we’ll tell you when not to hire us for a HIPAA build. If your app never touches a covered entity, the right project is strong privacy and FTC breach readiness, not the full 164.312 apparatus. Tell us what you’re building and what patient data it has to touch, and we’ll give you a straight read on whether HIPAA even applies, what the safeguards cost, and where the PHI should and shouldn’t live. Reach out and we’ll come back within 48 hours.