The HIPAA Security Rule, Explained: Safeguards and Fines

Almost everyone who has to comply with the HIPAA Security Rule describes it the same way: administrative, physical and technical safeguards, plus something vague about encryption. That summary is accurate and close to useless, because it leaves out the part that decides whether an organization passes an investigation. The rule is a numbered list of standards, each with implementation specifications that are either mandatory or conditional, and the conditional ones carry a documentation obligation that is where most organizations actually fail.

What Is the HIPAA Security Rule?

The Security Rule is one of three regulations that together implement the privacy and security provisions of the Health Insurance Portability and Accountability Act of 1996. The Privacy Rule governs how protected health information may be used and disclosed in any form. The Breach Notification Rule governs what happens after something goes wrong. The Security Rule governs the safeguards, and only for information held or moved electronically.

According to the Department of Health and Human Services summary of the rule, the text lives at 45 CFR Part 160 and Part 164, Subparts A and C, and the Security Rule protects electronic protected health information specifically. Paper records and spoken disclosures are covered by the Privacy Rule and fall outside the Security Rule entirely. A fax sitting in a tray is a Privacy Rule problem. The same document as a PDF on a shared drive is a Security Rule problem.

Electronic protected health information, usually shortened to ePHI, is individually identifiable health information created, received, maintained or transmitted in electronic media. That is broader than a chart. Appointment reminders in a scheduling system, claims data in a billing platform, a spreadsheet of patient names on somebody's laptop, and backups of any of the above are all ePHI, and the obligations attach wherever it sits.

The rule was written to be scalable. HHS says it applies to organizations ranging from a single provider to a multi-state health plan, and from one medical transcriptionist to a large cloud service provider, which is why it names outcomes rather than products. That flexibility is the rule's defining feature and the reason defending a hospital or a physician group is a different exercise from defending a company that answers only to its customers.

Who Must Comply With the HIPAA Security Rule?

Two categories of organization, and the second one surprises people.

Covered entities are health plans, health care clearinghouses, and any health care provider that transmits health information electronically in connection with a transaction for which HHS has adopted a standard. That last clause matters. A provider that bills electronically is covered. The rare provider that has never transmitted a covered transaction electronically is not, which is a smaller category every year.

Business associates are organizations that create, receive, maintain or transmit ePHI on behalf of a covered entity. Billing companies, transcription services, cloud hosting providers, electronic health record vendors, claims processors, IT managed service providers, shredding companies handling electronic media, and analytics firms are all business associates when they touch the data. HHS refers to both groups together as regulated entities.

The change that made this consequential arrived with the HITECH Act in 2009. Section 13401 applied the Security Rule's safeguards and its documentation requirements to business associates in the same manner as to covered entities, and made business associates civilly and criminally liable for violations. Before that, a vendor's obligations ran only through its contract with its customer. Since then, the Office for Civil Rights can take enforcement action directly against the vendor.

Subcontractors inherit the same duty. A business associate that hands ePHI to a subcontractor must obtain the same written assurances from that subcontractor that the covered entity obtained from it, and those agreements must meet the same requirements. The chain runs as far as the data does.

What the HIPAA Security Rule Requires

Before any specific safeguard, section 164.306 states four general requirements that everything else serves.

Three words in that text carry most of the weight. Availability is the one people forget: a ransomware attack that encrypts records without exfiltrating a single byte is still a Security Rule failure, because the data is no longer accessible and usable on demand by an authorized person. Reasonably anticipated is the standard against which every decision is judged, and it moves as threats become common knowledge. Costs appears in the regulation as a factor a regulated entity may weigh, which is unusual in federal security regulation and is regularly misread as permission to do nothing affordable.

The safeguards themselves are organized in nested rings around the data.

HIPAA Security Rule Administrative Safeguards

This is the largest section of the rule and the one investigations start with. Section 164.308 carries nine standards.

Security management process is the anchor, and it holds four implementation specifications, all of them required: risk analysis, risk management, a sanction policy for workforce members who break the rules, and information system activity review, meaning somebody regularly reviews audit logs, access reports and incident tracking reports. All four are mandatory with no exceptions.

Assigned security responsibility requires the entity to identify the security official responsible for developing and implementing its policies and procedures. One named person, not a committee and not a job left vacant. Practices too small to employ one increasingly fill it with a fractional or virtual CISO, which the rule permits because it names a role rather than a headcount.

Workforce security and information access management together govern who gets access and how it is granted, reviewed, modified and removed. Termination procedures sit here, and offboarding that leaves accounts live is one of the most common findings in any healthcare investigation.

Security awareness and training requires a program for all workforce members, including management. Its four implementation specifications name security reminders, protection from malicious software, log-in monitoring and password management, which makes security awareness training one of the few areas where the regulation gets specific about content.

Security incident procedures requires policies to identify and respond to suspected or known incidents, mitigate harmful effects to the extent practicable, and document incidents and their outcomes. That documentation duty is what turns a written incident response plan from good practice into evidence.

