Data Security & Encryption Procedures

Encryption in transit

• Web / application / API traffic: TLS 1.2 minimum, TLS 1.3 preferred. SSL and TLS < 1.2 are deprecated and prohibited for ePHI.
• File transfer: SFTP, FTPS, or HTTPS/TLS. Plaintext FTP is prohibited.
• Remote administrative access: SSH (key-based) or a VPN using an approved cipher suite.
• Asymmetric / key exchange: RSA ≥ 2048-bit or ECDSA ≥ 256-bit; certificates issued by a recognized certification authority.

Integrity / hashing

• Checksums & integrity verification: SHA-256 or stronger. MD5 and SHA-1 are not acceptable for integrity assurance of ePHI.

Key management

1. Generate keys with the [cloud infrastructure provider]'s key-management service (or an approved equivalent) using the strength above.
2. Treat keys as Confidential: any storage or transmission of a key uses encryption at least as strong as the key itself.
3. Restrict key access to named privileged accounts; production infrastructure keys are encrypted under a primary key.
4. Rotate / regenerate a key when any of the following occurs:
   • new technology is introduced that requires a new key;
   • a workforce member who knew a key departs (see Access Control Procedures, offboarding);
   • compromise of the key is suspected (internally or at a third party);
   • the key reaches the end of its defined lifetime (set per use case, not to exceed one year for keys used outside a managed-rotation service);
   • it is required after a security incident.
5. Replace the active key with the new key; if a retired key must be retained, store it securely and never reuse it. Record the rotation in the [ticketing system].

2. Encryption-at-rest enablement (164.312(a)(2)(iv))

1. Before ePHI is placed on any system, IT confirms encryption is enabled: full-disk encryption on endpoints, volume/transparent encryption on servers and databases.
2. New endpoints are enrolled in the [MDM solution], which enforces and reports disk-encryption status; non-compliant devices are blocked from ePHI until remediated.
3. IT records encryption status as part of the asset inventory and re-verifies during periodic reviews.
4. ePHI is never stored on unencrypted removable media or personal/unmanaged devices.

3. Transmission decision tree (164.312(e)(2)(ii), 164.312(e)(2)(i))

Before sending ePHI, the sender works top-down and stops at the first matching row.

Inbound files: before processing any file received into the [Organization] environment, verify it originated from a known/expected source and is free of corruption; where the method supports it, compare the sender-provided SHA-256 checksum against the received file. Quarantine and report any mismatch.

4. Integrity-check SOP (corroborating ePHI) (164.312(c)(1), 164.312(c)(2))

Performed by the [Security Official] (or delegate) on the defined cadence ([monthly] for primary ePHI stores) and on any suspicion of compromise:

1. Identify the ePHI store(s) in scope (primary database/records, cloud document stores, backups).
2. Confirm tamper-evidence is on: version history and activity/audit logging are enabled and that workforce members cannot disable or edit those logs.
3. Review change/activity logs for the period for unexpected, unauthorized, or bulk modifications/deletions of ePHI, and confirm each change is attributable to an authorized user.
4. Verify file/backup integrity by recomputing SHA-256 checksums and comparing against the recorded baseline; investigate any mismatch.
5. On any anomaly, preserve the evidence, attempt restoration from version history or a verified backup, and trigger the Security Incident Response Policy.
6. Record the check, scope, findings, and any follow-up as the integrity-verification evidence.

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

Triggered whenever hardware or media containing ePHI will be relocated, decommissioned, returned, shipped, or sent for repair:

1. Determine whether the equipment holds the only/authoritative copy of any ePHI, or ePHI not yet captured by routine backup.
2. If so, create a copy of that ePHI to an approved encrypted destination (managed backup target or another encrypted, controlled system).
3. Verify the copy is retrievable and intact using the §4 checksum step before the equipment is moved.
4. Record the equipment, ePHI captured, copy location, verification result, date, and the person responsible in the [ticketing system].
5. Hand off the equipment to the physical movement/disposal process in the Device & Media Controls Policy; full backup/DR scheduling remains governed by the Contingency Planning Policy.

Records produced (evidence)

Approved-cipher list with review dates · disk-encryption / [MDM solution] compliance reports · key-rotation tickets · transmission-channel exceptions approved by the [Security Official] · inbound-file verification notes · integrity-check records (logs reviewed, checksums, findings) · backup-before-movement records. These are the artifacts an auditor will request to confirm the controls operate.

HIPAA controls addressed

Review & version

Reviewed at least annually by the [Security Official], and whenever an approved cipher or protocol changes. v1.0.