Checklist for Encrypting and Storing PHI

Encrypting and storing Protected Health Information (PHI) is no longer optional - it’s mandatory under updated HIPAA rules as of January 2025. With healthcare breaches costing an average of $10.9 million in 2025 and penalties reaching $2.19 million per violation, encryption is critical for compliance and security. Here’s what you need to know:

• Identify PHI Storage: PHI can be found in databases, cloud storage, endpoints, backups, and even unexpected places like debug logs or CSV exports. Maintain a detailed inventory of all locations with real-time portfolio risk management.
• Classify Data: Use a tiered system to prioritize encryption - sensitive data like HIV status needs stronger protections like field-level encryption.
• Encrypt Data at Rest: Use AES-256-GCM for robust encryption. Ensure tools are FIPS 140-2/3 validated to meet compliance standards.
• Encrypt Data in Transit: TLS 1.3 is the gold standard for securing PHI during transmission. Use strong cipher suites and enforce HTTPS.
• Secure Devices: Full-disk encryption is essential for laptops, mobile devices, and USB drives. Add pre-boot authentication and auto-lock features.
• Key Management: Store encryption keys in a centralized, secure KMS or HSM. Rotate keys every 90 days and keep keys separate from the data.
• Backups and Cloud Storage: Encrypt backups with AES-256 and use immutable storage like WORM. Ensure cloud providers sign a Business Associate Agreement (BAA).
• Audit and Maintain: Conduct regular encryption audits, verify key rotation, and retain logs for six years to meet HIPAA requirements.

Encryption not only protects patient data but also shields organizations from breach notifications if the data is stolen but encrypted. Follow these steps to safeguard PHI and stay compliant with HIPAA regulations.

HIPAA Compliance Checklist: Easy to Follow Guide for 2024

sbb-itb-535baee

PHI Locations and Storage Scope

Understanding where PHI (Protected Health Information) is stored is crucial for healthcare organizations. While many focus on primary systems like EHRs, patient portals, and billing platforms, they often overlook other areas where PHI resides. A comprehensive inventory is essential for building a strong encryption strategy. Once storage locations are identified, the next step is to classify the data correctly.

Identifying PHI Storage Locations

PHI can be found in numerous places, including databases, file systems, cloud storage, and endpoints. Removable media - like USB drives, external hard drives, and smart cards - are also common carriers.

A hidden risk lies in shadow PHI, which includes data stored in unexpected locations like ad hoc CSV exports, debug logs, or developer workspaces. These often bypass standard encryption protocols ^[6][7].

To stay on top of this, maintain a dynamic inventory and data flow diagram. This should track system ownership, storage types, PHI presence, and encryption status. Such tools help identify transmission points between applications, APIs, and third-party partners that might otherwise go unnoticed ^[6].

After identifying these storage locations, the next step is to classify the data as ePHI.

Classifying Data as ePHI

Classification is key to managing PHI effectively. ePHI refers to any protected health information that is created, received, maintained, or transmitted electronically - whether it’s on a single workstation or spread across a complex cloud network ^[8].

Not all health-related data carries the same level of sensitivity. Using a three-tier classification system can help prioritize encryption and other security measures:

• Restricted PHI: This includes highly sensitive data like HIV status, genetic information, or mental health records. It requires the strongest protections, such as field-level encryption in addition to disk encryption.
• Confidential PHI: This category covers standard clinical records and billing or claims data. These must meet baseline HIPAA encryption standards.
• Internal/Public Data: This includes non-PHI business data or fully de-identified information. Standard access controls are sufficient here, with no HIPAA encryption requirement ^[10].

Proper classification not only guides encryption priorities but also aligns with HITECH’s safe harbor provision. When ePHI is encrypted and keys are kept secure, any loss or theft of that data is not considered a reportable breach under HITECH ^[1][9]. Compliance attorney Devi Narayanan emphasizes:

"If your organization chooses not to encrypt, you must document why it's not reasonable and detail equivalent protections you do implement." ^[9]

To ensure consistent handling, apply file-level metadata labels (e.g., "PHI-Restricted") so that DLP tools and encryption engines can enforce the appropriate protections ^[10].

