HIPAA Encryption Requirements: An Updated Guide
Learn what HIPAA says about encryption, what your company must do to safeguard PHI, and how you can ensure your systems stay in compliance with HIPAA.
An individual’s health data is among the most personal information you can have. In the U.S., the Health Insurance Portability and Accountability Act of 1996 (HIPAA) states that Americans should be able to trust that their health data will remain private. Under HIPAA, covered entities and business associates (like hospitals, insurers, and their vendors) must safeguard protected health information (PHI) and electronic protected health information (ePHI) against unauthorized access. PHI is a blanket term that covers all “individually identifiable health information” in any form (written, electronic, even spoken), so healthcare providers need robust HIPAA compliance programs.
The shape those safeguards should take isn’t always clear. HIPAA regulations provide required outcomes rather than required methods, recognizing that security best practices are always changing. The Department of Health and Human Services (HHS) and the National Institute of Standards and Technology (NIST) have offered plenty of guidance regarding encryption of ePHI. Here’s what you need to know about HIPAA encryption requirements, how to properly encrypt ePHI, and how to keep your organization compliant with HIPAA at all times.
New to HIPAA? We’ve created a HIPAA compliance checklist resource to help you kick off your compliance journey.
What Does HIPAA Say About Encryption?
Healthcare providers that encrypt patient data are typically doing so to comply with these two requirements of HIPAA:
45 CFR § 164.312(a)(1): Systems must be configured to restrict ePHI access “only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).”
45 CFR § 164.312(e)(1): Anyone who transmits ePHI over an electronic communications network must “implement technical security measures to guard against unauthorized access.”
In both cases, the rule text is followed by a section with implementation specifications that mentions encryption.
However, unlike some of the implementation specifications which are labeled “required,” the encryption subpoints are considered “addressable.” In HHS lingo, this means covered entities have three options:
Use the addressable specification if they consider it “reasonable and appropriate.”
Find a “reasonable and appropriate” alternative solution that leads to the same outcome.
Decline to implement the addressable specification or an alternative solution because neither is “reasonable and appropriate” for their operations.
The rule was written this way to allow healthcare organizations the flexibility to determine their own security setup. By making this requirement addressable, HHS also left room for organizations to implement more effective data security practices, if they ever arise.
When is Encryption Required Under HIPAA?
Technically, HIPAA does not require data encryption because organizations have the right to not comply with addressable implementation specifications. In practice, however, it’s smart to follow HIPAA’s encryption suggestions.
HHS included the “reasonable and appropriate” clause to allow organizations to find their own implementations if the suggested one is truly too burdensome or unworkable. If you choose to make use of this leeway, you must document why encryption is not a “reasonable and appropriate” option for your company. You must conduct and write out a risk assessment that validates your choice to deviate from the rule and show how the alternative solution you choose fulfills the same purpose as encryption would.
If your systems suffer a data breach or are otherwise compromised and you weren’t encrypting patient data, your justifications would be under heavy scrutiny. And because HIPAA fines are higher for entities that violate the law knowingly or through neglect, your documentation could be used against your company.
In short, the HIPAA Omnibus Rule strongly suggests that companies should encrypt ePHI. Encryption is one of the best ways to keep information private. Plus, it’s not overly burdensome, and regulators will look more kindly on your company should the worst happen.
Securing Data at Rest
Encryption meets two needs: securing data when it’s at rest and when it’s in transit. Data “at rest” is stored digitally on a server, hard drive, mobile device, or other similar system. It’s static, meaning it’s not currently being accessed, used, or changed.
Any ePHI that’s at rest should be encrypted. Even if someone were to physically access the storage device, they should not be able to see or use the data on it. HIPAA refers holders of ePHI to NIST. Special publications 800-66r2, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, and 800-111, the Guide to Storage Encryption Technologies for End User Devices, detail the technical requirements.
SP 800-66r2 and SP 800-111 stress that encryption and access control are connected: Users should only be able to access ePHI after authentication, and systems should automatically return data to its encrypted state by ending authenticated sessions after an interval of inactivity.
SP 800-111 goes on to discuss common encryption solutions that could be used to protect ePHI. Read on to learn more about each.
Full Disk Encryption
Full disk encryption, otherwise known as FDE, is largely a software-based encryption solution that encrypts everything on a computer’s hard drive, including the operating system (OS). When turned on, a device with FDE doesn’t trigger the OS to load. Instead, it takes the user to a pre-boot environment (PBE), where they must input their credentials to authenticate their identity. This pre-boot authorization (PBA) can be run locally on the machine or connected to a larger network.
After the user completes the PBA, the OS is decrypted and booted. The majority of the hard drive stays encrypted; when a user accesses or saves a file, the hard drive is decrypted and re-encrypted as necessary in sectors.
FDE can be done on a hardware level, with everything needed to authenticate, encrypt, and decrypt the data built into a hard drive. In this case, the hard drive, not the OS, handles the PBA process.
Potential downsides of FDE include slight delays when interacting with large files, booting or shutting down the computer, or hibernating. FDE is also incompatible with some operational configurations, like dual-boot capabilities and the use of wake-on-LAN. Additionally, FDE is not compatible with OS-based authentication measures, such as touchscreen code entry, because the OS does not load until after PBA has been passed. Hardware-based FDE bypasses some of the limitations above, like delays and incompatibility with dual-boot configurations, but it usually cannot be managed over a network.
Virtual Disk Encryption
Rather than encrypting an entire drive, virtual disk encryption secures a “container,” a folder that can hold files. This encrypted folder lives in a logical volume.
A user must authenticate themself before they can access the container. After they successfully provide their credentials, the container mounts as a virtual disk, and the user can see and interact with its contents. The OS handles decrypting and encrypting sectors of the container as needed, similar to FDE.
The strength of this method is that containers can be copied with the encryption intact—they can be moved to storage media like flash drives, CDs, and DVDs. This makes it easy to back up encrypted data without compromising its security.
One difficulty with virtual disk encryption is human fallibility. If a user’s system does not default to saving new files in the container, they may save ePHI to an incorrect, unencrypted location. IT teams setting up virtual disk encryption should ask what they can do to push users toward saving files in encrypted locations. Additionally, files are only encrypted as long as they are in the container. If they were, say, backed up individually and not as part of the container, they would be accessible without authentication.
File-Level Encryption
File encryption (and a similar method, folder encryption) secures individual files or folders so they can only be opened by authorized individuals. Unlike virtual disk encryption, which locks encrypted files in a container that must be “opened” via authentication, the encrypted files are visible to all but inaccessible. When users attempt to open the encrypted file, they are asked to authenticate before the operation completes.
File and folder encryption enable organizations to choose exactly which data needs to be encrypted. Encryption does not have to be manually turned on for each file; admin-level rules can, for instance, encrypt all files in a specific location or of a specific type. Because decryption is handled on an individual basis when a file is accessed, this method tends to cause fewer slowdowns than FDE.
The downside of file and folder encryption is that it provides less privacy. Unauthenticated users on a device that holds encrypted files can see the names and potentially other metadata attached to these files. Additionally, there’s a risk of high-level encryption rules missing files that should be encrypted.
AES-128, AES-192, and AES-256 Encryption
No matter which method of encryption you choose, you’ll also need to choose an encryption algorithm. NIST recommends using its Advanced Encryption Standard (AES) algorithms whenever possible. AES is used across the government whenever encryption is required because it’s difficult to break, but encryption and decryption don’t take long.
The current AES algorithms are block ciphers from the Rijndael family. They split data into chunks that are all 128 bits in size, then encrypt that data into a 128-bit block.
There are three varieties of AES encryption: AES-128, AES-192, and AES-256. The number specifies the length of the decryption key in bits. The longer your key, the harder it is to break, but each block also takes longer to decrypt.
Securing Data in Transit
When data is moving between any two locations, it is considered “in transit.” This covers situations including files being copied from one disk to another, shared through email or messaging services, downloaded to a machine or uploaded to a cloud, and similar operations.
Data is often less secure when it’s in transit because it’s moving through networks that others have access to. Network protections are a must to prevent data sniffing and the exposure of ePHI. Data should always be encrypted before it is sent, but NIST SP 800-52 r2 and NIST SP 800-77 lay out requirements for Transport Layer Security (TLS) and Internet Protocol Security virtual private networks (IPSec VPNs).
Transport Layer Security (TLS)
TLS is widely used across the internet to encrypt data as it travels to and from servers. It’s a broadly applicable protocol that can safeguard all types of traffic, including emails, communications sent through messaging apps, and VoIP calls. It’s an updated version of the Secure Sockets Layer (SSL) 3.0 protocol, so you may hear it referred to by that name.
TLS can encrypt information, verify its provenance and integrity, and authenticate the parties on either end of the transmission. When you attempt to connect with another device, server, or network, TLS initiates a secure connection with the TLS handshake. The handshake protocol has multiple purposes, including:
Establishing the encryption algorithms that will be used to secure the transmission.
Verifying the identities of the parties on either side of the connection.
Generating the encryption keys that will be used to protect the data transmitted.
Ensuring third parties do not capture and re-transmit (replay) data.
Once you start sending information, TLS signs each communication with a message authentication code (MAC) that can be used to verify the data was not tampered with. TLS 1.2 allows you to use other authentication methods, which may offer different capabilities.
To learn more about TLS implementation recommendations, read NIST SP 800-52 r2.
Internet Protocol Security (IPSec) VPNs
Virtual private networks (VPNs) encrypt Internet Protocol (IP) traffic as it travels over public or private networks. NIST recommends using Internet Protocol Security (IPSec) standards to secure your VPN. You may also hear these referred to as Internet Key Exchange (IKE) VPNs; however, IKE is just a protocol used to secure connections and manage communication channels. An IPSec VPN must also use the Encapsulating Security Payload (ESP) protocol to encrypt each communication.
A VPN protects data in multiple ways: It ensures confidentiality and integrity, authenticates its origin, protects against replay attacks, and provides general access control. Depending on your needs, VPNs can be set up with various architectures:
A gateway-to-gateway VPN connects two specific networks. For example, you may want to make it easy to communicate HIPAA-protected information between your general hospital and an outpatient clinic if you often transfer patients back and forth.
A host-to-host VPN connects two specific machines. It’s most commonly used for off-site or remote administration of systems.
A remote access VPN allows individuals who are not on the premises to log in to your main network. If a staff member is traveling or telecommuting, this type of VPN will allow them to safely access sensitive information from their current location.
A mesh VPN covers one or multiple networks and makes it easy for any two points within those networks to securely connect and transfer data. It’s a useful setup for a hospital network that needs to share patient health data between different locations.
These VPNs can all comply with NIST guidelines as long as they use approved cryptographic algorithms found in FIPS publication 140-2 and NIST SP 800-56A r3. For more information on how to securely configure a VPN, read NIST SP 800-77 r1.
How to Meet HIPAA Encryption Requirements
Encryption is usually the easiest way to meet HIPAA’s requirement for protecting patient information. Here’s how organizations of every size can become HIPAA compliant when building out their systems and security.
Conduct a Risk Assessment
A risk assessment is the first step of any successful security program. It helps your organization understand the risks to the ePHI you hold and allows you to pinpoint potential vulnerabilities—ways bad actors could compromise your systems.
NIST SP 800-66r2 does not require organizations to use any specific risk assessment methodology, but recommends the following steps:
1. Prepare. Map all the places ePHI lives in your systems, where it is created, and where it may be transferred to other systems or third parties. This map should include physical locations (computers, server rooms) and network locations.
2. Anticipate threats. Consider three potential sources: natural (extreme weather events that could affect facility security), human-caused (hackers or unsecured workstations), and environmental (power failures that knock out your servers). Use the ePHI map you created in step one to guide your work and consider researching threats similar organizations have faced.
3. Identify vulnerabilities. Look at the threats you anticipated in step two and ask how someone might exploit your systems to attempt each attack. System scans and security tests, along with vendor publications, vulnerability databases, and other third-party sources can help you identify potential weak points in your system.
4. Evaluate the likelihood of an attack. Ask how likely it is that a bad actor will threaten your systems using an identified vulnerability.
5. Evaluate the impact of an attack. Consider how ePHI would be affected by each threat event and vulnerability exploit identified in the previous step. Your business impact analysis and asset criticality assessment may already include some of this information.
6. Determine risk levels. Use your evaluations of likelihood and potential impact of attack in concert to determine where your organization’s biggest threats lie.
7. Document your results. Note all risks and associated vulnerabilities and your analysis of how likely and serious a threat event involving each one would be.
At the end of your risk assessment, you’ll understand where your organization needs to focus its security efforts.
Follow NIST Recommendations
The NIST publications we’ve recommended throughout this article can help you determine the appropriate security measures for your systems. Base measures like encryption of data at rest and in transit should be a priority for all organizations. You may also need defenses that specifically address each likely and highly impactful threat you identified during your risk assessment. NIST offers suggestions for administrative, physical, and technical safeguards in SP 800-66r2.
Use Vetted Vendors and Tools
Your tech stack will be one of your main defenses against bad actors. It could also be a source of risk if you don’t vet every tool and service you incorporate.
Look for businesses with a core focus on HIPAA compliance and experience with the healthcare industry. Companies that seek to add compliance to their product to meet a single client’s need are more likely to make mistakes that put your organization and patients at risk. Evaluate tools before adding them to ensure the claims of HIPAA compliance aren’t overstated.
Automate Monitoring and Documentation
Organizations may fall out of compliance with HIPAA thanks to changes in their system or tools. Consider adding a compliance oversight manager to monitor systems and keep logs to prove you are compliant.
Monitoring helps you catch any changes in systems, software, or tools that could threaten your HIPAA compliance status. It’s also a first line of defense against bad actors—an automated tool is likely to catch system anomalies before events become a crisis.
Drata, Your HIPAA Compliance Partner
Drata knows compliance. Our HIPAA compliance framework helps you see, understand, and adjust system controls necessary to protect ePHI. Our software walks you through HIPAA requirements step by step, showing you where you can automate compliance efforts and create documentation as you go.
Drata’s continuous control monitoring service provides real-time visibility into your compliance status. It’s easy to produce reports to reassure partners looking for information on how your systems secure ePHI and address patient privacy concerns. Our platform also comes with HIPAA employee training to keep your whole team sharp and your company in compliance with HIPAA as you scale and evolve.
Drata can help you navigate complex compliance requirements like HIPAA. Schedule a demo of our HIPAA compliance framework today.
HIPAA Encryption Requirement Frequently Asked Questions (FAQs)
Below we answer the most common questions about HIPAA encryption requirements.
Is Encryption Required Under HIPAA?
No, encryption is not required by HIPAA. However, organizations should follow encryption best practices unless they have a specific reason not to and an equivalent alternative measure to secure patients’ protected health information.
What Encryption Methods Meet HIPAA Encryption Standards?
Organizations should use AES-128, AES-192, and AES-256 encryption algorithms. They may choose full disk, virtual disk, folder level, or file level encryption to secure data at rest. TLS and IPSec VPNs are a must for securing data in transit.
What Happens If I Don’t Encrypt PHI?
If you don’t encrypt PHI, you may be subject to large penalties if a bad actor or employee mistake results in protected patient data being shared.
Does Email Need to be Encrypted Under HIPAA?
Yes, email should be encrypted under HIPAA because it’s often used to share ePHI. While every email might not contain sensitive information, encrypting all emails is the best choice for most organizations.
