Compliance Foundations

HIPAA Encryption Policy Template (45 CFR § 164.312(a)(2)(iv) + (e)(2)(ii))

9 min read · Last reviewed May 23, 2026

A HIPAA encryption policy is the written policy implementing the addressable encryption specifications at 45 CFR § 164.312(a)(2)(iv) (data at rest) and 45 CFR § 164.312(e)(2)(ii) (data in transit). It names the algorithm, key length, key management, scope of covered systems, and the documented risk decision for any system left unencrypted.

What HHS actually requires

The HIPAA Security Rule treats encryption as addressable, not optional. Addressable means the practice must either implement the specification, implement an equivalent alternative and document why, or document why neither is reasonable and appropriate under § 164.306(d)(3). The HHS Guidance to Render Unsecured Protected Health Information Unusable defines what counts as encrypted for breach-safe-harbor purposes — encryption that meets the guidance removes the data from the § 164.402 breach definition entirely.

In our review of OCR Resolution Agreements through 2025, unencrypted devices drive a disproportionate share of penalties. Concentra Health Services ($1.7M), QCA Health Plan ($250K), Lifespan ACE ($1.04M), and the University of Rochester Medical Center ($3M) all involved an unencrypted laptop or USB drive holding ePHI. The pattern is consistent: the device walks out of the building, the practice cannot prove encryption, the safe-harbor breaks, and the breach is reportable.

The four entities every credible encryption policy references: the HHS Office for Civil Rights (OCR), NIST SP 800-111 for storage encryption, NIST SP 800-52 Revision 2 for TLS configuration, and the FIPS 140-2 / 140-3 cryptographic module validation program.

Template — section by section

Paste this into the binder. Adjust bracketed fields to the practice.

``` HIPAA ENCRYPTION POLICY [Practice Name] Effective: [DATE] Owner: Security Officer

  1. PURPOSE

This policy implements the addressable encryption specifications at 45 CFR § 164.312(a)(2)(iv) (encryption and decryption of ePHI at rest) and 45 CFR § 164.312(e)(2)(ii) (encryption of ePHI in transit). It defines the algorithms, key management, scope, and documented risk decisions required to keep ePHI within the breach-safe-harbor of 45 CFR § 164.402.

  1. SCOPE

This policy covers every system, device, and transmission path that creates, receives, maintains, or transmits ePHI on behalf of the practice, including:

  • EHR and practice-management systems (production and backup)
  • Workstations (desktop, laptop, mini-PC)
  • Portable media (USB drives, external hard drives, backup tapes)
  • Mobile devices (smartphone, tablet, wearable)
  • Email, secure messaging, fax-to-email gateways
  • Cloud storage and backup services
  • Imaging modalities and PACS
  • Telehealth video platforms
  • All BAA-covered vendor systems that handle the practice's ePHI
  1. ALGORITHM AND KEY-LENGTH BASELINE

Data at rest: Primary: AES-256 (NIST SP 800-111, FIPS 140-2/140-3 validated) Acceptable: AES-128 (FIPS-validated) Prohibited: any non-FIPS-validated cipher; RC4; DES; 3DES; MD5 hashing; Blowfish; proprietary or unpublished algorithms

Data in transit: Primary: TLS 1.3 with strong cipher suites Acceptable: TLS 1.2 with strong cipher suites (NIST SP 800-52r2) Prohibited: TLS 1.0, TLS 1.1, SSL (any version), unencrypted FTP, unencrypted HTTP for any ePHI flow, unencrypted SMS or MMS, consumer messaging apps without BAA

Email: Either TLS-encrypted end-to-end (with DANE or MTA-STS enforced) or a portal-based secure email product with BAA.

  1. KEY MANAGEMENT
  • Keys generated by FIPS-validated cryptographic modules only.
  • Keys stored separately from encrypted data.
  • Keys rotated at least every 24 months and on suspected compromise.
  • Recovery keys escrowed in a documented system; access logged.
  • Vendor-managed keys acceptable when vendor BAA names key

management as a service.

  1. SYSTEM-SPECIFIC IMPLEMENTATION

Workstations and laptops: Full-disk encryption (BitLocker, FileVault, LUKS) enforced by central management (Intune, Jamf, equivalent). Encryption status audited monthly.

Mobile devices: Device-level encryption + MDM-enforced PIN/biometric + remote-wipe enabled. See the BYOD policy for personally-owned devices.

Portable media: Encrypted USB drives only (hardware-encrypted preferred). Backup tapes and external drives encrypted at the volume level before any ePHI is written.

Email: Outbound TLS enforced for any external recipient. Secure email portal used when TLS is not negotiable.

Cloud storage and backup: Encryption at rest enabled at the storage layer; in-transit TLS 1.2+; provider must hold a BAA and provide encryption attestation.

EHR, PM, and imaging: Vendor encryption configuration documented; encryption attestation in the vendor file.

  1. RISK DECISIONS (ADDRESSABLE DEVIATIONS)

Any system that does not meet the baseline must be documented on the Encryption Risk Decision Form (Appendix A). The form names the system, why encryption is not implemented, the alternative safeguard, the residual risk score, and the approving officer.

  1. BREACH SAFE-HARBOR EVIDENCE

For every ePHI-bearing device, the practice retains evidence of encryption: Intune/Jamf report, FIPS validation certificate of the cryptographic module, vendor encryption attestation, or equivalent. On a device loss or theft, the safe-harbor analysis under 45 CFR § 164.402 is performed using this evidence within 24 hours.

  1. ENFORCEMENT

Violations of this policy are subject to the practice's workforce sanction policy under 45 CFR § 164.308(a)(1)(ii)(C). Disabling encryption on a practice-owned device is a Level 3 violation.

Reviewed and approved: ___________________________ Security Officer Date: ________ ___________________________ Privacy Officer Date: ________ ___________________________ Practice Owner Date: ________ ```

