Understand Potential Pitfalls of Reliance on End-to-End TLS Encryption for HIPAA / FSA and Other Regulated Private Email
One of our insurance broker clients “BROKER” was recently asked to rely on end-to-end TLS encryption when sending, in this case HIPAA regulated information from sender insurance broker to recipient insurance carrier “CARRIER”.
They reported that they were told by the insurance carrier IT department, “TLS communications exist between your email service provider “ISP” email server and our email server which means we virtually have a 100% secure channel for both inbound and outbound email between our organizations. My guess is that a VPN exists between your email server and your ISP server which means we have a 100% secure email channel between our organizations. Therefore, I am requesting all email sent to our organization from your organization including any that contains protected health information (PHI) continue to be sent as normal email.”
This is an interesting comment, but opens the sender up to liability – and note, a breach in communication from sender to recipient would cause financial harm to the sender – not the recipient who in this case is providing the suggestion.
Consider the following:
1. Even if the recipient carrier assumptions are correct, and if the sender broker’s organization is confident that they have an encrypted messaging link to their third-party email service provider ISP, and they have an encrypted email route to the recipient insurance carrier, it is the sender broker who is exposed to the exact risk that the Council of Insurance Agents and Brokers (CIAB) is recommending protecting against (described more below).
2. Essentially, with the TLS system that is described by the insurance carrier above, in the case of a data breach, all parties would be susceptible to a fine – sender insurance broker, recipient insurance carrier, and the email service provider. Why? If there was a scenario where one of many servers en route for some reason had the encryption turned off, or if there was another type of data breach at the email service provider level, or at the insurance carrier AFTER delivery of the information, the sender broker could be blamed and fined. This is because with the system described above, no one would have any proof that in fact the email in question was transmitted encrypted end-to-end. Simple server logs are easily changed if they can even be found after the fact. Further, you cannot assume that if one message went through one server system / channel that another message went through the same. You cannot easily prove the content of the particular message that you would claim to have been transmitted encrypted and associated with a particular server log.
3. Now, consider the Council of Insurance Agents and Brokers (CIAB) top level evaluation criteria in their recommendations.
When considering data breach, we are considering two points, a data breach when the data is (a) within the sender’s control (i.e. where the email is sent from sender to recipient - “security of sender-controlled data”); and (b) after the data leaves the sender’s control (i.e. if there is a data breach on the recipient’s system or after the recipient forwards the information on to others - “downstream data breach”).
4. In reference to protection from downstream data breach, CIAB cites as the most important criteria, as having “Auditable proof of compliance”.
CIAB goes on to state, “It seems that only RPost has a robust mechanism in place to provide an auditable record of precisely what message content (body text and attachments) was in fact sent and received in an encrypted manner to each intended recipient. This is important because, in the case where there is a data breach after the email has reached the recipient (in the recipient’s environment, or after they have passed the information along to others), the sender will need to retain information to prove that the breach did not happen “on their watch” – that they in fact complied with the data security requirements and delivered the information in a compliant, encrypted manner.
RPost addresses this issue by having built its encrypted email service on top of its core Registered Email® service, which The Council endorsed in 2004 as the best way to prove email content, time, and delivery with court-admissible records. By doing this, RPost provides not only effective encryption, but also the most robust proof and record of compliance with the rules of regulators.
Voltage, another encryption provider, while having the benefit of encrypted delivery direct to the recipients’ inbox – like RPost -- does not provide any mechanism to prove what email content was sent and received encrypted. Voltage support confirms that there is no proof record and suggests that this is an ‘infrastructure’ issue and not part of their encryption system.
5. What happens if the insurance carrier, which requests that you transmit your information in a normal manner without message level encryption, was involved in a data breach containing data that originated from the sender broker?
If they are going to recommend that the sender send HIPAA regulated messages in an unencrypted manner and are claiming that they have sufficiently studied the data encryption procedures of the ISP and the reliability of the ISPs encryption, then they should be willing to fully indemnify the sender broker against any fines related to data breach from correspondence from sender broker to recipient carrier. You might request this next time the recipient dictates that the sender send unencrypted message relying solely on TLS connection of the ISP, without any proof of TLS transmission for each message.
6. However, this still presents a problem – having a policy of sending unencrypted to the insurance carrier (relying on simple TLS encryption) due to their indemnification of sender broker (assuming they provide one to sender), would likely open sender broker to exposure that someone mistakenly transmits email unencrypted to other insurance carriers mistakenly assuming those carriers also have encrypted email connections pre-set with the ISP.
7. Again, and most importantly as pointed out by CIAB email encryption buyer’s guide, how would you protect your firm – your senders – against claims of a breach that happened downstream? If you could not demonstrate irrefutably that the breach did not happen ‘on your watch’ then you would be likely party to the fines.
We recommend that insurance broker senders – or any senders -- send their messages that contain protected health information or other regulated private content via RPost’s SecuRmail service, which provides auditable proof of compliance with the data encryption laws. This RPost service provides desktop-to-desktop encryption sent via Registered Email message for proof of encrypted delivery end-to-end. RPost does offer some TLS options but in these cases, RPost still transmits TLS encrypted via Registered Email message, so you still receive verifiable proof of sender encrypted delivery to recipient – proof that will protect you in case of a data breach after receipt – after the email has left your control. This proof is on a message by message level and can be independently verified years later. No other service will protect you from liability in the manner the RPost service does.