Encryption Standards and Data-at-Rest Controls

After pinpointing where data is stored and classifying it, the next step is implementing encryption standards. Once PHI (Protected Health Information) is mapped and categorized, the focus shifts to applying proper encryption. HIPAA regulations require encryption for ePHI, with no exceptions outlined for covered entities ^[1].

Encrypting PHI at Rest

The go-to standard for encrypting PHI at rest is AES-256, recommended by NIST in Special Publication 800-111 ^[2][11]. Even better, AES-256-GCM (an AEAD mode) is preferred since it combines confidentiality and data integrity in one process ^[11][1]. For highly sensitive fields like Social Security Numbers or Medical Record Numbers, field-level encryption should complement disk encryption. This approach adds an extra layer of protection against third-party risk, SQL injection, or misuse by over-privileged accounts, which disk encryption alone might not address ^[1].

Your encryption tools must be FIPS 140-2 or 140-3 validated. This validation provides a critical advantage: under the HIPAA Breach Notification Rule, a lost or stolen device containing encrypted data doesn’t qualify as a reportable breach - provided the encryption keys remain secure ^[2][12].

Here’s a quick rundown of recommended and outdated algorithms:

Endpoint and Mobile Device Encryption

Strong encryption for stored PHI isn’t enough - it needs to extend to all endpoints accessing sensitive data. This means every laptop, workstation, and mobile device handling ePHI must have full-disk encryption (FDE). Most operating systems already include tools for this: BitLocker for Windows, FileVault 2 for macOS, and LUKS/dm-crypt for Linux. For portable media like USB drives, options like BitLocker To Go or VeraCrypt with AES-256 are highly effective ^[13][5].

Skipping these measures can come at a high cost. For example, in 2017, Children's Medical Center of Dallas faced a $3.2 million penalty from the Office for Civil Rights after losing an unencrypted BlackBerry and having an unencrypted laptop stolen. The OCR highlighted that the organization had identified the encryption gap years earlier but failed to address it ^[2].

To bolster FDE, add pre-boot authentication (requiring a PIN or password before the OS starts) and configure workstations to auto-lock after 15 minutes of inactivity - or just 5 minutes for shared or public terminals ^[5][13]. If your organization permits personal devices under a BYOD (Bring Your Own Device) policy, those devices must adhere to the same encryption standards as corporate hardware. Enforce this through a Mobile Device Management (MDM) platform ^[2].

Encryption for Data in Transit

Protecting PHI (Protected Health Information) as it moves across networks is just as important as securing it when stored. Whether it’s traveling through web portals, APIs, email, or telehealth platforms, PHI in transit is vulnerable to interception. This is a critical component of taking the risk out of healthcare operations. By 2026, encrypting PHI during transmission is no longer optional - it’s a required safeguard ^[1].

TLS Encryption for Transmission

TLS (Transport Layer Security) 1.3 is now the gold standard for securing web-based PHI, such as patient portals, EHR (Electronic Health Record) interfaces, and REST APIs. TLS 1.2 is still acceptable, but only when configured with strong cipher suites and forward secrecy. For example, ECDHE-family ciphers like P-256 or X25519 ensure that even if a private key is compromised in the future, past sessions remain secure ^[1][5].

To maintain a secure setup, make sure to:

• Disable outdated protocols like SSL v2/v3, TLS 1.0, and TLS 1.1 at your network gateway.
• Use tools like testssl.sh or SSL Labs to identify vulnerabilities, such as fallback issues.
• Enforce HTTPS with HSTS on all web-facing services.
• Implement mutual TLS (mTLS) for secure internal service-to-service communication.
• Automate certificate management to avoid downtime caused by expired certificates.
• Use WPA3 Enterprise for wireless networks, or at least WPA2 Enterprise with AES encryption ^[5].

Here’s a quick reference for the 2026 standards:

Beyond transport layer encryption, email and messaging systems require equally strong safeguards.

Email and Messaging Encryption

Securing email communication is especially tricky, but it’s essential for protecting PHI. Ensure that mail servers handling PHI enforce TLS 1.2 or higher. For particularly sensitive communications, such as lab results or referrals, end-to-end encryption via S/MIME (X.509 certificates) or PGP is ideal. These methods ensure messages remain encrypted even if a mail server is compromised ^[1][5].

