HIPAA addressable vs required: addressable does not mean optional

In the HIPAA Security Rule, addressable does not mean optional. You must assess whether each addressable specification is reasonable and appropriate for your environment, then implement it, or document why it is not and put an equivalent alternative in place if one is reasonable. Required specifications must always be implemented.

What the rule text says

Section 164.306(d) separates implementation specifications into required and addressable. For required ones, you implement them. For addressable ones, you must assess whether the specification is a reasonable and appropriate safeguard in your environment, based on its likely contribution to protecting electronic PHI. Then you either implement it if reasonable and appropriate, or, if not, document why and implement an equivalent alternative measure if reasonable and appropriate.

So there are three outcomes: implement, implement an alternative, or document that neither fits. The documentation is the part auditors read.

Which ones are addressable

Examples from 164.312 and 164.308:

• Automatic logoff and encryption and decryption of stored ePHI (access control).
• Mechanism to authenticate ePHI (integrity).
• Integrity controls and encryption for ePHI in transmission.
• Authorization and supervision, workforce clearance and termination procedures.
• Security reminders, protection from malicious software, log-in monitoring and password management.
• Testing and revision of contingency plans, and applications and data criticality analysis.

And some that are required: unique user identification, emergency access procedure, risk analysis, risk management, sanction policy, information system activity review, response and reporting for incidents, data backup, disaster recovery and emergency mode operation plans.

Why "we skipped it" rarely survives

Take encryption of stored ePHI. If you decide it is not reasonable for a specific system, you need a written reason tied to your risk analysis and an alternative, such as physical protections or compensating access controls. A blank is not an answer. In practice, for cloud and mobile workloads, encryption is cheap enough that the documented reason to skip it is hard to write.

Note the scope. This describes the rule text as it stands in the version fetched for this article. A 2025 federal proposal would change how the rule treats addressable specifications, so check the current status of that rulemaking before you rely on the distinction in a policy. Our post on the 2025 proposed rule covers it.

A simple assessment record

For each addressable specification, record:

1. The system or data set in scope.
2. The risk it addresses, linked to your risk analysis.
3. The decision: implemented, alternative, or not reasonable.
4. The reason, in a sentence or two.
5. The owner and the review date.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• 45 CFR 164.306, security standards general rules
• 45 CFR 164.312, technical safeguards
• 45 CFR 164.308, administrative safeguards

Last reviewed: 19 October 2026.