AegisAI Perspectives · 038
Email encryption is addressable under HIPAA, so each entity assesses it per email flow, then encrypts or records why not and uses an alternative measure.
Under 45 CFR 164.306(d)(3), addressable means you must assess whether email encryption is reasonable and appropriate, then implement it, or document why not and implement an equivalent alternative45. It does not mean optional. AegisAI reads each outbound email to see who sends sensitive data to whom and whether that is normal, then applies your policy19.
The encryption line sits at 45 CFR 164.312(e)(2)(ii), labelled Addressable: encrypt electronic protected health information (ePHI) "whenever deemed appropriate"1. It belongs to the transmission security standard, which covers ePHI sent over an electronic communications network2. For the full set of healthcare email controls, read What does email security for healthcare need to cover?
The test takes your risk analysis as its input and gives a written decision per email flow as its output. Work through it in this order.
Open 164.312(e). The standard is transmission security; its two implementation specifications, integrity controls and encryption, are both Addressable3.
Risk analysis at 164.308(a)(1)(ii)(A) is Required: an accurate and thorough assessment of the risks to ePHI10. List every email flow that carries ePHI from it.
Section 164.306(b)(2) names them: size and capabilities; technical infrastructure; cost; the probability and criticality of risks to ePHI6.
Is encryption a reasonable and appropriate safeguard in your environment, judged by its likely contribution to protecting ePHI?
The rule says implement the specification if reasonable and appropriate. Encrypt that flow.
If encryption is not reasonable and appropriate, record why. Then implement an equivalent alternative measure if reasonable and appropriate. The rule requires a written record of any documented assessment7.
Retain it for 6 years from creation or from when it last applied, whichever is later8. Review it after environmental or operational changes9.
Each flow gets its own row in the record, because the assessment is made per specification in your environment. The table shows what to capture.
| Email flow with ePHI | What the assessment weighs | Allowed outcomes under 164.306(d)(3) | What to keep on file |
|---|---|---|---|
| Referral letter to another practice | Who receives it, the network it crosses, cost of encrypting | Encrypt, or document why not and use an equivalent alternative | The decision, the reason, the date |
| Lab result to a patient | Patient's means of receipt, risk if intercepted | Encrypt, or document why not and use an equivalent alternative | The decision, the alternative chosen, the review date |
| Billing file to a business associate | Volume of ePHI, criticality of a leak | Encrypt, or document why not and use an equivalent alternative | The decision and who signed it |
| Internal email between staff | Whether it leaves your network | Encrypt, or document why not and use an equivalent alternative | The decision and the network boundary used |
No row offers "skip it". The rule gives two branches. One is to implement. The other is to document the reason and use an alternative.
The Outbound Email DLP product reads who sends sensitive data to whom and whether that is normal, then applies your policy, checking each email before it is delivered. Seven agents look at the content and attachment of each message20. They also look at the recipient and at the sender's habits. It is in early access: a policy runs in audit on live outbound mail, then is raised to alert21. Actions depend on the platform, and pre-delivery blocking is not available on Google Workspace.
A short record per flow is enough to show the test was run. The box shows one.
Illustrative example, figures are fictional. Harbor Street Clinic has 22 staff and sends about 150 lab result emails to patients a month. Its risk analysis lists the flow. Weighing its size, its email platform and cost, it finds encryption reasonable and appropriate for referral letters and encrypts them. For lab results, it writes that most patients cannot open encrypted mail, then sends a portal notice with no ePHI in the body as its equivalent alternative. The clinic dates and signs the record and keeps it for 6 years.
Because the rule leaves you two branches and neither is "do nothing". You implement encryption where it is reasonable and appropriate, or you document why not and implement an equivalent alternative. Risk analysis, by contrast, is labelled Required.
HHS said this plainly in its 2025 proposal. Some regulated entities, it wrote, proceed as if an addressable specification is optional, and that interpretation is incorrect13. The sibling question, whether the rule requires encryption at all, is answered in Does the HIPAA Security Rule require email encryption?
Assess it with the four 164.306(b)(2) factors, per email flow, against your risk analysis. The factors are size and capabilities; technical infrastructure; cost; the probability and criticality of risks to ePHI. The question the rule asks is narrow: is encryption a reasonable and appropriate safeguard in your environment, judged by its likely contribution to protecting ePHI?
Write the answer for each flow. A required risk management step then follows: implement measures that reduce risks to a reasonable and appropriate level11.
The trigger is ePHI moving over an electronic communications network. The transmission security standard exists to guard against unauthorized access to ePHI in that state. An email that carries ePHI in its body or an attachment across a network falls under it. Integrity controls sit under the same standard and are also Addressable.
Your risk analysis decides how likely and how damaging each case is. Those two answers feed the probability and criticality factor.
Evaluate a solution by which specification it helps you meet and what record it leaves. Map each feature to a line of the rule: transmission security, integrity controls, encryption. Then ask what it writes down, because the record is part of compliance.
Ask three questions of any product. Which flows does it cover? Can its settings be exported for the 6 year record? Does it support the periodic evaluation the rule requires after operational changes12?
The rule text sets the minimum, and OCR, the HHS office behind the 2025 proposal, calls treating addressable as optional incorrect. For each addressable specification you do not implement, keep a written record of why and of the equivalent alternative. Keep it for 6 years. Review it when your environment or operations change.
NIST SP 800-66 Revision 2, published February 2024, is the federal guide to implementing the Security Rule for entities of all sizes18. Use it to structure the record.
Track three numbers.
It means assess, then act. Decide whether encryption is reasonable and appropriate for each email flow. If yes, encrypt. Otherwise, document why it is not, then implement an equivalent alternative if reasonable and appropriate. It is not a choice to do nothing.
Not yet. HHS proposed removing the distinction between addressable and required in its 2025 notice of proposed rulemaking. That rule is still proposed: the OMB website shows final action due in July 2027. Today's addressable test applies until a final rule takes effect.
Proposed 164.312(b)(2) would require encryption of all ePHI at rest and in transit, with documented exceptions. OCR published it on January 6, 2025, and received almost 5,000 comments. It is a proposal, not final text.
Under the 2025 proposal, yes: one exception covers an individual who asks to receive ePHI unencrypted and has been informed of the risks. That exception is proposed text. Under today's rule, the patient email flow goes through the addressable test like any other.
Six years from the date it was created or the date it last applied, whichever is later. Review it when your environment or operations change.
