In the HIPAA Security Rule, an addressable implementation specification is not optional. It is a specification you must implement if it is reasonable and appropriate for your environment — and if it is not, you must document why and implement an equivalent alternative measure where one is reasonable and appropriate. A required specification, by contrast, must simply be implemented, full stop. The word "addressable" grants flexibility in how you meet a standard. It never grants permission to ignore it.
What the regulation actually says
The distinction lives in 45 CFR 164.306(d). Every implementation specification in the Security Rule carries a parenthetical label after its title — either "(Required)" or "(Addressable)".
For a required specification, the rule is one sentence long: the regulated entity must implement it.
For an addressable specification, the regulation lays out a decision procedure. The entity must first assess whether the specification is a reasonable and appropriate safeguard in its environment, analyzed with reference to the likely contribution to protecting electronic protected health information (ePHI). Then, as applicable, it must either implement the specification, or — if implementing it is not reasonable and appropriate — document why it would not be reasonable and appropriate and implement an equivalent alternative measure if one is reasonable and appropriate.
Required vs. addressable, side by side
| Required | Addressable | |
|---|---|---|
| Must you act? | Yes | Yes |
| Can you skip it? | No | No — you can only substitute or, in narrow cases, justify not implementing |
| Assessment step | Not applicable | Mandatory: is it reasonable and appropriate here? |
| Documentation | Document the implementation | Document the assessment, the rationale, and any alternative |
| Alternative permitted? | No | Yes, if reasonable and appropriate |
| Applies to the standard itself? | No — every standard is mandatory regardless of how its specifications are labeled | |
That last row is the one people miss. Standards and implementation specifications are different things. The standards in 164.308, 164.310, 164.312, 164.314 and 164.316 are all mandatory. "Addressable" only ever describes an implementation specification sitting underneath a standard — a suggested method of satisfying an obligation you already have.
The three legitimate paths for an addressable specification
- Implement it as written. You assessed it, it is reasonable and appropriate, you did it. Document the decision and the implementation. This is the cleanest path and the right one most of the time.
- Implement an equivalent alternative. The specification is not reasonable and appropriate in your environment, but the underlying goal still is. Document why the specification does not fit, then deploy a different control that accomplishes the purpose of the standard. Document that too.
- Implement nothing, and document why. The narrowest path. Available only where neither the specification nor any alternative is reasonable and appropriate, judged against the likely contribution to protecting ePHI. You still owe a written rationale. "It was expensive" or "our vendor does not support it" will not carry the argument on its own.
Notice what is absent from that list: a fourth path where you read the word "addressable," conclude it is discretionary, and move on without a record. That path does not exist in the regulation.
Which specifications are addressable?
The labels are printed directly in the regulation text. A few of the most consequential examples:
| Specification | Citation | Label |
|---|---|---|
| Risk analysis | 164.308(a)(1)(ii)(A) | Required |
| Risk management | 164.308(a)(1)(ii)(B) | Required |
| Data backup plan | 164.308(a)(7)(ii)(A) | Required |
| Disaster recovery plan | 164.308(a)(7)(ii)(B) | Required |
| Testing and revision procedures | 164.308(a)(7)(ii)(D) | Addressable |
| Unique user identification | 164.312(a)(2)(i) | Required |
| Emergency access procedure | 164.312(a)(2)(ii) | Required |
| Automatic logoff | 164.312(a)(2)(iii) | Addressable |
| Encryption and decryption (at rest) | 164.312(a)(2)(iv) | Addressable |
| Encryption (in transmission) | 164.312(e)(2)(ii) | Addressable |
Encryption is the specification that causes the most trouble, precisely because it is addressable. Addressable encryption does not mean "encryption is optional." It means you must assess whether encrypting ePHI is reasonable and appropriate — and for most organizations handling ePHI on modern systems, where strong encryption is inexpensive and built into the platforms they already own, that assessment is very difficult to lose. If you decline to encrypt, you are betting that a regulator will agree the decision was reasonable, and you are betting it in writing.
The flexibility factors you must weigh
The Security Rule is deliberately scalable, and 164.306(b) tells you what to weigh when deciding which security measures to use:
- The size, complexity, and capabilities of the entity.
- Its technical infrastructure, hardware, and software security capabilities.
- The costs of security measures.
- The probability and criticality of potential risks to ePHI.
Cost is on the list. It is not, however, alone on the list, and it does not sit above the others. A solo practice and a multi-state health plan can reach different defensible conclusions about the same addressable specification. Neither can reach a defensible conclusion without doing the analysis.
Documenting the decision
For addressable specifications, the documentation is the compliance artifact. If you implemented the specification, your record shows what you did. If you did not, your record has to carry the entire weight of the decision. A usable entry answers:
- Which specification, by citation.
- What you assessed, and what you found — tied back to your risk analysis, not written in the abstract.
- Why the specification is or is not reasonable and appropriate here, referencing the 164.306(b) factors.
- What alternative measure you implemented instead, and why it achieves the purpose of the standard.
- Who decided, when, and when it will be revisited.
Under 164.316, Security Rule documentation must be retained for six years from the later of the date it was created or the date it was last in effect, and it must be reviewed and updated as your environment changes. An addressable-specification rationale written five years ago against an infrastructure you no longer run is not a live document.
Common mistakes
| Mistake | Correction |
|---|---|
| Reading "addressable" as "optional" | It means "assess, then implement, substitute, or justify in writing" |
| Skipping the written rationale | The rationale is expressly required by 164.306(d)(3) |
| Treating a whole standard as addressable | Standards are always mandatory; only specifications carry the label |
| Deciding once and never revisiting | 164.306(e) requires review and modification as needed |
| Justifying on cost alone | Cost is one of four factors, weighed against risk to ePHI |
How the proposed updates would change this
In December 2024, HHS's Office for Civil Rights issued a Notice of Proposed Rulemaking that would substantially modify the Security Rule, including proposals that would remove much of the required/addressable distinction and make specifications mandatory with limited exceptions. It is important to be precise about status: this is a proposal, not law. HHS states that while the Department is undertaking this rulemaking, the current Security Rule remains in effect. There is no compliance deadline attached to the proposal, because the proposal has not been finalized.
The practical read for a compliance team: keep operating under the required/addressable framework as it exists today, and treat the proposal as a signal about where scrutiny is heading. Organizations that have been using "addressable" as a reason to defer encryption or multi-factor authentication have the most to reconsider — not because a new rule binds them, but because the analysis the current rule already demands rarely supports that deferral.
The bottom line
Required means do it. Addressable means assess it, then do it, replace it with something equivalent, or write down exactly why neither is reasonable and appropriate. Every standard in the Security Rule is mandatory; the labels only describe how much latitude you have in the method. If your compliance file contains an addressable specification with no implementation and no rationale, you do not have flexibility — you have a gap.
Common questions
Is an addressable implementation specification optional?
No. HHS states directly that the addressable designation does not mean a specification is optional. It means you must assess whether the specification is reasonable and appropriate for your environment, then either implement it, implement an equivalent alternative measure, or document why neither is reasonable and appropriate.
Is encryption required under the HIPAA Security Rule?
Encryption is an addressable implementation specification, both for ePHI at rest (45 CFR 164.312(a)(2)(iv)) and in transmission (164.312(e)(2)(ii)). That means it is not automatically mandatory, but you must assess it and, if you do not implement it, document why it is not reasonable and appropriate and adopt an equivalent alternative where one is.
What happens if I do not document my decision on an addressable specification?
The documentation is the compliance artifact. 45 CFR 164.306(d)(3) expressly requires a written rationale when an addressable specification is not implemented, and 164.316 requires Security Rule documentation to be retained for six years from the later of its creation or the date it was last in effect. An undocumented decision is functionally indistinguishable from no decision.
Do the proposed 2024 Security Rule updates eliminate addressable specifications?
The HHS Office for Civil Rights proposed changes along those lines in a Notice of Proposed Rulemaking issued December 27, 2024, but that rule is a proposal and has not been finalized. HHS states that the current Security Rule remains in effect while the rulemaking proceeds, and no compliance deadline exists for the proposal.