The Security Rule: Safeguards, Required and Addressable Specifications, and the Proposed Update

Rule versions described: the HIPAA Security Rule at 45 CFR 164.302 to 164.318 as published February 20, 2003 (68 FR 8334) and amended by the Omnibus Rule of January 25, 2013 (78 FR 5566), current eCFR text read October 28, 2026; and the proposed rule "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," published January 6, 2025 (90 FR 898, RIN 0945-AA22), which is not final. Rules change. Check the regulator's current text on the eCFR and in the Federal Register before relying on any point.¹

The Privacy Rule, covered in lesson 2, says who may see and share health information. The Security Rule says how an organization has to protect the electronic copy of that information so it stays secret, stays accurate and stays available when a nurse or a billing clerk needs it. It is the part of HIPAA that turns into server rooms, sign-in screens, backup tapes, door locks, written policies and, after a ransomware attack, an OCR investigation.

This lesson goes through the rule section by section. It lays out every standard and implementation specification in one table, with the required and addressable marks, and explains each one with a small clinic example and a hospital example. Then it covers the 2021 recognized security practices law, the voluntary HHS goals and practices that sit beside the rule, and the January 2025 proposal to rewrite it: what HHS proposed, what it estimated the cost would be, what the comment fight was about, and exactly where the proposal stands as of October 28, 2026. If HIPAA is new to you, start with the overview in Health Privacy: HIPAA and Beyond and with lesson 1 of this module on who the rules bind.

Where the Security Rule came from

Congress passed the Health Insurance Portability and Accountability Act in 1996. Its "administrative simplification" provisions pushed health care toward electronic claims and told HHS to write national standards for the security of health information that moves in electronic form. HHS proposed security standards in 1998 and published the final rule, "Health Insurance Reform: Security Standards," on February 20, 2003, at 68 FR 8334.² The final rule was shorter and more flexible than the proposal. HHS dropped many specific technical requirements after commenters said a fixed list of technologies would go stale and would crush small practices. The result was the structure the rule still has: broad standards, a set of implementation specifications marked "required" or "addressable," and a duty to choose measures that fit the organization.

Compliance dates

The rule gave regulated entities two years. Under 45 CFR 164.318, covered health plans, health care clearinghouses and covered health care providers had to comply by April 20, 2005. Small health plans got one more year, to April 20, 2006.³ Since then the core text of the standards has changed only once in a significant way, in 2013.

HITECH and the Omnibus Rule bring in business associates

As written in 2003, the Security Rule bound only covered entities. Vendors were reached only through contracts. The HITECH Act, Title XIII of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5), changed that. Section 13401, codified at 42 U.S.C. 17931, made the Security Rule's administrative, physical and technical safeguard sections and its policies and documentation section apply to business associates "in the same manner" as to covered entities, and made business associates subject to the same civil and criminal penalties.⁴

HHS wrote that change into the regulations in the Omnibus Rule, published January 25, 2013, at 78 FR 5566. The Omnibus Rule added "or business associate" throughout Subpart C, extended the rule to subcontractors of business associates, and revised the organizational requirements in 164.314 so a business associate has to get the same written assurances from its own subcontractors that a covered entity gets from it.⁵ That is why a billing company, a cloud host, an IT managed service provider or a records storage vendor can now be investigated and fined directly by OCR, as lesson 6 explains in detail.

The general rules in 164.306

Section 164.306 is short, and it controls how every other section is read. It has four pieces: what a regulated entity must protect against, how much freedom it has to choose its measures, the difference between required and addressable specifications, and a duty to keep its security current.⁶

Confidentiality, integrity and availability

Under 164.306(a), every covered entity and business associate must ensure the confidentiality, integrity and availability of all ePHI it creates, receives, maintains or transmits; protect against reasonably anticipated threats or hazards to its security or integrity; protect against reasonably anticipated uses or disclosures the Privacy Rule does not allow; and ensure its workforce complies. The three words have definitions in 164.304:

• Confidentiality means data is not made available or disclosed to unauthorized persons or processes. A stolen laptop with an unencrypted patient list is a confidentiality failure.
• Integrity means data has not been altered or destroyed in an unauthorized way. A medication allergy silently deleted from a chart, or a lab value changed in transit, is an integrity failure, and it can hurt a patient faster than a disclosure.
• Availability means data is accessible and usable on demand by an authorized person. A hospital whose electronic health record is encrypted by ransomware and that diverts ambulances is living through an availability failure.

Availability is the part of the rule most people forget, and it is the part ransomware attacks. The Security Rule has required contingency planning, backups and disaster recovery since 2003 because an organization that cannot reach its records cannot treat patients safely.

Flexibility of approach

Section 164.306(b) lets each regulated entity "use any security measures" that reasonably and appropriately implement the standards. In deciding which measures to use, it must consider four factors:⁶

1. its size, complexity and capabilities;
2. its technical infrastructure, hardware and software security capabilities;
3. the costs of security measures; and
4. the probability and criticality of potential risks to ePHI.

This is the "scalable" part of HIPAA. A three-provider family practice in Salmon, Idaho and a 20-hospital health system are both bound by the same standards, but they are not expected to buy the same tools. The family practice might meet the audit controls standard with the logging built into its cloud electronic health record and a monthly review by the office manager. The health system will need a security information and event management system and a staffed security operations center.

Flexibility has a limit that small organizations sometimes miss. Cost is a factor to consider, not a veto. HHS has said for years that a covered entity cannot skip a standard because it is expensive; cost helps decide which reasonable measure to pick. And the fourth factor, risk, means the answer depends on a written risk analysis. Without one, an organization has no basis to show that its choices were reasonable, which is why risk analysis failures show up in almost every OCR settlement. The risk analysis itself is the subject of lesson 4.

Maintenance: security is never finished

Section 164.306(e) requires each entity to review and modify its security measures as needed to keep providing reasonable and appropriate protection, and to update the documentation under 164.316. A risk analysis done once in 2019 and never touched does not meet this. Neither does a policy manual bought from a vendor and left in a drawer.

Required versus addressable: what "addressable" really means

The Security Rule is built in two layers. A standard is a broad requirement, such as "security awareness and training" or "transmission security." Under 164.306(c), every regulated entity must comply with every applicable standard. An implementation specification is a more detailed instruction for how to meet a standard. Some standards have none, in which case the standard itself is the requirement. Each specification is labeled in the regulation text with "(Required)" or "(Addressable)" after its title.⁶

A required specification must be implemented. There is no balancing test. A risk analysis, a data backup plan and a unique user ID for each person are required for every regulated entity from a solo chiropractor to a national insurer.

An addressable specification triggers a three-way decision under 164.306(d)(3). The entity must assess whether the specification is a reasonable and appropriate safeguard in its environment, considering its likely contribution to protecting ePHI. Then it must do one of these:

1. Implement the specification if it is reasonable and appropriate. For most organizations in 2026, encryption of laptops is reasonable and appropriate, so the answer is to encrypt them.
2. Implement an equivalent alternative measure if the specification itself is not reasonable and appropriate but another measure would meet the standard. A clinic whose old dictation system cannot log users off automatically might place it in a locked transcription room that only two people can enter.
3. Document why neither is reasonable and appropriate, if that is truly the case, and still meet the standard some other way. The documentation must be kept for six years under 164.316.

HHS's own summary of the rule says the same thing in plainer words: addressable specifications give flexibility, but an entity that decides not to implement one must document why and implement an equivalent alternative if reasonable and appropriate.⁷ In practice, "addressable" has been misread for two decades as "optional." OCR settlements keep finding organizations that never assessed encryption at all, or that assessed it, decided it was reasonable and appropriate, and then never did it. The Lifespan case in the common mistakes section below is the clearest example.

A short count of the labels

