Encryption standards at rest, in transit, and on removable media, with the addressable-specification rationale structure included.
What is in the download
- Format: DOCX
- Length: 5 page(s) / file(s)
- Includes: rule citations, fill-in guidance in the margin, and a completed example
- Licence: free to modify and use commercially
What is in the template
Encryption appears in the Security Rule twice, both times as an addressable specification — at rest under access control (§164.312(a)(2)(iv)) and in transit under transmission security (§164.312(e)(2)(ii)) — and “addressable” is the reason this template has the structure it does. The policy sections cover: scope (which systems and data classes the policy binds); encryption at rest for servers, databases, and managed storage; full-disk encryption for laptops and workstations; encryption in transit, naming TLS as the baseline for anything crossing a network; removable media, where the defensible default is “encrypted or prohibited”; mobile devices, cross-referencing your BYOD rules; and key management — who controls keys, where they live, and what happens when a key holder leaves, which is the section most home-grown policies omit entirely.
The distinctive inclusion is the addressable-specification rationale worksheet: a fill-in structure for documenting, per environment, either that you implement encryption, or the equivalent alternative you use, or the reasoned assessment of why neither is reasonable and appropriate. That written rationale is what the rule actually demands, and it is the artefact generalist templates never provide a home for.
How to use it
- Read it end to end before filling anything in.
- Delete every clause describing a control you do not have. An untrue policy is evidence against you.
- Assign an owner and a review date to each section.
- Publish it, collect acknowledgements against the version number, and retain both for six years.
How to customise it
Inventory before you write: list every place ePHI rests — production databases, backups, file storage, laptops, the odd USB drive — and every route it travels, then set the policy’s scope to that list. Name your actual mechanisms (your cloud provider’s storage encryption, your MDM-enforced FileVault or BitLocker, your TLS termination points) rather than abstract standards nobody can verify. Keep algorithm specifics in an appendix you can update without re-issuing the policy. The stakes worth remembering as you decide how far to go: ePHI encrypted to HHS specifications is “secured” under the Breach Notification Rule, meaning the lost laptop or misdirected backup is an incident log entry rather than a 60-day notification exercise. That asymmetry makes encryption the single highest-leverage technical control in the programme, and it is why the honest rationale for skipping it almost never survives being written down.
Common mistakes
- Claiming what the checkbox does not cover. “Everything is encrypted” usually means the cloud console’s default is on — while the export on a laptop, the backup at the old provider, and the USB drive in a drawer are not. Policy scope must match the inventory, not the console.
- No key management section. Encryption with keys in a shared document is a lock with the key taped to it, and a departed engineer who held keys is an access problem encryption cannot fix.
- Ignoring the transit residue. TLS on the app is the easy 90%; the findings live in email to patients, SMS, and vendor support channels. Name the approved channels for ePHI explicitly.
- Writing the rationale after the incident. The addressable-specification reasoning dated three days after the laptop went missing convinces nobody. Complete the worksheet when you adopt the policy.
- Stricter policy than practice. A policy mandating encrypted removable media at an organisation that has never configured or checked it is self-documented non-compliance.
Related templates
The encryption policy pairs naturally with the access control policy (who reaches the data encryption protects), the password policy (the credentials and keys themselves), and the BYOD and remote work policies (the devices that leave the building). The technical safeguards guide explains both addressable specifications in context, and the risk assessment template is where the inventory this policy depends on gets built.
The honest limitation
A template is a starting point, not a program. It cannot record who acknowledged it, prove it was followed, or update itself when your environment changes. Those three things are what the platform does, and they are the difference between having documents and having compliance.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.