Key takeaways
- The Security Rule's transmission security standard (45 CFR 164.312(e)) requires you to guard against unauthorized access to ePHI sent over a network. Encryption in transit is an addressable specification: you must implement it if reasonable and appropriate, or document why not and use an equivalent measure.
- Addressable does not mean optional. Under 45 CFR 164.306(d)(3), you must assess each addressable specification, then implement it or document why it is not reasonable and implement an equivalent alternative.
- A patient may choose to receive information by plain, unencrypted email. HHS said in the 2013 Omnibus Rule that a covered entity may do this if it has told the individual about the risk and the individual still prefers it. The covered entity is then not responsible for unauthorized access in transit at the patient's request.
- A provider must accommodate reasonable requests to communicate by alternative means or at alternative locations (45 CFR 164.522(b)), and may not demand an explanation.
- Encryption also matters for breaches. PHI that is made unusable, unreadable or indecipherable to unauthorized persons by an HHS-specified method is not "unsecured" PHI, which changes whether a breach notice is required.
- An email service that stores or processes PHI for you is generally a business associate and needs a signed BAA. A pure conduit is a narrow exception.
The short answer on email and HIPAA
Practices ask the same question every month: can we email patients? The answer is yes. HIPAA does not prohibit email, and it does not set a single required product. What it does is ask you to protect electronic protected health information (ePHI), to decide how, and to be able to show your reasoning. The decisions are yours, but they must be written down.
This article follows the rule text. We read 45 CFR 164.312 and 164.306 on the eCFR, the breach definition in 164.402, the confidential communications rule in 164.522, and the HHS preamble to the 2013 Omnibus Rule. HHS also publishes FAQs on email with patients, but its website did not open for our review, so we rely on the regulation and the preamble instead.
What the Security Rule says about email
The technical safeguards in 45 CFR 164.312 apply to covered entities and business associates. Four standards touch email directly.
- Access control (164.312(a)). Limit access to ePHI to authorized people and programs. Unique user identification and an emergency access procedure are required specifications. Automatic logoff and encryption and decryption of stored ePHI are addressable.
- Audit controls (164.312(b)). Use mechanisms that record and examine activity in systems that contain ePHI. In an email system, that means logs you can review.
- Integrity (164.312(c)). Protect ePHI from improper alteration or destruction. An authentication mechanism to confirm that ePHI has not been altered is addressable.
- Person or entity authentication (164.312(d)). Verify that the person or entity seeking access is the one claimed. Multi-factor sign-in on mailboxes is the usual way to meet this.
- Transmission security (164.312(e)). Guard against unauthorized access to ePHI sent over an electronic network. Integrity controls and encryption are addressable specifications.
Email is a network transmission, so the transmission security standard is the heart of it. Encryption of ePHI in transmission is an addressable implementation specification. The rule asks for encryption of ePHI in transmission when deemed appropriate. Most practices find it appropriate for almost all email that carries patient information, because the cost is low and the exposure is high.
What "addressable" really means
Addressable is the most misread word in the rule. Under 164.306(d)(3), an entity must assess whether the specification is a reasonable and appropriate safeguard in its environment, considering its likely contribution to protecting ePHI. If it is reasonable and appropriate, the entity must implement it. If it is not, the entity must document why, and implement an equivalent alternative measure if reasonable and appropriate. Skipping the analysis and the paper trail is the failure, not the choice itself.
The rule also gives flexibility of approach (164.306(b)). You may choose any security measures that let you reasonably and appropriately implement the standards, taking into account your size, complexity and capabilities, your technical infrastructure, the cost of the measures, and the probability and criticality of the risks. A solo practitioner and a hospital system may reach different answers. Both must reach them in writing, after a risk analysis.
The picture may change. HHS proposed a major update to the Security Rule in January 2025. It has not been finalized as of this review, and the federal agenda lists final action for July 2027. Our article on the HIPAA Security Rule tracks the proposal. Until a final rule is published, the current text governs, and a firm that already encrypts will be ready either way.
Why encryption matters even if the rule says addressable
Breach notification is the practical reason. Under 45 CFR 164.402, a breach is an impermissible acquisition, access, use or disclosure of PHI that is presumed to be a breach unless you show a low probability that the PHI has been compromised, using a risk assessment of at least four factors: the nature and extent of the PHI, who the unauthorized person was, whether the PHI was actually acquired or viewed, and how far the risk has been mitigated. The notification duties apply to "unsecured" PHI, which the regulation defines as PHI not rendered unusable, unreadable or indecipherable to unauthorized persons through a technology or methodology specified by the Secretary in guidance. Properly encrypted data can therefore stay outside the notification rules when a device or message is lost. Unencrypted data cannot.
The 2013 preamble adds a sobering example: hacking into an unencrypted database and theft of unsecured PHI would in almost all cases constitute a breach. Email stores are databases. If a mailbox full of patient messages is accessed by an attacker, the question is whether the content was protected and whether you can show it.
When a patient asks for plain email
Patients are allowed to choose convenience. In the preamble to the 2013 Omnibus Rule (78 Federal Register 5566), HHS answered commenters who asked whether covered entities may send unencrypted email. HHS clarified that covered entities are permitted to send individuals unencrypted emails if they have advised the individual of the risk and the individual still prefers unencrypted email. HHS rejected the argument that the duty to warn is too burdensome, calling it a necessary step. It said it does not expect covered entities to educate individuals about encryption technology. Rather, it expects the covered entity to notify the individual that there may be some level of risk that the information in the email could be read by a third party.
If the individual is told and still prefers plain email, HHS said the individual has the right to receive PHI that way, and the covered entity is not responsible for unauthorized access to PHI in transmission to the individual based on the individual's request. The entity is also not responsible for safeguarding information once it has been delivered to the individual.
The right is the patient's. It does not let the practice choose weak email for its own convenience. And it covers messages to that patient, at that patient's request. It does not cover forwarding the same information to a third party, or the practice's own mailbox, where its own safeguards still apply.
A separate rule helps with where and how you reach patients. Under 45 CFR 164.522(b), a health care provider must accommodate reasonable requests to receive communications of PHI by alternative means or at alternative locations. The provider may require the request in writing and may ask about payment arrangements, but may not demand an explanation of why the patient wants it. A patient who asks that messages go to a private email address, or not to a shared household account, is covered here.
Access requests have their own rule. Under 45 CFR 164.524(c)(2)(ii), if a patient asks for an electronic copy of electronic records, the provider must supply it in the requested form and format if it is readily producible, or otherwise in a readable electronic form agreed with the patient. The preamble notes that a patient who does not want a portable media device can opt for an alternative, such as email.
Does your email provider need a BAA?
A vendor that creates, receives, maintains or transmits PHI on your behalf is a business associate, and you need a written agreement before you let it. That includes a hosted email service where your patient messages are stored. We cover this for Microsoft 365, Google Workspace and Amazon Web Services in our article on HIPAA and the cloud.
The Omnibus preamble recognizes a narrow exception. Entities that act as mere conduits for the transport of PHI, without accessing it other than on a random or infrequent basis, are not business associates. HHS contrasted this with entities that manage the exchange of PHI through a network, which have more than random access and fall within the definition. A service that stores and scans your mailboxes is not a conduit. Do not rely on the exception for a mail host.
The same logic applies to add-on tools: an encryption gateway, a spam filter that sees message content, an archive, a secure-message portal, a transcription or AI assistant connected to the inbox. Each one that touches PHI needs a BAA and a place in your risk analysis.
A workable email policy for a practice
- Decide the channel. Use a patient portal or secure message system for clinical content and results. Use ordinary email only for scheduling and general information that does not reveal health details, unless the patient has chosen otherwise.
- Encrypt by default. Require TLS for mail in transit and automatic encryption or a secure-message link for messages that contain PHI. Test that the settings work, rather than assuming.
- Protect the mailbox. Multi-factor authentication for every user, automatic logoff on shared workstations, and mobile devices protected as described in our article on BYOD and remote work.
- Record patient choices. A short form: the risk of plain email, the patient's choice, the address to use, the date. Keep it in the chart.
- Limit what is sent. Send the minimum information needed, check the recipient address before sending, and avoid putting diagnoses in subject lines.
- Sign BAAs for the email host and any tool that sees messages. Keep a list.
- Log and review. Keep audit logs, review them on a schedule, and keep the retention period in line with your records policy.
- Authenticate your domain. SPF, DKIM and DMARC reduce spoofing of your practice's address, which is how many patients are tricked. See our article on email authentication.
- Train staff, and test them with phishing exercises. Wrong-recipient mistakes and phished mailboxes are the common causes of email breaches.
- Document the risk analysis and the addressable decisions, and review them at least once a year and when your email setup changes.
Where NIST fits in
NIST SP 800-66 Revision 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (February 2024), is a practical companion for regulated entities of all sizes. It is guidance, not a requirement, but it organizes the Security Rule's concepts into steps a small practice can follow, and it points to NIST's other publications for technical detail. We opened its publication record for this review; we did not rely on it for any legal statement above.
How Clayton Cybernetics can help
Our team designs and operates secure email for organizations that handle regulated data, including healthcare. We set up transport encryption and message encryption, multi-factor authentication, SPF, DKIM and DMARC, logging and retention, and document the settings so you can show a regulator or payer why you chose them. We can help you prepare the risk analysis, the patient-choice form and the BAA list. Call (305) 404-9404 to review how your practice handles email today.
Sources
- eCFR - 45 CFR 164.312, Technical safeguards
- eCFR - 45 CFR 164.306, Security standards: General rules (flexibility of approach; addressable specifications)
- eCFR - 45 CFR 164.402, Definitions (breach; unsecured protected health information)
- eCFR - 45 CFR 164.522, Rights to request privacy protection (confidential communications)
- eCFR - 45 CFR 164.524, Access of individuals to protected health information
- HHS - Modifications to the HIPAA Privacy, Security, Enforcement and Breach Notification Rules (Omnibus Rule), 78 FR 5566, Jan. 25, 2013 (GovInfo)
- NIST SP 800-66 Rev. 2: Implementing the HIPAA Security Rule - A Cybersecurity Resource Guide (February 2024)
This article is general information, not legal advice. The HHS website blocked our review of its email FAQs, so statements about patient choice come from the Omnibus Rule preamble, which is not a regulation itself. HIPAA also interacts with state law and with your payer and malpractice contracts. Confirm your obligations with your counsel. Last reviewed .
Keep reading
Next · InfrastructureSeparating Global Networks: VRFs, VLANs and VXLAN-EVPN Across DatacentersA multinational rarely wants one flat network. It wants many separate ones: one per region, business unit or regulated workload, sharing the same cables, optics and datacenters. This article explains the building blocks in the order you meet them: VLANs, QinQ, VRFs, VXLAN and EVPN, and what changes when the segments must stretch between datacenters.10 min read- SEC Regulation S-P Amendments: A Practical Checklist for Investment Advisers and Broker-Dealers7 min
- The Florida Information Protection Act: A Breach-Response Checklist for Florida Businesses7 min
Need help with this?
We find out whether everything you run is safe from attackers, then we fix it.
Cybersecurity