Contingency plan is the standard ransomware made urgent. Three of its five specifications are required: a data backup plan producing retrievable exact copies, a disaster recovery plan to restore lost data, and an emergency mode operation plan to keep critical processes running while the entity operates in emergency mode. Testing and revision procedures, and an analysis of which applications and data matter most, are addressable.

Evaluation requires a periodic technical and nontechnical assessment of how well the entity's policies and procedures meet the rule, repeated in response to environmental or operational changes. Business associate contracts and other arrangements closes the section, requiring written contracts documenting satisfactory assurances.

HIPAA Security Rule Physical Safeguards

Section 164.310 has four standards and is the shortest of the three categories, which is not the same as the least enforced. Lost and stolen devices remain a steady source of reportable breaches.

Facility access controls requires policies limiting physical access to electronic information systems and the buildings housing them, while still allowing properly authorized access. Its four specifications, all addressable, cover contingency operations during a disaster, a facility security plan, access control and validation procedures including visitor control, and maintenance records for repairs to physical components related to security.

Workstation use requires policies specifying what functions are performed at a workstation, how, and what the physical surroundings should be. Workstation security requires physical safeguards restricting workstation access to authorized users. Together they are the reason a screen facing a waiting room is a regulatory problem and not merely bad manners.

Device and media controls governs hardware and electronic media carrying ePHI moving into, out of and around a facility. Two of its four specifications are required: disposal, covering final disposition of ePHI and the media it sat on, and media re-use, requiring removal of ePHI before media is reused. Accountability, meaning a record of who moved what, and data backup before equipment moves are addressable.

The practical translation is short. Know where the data physically is, control who can reach it, and be able to prove that a decommissioned drive was wiped or destroyed rather than sold.

HIPAA Security Rule Technical Safeguards

Section 164.312 is the part everyone expects the rule to be about, and it is the shortest and least prescriptive of the three. Five standards, no product names, no algorithms.

Access control requires technical policies allowing access only to authorized persons or software programs. Two of its four specifications are required: unique user identification, meaning a distinct name or number per user, and an emergency access procedure for obtaining ePHI during an emergency. Automatic logoff after a period of inactivity and encryption and decryption of stored ePHI are both addressable.

Audit controls requires hardware, software or procedural mechanisms that record and examine activity in systems containing ePHI. It carries no implementation specifications at all, which means the standard itself is mandatory and the method is entirely yours.

Integrity requires protecting ePHI from improper alteration or destruction, with one addressable specification covering electronic mechanisms to corroborate that data has not been altered.

Person or entity authentication requires procedures to verify that whoever is seeking access is the one claimed. It names no method, which is why multi-factor authentication is a compliance expectation rather than a compliance requirement today.

Transmission security requires technical measures guarding against unauthorized access to ePHI travelling over an electronic communications network. Both of its specifications, integrity controls and encryption, are addressable.

Read the encryption lines twice, because this is where the rule diverges most sharply from how people describe it. Encryption of ePHI appears twice in section 164.312, and both times as addressable. The Security Rule does not mandate encryption. What makes encryption close to non-negotiable in practice comes from a different regulation, and it is worth understanding exactly how that works.

Required vs Addressable Implementation Specifications

Counting the text of sections 164.308, 164.310 and 164.312 gives 18 standards and 36 implementation specifications. Of those specifications, 14 are marked Required and 22 are marked Addressable. Every one of the 18 standards is mandatory. The flexibility lives one level down.

Three outcomes are legitimate for an addressable specification, and only three. Implement it. Implement something equivalent and write down what and why. Or determine that neither is reasonable and appropriate in your environment and write down that reasoning. Doing nothing and writing nothing is the fourth outcome, it is not on the list, and it is the one an investigator finds most often.

The documentation is the compliance artifact. An organization that skipped automatic logoff because its clinical workstations are in locked rooms with badge access, wrote that analysis down, and can produce it, has complied. An organization that skipped automatic logoff because nobody got to it has not, even if the risk was genuinely low. The rule tolerates a wide range of security postures and almost no undocumented ones.

What Is a HIPAA Risk Analysis?

The risk analysis at section 164.308(a)(1)(ii)(A) is a required implementation specification, and it is the one that governs every other decision in the program. It requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI the entity holds.

HHS explains why it treats risk analysis separately from the rest of the administrative safeguards: it affects the implementation of every safeguard in the rule, because it identifies the risks against which "reasonable and appropriate" is then measured. Without it, the flexibility of approach at section 164.306(b) has nothing to attach to. You cannot argue a control was disproportionate to your risk if you never established what your risk was.

An accurate and thorough assessment means, at minimum, knowing every system and location where ePHI lives, including backups, vendor platforms and personal devices; identifying the threats and vulnerabilities relevant to each; assessing likelihood and impact; and recording the result. A vulnerability scan is not a risk analysis. A completed questionnaire from a compliance platform is not a risk analysis. Both can be inputs to one.