If the recipient’s server doesn’t support strong TLS, use a secure fallback. For instance, the message can be stored on a secure server, and the recipient receives a notification to log in and retrieve it. This is especially useful for patient communications or smaller partners with limited third-party risk management capabilities. For inter-organization transfers, Direct Secure Messaging via DirectTrust is a safer alternative to unencrypted fax transmissions ^[5].

"Addressable does not mean optional; it means you must assess risk, implement encryption when reasonable and appropriate, or document why a comparable alternative control achieves equivalent protection." - Kevin Henry, HIPAA Expert ^[14]

Additional protective measures include:

• Using Data Loss Prevention (DLP) tools to detect PHI patterns and trigger encryption or secure routing.
• Disabling auto-forwarding for sensitive mailboxes.
• Avoiding PHI in email subject lines.
• Ensuring that any email or messaging platform handling ePHI has a signed Business Associate Agreement (BAA) in place ^[1][5].

Key Management and Access Controls

Encryption is only as strong as its key management and access controls. Without proper handling, even the best encryption can fail to protect sensitive data.

Centralized Key Management

Always store encryption keys separately from the data they protect. Key Encryption Keys (KEKs) and root certificates should be housed in a FIPS-validated Hardware Security Module (HSM) or a managed Key Management Service (KMS) like AWS KMS, Azure Key Vault, or Google Cloud KMS. Avoid storing master keys in risky locations such as environment variables, configuration files, or repositories like Git. These can be easily accessed by anyone with repository permissions ^[1].

A best practice is to use envelope encryption, where a Data Encryption Key (DEK) secures sensitive data, and a KEK secures the DEK. This setup simplifies key rotation - when you rotate keys, only the DEK needs re-encryption, sparing you from reprocessing the entire dataset. This is especially helpful for large healthcare systems ^[1][4].

Key rotation is another critical aspect. While NIST SP 800-57 suggests annual rotation, modern standards for workloads involving sensitive Protected Health Information (PHI) recommend rotating keys every 90 days ^[1]. Automating this process through your KMS console is far more reliable than manual updates.

"The single most common audit finding in this area is 'you say you rotate every 90 days, but the KMS console shows the master key has not changed in 2 years.' Don't be that team." - Garvita Amin, Healthcare Technology Expert ^[1]

Accountability is essential. Your key management policy should designate at least two key custodians to oversee operations. Pair this with strong access controls to ensure only authorized personnel can access encryption keys and PHI.

Access Control Measures

Access to PHI systems must adhere to the principle of least privilege - users should only have the permissions necessary to perform their role. Separation of duties is critical here: storage administrators should not have access to encryption keys, and security administrators should not have access to plaintext data ^[4].

"Separate duties so storage admins cannot access keys and security admins cannot access plaintext data." - Kevin Henry, HIPAA Expert ^[4]

For high-risk actions like exporting or deleting keys, implement dual control, requiring approval from more than one authorized individual. This reduces the risk of any single insider misusing their access ^[1][4].

Every user accessing PHI systems must have a unique user ID, and multi-factor authentication (MFA) is mandatory for systems managing encryption keys, KMS platforms, HSMs, or ePHI databases ^[1]. Additionally, every encryption, decryption, and key-related operation must be logged with the user ID, timestamp, and key ID. HIPAA mandates retaining these logs for at least 6 years ^[1].

For particularly sensitive information, like Social Security Numbers or clinical notes, consider adding field-level encryption at the application layer. This provides an extra layer of protection, even against over-privileged service accounts with broad database access ^[4][1].

Secure Backups, Cloud Storage, and Retention

Protecting live PHI with encryption and access controls is essential, but backups and cloud storage demand the same level of attention. Unprotected backups are a common issue flagged by auditors, so encrypting primary databases, backups, read replicas, and offsite archives is a must ^[1].

Encrypted and Immutable Backups

Every backup containing PHI should be encrypted using AES-256 encryption, implemented through a FIPS 140-2 or 140-3 validated cryptographic module ^[6][15]. To further secure the data, apply client-side encryption before transmitting it to the backup repository ^[1][15].

