Data Security & Encryption Policy

Scope

This Policy applies to all ePHI that [Organization] creates, receives, maintains, or transmits, and to every system component that handles it: applications, databases, endpoints (laptops, desktops, mobile devices), removable media, cloud services, and network infrastructure. It applies to all workforce members (employees, contractors, interns, and volunteers) and to business associates that transmit or store ePHI on [Organization]'s behalf. Physical destruction of media, device re-use/disposal, and device/media tracking are governed by the Physical Security Policy and the Device & Media Controls Policy; full backup, restoration, and disaster-recovery planning are governed by the Contingency Planning Policy. This Policy addresses only the data-protection controls named above, plus the requirement to create a retrievable copy of ePHI before equipment is moved.

Policy

1. Encryption at rest (164.312(a)(2)(iv))

All ePHI at rest is encrypted using approved ciphers (see the Data Security & Encryption Procedures for the maintained approved-cipher list; AES-256 is the baseline). This includes:

• Databases and data stores holding ePHI, PII, customer data, or payment data: encrypted at rest;
• Servers and production volumes: encrypted using volumes managed by [Organization] or the [cloud infrastructure provider];
• All endpoints: laptops, desktops, and mobile devices use full-disk encryption ([full-disk encryption]), enabled before any ePHI is stored on them;
• Removable media: encrypted if used for ePHI at all; storing ePHI on unencrypted or personal devices is prohibited.

Encryption is enabled by the operating-system or platform function automatically, and IT is responsible for verifying enablement and configuration. Authenticators (passwords, keys) are never stored in plaintext.

2. Key management (164.312(a)(2)(iv))

Cryptographic keys are generated, distributed, stored, rotated, retired, and destroyed in a manner that prevents loss, theft, unauthorized access, or compromise. [Organization] uses a managed key service (the [cloud infrastructure provider]'s key-management service or an equivalent) that supports the full key lifecycle. Access to encryption keys is restricted to privileged accounts on a least-privilege basis; production infrastructure keys are themselves encrypted under a primary key. [Organization] (or an escrow service it controls) retains control of keys when external service providers encrypt stored ePHI, so that information remains available if a user's key is lost. Detailed key-rotation triggers and steps are in the companion Procedures.

3. Transmission security (164.312(e)(1))

[Organization] guards against unauthorized access to ePHI that is transmitted over an electronic communications network. ePHI is never transmitted over an untrusted network in cleartext. Every transmission channel (email, patient/secure portal, fax, file transfer, application APIs, and remote access) must provide both confidentiality (encryption) and integrity (assurance the data was not altered in transit). Workforce members route ePHI only through approved channels; the Data Security & Encryption Procedures provide a transmission decision tree that maps each scenario to an approved method.

4. Encryption in transit (164.312(e)(2)(ii))

ePHI in transit is encrypted end-to-end using approved protocols: TLS 1.2 or higher for web/application traffic and APIs, SFTP/FTPS or TLS-protected transfer for file movement, and an encrypted tunnel (e.g., VPN) for remote administrative access. Plaintext protocols (HTTP, FTP, Telnet, unencrypted SMTP) are prohibited for ePHI. Public-key certificates are validated through recognized certification authorities. Specific channel guidance:

• Email: ePHI is sent only via an encrypted/secure-messaging method; ordinary email is not an approved channel for ePHI unless TLS-enforced and, where required, message-level encryption is applied;
• Patient/secure portal: served over TLS with authenticated access;
• Fax: preferred as secure/electronic fax over an encrypted channel; traditional fax is used only to a verified number with confirmation of receipt (see Procedures);
• File transfer: outbound and inbound files use a secure file-transfer platform.

5. Integrity controls in transmission (164.312(e)(2)(i))

[Organization] implements measures to ensure that transmitted ePHI is not improperly modified without detection. The encrypted protocols required in §4 (TLS, SFTP/FTPS) provide cryptographic integrity verification of data in transit. For file transfers, inbound files are verified to have originated from a known source and to be free of corruption before processing, and integrity is corroborated using a checksum/hash where the transfer method supports it.

6. Integrity of stored ePHI (164.312(c)(1))

[Organization] protects ePHI from improper alteration or destruction throughout its lifecycle by:

• Access and segmentation controls so ePHI is modifiable only by authorized personnel (governed in detail by the Access Control Policy);
• Storage on systems that support logging and automated monitoring for security-relevant events;
• Version history / immutable activity logs on data stores, so prior states are recoverable and changes are attributable;
• Isolation of production data from development and test environments, and sanitization of any production ePHI before use in non-production environments, to prevent accidental modification or exposure.

Detected unauthorized alteration or destruction of ePHI triggers the process in the Security Incident Response Policy.

7. Mechanism to authenticate ePHI (164.312(c)(2))

[Organization] implements a mechanism to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. The primary mechanism is the data store's version history and tamper-evident activity/audit logs (e.g., file or record version history and change logs); for file-based exchange and backups, cryptographic checksums/hashes are used to confirm integrity. The [Security Official] reviews integrity evidence on a defined cadence and on any indication of compromise, per the integrity-check procedure in the companion Procedures.

8. Retrievable copy before equipment movement (164.310(d)(2)(iv))

Before any hardware or electronic media containing ePHI is moved, relocated, decommissioned, returned, or sent for repair, [Organization] creates a retrievable, verified copy of the ePHI on that equipment when needed, so that no information is lost in the move. The copy's integrity is confirmed (per §7) before the equipment is moved, and the movement is recorded. Routine backup, restoration testing, and disaster recovery are governed by the Contingency Planning Policy; the physical movement, tracking, and disposal of the equipment itself are governed by the Device & Media Controls Policy. This section establishes only the requirement to capture a retrievable copy before movement.

Roles & Responsibilities

• [Security Official]: owns this Policy; approves the approved-cipher and approved-channel standards; reviews integrity evidence; documents addressable-item decisions in the risk analysis.
• IT / system administrators: enable and verify encryption at rest and in transit; operate key management; perform the backup-before-movement step.
• System / data owners: ensure their data stores meet the encryption and integrity requirements.
• Workforce members: transmit ePHI only through approved channels, use only encrypted devices for ePHI, and report suspected integrity or transmission failures immediately.
• Business associates: maintain equivalent encryption and integrity safeguards under a Business Associate Agreement.

Related documents

Data Security & Encryption Procedures · Access Control Policy · Device & Media Controls Policy · Physical Security Policy · Contingency Planning Policy · Security Incident Response Policy · Audit Controls & Activity Review Policy.

HIPAA controls addressed

Review & version

Reviewed at least annually by the [Security Official] and after any significant change to the ePHI environment or to approved ciphers/protocols. v1.0.