Home / Blog / Does HIPAA Require Encryption?

Does HIPAA Require Encryption?

Posted on

One of the most common questions I have fielded in the past two years is, does HIPAA require encryption? The good news is that the answer is simple, yes, encryption is an addressable item under HIPAA. However, that is not the end of the story nor are the answer(s) to surrounding questions as simple as the yes or no. Let’s explore what we have to consider.

Data Primer:

Before you can even ask the question about if or how to encrypt you need to understand what may require encryption by virtue of it being sensitive data. Let’s start with a small primer on data.

In most “compliance” scenarios (PCI-DSS, HIPAA, FISMA etc.) there are really two categories of data. Category one is data that is considered as personally identifiable information (PII), which is data that can identify its association with a single individual. The second category is that which is not personally identifiable. Examples of PII are your name tied to a medical record, or your name tied to even an email address. Examples of data that is not PII is your address by itself, phone number by itself or even a medical record that does not have any name or individually identifiable trait. It is also possible the PII can be de-identified by removing the PII categories.

HIPAA Data Primer:

HIPAA calls PII Protected Health Information (PHI) or in electronic form, ePHI. HIPAA has eighteen categories of data that are considered to be PHI/ePHI. Those eighteen categories are (source).

  1. Names.
  2. All geographic subdivisions smaller than a state, including street address, city, county, precinct, ZIP Code, and their equivalent geographical codes, except for the initial three digits of a ZIP Code if, according to the current publicly available data from the Bureau of the Census:
    1. The geographic unit formed by combining all ZIP Codes with the same three initial digits contains more than 20,000 people.
    2. The initial three digits of a ZIP Code for all such geographic units containing 20,000 or fewer people are changed to 000.
  3. All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older.
  4. Telephone numbers.
  5. Facsimile numbers.
  6. Electronic mail addresses.
  7. Social security numbers.
  8. Medical record numbers.
  9. Health plan beneficiary numbers.
  10. Account numbers.
  11. Certificate/license numbers.
  12. Vehicle identifiers and serial numbers, including license plate numbers.
  13. Device identifiers and serial numbers.
  14. Web universal resource locators (URLs).
  15. Internet protocol (IP) address numbers.
  16. Biometric identifiers, including fingerprints and voiceprints.
  17. Full-face photographic images and any comparable images.
  18. Any other unique identifying number, characteristic, or code, unless otherwise permitted by the Privacy Rule for re-identification.

Exactly what is Encryption?

Once you had determined what is considered sensitive data (PII or ePHI), then we can start to ask what we are to do to protect that data. The most common method of protecting this kind of data is through encryption.

Encryption serves two functions, one is it ensures confidentiality of data and in some cases can provide for integrity of the data.

Encryption is a mathematical computation process that takes plain (readable) text and transforms that into a secret or cipher text. To the naked eye, the data starts in a readable format and then becomes scrambled and unrecognizable when encrypted. Encryption requires a key to encrypt and decrypt the data.

Because encryption is a mathematical computation, each time that a piece of data is encrypted or decrypted, the process runs through your CPU / processor and thus is taxing upon that portion of your system. This can have a significant impact upon performance if not done correctly.

More details on encryption and the specifics of that will be addressed in other blog posts.

Required or Addressable?

Before diving into what HIPAA says about encryption, we must first understand two terms used for rules within HIPAA. They are “Required” and “Addressable.”

The difference between addressable and required in HIPAA is that if required, one has to meet the letter of the law. If addressable, then there is some interpretation in how it is addressed. Addressable means that the covered entity or business associate needs to take “reasonable and appropriate security measure to apply within its particular security framework.” To put it simple, if required do it exactly as it says. If addressable, do it with your efforts meeting best practices.

Finally, what does HIPAA Say?

The specific language is in Item § 164.312(2)(iv) Technical safeguards. It states “A covered entity or business associate must, in accordance with § 164.306:…” (iv) “Implement a mechanism to encrypt and decrypt electronic protected health information.” This is an addressable requirement.

And now you understand a bit why I walked you through the data aspect of this scenario. The key phrase to look at is “…electronic protected health information.” Encryption needs to be applied to the ePHI, the 18 categories of data. It does not need to be blanket applied to a server or scenario.

If you are “research” provisions that allows some of these rules to bend slightly. If you are using ePHI for research, check with your institutional security or legal teams for further guidance.

Exactly how do we do this?

Though HIPAA says that you have to have encryption on ePHI, where it is to be encrypted and when it is to be encrypted leads many people to remain confused on what they need to do. Here are a couple of situations to consider that may help.

First, keep in mind that the question should always come back to the data classification, is it ePHI or not? If it is, then encryption needs to be applied whether it is in transit / motion or sitting on the server.

Once you have the data classification and need (or not) to encrypt clearly determined, then picking the right solutions is similar if not the same to selecting a tool for any other security function.

If the data is in motion, it is best to use an end to end encryption capability like SSL./TLS certificates. These certificates should not be internally generated, or self-signed. They can be purchased online from a hosting provider or a number of different Certificate Authorities (CA’s). Each CA has a series of instructions on how to provide them the needed information to create the certification and apply it properly.

Virtual Private Networks can also be useful for data in motion encryption, but they are rarely end to end, so be careful in your use of these systems.

On the server itself, a big question is how to encrypt the data. There are two main ways to encrypt the date, Full Disk Encryption (FDE) or folder / file level encryption.

Full Disk Encryption (FDE) is likely not necessary and will place additional load upon the CPU and there are many places on a disk that do not contain ePHI and therefore do not need to be encrypted. FDE is most useful when physically transporting a disk, such as through a courier. This will ensure that if the disk is lost, nothing on the disk is readable.

Folder level encryption is probably the best method for encrypting collections of individual files, like a PDF, Word document or Excel spreadsheet. If encryption of an entire folder is not feasible, then individual files can be encrypted. The advantage of encrypting a folder is that it is automated, any file placed within the folder would be encrypted with no further action. If individual file level encryption is selected, the user would have to individually encrypt the file(s). When a manual process is involved, that leaves open the possibility of error.

Database encryption is another area to consider. There are generally two strategies to encrypt data within the database, either the whole database or by row / column.

The whole database scenario, like FDE, is probably encrypting data that may not need to be encrypted. However, FDE is much more valuable than full database encryption should be seriously considered after an internal risk assessment and determination is made.

Most companies opt for row/column based encryption within a database. Row/column based encryption encrypts only the data within specific rows or columns, usually those that are identified as one of the 18 or another sensitive field and allows for a database to be efficient in its operation. Also, as noted on earlier items, encryption is taxing on the CPU and only encrypting what is necessary will ensure that the CPU is also efficient.


Encryption is a valuable tool to ensure confidentiality and integrity of sensitive data. HIPAA requires that we address the issue and apply encryption commensurate with industry best practices. If you have any further questions, please feel free to get a hold of our team to dive into this issue further.