Immutability is just as critical. Use Write-Once-Read-Many (WORM) storage or enable Object Lock to prevent unauthorized changes or deletions of backup sets ^[15][16]. Following the 3-2-1-1-0 backup strategy adds another layer of protection: maintain three copies of the data on two different media types, ensure one copy is stored offsite, one is immutable or air-gapped, and confirm there are zero unresolved restore errors ^[15].

Testing backup recovery regularly is non-negotiable to ensure data integrity. As Kevin Henry, a HIPAA expert, emphasizes:

"Backups matter only if restores succeed. Conduct recurring restore tests for files, databases, and full systems." ^[15]

During restore drills in non-production environments, sanitize or de-identify the data to maintain compliance ^[15]. For high-risk operations like backup deletions or encryption key exports, implement multi-factor authentication (MFA) and require dual-control approvals ^[4][15]. Audit logs should be retained for six years to meet regulatory requirements ^[1][15].

These principles also extend to securing PHI stored in the cloud.

Cloud Storage Security

Cloud storage security builds on the foundation of strong encryption practices for backups but introduces additional considerations. Before storing PHI in the cloud, sign a Business Associate Agreement (BAA) with the provider. Ensure the BAA explicitly covers specific storage services, such as Amazon S3, Azure Blob Storage, or AWS Glacier ^[15][16]. Not all services within a cloud platform are HIPAA-compliant, so verify that the service you’re using is listed as HIPAA-eligible ^[17].

The shared responsibility model is key here: while the cloud provider secures the infrastructure, your organization is responsible for configuring encryption, managing access controls, and monitoring logs ^[17]. Use tools like AWS Config or Azure Policy to continuously check for misconfigurations - issues like public-facing buckets or unencrypted volumes can lead to costly breaches ^[17][18]. To validate your vendor’s security, ensure they have certifications such as SOC 2 or HITRUST ^[16][18].

Additionally, use Service Control Policies to limit PHI backups to BAA-eligible geographic regions. Define secure deletion timelines and include certificates of deletion in your BAA ^[1][16].

Validation, Audit, and Maintenance

Setting up encryption controls is just the beginning. Without regular checks, even the best systems can falter - keys may not rotate as planned, certificates can expire, and unnoticed misconfigurations might creep in. This section dives into how to ensure your encryption and key management systems are working as they should and how to keep documentation in sync with actual practices.

Routine Encryption Audits

Encryption audits are essential to confirm that your PHI encryption controls are functioning as expected. Start by verifying that your encryption standards align with established benchmarks - like AES-256 for data at rest and TLS 1.3 (or TLS 1.2 with strong cipher suites) for data in transit. Tools such as testssl.sh or SSL Labs can help identify weak configurations, like fallback to outdated protocols such as SSL v2/v3 or TLS 1.0/1.1 ^[1].

Don’t rely solely on policy documents - check your KMS console quarterly to confirm actual key rotation dates ^[1]. Every key operation should be logged with details like user ID, timestamp, key ID, and the accessed resource. These logs should be retained for six years ^[1][5]. To stay ahead of potential issues, configure your SIEM system to send daily automated alerts for unusual activity, such as unexpected decryption patterns or unauthorized key access attempts ^[5].

One area often overlooked during audits is observability pipelines. Ensure these pipelines aren’t unintentionally logging plaintext PHI. For example, SQL errors, stack traces, or debug logs in tools like CloudWatch can inadvertently expose sensitive patient data if not properly sanitized ^[1].

Here’s a quick summary of acceptable standards for 2026 compared to configurations that could fail an audit:

Document your audit findings and adjust policies as needed to ensure compliance remains intact.

Policy and Documentation Maintenance

After completing your audits, it’s critical to ensure your documentation reflects your current encryption and key management practices. Maintain a detailed written risk analysis that outlines the algorithms, key lengths, and FIPS validation for each PHI storage location. This analysis should be reviewed annually or whenever there’s a significant architectural change ^[1][11]. Complement this with an Encryption Coverage Matrix, a dynamic document that maps encryption controls to every system, storage location, backup, and integration ^[4].

