What Is the HIPAA Security Rule? A Defender's Guide

A ransomware operator who locks up a hospital's electronic health records has not just caused an outage. Under federal law, that hospital was already required to have a written risk analysis on file, access controls on the systems holding patient data, audit logs that record who touched a record, and a contingency plan to restore the data. The control that failed, and the one OCR will ask about first, is named in a specific subsection of the Code of Federal Regulations. That regulation is the HIPAA Security Rule.

The HIPAA Security Rule is the federal standard that requires anyone handling electronic protected health information to protect its confidentiality, integrity, and availability. It is codified at 45 CFR Part 160 and Part 164, Subpart C, and it is built from three categories of safeguards: administrative, physical, and technical. This guide covers what the rule is, who it binds, the three safeguard categories and the standards inside each, the required-versus-addressable distinction that trips up most readers, how it is enforced, and the major rewrite that HHS proposed in January 2025. It is written for the people who implement and audit these controls: SOC analysts, security engineers, and compliance practitioners in healthcare and the vendors that serve it.

What is the HIPAA Security Rule?

The HIPAA Security Rule is a set of national standards, issued by the U.S. Department of Health and Human Services, for protecting electronic protected health information (ePHI). It tells covered entities and their business associates what they must achieve to secure patient data held in electronic form, and it gives them latitude in how they get there.

The scope is narrower than people assume. The Security Rule applies only to ePHI: patient data that is created, received, maintained, or transmitted in electronic form. Spoken PHI and paper records are governed by the separate HIPAA Privacy Rule (45 CFR Part 164, Subpart E), not the Security Rule. If the data is not electronic, the Security Rule does not reach it.

The rule sets three security objectives in its General Rules at 45 CFR 164.306(a). A regulated organization must ensure the confidentiality, integrity, and availability of all ePHI it creates, receives, maintains, or transmits. It must protect against reasonably anticipated threats to that data, protect against reasonably anticipated impermissible uses or disclosures, and ensure its workforce complies. Those three properties, confidentiality, integrity, and availability, are the same CIA triad that underpins the rest of information security. The Security Rule is one of the few places where it is written into law.

History matters here because the rule has aged. HHS published the Security Rule on February 20, 2003, and compliance became mandatory in April 2005 for most covered entities. The HITECH Act of 2009 and the 2013 Omnibus Final Rule extended and updated it, most importantly by making business associates directly liable. The core technical requirements, though, have not been substantially revised since 2013, which is the backdrop for the 2025 proposed overhaul covered at the end of this guide.

Who must comply

The Security Rule binds two groups, and the second is where most security vendors discover they are in scope.

Covered entities. These are health plans, health care clearinghouses, and any health care provider who transmits health information electronically in connection with a covered transaction (such as a claim or eligibility check). Hospitals, clinics, insurers, and billing services are the obvious examples.

Business associates. A business associate is any person or organization that creates, receives, maintains, or transmits ePHI on behalf of a covered entity. Cloud hosting providers, managed service providers, SaaS vendors, analytics firms, and contractors all qualify when patient data passes through their systems. Before the HITECH Act of 2009, business associates were bound only by contract. HITECH, implemented through the 2013 Omnibus Rule, made them directly liable to OCR for Security Rule compliance. A breach at a vendor is now the vendor's regulatory problem, not only the hospital's.

This matters for anyone building infrastructure that touches healthcare data. If your platform stores or processes ePHI, you are a business associate, you sign a business associate agreement, and you are independently on the hook for the safeguards below. A signed data compliance agreement does not transfer the obligation away; it documents that both parties carry it.

The three safeguard categories

The substance of the Security Rule is organized into three categories of safeguards, each with its own set of standards and its own section of the regulation. Administrative safeguards are at 45 CFR 164.308, physical at 164.310, and technical at 164.312. Two further sections cover organizational requirements (164.314) and policies, procedures, and documentation (164.316).

Administrative safeguards (164.308)

Administrative safeguards are the policies and processes that govern how an organization manages security: the people and procedure half of the rule, and the largest of the three categories. The nine standards are:

• Security Management Process, which contains the single most consequential requirement in the rule, the risk analysis (discussed below).
• Assigned Security Responsibility, naming one individual responsible for security.
• Workforce Security, controlling which staff get access to ePHI.
• Information Access Management, authorizing and modifying that access.
• Security Awareness and Training for the workforce.
• Security Incident Procedures for identifying and responding to incidents.
• Contingency Plan, including data backup, disaster recovery, and emergency operation.
• Evaluation, a periodic technical and non-technical review.
• Business Associate Contracts and Other Arrangements, the written assurances from vendors.

