The HIPAA Security Rule is the part of HIPAA that engineers actually build against. It governs how electronic protected health information (ePHI) is secured, and it places direct obligations on the systems that create, receive, maintain, or transmit that data. Unlike a checklist standard, it is deliberately flexible — which makes it easy to misread. This guide explains how the rule is structured, what "required" versus "addressable" really means, and how a proposed 2025 overhaul could make the expectations far more prescriptive.
What the Security Rule is
The Security Rule lives at 45 CFR Part 164, Subpart C, and protects the confidentiality, integrity, and availability of ePHI. It is organized into three categories of safeguards:
- Administrative safeguards (164.308): the security management process, workforce security, contingency planning, and — critically — the risk analysis and risk management requirements.
- Physical safeguards (164.310): facility access, workstation use, and device and media controls.
- Technical safeguards (164.312): access control, audit controls, integrity, person-or-entity authentication, and transmission security.
Two design choices shape everything. First, the rule is technology-neutral: it names outcomes, not specific technologies or CVE-patching deadlines. Second, each implementation specification is either required or addressable. "Addressable" does not mean optional — it means you must implement the measure if reasonable and appropriate, or document why not and adopt an equivalent alternative. The linchpin is 164.308(a)(1)(ii)(A), the risk analysis: you cannot justify any safeguard as "reasonable and appropriate" without an accurate, ongoing assessment of the risks to ePHI.
Who is on the hook and when
HIPAA reaches two groups. Covered entities are health plans, clearinghouses, and providers who transmit health information electronically. Business associates are the vendors that handle ePHI on their behalf — where most software companies land. Since the HITECH Act, business associates are directly liable under the Security Rule, and subcontractors inherit the same duties through a chain of Business Associate Agreements (BAAs). There is no "we only wrote the code" exemption.
Enforcement sits with the HHS Office for Civil Rights (OCR), which investigates breaches and can impose tiered civil monetary penalties. The Breach Notification Rule (45 CFR 164.400-414) separately requires notifying affected individuals without unreasonable delay and no later than 60 calendar days after discovery of a breach of unsecured ePHI.
The rule may soon get sharper. In January 2025, HHS published a Notice of Proposed Rulemaking to modernize the Security Rule. As proposed, it would largely eliminate the required-versus-addressable distinction (making most specifications mandatory), require a written technology asset inventory and network map, mandate encryption of ePHI at rest and in transit, require multi-factor authentication, and set explicit cadences for vulnerability scanning and penetration testing. As of mid-2026 this remains a proposal, not a final rule, so treat the specifics as evolving — but the direction of travel toward prescriptive technical controls is clear.
Software and supply-chain obligations
The technical safeguards translate directly into engineering work, and each has a supply-chain dimension:
| Safeguard (45 CFR 164.312) | What software teams implement |
|---|---|
| Access control | Unique user IDs, role-based access, automatic logoff, encryption of ePHI |
| Audit controls | Tamper-evident logging of access to and actions on ePHI |
| 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 against interception |
None of this holds if the third-party code underneath it is vulnerable. A modern health application is mostly dependencies, and a known, exploitable flaw in one of them that could expose ePHI is a risk your risk analysis must account for and your risk management process must address. The proposed 2025 update would make this explicit by requiring an asset inventory and regular vulnerability scanning — but even under today's rule, "we did not know that library was in there" reads to an investigator as evidence of an inadequate risk analysis, not as a defense.
Compliance checklist
- Conduct and maintain a documented, ePHI-wide risk analysis (164.308(a)(1)(ii)(A))
- Keep an inventory of application components and dependencies (an SBOM)
- Run continuous vulnerability scanning against those components
- Feed dependency risk into your risk-management decisions
- Enforce encryption in transit; encrypt ePHI at rest where reasonable
- Implement unique authentication, RBAC, and tamper-evident audit logging
- Define and track remediation SLAs for vulnerabilities affecting ePHI
- Execute BAAs with every 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 Security Rule obligations into something you can evidence rather than assert. SBOM Studio maintains a live inventory of every component in your applications — the asset visibility the proposed 2025 rule leans toward and that a defensible risk analysis already requires. Software composition analysis continuously scans those components, so a flaw that could expose ePHI surfaces as an actionable finding with the timeline evidence an OCR investigation would ask for.
Griffin AI triages findings against your actual code so remediation concentrates on vulnerabilities genuinely reachable in the paths that handle ePHI. If you are weighing HIPAA-readiness platforms against engineering-grade supply chain tooling, our Vanta comparison explains where automated evidence collection ends and continuous vulnerability management begins.
The Security Rule gives software teams latitude, but that latitude comes with a burden of proof. Know what is in your software, watch it continuously, and keep the evidence.
Frequently Asked Questions
Does "addressable" mean a safeguard is optional? No. An addressable specification must be implemented if it is reasonable and appropriate for your environment. If it is not, you must document the rationale and adopt an equivalent alternative measure. The proposed 2025 update would remove most of this flexibility by making the specifications required outright.
Is a HIPAA-compliant cloud provider enough to make our app compliant? No. Under the shared-responsibility model, the provider secures the infrastructure, but your application code, its dependencies, and how it handles ePHI remain your responsibility. A compliant hosting environment does not cure a vulnerable dependency in your own software.
Are software vendors directly liable under the Security Rule? Yes, if they are business associates. Since the HITECH Act, business associates are directly subject to the Security Rule and to OCR enforcement, and subcontractors inherit the same obligations through their BAAs. Building software that processes ePHI for a covered entity almost always makes you a business associate.
Does the Security Rule require vulnerability scanning today? The current rule does not name scanning as a discrete control, but the risk-analysis and risk-management requirements make it very difficult to justify skipping it for ePHI systems. The proposed 2025 update would make regular vulnerability scanning and penetration testing explicit obligations.
Start closing the supply-chain gap in your HIPAA risk analysis. Create a free account or read the Safeguard documentation to connect your first repository.