For method, the federal government publishes its own guidance. NIST Special Publication 800-66 Revision 2, published in February 2024, is a cybersecurity resource guide for implementing the Security Rule, and NIST maps the rule's standards and implementation specifications to the NIST Cybersecurity Framework subcategories and to SP 800-53 controls. Using it does not create a safe harbor, and no framework does. It does mean your method has a published federal pedigree when somebody asks where it came from.

What the HIPAA Security Rule Does Not Require

As much confusion comes from what people add to the rule as from what they leave out.

It does not require certification. There is no HIPAA certificate, no accreditation body, no registry and no expiry date. HHS certifies nobody. A vendor advertising itself as HIPAA certified has bought an assessment from a private company, which may be perfectly good work, but the label carries no regulatory standing. That is different from a SOC 2 report, which at least names the CPA firm that formed the opinion and the period it examined.

It does not name technologies. No algorithm, no key length, no product category, no vendor list. HHS built the rule to be technology neutral so that regulated entities could adopt new technology without the regulation obstructing it.

It does not mandate encryption or multi-factor authentication. Both are addressable or absent in the current text, for the reasons set out above. Both are also proposed as requirements in the pending update.

It does not cover paper or speech. Those obligations exist, and they sit in the Privacy Rule.

It does not require a specific audit frequency. The evaluation standard says periodic and ties re-evaluation to environmental or operational change. The proposed update would add a compliance audit at least once every 12 months.

HIPAA Security Rule vs the HIPAA Privacy Rule

The two rules are often merged in conversation and they answer different questions.

The Breach Notification Rule at Subpart D is the bridge between them. A Security Rule failure becomes visible to the public through it: 60 calendar days to notify affected individuals, notice to the Secretary contemporaneously for breaches affecting 500 or more people, and an annual log submitted within 60 days of year end for smaller ones. The public breach portal that follows from those filings is the reason healthcare incidents are so much more visible than incidents in other sectors.

What Are the Penalties for a HIPAA Security Rule Violation?

This is the most misreported part of the rule, and getting it right takes two documents rather than one.

The second document is the part almost every summary omits. In April 2019, HHS published a notification of enforcement discretion regarding HIPAA civil money penalties stating that its General Counsel had concluded the better reading of the HITECH Act was to apply a different annual limit to each tier: $25,000 for no knowledge, $100,000 for reasonable cause, $250,000 for corrected willful neglect and $1,500,000 for uncorrected willful neglect, before inflation adjustment. That notice is effective indefinitely and pending further rulemaking, so the codified regulation still shows one cap while OCR applies four.

The practical consequence is that the headline figure quoted everywhere applies only to the worst tier. An organization that discovers a violation and corrects it inside 30 days faces an annual limit an order of magnitude below the one it read about, and the difference between tiers turns almost entirely on what the organization knew and how fast it acted.

Two things sit outside the civil penalty scheme and get forgotten. State attorneys general have independent authority to bring HIPAA actions on behalf of state residents, and state breach and health privacy laws stack on top of the federal ones. Criminal liability for knowingly obtaining or disclosing protected health information is enforced by the Department of Justice rather than OCR, which is what those 2,419 referrals are.

The Proposed HIPAA Security Rule Update

The Security Rule's substantive text has not changed since the 2013 Omnibus Final Rule. A significant rewrite is pending, and it has been pending long enough that a lot of published commentary describes it as though it were already law. It is not.

The HHS fact sheet on the proposal lists what would change, and the list is long. The distinction between required and addressable implementation specifications would be removed, making all of them required with specific, limited exceptions. Written documentation of every policy, procedure, plan and analysis would become mandatory. Specific compliance time periods would replace today's open-ended language.

Beyond that, the proposal would require a technology asset inventory and a network map showing how ePHI moves, reviewed at least every 12 months; a far more prescriptive written risk analysis; notification within 24 hours when a workforce member's access is changed or terminated; written procedures to restore critical systems and data within 72 hours; a compliance audit at least every 12 months; encryption of ePHI at rest and in transit with limited exceptions; multi-factor authentication with limited exceptions; anti-malware deployment, removal of extraneous software and disabling of unused network ports; vulnerability scanning at least every six months and penetration testing at least every 12 months; network segmentation; and separate technical controls for backup and recovery.

The reasoning HHS gives is a set of numbers from its own breach data. OCR's announcement of the proposal states that reports of large breaches rose 102 percent between 2018 and 2023 while the number of individuals affected rose 1002 percent, that over 167 million individuals were affected by large breaches in 2023, and that since 2019 large breaches caused by hacking rose 89 percent and those caused by ransomware rose 102 percent.

How to Comply With the HIPAA Security Rule

The order below is the order an investigation follows, which is a good reason to work in it.

When to Hire Help With HIPAA Compliance

The judgment calls are where outside help pays for itself. Deciding what is reasonable and appropriate for your size and risk, writing an assessment that survives being read back to you, and building a program that a four-person practice can actually operate are all harder than the checklists suggest.