Counting the labels in the current text of 164.308, 164.310 and 164.312: the administrative safeguards have 21 implementation specifications (10 required, 11 addressable), the physical safeguards have 8 (2 required, 6 addressable), and the technical safeguards have 7 (2 required, 5 addressable). That is 36 specifications, 22 of them addressable. Every specification in 164.314 and 164.316 is required.⁸⁹¹⁰ Seven standards have no implementation specifications, so the standard itself must be met: assigned security responsibility, evaluation, workstation use, workstation security, audit controls, person or entity authentication, and the policies and procedures standard in 164.316(a). The business associate standard in 164.308(b) has just one implementation specification, a required written contract or other arrangement.

Every standard and specification in one table

The table below lists every standard (in bold) and every implementation specification in the current Security Rule, with its citation, its label (R for required, A for addressable, and "Std" for a standard; a standard with no specification rows under it must be met as written), a plain-language meaning, and two short examples: one for a small clinic with a dozen staff and a cloud electronic health record, and one for a hospital or health system. The wording is a paraphrase; the regulation text controls.^89101112 The examples are illustrations of reasonable approaches, not the only ones, and not a checklist that makes anyone compliant.

Administrative safeguards, 45 CFR 164.308

Administrative safeguards are the management side of security: the policies, people decisions, training and planning that control how technology is chosen and used. HHS defines them in 164.304 as administrative actions and policies to manage the selection, development, implementation and maintenance of security measures and the conduct of the workforce. They make up more than half of the rule.

Physical safeguards, 45 CFR 164.310

Physical safeguards protect buildings, equipment and media: who can walk in, where the screens face, and what happens to a hard drive when a copier lease ends.

Technical safeguards, 45 CFR 164.312

Technical safeguards are the technology and the policies for using it that protect ePHI and control access to it. They are deliberately technology-neutral in the current rule: the text says "encryption" and "audit controls," not which product or algorithm.

Organizational requirements and documentation, 45 CFR 164.314 and 164.316

The six-year clock in 164.316(b)(2)(i) runs from the date a document was created or the date it was last in effect, whichever is later.¹² A policy adopted in 2015 and replaced in 2024 must be kept until 2030. Investigators routinely ask for prior versions, because the question in a breach case is what the organization was doing on the day of the breach, not what it wrote afterward.

The administrative safeguards up close

The table gives one line per item. Some items carry most of the weight in real investigations and deserve more explanation.

Security management process: the engine of the rule

The four required specifications under 164.308(a)(1) form a loop. The risk analysis finds what could go wrong with ePHI and how likely and how harmful it would be. Risk management fixes the problems found, down to a reasonable and appropriate level. The sanction policy makes the rules enforceable inside the organization. Information system activity review watches whether the controls work. OCR's 2010 guidance on risk analysis, still the agency's main explainer and last reviewed August 12, 2026, says the analysis must cover all ePHI the organization creates, receives, maintains or transmits, in every form of electronic media, and must be updated periodically.¹³

For a clinic, "all ePHI" includes places people forget: a scanner that keeps images on its internal drive, the phone a physician uses to text photos of a wound, the spreadsheet the billing clerk exports each month, the fax server and the old practice management database kept "just in case." For a hospital it also includes research data sets, departmental systems bought outside the IT budget, imaging archives, and connections to hundreds of vendors. Lesson 4 walks through the method step by step.

Information system activity review is required, and it is where many organizations fall down. Turning on logs is the audit controls standard in 164.312(b). Looking at them is this specification. OCR's $1.5 million civil money penalty against Warby Parker, announced February 20, 2025, after credential stuffing attacks in late 2018 reached accounts of 197,986 people, found three Security Rule failures: no accurate and thorough risk analysis, no adequate risk management, and no procedures to regularly review information system activity.¹⁴

The security official

The assigned security responsibility standard in 164.308(a)(2) requires one named person. It can be the same person as the Privacy Rule's privacy official, and in small practices it usually is. Naming someone matters because the rest of the rule assumes a person who owns the risk analysis, signs off on addressable decisions and answers OCR's data request. When nobody owns security, the documents that OCR asks for after a breach tend not to exist.

Workforce security and information access management

These two standards decide who gets in. Termination procedures are addressable today, but OCR has treated a failure to cut off former workforce members as a serious problem. In the Ambry Genetics settlement of September 17, 2026 ($700,000, after a January 2020 phishing attack affecting 225,370 people), OCR's findings included failure to terminate access and failure to assign unique user identifiers, along with an inadequate risk analysis.¹⁵ A clinic can do this with a separation checklist. A hospital should connect its human resources system to account management so the two cannot drift apart. The proposed rule discussed below would make the deadline one hour.

Training, and the addressable specifications inside it

The security awareness and training standard is mandatory, but its four specifications (reminders, protection from malicious software, log-in monitoring and password management) are all addressable. That looks odd in 2026: malware protection is addressable? It reflects the 2003 drafting, in which HHS placed technical measures under a training standard and left the method to each entity. Nearly every organization today will find anti-malware tools reasonable and appropriate, and the proposed rule would move them to a stand-alone, required configuration management standard. For practical guidance on accounts and passwords for a small office, see Accounts, Passwords and Two-Step Sign-In.

Incident procedures and contingency plans

A "security incident" under 164.304 includes attempted as well as successful unauthorized access, use, disclosure, modification or destruction of information, or interference with system operations. Read literally, that covers every blocked phishing email and port scan. In the 2003 preamble, HHS said that whether a specific action counts as a security incident, and how it is documented, depends on each entity's environment and on its risk analysis.² Many organizations handle this by documenting attempted incidents in aggregate and successful ones individually. The required response and reporting specification asks for identification, response, mitigation of harmful effects "to the extent practicable" and documentation of each incident and its outcome. Whether a security incident is also a reportable breach is a separate question, answered by the Breach Notification Rule in lesson 5.

The contingency plan standard has three required specifications (data backup, disaster recovery and emergency mode operation) and two addressable ones (testing and revision, and criticality analysis). Backups are required, but nothing in the current text sets how often backups run, how old they may be, whether they must be offline, or how fast systems must come back. That gap matters in a ransomware era. The largest health data breach ever reported to OCR, the February 2024 ransomware attack on Change Healthcare, affected about 192.7 million people as of July 31, 2025 and disrupted claims and pharmacy processing across the country.¹⁶ For a small office's backup basics, see Computers, Local Data and Backups.

Evaluation

The evaluation standard in 164.308(a)(8) requires periodic technical and nontechnical evaluation, first against the 2003 rule and then whenever environmental or operational changes affect ePHI security. The word "periodic" is not defined. Many organizations read it as yearly. The proposed rule would instead require a written evaluation before each environmental or operational change that may affect ePHI, plus a separate compliance audit at least once every 12 months.

Business associate contracts in the Security Rule

Section 164.308(b) and 164.314(a) together say a covered entity needs a written contract before a business associate touches ePHI, and the contract must make the business associate comply with Subpart C, flow the same terms to subcontractors, and report security incidents, including breaches of unsecured PHI. The Security Rule terms sit alongside the Privacy Rule contract terms in 164.504(e). OCR's 2016 cloud computing guidance adds that a cloud provider that stores only encrypted ePHI and has no key is still a business associate.¹⁷ Today's rule asks for contract assurances but not proof; the proposal would require yearly written verification. Lesson 6 covers business associate agreements in full.

The physical safeguards up close

Physical safeguards get less attention than they deserve. Theft and loss of laptops, drives and paper were among the most common large breaches in the years after the breach rule took effect, and they still occur. The device and media controls standard is where most physical failures land.

Facility access controls

The standard requires policies to limit physical access to electronic information systems and the facilities they sit in, while allowing properly authorized access. All four specifications are addressable. For a clinic in a strip mall, that may mean a locked network closet, an alarm, and a rule that the copier technician is escorted. For a hospital it means badge readers, cameras, visitor management, controlled access to data centers and to wiring closets on every floor, and procedures that let the right staff in during a fire or flood.