Physical safeguards (164.310)

Physical safeguards protect the hardware, facilities, and media where ePHI lives from unauthorized physical access and from mishandling. The four standards are Facility Access Controls, Workstation Use, Workstation Security, and Device and Media Controls. Device and Media Controls is the one that catches organizations off guard: it governs how disks, drives, and backup media are reused and disposed of, which is why a hard drive sold at auction with patient data still on it is a Security Rule violation, not just bad hygiene.

Technical safeguards (164.312)

Technical safeguards are the controls built into the systems that store and move ePHI. This is the category most security engineers own day to day. The five standards are:

• Access Control: unique user identification, emergency access, automatic logoff, and encryption/decryption, so that only authorized users reach ePHI.
• Audit Controls: hardware, software, or procedural mechanisms that record and examine activity in systems holding ePHI.
• Integrity: protecting ePHI from improper alteration or destruction.
• Person or Entity Authentication: verifying that someone seeking access is who they claim to be.
• Transmission Security: guarding ePHI against unauthorized access while it moves across a network, including integrity controls and encryption.

Strong access control and audit logging are not optional extras here. They are named standards, and an auditor will ask to see them working.

Required vs. addressable: the distinction that trips everyone

Inside each safeguard, the rule lists implementation specifications, and each one is flagged either Required or Addressable (45 CFR 164.306(d)). This is the single most misread part of the Security Rule.

Required means exactly that: you must implement it, no judgment call. The risk analysis is required. Unique user identification is required.

Addressable does not mean optional. It means the organization must assess whether the specification is a reasonable and appropriate safeguard in its environment. If it is, you implement it. If it is not, you must document why, and implement an equivalent alternative measure where reasonable and appropriate. Encryption of ePHI at rest, for example, is an addressable specification, not a required one. An organization can decline to encrypt only if it documents a defensible reason and puts an equivalent control in its place. "Addressable" has never meant "skip it," and treating it that way is a common finding in OCR investigations.

This required-or-addressable structure exists to serve the rule's flexibility of approach.

Flexibility, scalability, and risk analysis

The Security Rule is deliberately not a checklist of specific products. 45 CFR 164.306(b) lets a regulated organization use any security measures that reasonably and appropriately implement the standards, weighing its size and complexity, its technical infrastructure and capabilities, the cost of the measures, and the probability and criticality of the risks to its ePHI. A solo physician's practice and a national insurer are held to the same standards but not to the same implementation.

That flexibility only works if you know your own risks, which is why the risk analysis is the keystone of the whole rule. 45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI the organization holds. Everything else flows from it: you cannot decide whether an addressable spec is reasonable, or what counts as an appropriate measure, without first knowing where your ePHI lives and what threatens it. In OCR enforcement actions, "no accurate and thorough risk analysis" is one of the most frequently cited failures, and it is almost always the first thing investigators ask for after a breach. A risk analysis that is missing, stale, or scoped to leave out a system is the gap that turns an incident into a penalty.

How the HIPAA Security Rule is enforced

The HHS Office for Civil Rights (OCR) enforces the Security Rule. Enforcement usually begins one of two ways: a breach report (covered entities must report breaches of unsecured PHI under the separate Breach Notification Rule) or a complaint. OCR investigates, and where it finds noncompliance it can require corrective action and impose civil monetary penalties.

Penalties are tiered by culpability under 45 CFR 160.404, from "did not know" at the low end to "willful neglect, not corrected" at the top. The dollar amounts are adjusted for inflation every year, so the figures in the base regulation are out of date. As adjusted effective January 2026, the minimum penalty for the lowest tier is 145 dollars per violation, and the annual cap for all violations of an identical provision reaches 2,190,294 dollars. The tier turns on what the organization knew and whether it corrected the problem, which is why a documented, current risk analysis and a real remediation effort change the outcome even after a breach. A serious data breach with no risk analysis on file is the scenario that lands organizations in the top tier.

What is changing: the 2025 proposed update

