"Addressable" is the most misread word in the HIPAA Security Rule. Teams new to HIPAA often read it as "optional." Teams that have been through an investigation tend to read it as "required, with paperwork." The regulation says something more precise than either.
Encryption is where the misreading costs most. It is addressable in the text, it is expected in practice, and it decides whether a lost laptop is a reportable breach. This article explains what addressable means under 45 CFR §164.306(d), where encryption appears in the rule, how it connects to breach notification, and how to document the decision so it survives review.
What addressable means in the regulation
Each Security Rule standard comes with implementation specifications, and each specification is labeled required or addressable. Required means you implement it. Addressable triggers a process set out in §164.306(d)(3). You must assess whether the specification is a reasonable and appropriate safeguard in your environment, considering its likely contribution to protecting ePHI. Then:
If it is reasonable and appropriate, implement it.
If it is not, document why, and implement an equivalent alternative measure if one is reasonable and appropriate.
That leaves three possible outcomes: implement the specification, implement an alternative, or implement neither. All three require a written record of the reasoning. The third is rarely defensible, because the standard behind the specification still applies.
The assessment draws on the factors in §164.306(b)(2): your size, complexity, and capabilities; your technical infrastructure, hardware, and software security capabilities; the costs of security measures; and the probability and criticality of potential risks to ePHI. Cost is a legitimate factor. It is not a trump card when the risk is high and the safeguard is cheap.
HHS has said in its Security Rule guidance that addressable does not mean optional. The flexibility is in how you protect ePHI, not in whether you do.
Where encryption sits in the rule
Encryption appears twice, both times as an addressable specification under a required standard:
Encryption and decryption, §164.312(a)(2)(iv). Under the access control standard. You implement a mechanism to encrypt and decrypt ePHI. In practice, this is where encryption at rest is assessed.
Encryption, §164.312(e)(2)(ii). Under the transmission security standard at §164.312(e)(1). You implement a mechanism to encrypt ePHI whenever deemed appropriate. This covers encryption in transit.
The detail that matters is the hierarchy. The transmission security standard requires you to guard against unauthorized access to ePHI sent over an electronic communications network. That obligation does not go away if you decide encryption is not reasonable for some path. You still have to protect it some other way.
The rule also defines the term. Section 164.304 describes encryption as an algorithmic process that transforms data into a form with a low probability of assigning meaning without a confidential process or key. Encoding, obfuscation, or a password on a spreadsheet does not meet that description.
Why encryption is rarely a defensible "no"
Run the §164.306(b)(2) factors for a SaaS company on a major cloud provider, and they point one way. Storage and database encryption at rest is usually a configuration setting. TLS is standard on every modern framework and load balancer. Full-disk encryption ships with every mainstream laptop operating system. The cost is low, the capability is present, and the risk of losing ePHI on the internet is high.
A documented "not reasonable and appropriate" decision for encryption in that environment would be hard to defend to an investigator or to a customer's security team. Expect to encrypt laptops, databases, object storage, backups, and every network path that carries ePHI.
Where the alternative path is legitimate, it tends to involve equipment you cannot change. Say a hypothetical clinic runs a device that stores ePHI and cannot support encryption. A reasonable response documents the limitation, isolates the device on a restricted network segment, limits physical access, and sets a replacement date. That is an equivalent alternative measure with a record behind it.
Encryption and the breach notification safe harbor
The Breach Notification Rule applies to "unsecured" PHI, defined at §164.402. HHS guidance issued under the HITECH Act specifies encryption and destruction as the methods that render PHI unusable, unreadable, or indecipherable to unauthorized individuals. PHI protected that way is not unsecured, so its loss does not trigger the notification requirements.
The guidance ties valid encryption to NIST publications, including NIST SP 800-111 for storage encryption on end-user devices and NIST SP 800-52 for TLS. It also expects the decryption key to stay protected. A laptop encrypted with a key that was taped to the lid, or compromised with it, does not qualify.
This is why encryption earns its place despite being addressable. It is the one specification whose presence can change the outcome of an incident. The breach notification timelines and thresholds article covers what happens when the safe harbor does not apply.
How to document the decision
An investigator or auditor will ask to see your reasoning, not only your configuration. A complete record follows the same steps for every location:
List where ePHI is stored and transmitted. Start from the asset inventory in your risk analysis. Include laptops, databases, object storage, backups, logs, queues, and integrations with customers.
For each location, record whether it is encrypted. Note the method, where the keys are held, and who can use them.
Where it is not encrypted, record the assessment. Address the §164.306(b)(2) factors, describe the alternative measure, and name who approved the decision.
Link each entry to evidence. Configuration exports, device posture reports, and TLS settings show the control is real.
Revisit on change. New storage, a new integration, or a new vendor reopens the question.
Keep the record for six years. Section 164.316(b)(2)(i) applies to this documentation like any other the rule requires.
Two areas catch teams out. The first is laptops, because one device without full-disk encryption can turn a stolen bag into a reportable breach. The full-disk encryption on every laptop article covers enforcement and evidence. The second is email to patients. HHS has said a covered entity may send ePHI to a patient by unencrypted email if the patient asks for it after being warned of the risk. That is a narrow accommodation for the individual's request, not a general exception, and it belongs in your documentation too.
What the proposed changes would do
In early 2025, HHS published a notice of proposed rulemaking to amend the Security Rule. Among other things, it proposed removing the distinction between required and addressable specifications, and making encryption of ePHI at rest and in transit required, with limited exceptions.
Those are proposals, not current law. Until a final rule is published and takes effect, the addressable framework above is the rule you are measured against. Confirm the current status before you rely on either version, and check the HIPAA framework overview for how the rule is structured today.
The practical point is the same either way. If you already encrypt everywhere ePHI lives and moves, and you can show it, a change from addressable to required costs you very little.
How TrustLynce helps
TrustLynce's device agent reports disk encryption status on every workforce laptop, and continuous monitoring flags cloud storage without encryption enabled and routes it to the owner. The records give you the per-location evidence your encryption decisions need.