Workstation use and workstation security

Both are standards with no specifications, so each organization must meet them as written. A "workstation" under 164.304 is an electronic computing device such as a laptop or desktop, and the electronic media stored in its immediate environment. Workstation use is about function and surroundings: what each class of workstation is for and where it may sit. Workstation security is about physical protection: cable locks, locked carts, privacy screens, and keeping devices out of public reach.

Device and media controls

Disposal and media re-use are required. When a copier lease ends, when a laptop is retired, when a server drive fails under warranty, the ePHI on it must be removed or the media destroyed. HHS's breach guidance points to NIST SP 800-88 for clearing, purging or destroying electronic media, and its encryption guidance points to NIST publications for encryption that makes PHI "secured" under the breach rule.¹⁸ Accountability (tracking who has which device) and data backup before moving equipment are addressable. Lifespan's 2020 settlement turned in part on device and media control failures: the organization did not have an adequate inventory of the devices that held ePHI.¹⁹

The technical safeguards up close

The technical safeguards are where the 2003 rule shows its age most clearly. The words are broad enough to cover modern tools, but several protections that security professionals now treat as basic are either addressable or not mentioned.

Access control and unique user IDs

Unique user identification and an emergency access procedure are required. Shared logins defeat audit controls, because nobody can tell who opened a record. Emergency access, often called "break the glass," lets a clinician reach a record outside normal permissions in a true emergency, with the access logged and reviewed afterward. Automatic logoff and encryption of stored data are addressable. For hands-on guidance on identity and access for small and medium organizations, see Identity, Access and Device Control.

Encryption today: addressable, but with a strong incentive

Encryption appears twice in the current rule: for stored data under 164.312(a)(2)(iv) and for data in transit under 164.312(e)(2)(ii). Both are addressable. But the Breach Notification Rule creates a strong reason to encrypt. Breach notice duties apply only to "unsecured" PHI, and HHS guidance says PHI encrypted consistent with NIST guidance, with the key kept separate and not compromised, is secured.¹⁸ A stolen encrypted laptop is a security incident to document. A stolen unencrypted laptop is often a breach requiring letters to patients, a report to HHS and, above 500 residents of a state, press notice. That is why OCR's settlements over lost devices so often say the entity knew encryption was reasonable and appropriate and did not do it.

Audit controls and integrity

Audit controls is a standard without specifications: a regulated entity must have hardware, software or procedures that record and examine activity in systems that contain ePHI. It does not say how long logs must be kept or what must be logged; the risk analysis and the six-year documentation rule shape those answers. Integrity requires protecting ePHI from improper alteration or destruction, with an addressable specification for an electronic way to confirm data has not been altered.

Person or entity authentication, and why MFA is not in the rule

The person or entity authentication standard in 164.312(d) requires procedures to verify that a person or entity seeking access to ePHI is who it claims to be. It does not say how. In 2003 that usually meant a password. The text does not mention multi-factor authentication, which combines two or more of something you know, something you have and something you are. Many organizations have used the risk analysis to decide that MFA is reasonable and appropriate for email, remote access and administrator accounts, and the free HHS Cybersecurity Performance Goals list MFA as an "essential" goal.²⁰ But no current text requires it. In testimony to Congress on May 1, 2024, UnitedHealth Group's chief executive said the attackers in the Change Healthcare incident used stolen credentials on a Citrix remote access portal that did not have MFA.²¹ That account comes from the company, not from an OCR finding, and OCR had announced no enforcement action against Change Healthcare as of October 28, 2026.

Transmission security

Transmission security requires technical measures to guard against unauthorized access to ePHI sent over a network. Its two specifications, integrity controls and encryption, are addressable. Encryption in transit is now routine for web portals and most interfaces, but it is still missing from some older systems, internal clinical networks and fax-to-email services.

Where this lesson links instead of repeating

The Security Rule tells you what to protect and how to decide. Other courses on this site explain the security practices in more detail. Use them alongside this lesson:

• Security Frameworks and Standards (course 73): the NIST Cybersecurity Framework, the CIS Critical Security Controls and ISO 27001, and how to choose among them.
• Identity, Access and Device Control (course 73): accounts, MFA, administrator rights and device management.
• Vulnerabilities, Patching and Your Website (course 73): scanning, patch cycles and web exposure.
• Accounts, Passwords and Two-Step Sign-In (course 72): the plain-language version for a small office.
• Computers, Local Data and Backups (course 72): backup basics.
• Health Privacy: HIPAA and Beyond (course 69): the overview of HIPAA and of health data outside HIPAA.

The recognized security practices law

On January 5, 2021, Public Law 116-321 amended the HITECH Act by adding section 13412, codified at 42 U.S.C. 17941.²² It does not change the Security Rule's text. It changes how HHS must treat an organization in enforcement.

What the law says

When HHS decides fines, the length and result of an audit, or other remedies in a settlement for potential Security Rule violations, the Secretary "shall consider" whether the covered entity or business associate adequately demonstrated that it had recognized security practices in place for not less than the previous 12 months. Those practices may mitigate fines, lead to an earlier, favorable end to an audit, and reduce the remedies the parties agree to. The law defines recognized security practices as standards, guidelines, best practices, methodologies, procedures and processes developed under section 2(c)(15) of the NIST Act (the NIST Cybersecurity Framework) and approaches promulgated under section 405(d) of the Cybersecurity Act of 2015 (the HHS Health Industry Cybersecurity Practices, known as HICP), along with other programs recognized by statute or regulation. The organization chooses which practices fit, consistent with the Security Rule.²²

The law also has limits written into it. It does not give HHS authority to increase fines, or the length or extent of audits, because an organization lacks recognized security practices. An organization is not liable for choosing not to adopt them. And nothing in it limits HHS's authority to enforce the Security Rule.²² In short, it is a credit for good behavior, not a safe harbor and not a new mandate.

How OCR asks for evidence

OCR asked the public how regulated entities were implementing recognized security practices in a request for information released April 6, 2022, with comments due June 6, 2022.²³ In practice, when OCR opens an investigation or compliance review, its data request letter tells the organization that it may voluntarily submit evidence that recognized security practices were in place, and explains how. In late 2022 OCR released a video on the topic, and trade press summarizing it reported the kinds of evidence OCR said it would consider: policies and procedures for the practices, implementation project plans and meeting minutes, network diagrams and narratives, training materials, application screenshots and reports, vendor contracts and statements of work, and dates showing the practices were in use over the previous 12 months.²⁴

The 12-month requirement is the part organizations underestimate. Adopting the NIST framework the week after a ransomware attack does nothing for that investigation. A clinic that wants this credit needs dated evidence that it was doing the work for a full year before the incident: training records, patch reports, MFA enrollment reports, backup test logs, and a risk analysis mapped to the practices it chose.

The two named frameworks

The NIST Cybersecurity Framework, updated to version 2.0 on February 26, 2024, organizes security outcomes into six functions: govern, identify, protect, detect, respond and recover.²⁵ It is free and widely used across industries. Course 73's frameworks lesson explains it in detail. NIST also publishes SP 800-66 Revision 2 (February 14, 2024), a resource guide that maps each Security Rule standard to framework activities and suggests actions for organizations of different sizes.²⁶

The Health Industry Cybersecurity Practices (HICP), produced by HHS and industry under section 405(d), are written for health care. The 2023 edition, "Managing Threats and Protecting Patients," addresses five threats (social engineering; ransomware; loss or theft of equipment or data; insider data loss, accidental or malicious; and attacks on network-connected medical devices that may affect patient safety) and ten practices: email protection, endpoint protection, access management, data protection and loss prevention, asset management, network management, vulnerability management, security operations centers and incident response, network-connected medical devices, and cybersecurity oversight and governance.²⁷ Technical Volume 1 is written for small organizations, such as ambulatory practices without dedicated IT staff.²⁸