The Security Rule's technical core has not been substantially revised since 2013, and the threat landscape it was written for no longer exists. On January 6, 2025, OCR published a Notice of Proposed Rulemaking to overhaul it, the first major proposed update in over a decade. The public comment period closed in March 2025. As of mid-2026 the rule is still proposed: it has not been finalized and it has not been withdrawn, and it is under review. Nothing in the NPRM is in force yet, but it signals where the requirements are headed.

The headline proposed changes are significant for any defender:

• Remove the addressable category. Nearly all implementation specifications would become required, ending the addressable judgment call described above.
• Mandatory encryption of ePHI both at rest and in transit, with limited exceptions.
• Mandatory multi-factor authentication for access to systems holding ePHI.
• Network segmentation to limit lateral movement.
• Asset inventory and a network map, maintained and updated at least annually.
• Regular compliance audits, vulnerability scanning, and penetration testing, with documentation of each.

If finalized in anything close to its proposed form, the update would convert practices that were "reasonable and appropriate" judgment calls into flat requirements. Organizations that already run MFA, encryption, segmentation, and a current asset inventory are largely positioned for it. The ones treating "addressable" as "optional" are not.

Frequently Asked Questions

What is the HIPAA Security Rule?

The HIPAA Security Rule is the U.S. federal standard, issued by the Department of Health and Human Services, that requires covered entities and business associates to protect the confidentiality, integrity, and availability of electronic protected health information. It is codified at 45 CFR Part 160 and Part 164, Subpart C, and organizes its requirements into administrative, physical, and technical safeguards.

What is the difference between the HIPAA Security Rule and the Privacy Rule?

The Security Rule applies only to electronic protected health information (ePHI) and sets the technical, physical, and administrative safeguards that protect it. The Privacy Rule is broader: it governs all protected health information in any form, including oral and paper records, and controls how that information may be used and disclosed. The Security Rule is essentially the electronic-safeguards companion to the Privacy Rule.

What are the three types of HIPAA Security Rule safeguards?

The three categories are administrative safeguards (45 CFR 164.308: policies, risk analysis, training, contingency planning), physical safeguards (164.310: facility access, workstation and device controls), and technical safeguards (164.312: access control, audit controls, integrity, authentication, and transmission security). Two further sections cover organizational requirements and documentation.

What does "addressable" mean in the HIPAA Security Rule?

Addressable does not mean optional. For an addressable implementation specification, the organization must assess whether it is a reasonable and appropriate safeguard in its environment, then either implement it, or document why it is not reasonable and implement an equivalent alternative measure where appropriate. Required specifications must always be implemented with no such judgment call.

Who has to comply with the HIPAA Security Rule?

Covered entities (health plans, health care clearinghouses, and health care providers who transmit health information electronically) and their business associates must comply. A business associate is any vendor or contractor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity, such as a cloud provider or SaaS platform. Since the HITECH Act of 2009, business associates are directly liable to OCR for Security Rule compliance.

What are the penalties for violating the HIPAA Security Rule?

The HHS Office for Civil Rights enforces the rule with civil monetary penalties tiered by culpability, from "did not know" to "willful neglect, not corrected." The amounts are adjusted for inflation annually; as adjusted effective January 2026, they range from a minimum of 145 dollars per violation up to an annual cap of 2,190,294 dollars for all violations of an identical provision. OCR can also require corrective action plans.

Is the HIPAA Security Rule being updated?

Yes. On January 6, 2025, OCR published a Notice of Proposed Rulemaking to modernize the Security Rule, its first major proposed update since 2013. As of mid-2026 it is still proposed and not finalized. Key proposed changes include removing the addressable category so most specifications become required, and mandating encryption, multi-factor authentication, network segmentation, asset inventories, and regular audits and testing.

The bottom line

The HIPAA Security Rule is the federal floor for protecting electronic patient data: ensure the confidentiality, integrity, and availability of ePHI through administrative, physical, and technical safeguards, codified at 45 CFR 164.308, 164.310, and 164.312. It binds covered entities and, since HITECH, the business associates that handle their data directly. Its flexibility of approach rests entirely on a real, current risk analysis, and its "addressable" specifications have never meant optional.

For defenders, two things matter most. First, the risk analysis is the keystone; without it, every other decision under the rule is unsupported, and it is the first artifact OCR demands after a breach. Second, the 2025 proposed update is moving the rule toward hard requirements for encryption, MFA, segmentation, and continuous testing. The organizations that already treat those as baseline controls, rather than addressable maybes, are the ones that will not have to scramble when it lands.