Encryption Inventory (Appendix A — copy-ready)

Every audit we sit on opens with this table. Fill one row per system.

| System | Vendor | ePHI flow | At-rest algorithm | Key length | In-transit | FIPS module | Evidence on file | Last verified | |---|---|---|---|---|---|---|---|---| | EHR (prod) | <vendor> | Both | AES-256 | 256 | TLS 1.2+ | Yes (cert #) | Vendor attestation | YYYY-MM-DD | | Cloud backup | <vendor> | Stored | AES-256 | 256 | TLS 1.2+ | Yes | Console screenshot | YYYY-MM-DD | | Workstation fleet | n/a | Both | BitLocker XTS-AES | 256 | n/a | Yes (Microsoft) | Intune report | YYYY-MM-DD | | Provider laptops | n/a | Both | FileVault | 256 | n/a | Yes (Apple) | Jamf report | YYYY-MM-DD | | Email | <vendor> | Transmitted | n/a | n/a | TLS 1.3 | Yes | Vendor attestation | YYYY-MM-DD | | Secure messaging | <vendor> | Both | AES-256 | 256 | TLS 1.2+ | Yes | Vendor attestation | YYYY-MM-DD | | Telehealth | <vendor> | Transmitted | n/a | n/a | E2E + TLS | Yes | Vendor attestation | YYYY-MM-DD | | Portable USB | hardware | Stored | AES-256 hw | 256 | n/a | Yes | Device serial log | YYYY-MM-DD |

Encryption Risk Decision Form (Appendix B)

`` ENCRYPTION RISK DECISION System: ____________________________ Vendor / owner: ____________________________ Why baseline not implemented: ____________________ Alternative safeguard (technical or administrative): ________________________________________________________________ Residual risk score (likelihood × impact): __ × __ = __ Compensating controls in place: □ Network segmentation □ VPN tunnel □ Restricted physical access (server room locked) □ Audit logging + quarterly review □ Other: ____________________ Approving officer: ____________________ Date: ________ Re-review due: ________ ``

How to deploy

The deployment sequence we use across small practices: ratify the policy with the Security Officer, Privacy Officer, and practice owner; pull the encryption inventory by walking every login screen and every storage location (workstations, laptops, mobile, USB, backup, cloud, vendor); fill the FIPS module and evidence columns; identify gaps; remediate the easy ones (turn on BitLocker, enforce TLS on email) inside two weeks; write a Risk Decision form for any system that cannot be encrypted; book a quarterly verification on the calendar.

The fastest measurable improvement comes from enforcing full-disk encryption on every laptop. Most small practices we audit have BitLocker available on every Windows machine and FileVault available on every Mac and have never enforced either centrally. An Intune or Jamf policy that requires encryption and reports compliance moves the practice from unprovable to provable in 30 days.

Common gaps

The five gaps we see most often:

  1. Backup volume unencrypted. The on-prem backup feels physically safe; the safe-harbor analysis does not care. Encrypt before any ePHI is written.
  2. Provider laptop never enrolled in MDM. BitLocker may be enabled, but there is no central evidence. A theft event triggers a reportable breach because the practice cannot prove encryption.
  3. TLS 1.0/1.1 still enabled on the practice email gateway. Outbound mail may negotiate down. NIST SP 800-52r2 disallows it; OCR enforcement record disfavors it.
  4. Vendor BAA in file but no encryption attestation. OCR investigators ask for the attestation, not just the BAA. Most vendors will issue one on request.
  5. No Risk Decision form for known-unencrypted systems. The legacy fax-to-email gateway, the imaging modality with hard-coded credentials, the office printer that retains scanned PHI on disk — each needs a documented decision.

Maintenance cadence

  • Monthly: Intune/Jamf encryption report; remediate any non-compliant device within 14 days.
  • Quarterly: vendor encryption attestation review; portable-media inventory; key-rotation tracking.
  • Annually: full policy refresh; cipher-suite review against current NIST guidance; Risk Decision forms re-reviewed; FIPS module currency confirmed.
  • On any incident: revisit the encryption evidence for the affected system; document the safe-harbor analysis.
  • On any vendor change: new encryption attestation required before go-live.

State preemption note: Massachusetts 201 CMR 17 requires encryption of personal information on portable devices and in transit across public networks — encryption is required, not addressable, for MA residents. New York SHIELD requires reasonable safeguards including encryption. California's CMIA imposes its own breach-notice timelines that interact with the safe-harbor analysis. The federal encryption policy is the floor; state laws layer obligations on top.

How d3rx fits

The d3rx compliance binder generates the encryption policy, the inventory tab, the Risk Decision form, and the quarterly verification workflow with § 164.312(a)(2)(iv), § 164.312(e)(2)(ii), and the HHS Guidance to Render Unsecured PHI Unusable cited inline. The practice's Security Officer remains responsible for verifying the algorithm choices, the key-management process, and the device evidence.

Step 1 · Get the binder

Get the d3rx compliance binder for your practice

Pre-filled to address the gaps this guide covers — HIPAA Encryption Policy Template (45 CFR § 164.312(a)(2)(iv) + (e)(2)(ii)). We will email you the section preview and your binder intake link.

No PHI required. We use your email to send the binder preview and intake link only.

Frequently asked

Do I need to encrypt SMS appointment reminders that contain only a name and a date?

A name combined with a treatment date is PHI under [45 CFR § 160.103](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103). Standard carrier SMS is not encrypted in transit at a level that satisfies the [§ 164.312(e)(2)(ii)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312) addressable specification. Practices either use a HIPAA-aware reminder vendor with a BAA, restrict SMS to non-PHI content, or document a written risk decision that the residual risk is acceptable. The third option requires a written rationale; most practices we work with move to a BAA-covered vendor instead.

Is encryption addressable or required under HIPAA?

Both at-rest [§ 164.312(a)(2)(iv)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312) and in-transit [§ 164.312(e)(2)(ii)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312) are addressable, not required. Addressable does not mean optional. The Security Rule requires the practice to either implement the specification or document why an equivalent alternative is reasonable and appropriate. The HHS Guidance on Securing Electronic Protected Health Information treats unencrypted ePHI as the breach-safe-harbor failure case — a lost unencrypted laptop is reportable; a lost encrypted laptop generally is not.

What encryption algorithm and key length does HHS expect?

HHS's [Guidance to Render Unsecured Protected Health Information Unusable](https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html) points to [NIST SP 800-111](https://csrc.nist.gov/publications/detail/sp/800-111/final) for data at rest and FIPS 140-2/140-3 validated modules for the cryptographic implementation. AES-256 is the operational baseline; AES-128 is acceptable when FIPS-validated. TLS 1.2 with strong cipher suites or TLS 1.3 is the in-transit baseline. RC4, DES, 3DES, and TLS 1.0/1.1 are not acceptable.

Do I need to encrypt the backup tape that lives in the office safe?

Yes. Under [45 CFR § 164.402](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.402), any impermissible use or disclosure of PHI is presumed to be a breach unless the covered entity demonstrates a low probability that the PHI has been compromised through a four-factor risk assessment. HHS encryption guidance separately removes properly encrypted PHI from the definition of unsecured PHI entirely, so a loss or theft of an encrypted device generally does not trigger the breach analysis at all. An unencrypted backup tape that is lost or stolen is presumed a breach unless and until the four-factor analysis documents low probability of compromise — which is rarely defensible for a physical media loss. Practices most often miss the unencrypted laptop backup volume and the unencrypted USB drive a clinician uses to ferry imaging files between locations. The on-prem backup is a frequent gap because it feels physically safe; the safe-harbor analysis does not care about physical custody, only encryption state.

How does Massachusetts 201 CMR 17 or New York SHIELD change my encryption obligation?

Massachusetts [201 CMR 17.04(3) and 17.04(5)](https://www.mass.gov/regulations/201-CMR-17-standards-for-the-protection-of-personal-information-of-residents-of-the-commonwealth) require encryption of personal information on portable devices and in transit across public networks for residents of the Commonwealth — encryption is required, not addressable, when MA residents are in scope. NY SHIELD requires reasonable safeguards including encryption as part of a written information security program. State law tightens what HIPAA leaves addressable. The federal policy is the floor.

What if a vendor refuses to encrypt data in transit from their legacy interface?

Two paths. First, document a written risk decision under [§ 164.308(a)(1)(ii)(B)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308) explaining the alternative safeguard (VPN tunnel, dedicated circuit, segmentation) and why it is reasonable and appropriate. Second, escalate the vendor under the BAA — material non-compliance is grounds for termination under [§ 164.504(e)(1)(ii)](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504). OCR has treated unencrypted vendor links as the practice's risk to manage when the practice knew and did not document.

Turn this into a review-ready binder

The Security Risk Analysis is where this guide becomes documentation you can actually hand to a reviewer — assembled into one review-ready binder. Source-grounded, citation-linked, and explicit about what it does and does not do.

Run the SRA readiness check →See how the SRA works →

Editorial process. This guide was drafted by an LLM (Anthropic Claude) against primary HHS, OCR, CMS, eCFR, NIST, and state-regulator publications, and edited by the D3rx team for restraint and source fidelity. A named credentialed reviewer (CHC, CHPC, or healthcare attorney) is being engaged to verify citations — see the team page for status. Until that reviewer engagement is finalized, this page does not claim credentialed review.

This article is an administrative documentation aid. It does not certify compliance, provide legal advice, replace counsel, or guarantee an audit outcome. The practice remains responsible for reviewing, adopting, and maintaining its compliance program. References cited link to primary sources at HHS, OCR, CMS, the Code of Federal Regulations, NIST, and state regulators.

Authored by D3rx

D3rx is a healthcare-billing and compliance research aid maintained by D3rx Inc. Articles are drafted by an LLM (Anthropic Claude) against primary HHS, OCR, CMS, eCFR, NIST, and state-regulator publications, and reviewed for restraint and source fidelity by the D3rx team.

Reviewer status: a named credentialed reviewer (CHC, CHPC, or healthcare attorney) is being engaged. Until that engagement is finalized, this page does not claim credentialed review.

See reviewer status →Editorial standards →How we research →
Sources & Citations
  1. 45 CFR § 164.312(a)(2)(iv)https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
  2. § 164.306(d)(3)https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306
  3. Guidance to Render Unsecured Protected Health Information Unusablehttps://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html
  4. § 164.402https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D/section-164.402
  5. NIST SP 800-111https://csrc.nist.gov/publications/detail/sp/800-111/final
  6. NIST SP 800-52 Revision 2https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final
  7. Massachusetts 201 CMR 17https://www.mass.gov/regulations/201-CMR-17-standards-for-the-protection-of-personal-information-of-residents-of-the-commonwealth
  8. New York SHIELDhttps://ag.ny.gov/internet/data-breach

Sources verified as of May 23, 2026

Research Aid Notice

This guide is a plain-English summary maintained by D3rx for healthcare practice administrators. It is not legal advice, medical advice, or accounting advice. The authoritative source is the cited regulation or agency document. Always confirm with qualified counsel before acting on a specific compliance question affecting your practice.

Related Guides

Compliance Foundations

Security Risk Analysis Template (2026): What Auditors Actually Want

8 min readCompliance Foundations

HIPAA Workforce Sanction Policy — Template (45 CFR 164.308(a)(1)(ii)(C))

8 min readEmergency Response

Breach Risk Assessment: The 4-Factor Analysis Required by 45 CFR 164.402

9 min read

Related across the archive