How the HHS Cybersecurity Performance Goals and HICP fit

In January 2024, HHS released voluntary Healthcare and Public Health Sector Cybersecurity Performance Goals (CPGs) through its HHS Cyber Gateway. There are ten "essential" goals and ten "enhanced" goals.²⁰

Three documents now sit side by side, and it helps to keep their legal status straight:

• The Security Rule is binding law. OCR enforces it with civil money penalties and settlements.
• HICP is voluntary guidance, but because it is promulgated under section 405(d), using it for 12 months counts as a recognized security practice that OCR must consider under 42 U.S.C. 17941.
• The CPGs are voluntary goals. They are not named in the 2021 law. They work as a short priority list, and many map directly to Security Rule standards and to HICP practices. Several of them, such as MFA, strong encryption, asset inventory, testing and network segmentation, became mandatory proposals in the January 2025 proposed rule.

A small clinic with no security staff can use the CPG essential goals as a first-year plan, the HICP small-organization volume as the method, and the free HHS Security Risk Assessment Tool for the risk analysis the rule requires.²⁹ None of those tools makes an organization compliant by itself, but together they produce the documentation the rule and the recognized security practices law both reward.

The proposed Security Rule update

On December 27, 2024, HHS released a notice of proposed rulemaking (NPRM) titled "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," with a fact sheet.³⁰ It was published in the Federal Register on January 6, 2025, at 90 FR 898 (pages 898 to 1022), docket HHS-OCR-2024-0020, RIN 0945-AA22. The comment period closed March 7, 2025.³¹ It is the first full rewrite of the Security Rule since 2003.

HHS's stated reasons were the rise in hacking and ransomware breaches, the age of the rule's text, inconsistent compliance found in OCR investigations, and changes in technology such as cloud computing. Hacking and IT incidents made up 534 of the 663 large breach reports OCR received for 2024 (81 percent) and affected 241,582,022 of about 242.9 million people counted (99 percent), according to OCR's report to Congress for that year.³²

Status as of October 28, 2026: still a proposal

As of October 28, 2026, the Security Rule overhaul is still a proposal. HHS's own regulatory agenda now lists it as a long-term action with a projected final action date of July 2027. The current reginfo.gov Unified Agenda entry for RIN 0945-AA22 (the 2026 agenda) places the rule in the "Long-Term Actions" stage, rated "Economically Significant," with a timetable of NPRM 01/06/2025 at 90 FR 898 and final action 07/00/2027.³³ The previous agenda, the Spring 2025 edition released in September 2025, had projected final action in May 2026. That date passed with no final rule.³⁴³⁵

Three things follow from that status:

• Nothing in the proposal is enforceable today. HHS's fact sheet says the current Security Rule stays in effect during rulemaking.³⁰ OCR investigates and settles cases under the 2003 rule as amended in 2013.
• A long-term listing is not a withdrawal. HHS has not withdrawn the NPRM. A long-term label means the agency does not expect action within the next 12 months; the projected date can move again, and a final rule could differ from the proposal in any respect.
• Be careful with vendor marketing. Many vendor blogs describe "the 2026 HIPAA Security Rule" as if it were final. It is not. If a final rule is published, HHS proposed that most provisions would take effect 60 days after publication, with compliance required 180 days after the effective date, and a longer transition for existing business associate agreements.³¹³⁶

Even so, the proposal matters now. It tells regulated entities what OCR considers good security in 2025 and 2026, and OCR investigators can already ask whether an organization's risk analysis reasonably considered MFA, encryption and tested backups. Many of the proposed controls are also in the CPGs, HICP and the NIST framework that count as recognized security practices.

What the proposal would change

The HHS fact sheet and the proposed regulatory text list these main changes.³⁰³⁷ All of them are proposals only.

1. Remove the addressable category. Every implementation specification would be required, with specific, limited exceptions written into the text. The proposed 164.306(c) simply says a regulated entity must comply with the standards "including their implementation specifications."
2. Write everything down. Written policies, procedures, plans and analyses for every requirement, with most of them reviewed and tested at least once every 12 months.
3. Technology asset inventory and network map. A written inventory of technology assets and a map of how ePHI moves through the organization's systems, updated at least every 12 months and when the environment changes.
4. A more specific risk analysis. The written risk analysis would have to include, among other things, a review of the asset inventory and network map, identified threats and vulnerabilities, an assessment of the risk from each business associate, and the likelihood and impact of each threat.
5. Patching deadlines. A new patch management standard would require patching critical risks within 15 calendar days and high risks within 30 calendar days of identifying the need (or of a patch becoming available), with documented exceptions.
6. Workforce access deadlines. Terminate a departing workforce member's access no later than one hour after employment ends, and notify other regulated entities within 24 hours when a workforce member's access to their systems changes or ends.
7. Contingency planning with clocks. A criticality analysis; written procedures to restore critical systems and data within 72 hours of a loss; backups no more than 48 hours old; and contingency plans tested at least once every 12 months.
8. Tested incident response. Written security incident response plans, tested at least once every 12 months.
9. Compliance audit. A documented audit of compliance with every standard and specification at least once every 12 months, in addition to the evaluation standard.
10. Encryption. Encrypt all ePHI at rest and in transit using prevailing cryptographic standards, with exceptions.
11. Multi-factor authentication. Deploy MFA to all technology assets in relevant systems, and for any action that changes a user's privileges, with exceptions.
12. Vulnerability management. Automated vulnerability scans at least every six months (or more often if the risk analysis calls for it), monitoring of authoritative sources for known vulnerabilities, and penetration testing by a qualified person at least once every 12 months.
13. Network segmentation and separate technical controls for backup and recovery.
14. Configuration management. Anti-malware protection, removal of extraneous software, secure configuration, and disabling network ports not needed, all tied to the risk analysis.
15. Business associate verification. Business associates would have to verify at least once every 12 months, through a written analysis by a subject matter expert and a written certification, that they have deployed the required technical safeguards, and would have to notify covered entities within 24 hours of activating a contingency plan. Subcontractors would owe the same to business associates.
16. Group health plans. Plan documents would have to require plan sponsors to comply with the administrative, physical and technical safeguards and to report contingency plan activation within 24 hours.
17. A new flexibility factor. The proposed 164.306(b)(2) would add a fifth factor: the effectiveness of the security measure in supporting the organization's resiliency.

The exceptions to encryption and MFA

The proposal is not a blanket mandate. Its exceptions are worth reading because they show HHS trying to deal with old technology and medical devices.³⁷

Under proposed 164.312(b)(3), encryption would not be required, to the extent the entity documents the exception, when:

• the technology asset cannot support encryption consistent with prevailing standards, and the entity has a written plan to migrate the ePHI to one that can within a reasonable and appropriate time;
• a patient exercising the right of access asks to receive ePHI unencrypted and has been told the risks (this does not apply when the patient receives it through technology the entity controls);
• an emergency makes encryption infeasible and the entity uses compensating controls under its contingency plan; or
• the asset is an FDA-authorized medical device, with conditions that depend on whether the marketing submission came before or after March 29, 2023 (the date the FD&C Act section 524B device cybersecurity requirements took effect) and whether the maker still supports it.³⁸

The MFA exceptions in proposed 164.312(f)(2)(iii) follow the same pattern: assets that cannot support MFA (with a migration plan), emergencies where MFA is infeasible (with compensating controls), and FDA-authorized devices on similar conditions. Where an exception applies, the entity would have to document it "in real-time" and use compensating controls approved by its security official and reviewed at least every 12 months. For a device authorized through a marketing submission received on or after March 29, 2023 and still supported by its maker, following the device's authorized labeling and the maker's patches would be presumed to be reasonable compensating controls.³⁷ Lesson 7 covers device rules in depth.