Your Key Management Policy should designate at least two key custodians and clearly define the rotation schedule ^[1]. Additionally, prepare runbooks in advance for tasks like key rotation, certificate renewal, and responding to key compromise incidents ^[4]. Organizations can further streamline these efforts by adopting RiskOps for healthcare to unify risk response across departments.

Under the 2026 HIPAA updates, covered entities must maintain and annually review a written inventory of all technology assets that interact with PHI, including cloud storage accounts ^[3]. Audit logs and related documentation need to be retained for at least 6 years from their creation or last use, whichever is later ^[1][5]. With civil penalties reaching up to $2,190,294 per violation category per year ^[2], maintaining thorough documentation isn’t just a compliance requirement - it’s a smart financial safeguard for your organization.

Conclusion: Keeping PHI Secure and Compliant

Securing PHI isn’t just about ticking boxes - it’s about creating a system that adapts and strengthens over time. The checklist we’ve outlined highlights critical steps: identifying every storage location, encrypting data with AES-256-GCM at rest, enforcing TLS 1.3 during transmission, centralizing keys using a managed KMS or HSM, and maintaining audit logs for at least 6 years. Each measure supports the next, and even a single gap can compromise the entire framework.

The risks are undeniable. According to the 2025 Ponemon/Proofpoint Healthcare Cybersecurity Report, 93% of healthcare organizations experienced a cyberattack in the past year, with the average healthcare data breach costing $7.42 million per incident - more than twice the average across industries. These figures aren’t just numbers; they reflect the real financial and reputational fallout of failing to protect PHI.

One key takeaway: encrypted data that’s stolen doesn’t count as a reportable breach under the Breach Notification Rule. This provides a significant legal and financial safeguard for covered entities and business associates. With encryption now mandatory under the January 2025 Security Rule update ^[1], organizations must pair it with other measures like RBAC, MFA, Zero Trust architecture, and frequent audits to ensure compliance and strengthen defenses.

Platforms such as Censinet RiskOps™ can simplify this process. By streamlining risk assessments and benchmarking cybersecurity efforts, these tools help healthcare organizations meet HIPAA standards while managing enterprise and third-party risks effectively.

The goal? A documented, adaptable process that safeguards PHI while staying compliant with regulations. By following the steps in this checklist, you can build a program that protects patient data and keeps your organization aligned with regulatory expectations.

FAQs

How can I locate 'shadow PHI' like exports and debug logs?

To locate hidden or "shadow" protected health information (PHI), start by mapping out how data moves across cloud platforms, SaaS applications, and third-party tools. Talk to process owners to understand how information flows, and scan storage repositories for sensitive data patterns, such as Social Security numbers. Don’t overlook ticket logs, backups, debug logs, or local files stored in places like OneDrive. Tools like Censinet RiskOps™ can assist healthcare organizations in identifying and securing these concealed data sources efficiently.

When do I need field-level encryption vs full-disk encryption?

Full-disk encryption (FDE) is a smart way to secure entire devices, like laptops or servers. It works by rendering the entire drive unreadable without the proper credentials, which is particularly useful if the device is lost or stolen. On the other hand, field-level encryption focuses on protecting specific pieces of sensitive information - think Social Security numbers or clinical notes - by encrypting individual fields within a database or system. This ensures that even if someone gains access to the system, the most critical data remains protected. While FDE is great for safeguarding against physical theft, field-level encryption adds an extra layer of precision to data security.

What’s the simplest way to rotate and protect encryption keys every 90 days?

The simplest way to handle encryption key rotation every 90 days is by leveraging automated, centralized key management systems such as AWS KMS, Azure Key Vault, or Google Cloud KMS. These platforms offer built-in support for automated rotation policies, which minimizes manual effort, reduces errors, and ensures compliance with security standards.

They also include features like envelope encryption and key versioning, which help maintain strong security practices while keeping operations smooth and uninterrupted.

Related Blog Posts

• HIPAA Compliance for Cloud Services: Checklist
• Best Practices for Cloud PHI Encryption at Rest
• How to Encrypt ePHI in Cloud Systems
• Ultimate Guide to PHI Encryption in Healthcare