Posts Tagged ‘email encryption’

If you’re involved in the healthcare field, you may have wondered what HIPAA’s exact requirements are when it comes to email encryption. Understandably, not too many people are willing to read the 115 pages of the simplified regulation text, so the question tends to go unanswered.

The good news is that we’ve gotten someone to do it for you. They’ve trawled through the long and arduous document to pick out the exact HIPAA regulations concerning email encryption.

We’ve gone through and found out what the text actually says, as well as conducted some analysis to help you figure out just how your organization can comply with these requirements.

What Do the Regulations Actually Say?

There are a few different segments of the security rule which are pertinent to email encryption. The first one is section 164.306 Security standards: General rules:

(a) General requirements. Covered entities and business associates must do the following:

(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.

(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.

(3) Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part.

(4) Ensure compliance with this subpart by its workforce.

Let’s unpack some of these terms a bit:

Covered entity – As a simplification, a covered entity is essentially any healthcare-related organization that deals with data.

Business associate – A business associate (BA) is a person or organization that a covered entity shares electronic protected health information (ePHI) with. This must be done under a business associates agreement (BAA)

Electronic protected health information (ePHI) – This is basically any digital information that is both “individually identifying” and contains “protected health information”. “Individually identifying” information includes names, contact details, social security numbers and much more. “Protected health information” is any information related to a patient’s health, treatment or payment. Check out our article on ePHI for the specifics.

So let’s summarize things a little bit. Under the Security Rule, organizations in the healthcare field and those that deal with their sensitive data are obligated to protect it.

Let’s wade a little bit further into the text. It specifically talks about encryption in section 164.312 Technical safeguards:

Notice how it says “addressable”? HIPAA has two different specifications when it comes to implementation, “required” and “addressable”. “Required” means that a certain mechanism must be in place for compliance.

“Addressable” means that there is flexibility in the mechanisms that can be used. This isn’t particularly specific, but it’s important to be aware that HIPAA is intentionally vague and technologically agnostic. This gives organizations the flexibility they need to come up with the best security measures for their own unique situation. It is not an excuse to be lax about security.

Are Encryption & Decryption Required?

At this stage, you may be thinking that you have found a loophole and you don’t technically have to use encryption. This assumption is kind of correct–nowhere in the HIPAA documentation does it specify that encryption and decryption must be used.

But unfortunately, things aren’t that simple. Let’s return to section 164.306, where it states that covered entities and business associates must:

(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.

This time, we’ve put different terms in bold. So, while HIPAA does not state that covered entities have to use encryption, it does say that they need to ensure the confidentiality of any ePHI that is created, received, maintained or transmitted.

The big question is, “If you aren’t going to use encryption, what techniques are you going to use to guarantee confidentiality instead?” Will you put all of the data on flash drives, then lock them in metal boxes for storage and transit?

Sure, the text says that you don’t have to use encryption, but given the other requirements stated in the HIPAA documentation, encryption is the only reasonable solution.

When it comes to encryption, the HIPAA legislators are kind of like a parent who takes their child to a store, promising them that they can eat anything that they want. The child’s eyes light up with excitement, imagining all of the candy that they will be gobbling down in just a few moments

When they arrive, the child’s heart sinks – they are at the fruit store. Sure, they can have anything they want, but the only thing around them is fruit.

You don’t technically have to use encryption under HIPAA, but it’s pretty much the only thing on offer.

How Should You Use Encryption to Protect Email?

Since the HIPAA text doesn’t include any encryption requirements, the documentation isn’t particularly helpful for those organizations that want to be both compliant and secure. Thankfully, the National Institute of Standards and Technology (NIST), another government agency, has released its own documentation about email and how to keep it secure.

The guide is extensive, but some of the key takeaways are:

Appropriate authentication and access control measures need to be in place.

TLS should be used to connect to the email server.

Mechanisms such as PGP or S/MIME should be used to encrypt sensitive data (such as ePHI).

If you don’t feel like reading such an exhausting document, you can turn to a HIPAA compliance specialist like LuxSci instead. Our HIPAA-Compliant Email includes all of these features and much more, helping your organization stay both secure and compliant.

Email is the most convenient way of communicating with patients. HIPAA permits email communications but expects covered entities to take the necessary precautions to protect the integrity and security of patient health information shared via email.

HIPAA email rules

HIPAA email rules require covered entities to implement controls and security to restrict access to PHI, ensure the integrity of PHI at rest, safeguard PHI against unauthorized access during transit and ensure message accountability. The language of the HIPAA Security Rule is important as some standards are ‘required’ and some ‘addressable’. Required rules must be mandatorily followed while you may or may not implement addressable rules if a thorough risk analysis concludes that implementation is not reasonable. An implementation specification deemed unreasonable can be replaced by an equivalent alternative.

Any decision you take regarding addressable specifications needs to be documented in writing. That means you cannot simply “opt out” of addressable specifications.

facebook has a great feature where you can have all facebook notifications sent to you using PGP-encrypted email. This is great if you want to be sure that noone except for you can read these messages.

We have long held that leaving it to each sender/employee to properly enable encryption for each sensitive message (a.k.a “Opt In Encryption”) is too risky. Why? Any mistake or oversight immediately equals a breach and liability.

Instead, LuxSci has always promoted use of “Opt Out Encryption,” in which the account default is to encrypt everything unless the sender specifically indicates that the message is not sensitive. The risk with Opt Out Encryption is very much smaller than with Opt In. (See Opt-In Email Encryption is too Risky for HIPAA Compliance).

The problem is: many companies use Opt In Encryption because it is convenient when sending messages without sensitive information — you just send these messages “as usual,” without forethought. These companies are trading large risks in return for conveniences.

LuxSci has solved the “Opt In vs. Opt Out” conundrum with its SecureLine Email Encryption Service. You could say that SecureLine enables the “Next Generation” of Opt In Email Encryption — combining both usability and security.

There are many ways to encrypt email, TLS being the simplest and most seamless. With SMTP TLS (the use of TLS encryption to secure the “SMTP Protocol” used for the transmission of email between computers), messages are transported between the sender, recipient, and all servers securely. TLS is a layer that fits seamlessly over “regular email” to ensure transport email encryption when supported by both the message sender and the recipient. With SMTP TLS, sending a secure message works and feels the same as sending any other email message.

“It just works.” That is the ideal combination of security and usability.

However, SMTP TLS only solves the problem of email encryption during transmission from sender to recipient. It does not in any way secure an email message while it is at rest, whether while in the sender’s “sent email” folder, queued or backed up on the email servers of the sender or recipient, or saved and stored in the email recipient’s folders. While SMTP TLS is really easy to use, it is important to consider if use of SMTP TLS alone is “good enough” for companies to comply with the many U.S. government laws which apply to email.

When it is “good enough,” organizations may opt for the seamless simplicity of TLS over the added complexity of other modes of secure email communication.

In this article, we shall examine the security afforded by SMTP TLS and compare that to other modes of email encryption such as PGP, S/MIME, and Escrow (i.e. picking up your message from a secure web portal). We shall then look at many of the most important laws (HIPAA, GLBA, Sarbanes-Oxley, SB1386, NASD 3010, FRCP, SEX 17a-4, FINRA, and PCI DSS) to see what is said or implied about using “Just TLS” vs. other, stronger forms of encryption. We won’t spend a lot of time explaining each law; if you are interested there are innumerable articles on the web for that. We focus only on what they say or imply about encryption for email transmission and storage.

The short answer is that many of these laws outline various requirements for email storage, archival, and retrieval for legal proceedings without specifically delineating requirements for the encryption of those messages. So, use of TLS is just fine with respect to those.

For PCI compliance, avoid email if at all possible; however, if you must use email for sending credit card data, “Just TLS” is not sufficient.

For the rest, the burden ends up being on each individual organization to decide for itself the level of encryption appropriate to protect sensitive data. Use of encryption methods that provide protection for data at rest can mitigate liability in the case of a breach, but they are not mandated. There are also ways of protecting data at rest that do not involve more onerous methods of email encryption.

Indeed, your internal risk analysis may find that “Just TLS” is best in some cases and methods that provide explicit data-at-rest email encryption are warranted in others.