What HHS estimated it would cost

The regulatory impact analysis in the NPRM states: "The Department estimates that the first-year costs attributable to this proposed rule total approximately $9 billion," with "estimated annual costs of approximately $6 billion" for years two through five. The detailed table puts the first-year figure at about $9,314 million. Using a 2 percent discount rate, HHS estimated annualized costs of $6.8 billion for regulated entities and health plan sponsors combined, and a five-year present value of about $34 billion undiscounted, or $32 billion at 2 percent, in 2023 dollars, for 2026 to 2030.³⁹

HHS did not put a full dollar figure on benefits. Instead it ran a break-even analysis: if the changes reduced the number of people affected by breaches by 7 to 16 percent, the rule would pay for itself. In its small-entity analysis, HHS said annualized costs would be about $1,235 per regulated entity, figured per establishment ($2.3 billion divided across 1,822,600 regulated entities), and that larger firms with many facilities would pay more.³⁹

Read those numbers with care. They are HHS's estimates, published before comments. They are averages across very different organizations, from a solo therapist to a national insurer. Industry groups said they were far too low, and HHS has not published a revised estimate. A small clinic should not assume its cost would be $1,235 a year. Outside penetration tests, scans and compliance audits are bought from vendors at prices that vary widely, and this lesson found no verified per-clinic figure.

The comment debate

More than 4,700 comments were filed by the March 7, 2025 deadline, according to trade press tallies of the docket.⁴⁰ The arguments fall into a few groups.

Calls to withdraw. In February 2025, eight associations, including the College of Healthcare Information Management Executives (CHIME), the Medical Group Management Association (MGMA), the American Health Care Association and the Health Innovation Alliance, wrote to President Trump and HHS Secretary Robert F. Kennedy Jr. asking that the proposal be rescinded. They called HHS's $9 billion first-year figure a "woefully inadequate estimate," said the rule would create "undue financial strain" for hospitals and health systems, and warned it could leave smaller and rural providers more vulnerable, not less.⁴¹

Requests to change specific deadlines. Commenters, including a Wisconsin association of community health centers, asked HHS to drop the 72-hour restoration requirement, saying recovery after a major ransomware attack can take weeks no matter how well a clinic plans. Others called the annual business associate verification a heavy burden, while some wanted it to cover administrative and physical safeguards too. Small and rural providers asked for requirements tiered by size and capacity.⁴⁰

Requests for clarity. The Healthcare Information and Management Systems Society (HIMSS) asked HHS to exclude unsuccessful attempts, such as blocked phishing emails, from the definition of a security incident. Others asked whether text message codes count as MFA, and asked HHS to align the rule with NIST and create one federal incident reporting channel.⁴⁰

Support and calls to go further. Some security vendors, patient advocates and individual security professionals supported the proposal, and some commenters asked HHS to explicitly cover mobile apps.⁴⁰ Supporters point out that many of the proposed controls are already listed as essential or enhanced goals in HHS's voluntary CPGs, and that voluntary adoption had not prevented the record breaches of 2024.

What a regulated entity can sensibly do while it is pending

Because the proposal could change or stall, the safest approach is to treat it as a description of where OCR's expectations are heading, not as a deadline. Many of its controls are things a current risk analysis should already weigh. Organizations that already have MFA on email and remote access, encrypted laptops and backups, a current asset inventory, tested offline backups and a written patch process will have less to do if a final rule arrives, and they will have 12 months of evidence for the recognized security practices law in the meantime. Course 73's vulnerabilities and patching lesson explains scanning and patch cycles. CISA offers free vulnerability scanning of internet-facing systems to critical infrastructure organizations, which includes health care.⁴²

How the current rule is enforced today

OCR enforces the Security Rule through complaint investigations, compliance reviews opened after large breach reports, and, in some years, audits. Its report to Congress for calendar year 2024 says it received 30,256 new complaints, resolved 28,228, opened 730 compliance reviews (665 of them from breach reports), and closed 22 matters with resolution agreements or civil money penalties totaling $9,944,612. It also says "OCR did not initiate any audits in 2024 due to a lack of financial resources."⁴³

Since fall 2024, OCR has run a Risk Analysis Initiative focused on the required risk analysis in 164.308(a)(1)(ii)(A). As of April 23, 2026, it said it had completed 13 investigations under that initiative and 19 ransomware investigations.⁴⁴ The June 18, 2026 settlement with the Spencer Gifts LLC group health plans ($450,000) was described as the 14th Risk Analysis Initiative action and the 20th ransomware action,⁴⁵ and OSF HealthCare System's $552,250 settlement on July 29, 2026 was the 21st ransomware action.⁴⁶ Penalty amounts and the enforcement process are covered in lesson 8. Current per-violation civil money penalty amounts were last adjusted at 91 FR 3665 on January 28, 2026, with a maximum of $2,190,294 per calendar year for identical violations, and HHS said on October 21, 2026 it will keep using those 2025 levels.⁴⁷

Common mistakes, from OCR cases

These failures show up again and again in OCR resolution agreements and penalty notices. Each one ties back to a specific part of the current rule.

1. No real risk analysis, or one that leaves systems out

The most common finding in OCR's Security Rule cases. Warby Parker (no accurate and thorough risk analysis, $1.5 million penalty announced February 20, 2025),¹⁴ Ambry Genetics (inadequate risk analysis, $700,000, September 17, 2026)¹⁵ and every Risk Analysis Initiative case turned on 164.308(a)(1)(ii)(A). A checklist of policies is not a risk analysis, and neither is a vendor's generic report that does not list the organization's own systems.

2. Treating "addressable" as optional

Lifespan ACE paid $1,040,000 in a settlement announced July 27, 2020, after a stolen unencrypted laptop led to a breach report covering 20,431 people. OCR found Lifespan had determined that encryption was reasonable and appropriate but did not encrypt, lacked device and media controls, and had no business associate agreement with its parent company.¹⁹ The lesson is simple: an addressable decision must be made, written down and carried out.

3. Logs nobody reads

Audit controls without information system activity review do little. The Warby Parker findings included failure to implement procedures to regularly review records of information system activity.¹⁴ In insider snooping cases, logs can exist for years without anyone reviewing them until a patient complains.

4. Shared accounts and former staff who still have access

Unique user identification is required. Ambry Genetics' findings included failure to assign unique user identifiers and failure to terminate access.¹⁵ Shared "nurse" or "frontdesk" logins and accounts that outlive employment are exactly what attackers and curious insiders use.

5. Ransomware without tested recovery

OCR's ransomware settlements repeatedly cite risk analysis and risk management failures. The Bryan County Ambulance Authority in Oklahoma paid $90,000 in the first Risk Analysis Initiative settlement, announced October 31, 2024, after a 2021 ransomware attack affecting about 14,273 patients.⁴⁸ The current rule already requires backups, a disaster recovery plan and an emergency mode plan. Untested plans are the gap.

6. Documents that do not exist when OCR asks

Section 164.316 requires written policies and written records of required actions, kept six years. Organizations that cannot produce a dated risk analysis, training records or addressable decisions for the period before a breach start an investigation in a weak position, and they cannot claim recognized security practices credit either.

7. Vendors without agreements, or agreements without security terms

Lifespan had no business associate agreement with an affiliated entity that handled ePHI.¹⁹ In OCR's 2024 breach report, business associates were involved in 106 of 663 large breaches (16 percent), but those breaches affected 206,921,071 people, 85 percent of the total.³²

Questions people ask

Does the Security Rule cover paper records and conversations?

No. The Security Rule applies only to electronic protected health information. Paper charts, printed schedules and spoken conversations are covered by the Privacy Rule's general duty, in 45 CFR 164.530(c), to have reasonable administrative, technical and physical safeguards for all PHI. A fax printed on paper is Privacy Rule territory; the same fax arriving in an email inbox is Security Rule territory. Most organizations write one set of policies that covers both.

