I am hosting with a HIPAA compliant hosting company, as we are required to do because of the industry I am in. We have a BAA executed with them, and their responsibility terminates at the application level, meaning they are responsible for maintenance of the operating system. Therefore, they have access to the operating system and system files. We utilize SSL encryption for data in motion through our web server. The hosting provider has access to the operating system, thus they have access to the private key for SSL encryption and decryption.

My question is this: In theory, isn't it possible for a rogue employee at the hosting company to use the private key to decrypt the data in motion? This seems to be a hole in our security policy, but I must not be the only one to encounter this. For instance, Box.net must have the same issue because when you upload to Box, the data is encrypted over SSL, but the certificate is managed by Box. Therefore, they have access to your data. I welcome your thoughts and suggestions on this. Thanks.

3 Answers 3


TL;DR: Any security policy is going to require basic trust of employees and business partners, which should be balanced with controls.

In theory, isn't it possible for a rogue employee at the hosting company to use the private key to decrypt the data in motion?

Yes, it is possible.

This seems to be a hole in our security policy

Not really. You have a business relationship and a BAA with this company. It is a reasonable assumption that they will act responsibly and not attempt to maliciously compromise you given their access. You yourself acknowledge this when you say "rogue employee" - you're not worried about them being bad, you're worried about a bad apple that works for them.

By the same token, aren't you worried about the bad apples that work for you? You should be.

Are there access controls on the key files? Are there activity logs on the server? Do you have access to them? Do you audit them for inappropriate access? These are all things you should do, whether it's your server and your employees or the hosting provider's server and employees.


That depends on how you implemented SSL, Of you employ forward secrecy than your only at risk from a MitM type attack (with the certificates and private keys this is trivial to make and NO POSSIBLE PROTECTION is possible imho.)

The Forward secrecy means that the keys used for the connection (which should be something other than the RSA used for the certificates themselves.)

as @gowenfawr already pointed out. the basic security problem is one of trust. and how that is mitigated (through logging for example).

And if your really worried about this. Host your own server or use an unmanaged server on which you yourself do the maintenance.


Disclaimer - I am not a lawyer!


HIPAA mandates a recurring Risk Assessment exercise that looks at the entire infrastructure supporting the e-PHI and tries to identify, analyze and rate the risks to confidentiality, integrity, and availability of e-PHI (More Information).

A crucial aspect of this entire exercise is - identifying things that you can do to minimize the risks (also called controls). Some examples of possible controls were provided by gowenfawr above.

My 2 cents:-

IF this aspect has been identified as a risk, AND IF the necessary controls are in place (e.g., proper data / log / information sharing & right to audit agreement between the hosting provider and your company, proof of continued compliance of the hosting provider to HIPAA, proper logging, tighter access controls by the hosting provider, periodic access review by the hosting provider, periodic assessment of the risk by your company and timely reporting of the risk to management, etc.), THEN this risk can be addressed and should not pose any problem to e-PHI.

While many security policies address things from a 30,000 ft, and hence should be fool-proof, the underlying processes (e.g., periodic audit, things to escalate, vendor assessments, vendor evaluation criteria, putting up right to audit as a mandatory clause with vendors, etc.) are not always fool-proof, resulting in holes in the overall system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .