Key takeaways
- Separate "required" from "addressable" explicitly in your documentation, and for every addressable item, keep a written reasonable-and-appropriate assessment on file — not just the control decision itself.
NIST SP 800-66, Revision 2, "Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide," is NIST's guidance document for complying with the HIPAA Security Rule's safeguards over electronic protected health information (ePHI). Published February 2024 by NIST's Applied Cybersecurity Division and developed with the HHS Office for Civil Rights, its own Abstract states it "provides practical guidance and resources that can be used by regulated entities of all sizes to safeguard ePHI and better understand the security concepts discussed in the HIPAA Security Rule." It is explicitly not a substitute for the Security Rule itself, and using it "does not ensure or guarantee that an organization will be compliant with the Security Rule" — it supersedes SP 800-66 Revision 1 from October 2008.
Who this covers, and why it's voluntary
The guide applies its analysis to "regulated entities" — the Security Rule's own term covering Covered Healthcare Providers, Health Plans, Healthcare Clearinghouses, and Business Associates (including a business associate's subcontractors that handle protected health information). The underlying Security Rule itself is binding federal law on every regulated entity. NIST SP 800-66r2 itself is not: per its Authority section, the guide "may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States" (attribution to NIST is only "appreciated," not required). The guide repeatedly underscores that "the HHS Office for Civil Rights (OCR) does not prescribe any particular risk assessment or risk management methodology" — the Security Rule is, in its own words, "flexible, scalable, and technology-neutral," so an organization can follow this guide's recommended approach in whole, in part, or substitute a different one entirely.
Six safeguard sections, and the required-vs-addressable split
The Security Rule organizes its requirements into six sections: Security Standards: General Rules, Administrative Safeguards (§164.308), Physical Safeguards (§164.310), Technical Safeguards (§164.312), Organizational Requirements (§164.314), and Policies and Procedures and Documentation Requirements (§164.316). Within those sections, each standard may carry one or more "implementation specifications," each marked required or addressable:
| Type | What a regulated entity must do |
|---|---|
| Required | Comply with it directly — "similar to a standard in that a regulated entity must comply with it" |
| Addressable | Assess whether it is "a reasonable and appropriate safeguard" in the entity's own environment; if yes, implement it; if not, document why and implement an equivalent alternative that is reasonable and appropriate |
Addressable never means optional: every standard itself must still be met, and "regulated entities are required to document these assessments and all decisions." Required implementation specifications include, for example, Risk Analysis and Risk Management under the Security Management Process standard, the Response and Reporting piece of Security Incident Procedures, Unique User Identification and the Emergency Access Procedure under Access Control, and Audit Controls in full — while addressable items include things like automatic logoff, encryption of ePHI at rest, and the Facility Security Plan.
The seven-step risk assessment process
Section 3.2 lays out a risk assessment methodology, built on NIST IR 8286A and SP 800-30, that the guide is explicit a regulated entity "may choose to use" rather than must: (1) Prepare for the assessment — map where ePHI is created, received, stored, processed and transmitted, including third parties, cloud providers and remote/teleworker access; (2) Identify reasonably anticipated threats — natural, human and environmental sources, explicitly including "phishing, ransomware, or insider threat"; (3) Identify potential vulnerabilities and predisposing conditions; (4) Determine the likelihood a threat will exploit a given vulnerability, using a qualitative Very Low–to–Very High scale; (5) Determine the impact on confidentiality, integrity or availability if that exploit succeeds; (6) Determine the level of risk by combining likelihood and impact in a risk-level matrix; and (7) Document the risk assessment results — the guide recommends a risk register. Section 4 then walks through risk management: deciding which risk levels are within organizational risk tolerance, and documenting the security measures chosen to bring unacceptable risk down to that level.
Smaller regulated entities, per the guide, "may find the HHS Security Risk Assessment (SRA) Tool helpful in getting started" — though it cautions that a questionnaire-style tool "cannot identify technical vulnerabilities," so it needs to be paired with a technical method such as vulnerability scanning.
A workable starting point
Build the ePHI inventory before anything else— the guide treats mapping where ePHI is created, stored, processed and transmitted (including medical IoT and third parties) as the prerequisite for every later risk assessment step, not an optional nicety. Separate "required" from "addressable" explicitly in your documentation, and for every addressable item, keep a written reasonable-and-appropriate assessment on file — not just the control decision itself. Use Appendix D's crosswalk if you already run NIST CSF or SP 800-53 controls— the guide maps every Security Rule standard and implementation specification to Cybersecurity Framework Subcategories and SP 800-53r5 controls, so an existing control catalog doesn't need to be rebuilt from scratch for HIPAA. Treat connected medical devices as part of the ePHI boundary, not outside it— the guide specifically calls out "the myriad of medical devices (e.g., Internet of Things [IoT] used in healthcare) that can store, process, or transmit ePHI" as in-scope for both the risk assessment and the Workstation Use/Security standards. Remember this guide doesn't establish compliance on its ownFor binding requirements, device makers and health IT operators still need the Security Rule text itself (45 CFR Part 160 and Part 164, Subparts A and C) and HHS OCR's own guidance — this publication is a reading aid, not a substitute.
SoftWSP's device and firmware security assessments can document the technical-safeguard side of a HIPAA risk analysis — access control, audit logging, transmission security and vulnerability findings — for connected medical devices and the health IT systems they plug into: see Device & Firmware Security.
This guide quotes NIST SP 800-66r2's own published text (Abstract, Authority, Sections 1-5); it is not a substitute for the HIPAA Security Rule itself, HHS OCR guidance, or compliance/legal advice, and does not establish or guarantee Security Rule compliance.
Sources
- NIST SP 800-66r2: Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule — A Cybersecurity Resource Guide (Jeffrey A. Marron, February 2024; full text — Abstract, Executive Summary, Sections 1-5, Appendices A-G)
- NIST: official DOI / publication landing page for SP 800-66r2 (canonical citation, publication history, supersession of SP 800-66r1)
Frequently asked questions
What is NIST SP 800-66r2, and what does it explicitly NOT do?
NIST Special Publication 800-66, Revision 2, "Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide," is a NIST guidance document, authored by Jeffrey A. Marron of NIST's Applied Cybersecurity Division and published February 2024 (DOI 10.6028/NIST.SP.800-66r2), developed in collaboration with the Department of Health and Human Services (HHS) Office for Civil Rights (OCR). Per its own Abstract, it "provides practical guidance and resources that can be used by regulated entities of all sizes to safeguard ePHI and better understand the security concepts discussed in the HIPAA Security Rule." Its own stated purpose is explicit about its limits: "This publication is intended to aid understanding of the HIPAA Security Rule and does not supplement, replace, modify, or supersede the Security Rule itself," and its Disclaimer adds, "The use of this publication or any other NIST publication does not ensure or guarantee that an organization will be compliant with the Security Rule." It supersedes NIST SP 800-66 Revision 1 (October 2008).
Who is a "regulated entity" under the Security Rule, and is following this NIST guide mandatory?
The guide defines "regulated entity" as both covered entities and business associates (including business associates' subcontractors with access to protected health information), and lists the Security Rule's own four regulated-entity categories: Covered Healthcare Providers, Health Plans, Healthcare Clearinghouses, and Business Associates. The underlying HIPAA Security Rule itself is federal law and mandatory for all regulated entities. NIST SP 800-66r2 is not: per its Authority section, it "may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States" (attribution to NIST is merely "appreciated"). The guide also notes a flexibility baked into the Security Rule itself — "the HHS Office for Civil Rights (OCR) does not prescribe any particular risk assessment or risk management methodology" — so entities may use SP 800-66r2's recommended approach in whole, in part, or substitute a different methodology entirely.
What's the difference between a "required" and an "addressable" implementation specification under the Security Rule, per this guide?
The Security Rule groups its requirements into six sections — Security Standards: General Rules, Administrative Safeguards, Physical Safeguards, Technical Safeguards, Organizational Requirements, and Policies/Procedures/Documentation Requirements — each built from standards, many of which carry "implementation specifications," either required or addressable. Per the guide's own summary: "A required implementation specification is similar to a standard in that a regulated entity must comply with it, " while for an addressable one, "a regulated entity must (i) assess whether each implementation specification is a reasonable and appropriate safeguard in its environment... and (ii) as applicable... implement the implementation specification if reasonable and appropriate; or, if not, (1) document why it would not be reasonable and appropriate... and (2) implement an equivalent alternative measure that is reasonable and appropriate." Addressable never means optional — regulated entities must still comply with the parent standard itself, and the guide stresses that "regulated entities are required to document these assessments and all decisions."
What risk assessment process does SP 800-66r2 recommend for ePHI?
Section 3.2 lays out a seven-step process, built on NIST IR 8286A and SP 800-30, that regulated entities "may choose to use" (the guide is explicit this is not the only acceptable methodology): (1) Prepare for the assessment — map where ePHI is created, received, stored, processed and transmitted, including third parties and remote/teleworker access; (2) Identify reasonably anticipated threats, covering natural, human and environmental sources; (3) Identify potential vulnerabilities and predisposing conditions; (4) Determine the likelihood that a threat will exploit a vulnerability, using a qualitative scale (Very Low to Very High); (5) Determine the impact of a successful exploit on confidentiality, integrity or availability; (6) Determine the level of risk by combining likelihood and impact in a risk-level matrix; and (7) Document the risk assessment results, ideally in a risk register. The guide notes small regulated entities "may find the HHS Security Risk Assessment (SRA) Tool helpful in getting started," while cautioning that a questionnaire tool "cannot identify technical vulnerabilities" on its own.
In this cluster