Is there an official HIPAA Security Rule certification?

No. HHS does not certify products, vendors or organizations as "HIPAA compliant." A vendor that says its product is "HIPAA certified" is describing its own claim or a private assessment. What matters is whether the product lets the regulated entity meet the standards, whether the vendor will sign a business associate agreement if it handles ePHI, and what the organization's own risk analysis says. Private frameworks and attestations, such as HITRUST or a SOC 2 report, can be useful evidence, but they do not substitute for the entity's own risk analysis and are not HHS approvals.

Is encryption required right now?

Under the current rule, encryption of stored data and of transmissions is addressable, not required. That means each organization must assess it, and if it decides not to encrypt, it must document why and use an equivalent measure if reasonable. In 2026, with inexpensive full-disk encryption built into most operating systems and phones, it is hard to document why encrypting a laptop would not be reasonable and appropriate. Encryption also keeps a lost device from becoming a reportable breach of unsecured PHI. The January 2025 proposal would make encryption required, with exceptions, but it is not final.

Is multi-factor authentication required?

Not by name. The person or entity authentication standard requires verifying identity but does not say how. Many organizations' risk analyses conclude that MFA is reasonable and appropriate for email, remote access and administrator accounts, and HHS lists MFA among its voluntary essential performance goals. The proposed rule would require MFA with limited exceptions. Until a final rule exists, an organization without MFA on remote access should be able to explain, in writing, how its risk analysis handled the risk of stolen passwords.

Does a solo practice really have to follow the same rule as a hospital?

Yes, the same standards apply, but the measures can differ. The flexibility factors in 164.306(b) let a small practice choose simpler, cheaper ways to meet each standard, as long as they are reasonable and appropriate given its risks. What a small practice cannot do is skip a standard or a required specification, such as the risk analysis, backups, unique user IDs or a written contract with each business associate.

If our electronic health record is in the cloud, isn't security the vendor's job?

Partly. The vendor is a business associate with its own direct Security Rule duties, and its agreement should say what it protects. But the practice still owns everything on its side: who has accounts, whether former staff are removed, whether laptops and phones that reach the record are secured, whether staff fall for phishing, and whether the practice can keep seeing patients if the vendor goes down. The practice's risk analysis has to cover the vendor relationship, too. Lesson 6 covers how to split those duties.

If the proposed rule becomes final, how long would we have?

Under the proposal, a final rule would take effect 60 days after publication, and most regulated entities would have to comply 180 days after the effective date. Existing business associate agreements could be kept until renewal, within limits.³¹³⁶ A final rule could change all of that. As of October 28, 2026, HHS projects final action in July 2027, on a long-term listing.

How long must we keep audit logs?

The current rule does not set a log retention period. The six-year retention rule in 164.316 applies to required documentation, such as policies, risk analyses and incident records, and many organizations keep the log reviews and incident evidence they rely on for six years. How long to keep raw logs is a decision for the risk analysis, informed by state law, contracts and storage cost.

If we follow the NIST framework, are we protected from penalties?

No. The recognized security practices law requires HHS to consider practices in place for the previous 12 months as a mitigating factor in fines, audits and settlement terms. It does not create a safe harbor, does not excuse Security Rule violations, and does not let HHS raise penalties for not using the practices.²² The benefit depends on evidence, so keep dated records.

Hard questions

These are contested policy questions. Each side has a serious case, and the evidence does not settle all of them.

Should the Security Rule mandate MFA and encryption?

The case for a mandate. Stolen passwords and unencrypted data are behind a large share of health data breaches. Hacking and IT incidents were 81 percent of large breaches reported to OCR for 2024 and accounted for 99 percent of people affected.³² The company's own account of the Change Healthcare attack, the largest health data breach ever reported to OCR, is that attackers used stolen credentials on a remote access portal without MFA.²¹ HHS's voluntary goals already call MFA and strong encryption "essential."²⁰ Supporters argue that after two decades, the addressable approach has let organizations postpone basic controls, and that a clear floor is easier to follow and to enforce than a case-by-case judgment.

The case against a rigid mandate. Clinical environments have real constraints. A shared workstation in an emergency department, a device cleared by FDA years ago that cannot run modern encryption, or an MFA prompt during a code can slow care. Opponents also argue that a technology-specific rule ages badly: the 2003 drafters deliberately avoided naming technologies for that reason. They say the risk-based approach lets security staff put money where risk is highest, and that a mandate may push small organizations to buy tools for compliance rather than security.

What the evidence shows. The proposal tries to split the difference: required controls, with documented exceptions for assets that cannot support them, emergencies, and FDA-authorized devices, plus compensating controls.³⁷ The breach data clearly show that credential theft and hacking dominate. What is not well measured is how many breaches MFA or encryption would have prevented in health care specifically; HHS's own analysis used a break-even approach (a 7 to 16 percent reduction in people affected) rather than claiming a measured effect.³⁹

Can small and rural providers afford the proposal?

The concern. Industry groups called HHS's roughly $9 billion first-year estimate "woefully inadequate" and warned that unfunded mandates would strain hospitals and leave smaller and rural providers more vulnerable.⁴¹ Rural hospitals and small practices often have thin margins, no full-time security staff, and few local vendors who can do penetration tests or 72-hour recovery plans. Commenters asked for tiered requirements by size.⁴⁰

The response. HHS's small-entity analysis estimated annualized costs of about $1,235 per regulated entity per establishment, and argued the burden would not fall disproportionately on small entities.³⁹ Supporters add that small organizations are frequent ransomware targets, that a small practice that loses its records for weeks may close, and that free tools already exist: the HHS SRA Tool, HICP's small-organization volume, the CPGs, and CISA's free scanning service.⁴²²⁹²⁸

What the evidence shows. HHS's per-entity figure is an average per establishment and is contested. No independent study of the proposal's cost to small and rural providers was verified for this lesson. What is clear is that the proposal contains no new federal funding, and that the cost question is likely to shape whatever final rule emerges. Readers following Idaho's critical access hospitals can look at whether they filed comments and what they said.

Should HHS keep "addressable" flexibility?

For keeping it. The flexibility in 164.306 is why the same rule can apply to a one-dentist office and a national insurer. It respects that the organization knows its systems best. Removing it may produce documentation for its own sake, such as annual audits and written verifications, without better security.

For removing it. OCR's cases show the flexibility has been widely misread as permission to do nothing. A floor of required controls with written exceptions keeps some flexibility while making the minimum clear. The proposal keeps the 164.306(b) factors and adds resiliency as a fifth one, so organizations would still choose how to meet each requirement.³⁷

What the evidence shows. Repeated OCR findings that entities never did the risk analysis, or decided to encrypt and did not, support the view that "addressable" has been misunderstood. They do not show whether a mandate would change behavior at organizations that already ignore required specifications such as the risk analysis.

Can OCR enforce a tougher rule with the resources it has?

The concern. OCR started no audits in 2024 because of a lack of money, and it resolved 22 enforcement matters that year with $9,944,612 in payments,⁴³ against 663 large breach reports.³² Some argue a rule with many new annual tasks will be enforced mainly after breaches, as now, so its real effect depends on whether organizations comply voluntarily.

The other view. Clear requirements are easier to enforce than judgment calls, and OCR's Risk Analysis Initiative shows it can process cases faster when the issue is narrow.⁴⁴ Clear requirements may also help insurers, boards and contracting partners hold organizations to account without waiting for OCR.

What the evidence shows. OCR's enforcement capacity is limited and largely breach-driven. Whether a final rule would change compliance more through enforcement or through contracts, insurance and board oversight is not yet known.

Where to go next

