HIPAA tells you what.
800-66 is the how.

No — this is the most important distinction. NIST SP 800-66 is a cybersecurity resource guide, not a regulation, and there's no being "certified" or "required" to follow 800-66 on its own. The binding law is the HIPAA Security Rule (45 CFR Part 160 and Part 164), which all regulated entities — covered entities and business associates — must comply with.

What SP 800-66 Revision 2 does, published in February 2024 with the HHS Office for Civil Rights, is explain how to implement that Security Rule in practice — guidance, typical activities, and resources for assessing and managing risk to ePHI. So the HIPAA Security Rule tells you what you must achieve, and 800-66 is the government-authored how-to for getting there. You comply with HIPAA; you use 800-66 as the implementation playbook that turns the Rule's high-level requirements into something you can execute and document.

800-66 sits between the HIPAA Security Rule and the rest of the NIST ecosystem, which makes it valuable as a bridge. On one side, it's organized directly around the Security Rule's standards and implementation specifications — the administrative, physical, and technical safeguards — so working through it maps cleanly onto your HIPAA obligations. On the other, Revision 2 aligns that guidance with the broader NIST family: the Cybersecurity Framework, the 800-37 RMF, 800-30 for risk assessments, and the 800-53 control catalog.

The practical payoff: you don't have to run HIPAA as an island. If your organization already uses, or wants to use, the NIST CSF or 800-53 — common when you also pursue HITRUST or SOC 2 — 800-66 lets you connect your HIPAA implementation to that same program instead of maintaining a separate, parallel effort. For a healthcare organization juggling multiple compliance demands, that crosswalk is often the difference between one coherent program and several disconnected ones.

Because the risk analysis is both a required element of the HIPAA Security Rule and, in practice, the most frequently cited deficiency in OCR enforcement. The Rule requires an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI, and then security measures sufficient to reduce those risks to a reasonable and appropriate level. SP 800-66 Revision 2 builds its whole approach around that cycle, presenting risk assessment and risk management guidance sequentially and adding risk tolerance and risk appetite so you prioritize deliberately rather than treating every gap identically.

Many organizations get into trouble not for lacking security tools, but because they never performed a genuine, organization-wide risk analysis covering everywhere ePHI lives — or did one once and never updated it. A defensible 800-66 implementation treats the risk assessment as a living, repeating process and documents both the assessment and the management decisions that follow. We help you build and maintain exactly that, because it's what an OCR investigator looks for first.

No — one of the most common and dangerous misunderstandings in HIPAA. The Security Rule labels implementation specifications as either "required" or "addressable," but addressable does not mean optional. For an addressable specification, you must assess whether it's reasonable and appropriate in your environment, then either implement it, implement an equivalent alternative that achieves the same purpose, or — if neither is reasonable and appropriate — document the rationale for why and what you did instead. What you can't do is simply skip it because of the label.

800-66 is especially useful here because it helps you work through that decision logic for each specification and, critically, capture the documentation behind it. If OCR investigates, the difference between a defensible position and a finding is often whether you can show the reasoning and evidence behind how you handled each addressable specification. We help you make and document those determinations so the choices are defensible, not accidental.