Developers building software that handles health data often assume HIPAA is a legal and operations problem. It is not — the HIPAA Security Rule places direct, technical obligations on the systems you build, and a vulnerable dependency in your application is squarely your responsibility. This guide clears up what HIPAA actually requires of engineers and where the software supply chain fits in.
What HIPAA requires (and what it deliberately does not)
HIPAA — the Health Insurance Portability and Accountability Act — protects the confidentiality, integrity, and availability of electronic protected health information (ePHI). The part that concerns developers is the Security Rule (45 CFR Part 164, Subpart C), which defines administrative, physical, and technical safeguards for ePHI.
The Security Rule is deliberately technology-neutral. It does not say "use TLS 1.3" or "patch this CVE within 30 days." Instead it sets outcomes and lets you choose reasonable and appropriate measures for your size and risk. That flexibility is often misread as vagueness, but for engineers it means one thing above all: you must be able to justify your security decisions through a documented risk analysis. The absence of a prescribed control is not the absence of an obligation.
A common myth is that using a HIPAA-compliant cloud provider makes your application compliant. It does not. The provider secures the infrastructure under a shared-responsibility model; the application code, its dependencies, and how it handles ePHI remain yours to secure.
Who is on the hook?
HIPAA obligations flow to two groups. Covered entities are health plans, health care clearinghouses, and providers who transmit health information electronically. Business associates are the vendors that create, receive, maintain, or transmit ePHI on a covered entity's behalf — which is where most software companies land. If you build a SaaS product that processes ePHI for a hospital or insurer, you are almost certainly a business associate, bound by a Business Associate Agreement (BAA) and directly liable under the Security Rule and the HITECH Act enforcement provisions.
Subcontractors of business associates inherit the same duties. There is no "we only wrote the code" exemption.
The technical safeguards developers implement
The Security Rule's technical safeguards translate into engineering work:
| Safeguard (45 CFR 164.312) | What developers implement |
|---|---|
| Access control | Unique user IDs, role-based access, automatic logoff, session management |
| Audit controls | Logging of access to and actions on ePHI, retained and tamper-evident |
| Integrity | Mechanisms to detect improper alteration or destruction of ePHI |
| Authentication | Verifying that a person or system is who it claims to be |
| Transmission security | Encryption of ePHI in transit; encryption at rest as an addressable measure |
Underpinning all of these is 164.308(a)(1)(ii)(A): the risk analysis requirement. You cannot claim a safeguard is "reasonable and appropriate" without an accurate, ongoing assessment of the risks to ePHI across your systems — and that assessment is incomplete if it ignores the vulnerabilities in the open source components your application depends on.
Note that the U.S. Department of Health and Human Services published a proposed update to the Security Rule in early 2025 that, if finalised, would make several currently "addressable" measures explicit — including an asset inventory, more regular vulnerability scanning, and encryption requirements. The direction of travel is clearly toward more prescriptive technical expectations, so building these habits now is prudent.
Where the software supply chain fits
A modern health-tech application is mostly third-party code. If a dependency has a known, exploitable vulnerability that could expose ePHI, that is a risk your Security Rule risk analysis must account for and your safeguards must address. Regulators investigating a breach will ask whether you knew what components were in your software and whether you had a process to find and fix vulnerable ones. "We didn't know that library was in there" is not a defence — it is evidence of an inadequate risk analysis.
Developer HIPAA checklist
- Maintain a current inventory of application components and dependencies (an SBOM)
- Run continuous vulnerability scanning against those components
- Feed dependency risk into your documented HIPAA risk analysis
- Enforce encryption in transit; encrypt ePHI at rest where appropriate
- Implement unique authentication, RBAC, and audit logging for ePHI access
- Define and track remediation SLAs for vulnerabilities affecting ePHI
- Confirm BAAs are in place with any subprocessor that touches ePHI
- Retain evidence: scan history, remediation records, and risk-analysis updates
How Safeguard helps
Safeguard turns the supply-chain half of your HIPAA risk analysis into something you can evidence rather than assert. SBOM Studio maintains a live inventory of every component in your application — the asset visibility the proposed Security Rule update leans toward and that a defensible risk analysis already requires. Software composition analysis continuously scans those components against known vulnerabilities, so a flaw in a library that could expose ePHI surfaces as an actionable finding, complete with the timeline evidence an investigator would ask for.
Griffin AI triages findings against your actual code so remediation effort concentrates on vulnerabilities that are genuinely reachable in the paths that handle ePHI, not the entire raw CVE list. Together these feed a single record of scan history and remediation timestamps that slots directly into your risk-analysis documentation. Our compliance pages map these capabilities to the Security Rule so you can show which control each one supports.
If you are choosing between HIPAA-readiness platforms and engineering-grade supply chain tooling, our Vanta comparison explains where automated evidence collection ends and continuous vulnerability management begins.
HIPAA gives developers latitude, but that latitude comes with a burden of proof. Know what is in your software, watch it continuously, and keep the evidence — that is what turns "reasonable and appropriate" from an aspiration into a documented fact.
Start closing the supply-chain gap in your risk analysis today. Create a free account or read the Safeguard documentation to connect your first repository.