• HHS Summary of the HIPAA Security Rule: HHS's own plain-language summary of the rule and the required versus addressable test. Free. Read it alongside the eCFR text when writing policies.
• HHS Security Risk Assessment (SRA) Tool, version 3.7: Free Windows app or Excel workbook from HHS for small and medium providers to work through the risk analysis; data stays on your computer. Use does not guarantee compliance.
• NIST SP 800-66 Rev. 2: Free NIST guide that maps each Security Rule standard to practical activities and to the NIST Cybersecurity Framework. Good for security officers and IT providers.
• HHS 405(d) HICP Technical Volume 1: Cybersecurity Practices for Small Health Care Organizations: Free HHS and industry guide for practices without IT staff, organized by the ten HICP practices. Using it for 12 months counts as a recognized security practice.
• HHS HPH Cybersecurity Performance Goals: Free list of 10 essential and 10 enhanced voluntary goals. A short priority list for a first-year security plan.
• CISA Cyber Hygiene Services: Free weekly vulnerability scanning of internet-facing systems for critical infrastructure organizations, including health care. Enroll by email to vulnerability@cisa.dhs.gov.
• Security Rule NPRM docket on Regulations.gov (HHS-OCR-2024-0020): Free public docket with the proposed rule and the public comments. Useful for reporters and advocates tracking what local providers told HHS.

Still being checked (6 items)

These points could not be fully confirmed against a primary source when this lesson was written and fact checked in October 2026. The text above states each one as uncertain.

• The number of public comments on the NPRM (more than 4,700) comes from trade press tallies, not from an HHS count.
• UnitedHealth Group's account that the Change Healthcare attackers used a Citrix portal without MFA comes from company testimony reported by trade press; OCR has made no finding and announced no enforcement action against Change Healthcare as of Oct. 28, 2026.
• HHS's cost estimates are pre-comment estimates from the NPRM; HHS has published no revised estimate, and no independent estimate of the cost to small and rural providers was verified.
• The specific kinds of recognized security practices evidence OCR lists come from trade press summaries of an OCR video released in late 2022; HHS's RFI page does not list them.
• The Kootenai Health and Minidoka Memorial Hospital breach figures come from trade press and filings, not from OCR findings.
• Whether a final Security Rule will be published in July 2027, or in what form, is unknown; the agenda date is a projection.

Last verified October 28, 2026. General education, not legal, compliance or medical advice; rule versions and dates are stated in the text, and the sources used are listed in the Notes and Sources below. Check the regulator's current text before relying on any point.

Notes

1. Electronic Code of Federal Regulations, 45 CFR Part 164, Subpart C, "Security Standards for the Protection of Electronic Protected Health Information," sections 164.302 to 164.318, current text (read Oct. 28, 2026). Read it online. ↩
2. HHS, "Health Insurance Reform: Security Standards," final rule, 68 FR 8334, February 20, 2003 (read Oct. 28, 2026). Read it online. ↩
3. 45 CFR 164.318, "Compliance dates for the initial implementation of the security standards": April 20, 2005 for covered entities other than small health plans; April 20, 2006 for small health plans (read Oct. 28, 2026). Read it online. ↩
4. HITECH Act section 13401, Pub. L. 111-5 (2009), codified at 42 U.S.C. 17931, "Application of security provisions and penalties to business associates of covered entities" (read Oct. 28, 2026). Read it online. ↩
5. HHS, "Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the HITECH Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules" (Omnibus Rule), 78 FR 5566, January 25, 2013 (read Oct. 28, 2026). Read it online. ↩
6. 45 CFR 164.306, "Security standards: General rules," 68 FR 8376 (Feb. 20, 2003), as amended at 68 FR 17153 (Apr. 8, 2003) and 78 FR 5693 (Jan. 25, 2013), Cornell Legal Information Institute text (read Oct. 28, 2026). Read it online. ↩
7. HHS Office for Civil Rights, "Summary of the HIPAA Security Rule," including the explanation of required and addressable implementation specifications (read Oct. 28, 2026). Read it online. ↩
8. 45 CFR 164.308, "Administrative safeguards," 68 FR 8376 (Feb. 20, 2003), as amended at 78 FR 5694 (Jan. 25, 2013), Cornell Legal Information Institute text; labels counted from the text (read Oct. 28, 2026). Read it online. ↩
9. 45 CFR 164.310, "Physical safeguards," 68 FR 8376 (Feb. 20, 2003), as amended at 78 FR 5694 (Jan. 25, 2013) (read Oct. 28, 2026). Read it online. ↩
10. 45 CFR 164.312, "Technical safeguards," 68 FR 8376 (Feb. 20, 2003), as amended at 78 FR 5694 (Jan. 25, 2013) (read Oct. 28, 2026). Read it online. ↩
11. 45 CFR 164.314, "Organizational requirements," 68 FR 8376 (Feb. 20, 2003), as amended at 78 FR 5694 (Jan. 25, 2013) and 78 FR 34266 (June 7, 2013) (read Oct. 28, 2026). Read it online. ↩
12. 45 CFR 164.316, "Policies and procedures and documentation requirements," 68 FR 8376 (Feb. 20, 2003), as amended at 78 FR 5695 (Jan. 25, 2013); six-year time limit at (b)(2)(i) (read Oct. 28, 2026). Read it online. ↩
13. HHS Office for Civil Rights, "Guidance on Risk Analysis Requirements under the HIPAA Security Rule," July 14, 2010, page last reviewed August 12, 2026 (read Oct. 28, 2026). Read it online. ↩
14. Saul Ewing, "Seeing is Believing: A Civil Money Penalty With Warby Parker Following Cybersecurity Incident," 2025, summarizing OCR's $1.5 million civil money penalty (finalized Dec. 11, 2024, announced Feb. 20, 2025) for failures of risk analysis, risk management and information system activity review; 197,986 people. The penalty also appears on OCR's resolution agreements and civil money penalties list (read Oct. 28, 2026). Read it online. ↩
15. HHS press release, "HHS Office for Civil Rights Settles HIPAA Investigation of Ambry Genetics Phishing Attack Affecting 225,000 Individuals," September 17, 2026: $700,000; findings include inadequate risk analysis, failure to terminate access and no unique user identifiers (read Oct. 28, 2026). Read it online. ↩
16. HHS Office for Civil Rights, "Change Healthcare Cybersecurity Incident Frequently Asked Questions," last reviewed August 13, 2025: about 192.7 million individuals as of July 31, 2025 (read Oct. 28, 2026). Read it online. ↩
17. HHS Office for Civil Rights, "Guidance on HIPAA and Cloud Computing," October 6, 2016, last reviewed December 23, 2022 (read Oct. 28, 2026). Read it online. ↩
18. HHS, "Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals" (encryption consistent with NIST SP 800-111 and related publications; media sanitization per NIST SP 800-88), first issued April 27, 2009, 74 FR 19006 (read Oct. 28, 2026). Read it online. ↩
19. HHS press release, "Lifespan Pays $1,040,000 to OCR to Settle Unencrypted Stolen Laptop Breach," July 27, 2020: 20,431 individuals; encryption found reasonable and appropriate but not implemented; device and media control failures; no business associate agreement; two-year monitoring (read Oct. 28, 2026). Read it online. ↩
20. HHS, "Healthcare and Public Health (HPH) Cybersecurity Performance Goals," HHS Cyber Gateway, released January 2024: 10 essential and 10 enhanced voluntary goals (read Oct. 28, 2026). Read it online. ↩
21. Healthcare Innovation, "UnitedHealth CEO Testifies on Cyberattack," May 2, 2024, reporting Andrew Witty's May 1, 2024 testimony that attackers used compromised credentials on a Change Healthcare Citrix portal that did not have multi-factor authentication (read Oct. 28, 2026). Read it online. ↩
22. 42 U.S.C. 17941 (HITECH Act section 13412, added by Pub. L. 116-321, 134 Stat. 5072, January 5, 2021), "Recognized security practices," including the limitation in (b)(2) and no-liability provision in (b)(3) (read Oct. 28, 2026). Read it online. ↩
23. HHS Office for Civil Rights, "Request for Information on Recognized Security Practices and Sharing Civil Money Penalties," released April 6, 2022 (FR Doc. 2022-07210), comments due June 6, 2022 (read Oct. 28, 2026). Read it online. ↩
24. Steve Alder, "OCR Issues Guidance on HITECH Recognized Security Practices," HIPAA Journal, November 1, 2022, summarizing OCR's video on how to demonstrate recognized security practices (read Oct. 28, 2026). Read it online. ↩
25. National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 26, 2024 (read Oct. 28, 2026). Read it online. ↩
26. Jeffrey Marron, NIST SP 800-66 Rev. 2, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide, February 14, 2024 (read Oct. 28, 2026). Read it online. ↩
27. HHS 405(d) Program and Health Sector Coordinating Council, Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients, 2023 Edition (original January 2019) (read Oct. 28, 2026). Read it online. ↩
28. HHS 405(d) Program, HICP Technical Volume 1, Cybersecurity Practices for Small Health Care Organizations, 2023 Edition (read Oct. 28, 2026). Read it online. ↩
29. HHS Assistant Secretary for Technology Policy and OCR, "Security Risk Assessment Tool," version 3.7, page last updated September 18, 2026 (read Oct. 28, 2026). Read it online. ↩
30. HHS Office for Civil Rights, "HIPAA Security Rule Notice of Proposed Rulemaking to Strengthen Cybersecurity for Electronic Protected Health Information," fact sheet, December 27, 2024; states the current rule remains in effect during rulemaking (read Oct. 28, 2026). Read it online. ↩
31. HHS, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," proposed rule, 90 FR 898 to 1022, January 6, 2025, docket HHS-OCR-2024-0020, RIN 0945-AA22; comments due March 7, 2025; proposes an effective date 60 days after publication of a final rule and a compliance date 180 days after the effective date (read Oct. 28, 2026). Read it online. ↩
32. HHS Office for Civil Rights, Annual Report to Congress on Breaches of Unsecured Protected Health Information for Calendar Year 2024: 663 reports of 500 or more, about 242,908,056 individuals; hacking/IT 534 reports (81 percent), 241,582,022 individuals (99 percent); business associates 106 reports (16 percent), 206,921,071 individuals (85 percent) (read Oct. 28, 2026). Read it online. ↩
33. Office of Information and Regulatory Affairs, Unified Agenda (2026 agenda, publication ID 202510), RIN 0945-AA22, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information": stage Long-Term Actions; priority Economically Significant; timetable NPRM 01/06/2025 (90 FR 898), Final Action 07/00/2027 (read Oct. 28, 2026). Read it online. ↩
34. McDermott Will and Schulte, "Final Action on HIPAA Security Rule Modifications Now Projected for July 2027," July 16, 2026 (read Oct. 28, 2026). Read it online. ↩
35. Davis Wright Tremaine, "HHS Updates HIPAA Rulemaking Timeframes," Privacy and Security Law Blog, July 2026 (read Oct. 28, 2026). Read it online. ↩
36. Norton Rose Fulbright, "HHS proposes Security Rule amendments including new deadlines," February 2025, summarizing the proposed timelines, the 180-day compliance period and the business associate agreement transition (read Oct. 28, 2026). Read it online. ↩
37. Proposed regulatory text, 90 FR 1011 to 1022 (January 6, 2025), govinfo text: proposed 45 CFR 164.304 definitions; 164.306(b)(2)(v) resiliency factor; 164.308(a)(4) patch management (15 and 30 calendar days); 164.308(a)(9) termination within one hour and notice within 24 hours; 164.308(a)(13) contingency plan (72-hour restoration, 12-month testing); 164.308(a)(14) compliance audit; 164.312(b) encryption and exceptions; 164.312(f) MFA and exceptions; 164.312(h) vulnerability scans every six months and penetration tests every 12 months (read Oct. 28, 2026). Read it online. ↩
38. 21 U.S.C. 360n-2 (FD&C Act section 524B, "Ensuring cybersecurity of devices"), added by section 3305 of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328), effective March 29, 2023 (read Oct. 28, 2026). Read it online. ↩
39. Regulatory impact analysis and regulatory flexibility analysis, 90 FR 898 (January 6, 2025), govinfo text: first-year costs "approximately $9 billion" (about $9,314 million); about $6 billion a year in years two through five; annualized $6.8 billion at 2 percent; present value $34 billion undiscounted and $32 billion at 2 percent (2023 dollars, 2026 to 2030); break-even at a 7 to 16 percent reduction in people affected; about $1,235 annualized per regulated entity ($2.3 billion divided by 1,822,600 entities) (read Oct. 28, 2026). Read it online. ↩
40. Paubox, "Public feedback shapes the future of HIPAA Security Rule amendments," April 11, 2025, summarizing comments on docket HHS-OCR-2024-0020 and citing TechTarget's count of more than 4,700 comments (read Oct. 28, 2026). Read it online. ↩
41. TechTarget, "MGMA, CHIME ask Trump to rescind proposed HIPAA Security Rule," February 25, 2025, on a letter from eight associations (read Oct. 28, 2026). Read it online. ↩
42. Cybersecurity and Infrastructure Security Agency, "Cyber Hygiene Services" (free vulnerability scanning and web application scanning for eligible critical infrastructure organizations) (read Oct. 28, 2026). Read it online. ↩
43. HHS Office for Civil Rights, Annual Report to Congress on HIPAA Privacy, Security, and Breach Notification Rule Compliance for Calendar Year 2024: 30,256 new complaints, 28,228 resolved, 730 compliance reviews, 22 resolutions totaling $9,944,612, no audits initiated (read Oct. 28, 2026). Read it online. ↩
44. HHS press release, "OCR Settles Four Ransomware Investigations," April 23, 2026: 13 Risk Analysis Initiative investigations and 19 ransomware investigations completed (read Oct. 28, 2026). Read it online. ↩
45. HHS press release, OCR settlement with Spencer Gifts LLC Flexible Benefits and Welfare Benefit Plans, $450,000, June 18, 2026: 14th Risk Analysis Initiative and 20th ransomware enforcement action (read Oct. 28, 2026). Read it online. ↩
46. HHS press release, OCR settlement with OSF HealthCare System, $552,250, July 29, 2026: 21st ransomware enforcement action (read Oct. 28, 2026). Read it online. ↩
47. HHS, "Annual Civil Monetary Penalties Inflation Adjustment," final rule, 91 FR 3665, January 28, 2026 (2025 amounts), and HHS notice of October 21, 2026 (FR Doc. 2026-21524, 91 FR 66566) that it will continue to use the 2025 levels (read Oct. 28, 2026). Read it online. ↩
48. HHS Office for Civil Rights, "Resolution Agreements and Civil Money Penalties" list, including Bryan County Ambulance Authority ($90,000, October 31, 2024, first Risk Analysis Initiative action; details of the 2021 ransomware attack from OCR's resolution agreement page as summarized in compliance trade press) (read Oct. 28, 2026). Read it online. ↩
49. HHS Office for Civil Rights, Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information (breaches affecting 500 or more individuals) (read Oct. 28, 2026). Read it online. ↩
50. SecurityWeek, "460k Impacted by Kootenai Health Ransomware Attack," 2024, citing 464,088 people in the filing with the Maine Attorney General (read Oct. 28, 2026). Read it online. ↩
51. HIPAA Journal, "Minidoka Memorial Hospital Cyberattack," April 22, 2026 (read Oct. 28, 2026). Read it online. ↩
52. Idaho Office of the Attorney General, Consumer Protection, "Security Breaches" list of notices received, including Minidoka Memorial Hospital notices dated 8/6/2026 and 9/28/2026 (read Oct. 28, 2026). Read it online. ↩