164.312(a)(2)(iv) Encryption and decryption requirements

What 164.312(a)(2)(iv) encryption requires for stored ePHI

Section 164.312(a)(2)(iv) calls for a mechanism to encrypt and decrypt electronic protected health information (ePHI). It is an addressable implementation specification, which means it is not optional in the sense of being skipped without a reason, but it also does not automatically require encryption in every case. Under 45 CFR 164.306(d)(3), the entity must first assess whether encryption is reasonable and appropriate for its environment. If it is, the entity implements it. If it is not, the entity must document why and implement an equivalent alternative measure, provided that measure is reasonable and appropriate. The assessment belongs in the risk analysis, and the written record of the decision is what an examiner will ask to see.

Under 45 CFR 164.304, encryption is an algorithmic process that turns data into a form that has a low probability of revealing its meaning without a confidential process or key. In practice, this specification is read as protection for ePHI at rest: data in databases, file shares, laptops, removable media, virtual disks and backups. Protection for ePHI moving across networks is handled by the transmission security standard in 164.312(e), so the two should be assessed together but documented separately. The core risk this specification addresses is exposure of stored ePHI through a lost or stolen device, a stolen disk or backup tape, or an unauthorized person or process reading storage directly.

The difficult parts are rarely the algorithm. Key custody is usually the first problem: who can create, rotate, back up and revoke keys, and whether a stolen server could also expose its keys. Databases, backups, logs, search indexes and exports often hold ePHI copies that teams forget to include in scope. Organizations should also confirm that their documented decision covers each storage location, because an encrypted primary system with an unencrypted backup is hard to defend. A useful first step is to list every store that holds ePHI, record whether it is encrypted and by which mechanism, and record the reasoning for any exception.

Which systems and decisions bring 164.312(a)(2)(iv) into scope

Encryption under 164.312(a)(2)(iv) applies wherever ePHI is stored, and the scope is set by where ePHI lives, who holds the keys and what the risk analysis concludes. The cards below cover the decisions that shape the work before any tool is chosen.

Map every ePHI store

Scope starts with an inventory of where ePHI sits at rest: databases, file shares, object storage, endpoints, backups, archives and logs that contain patient data. Each store needs a documented encrypt-or-justify decision. Logs and exports are often missed because they were created by a reporting job rather than an application. Ask the team to confirm which stores were found by discovery and which were found only from the application design.

Identify who holds the keys

The entity must know who can read the keys and who administers storage. Internal teams, a cloud provider, a managed service or a business associate may each control part of the stack. Key custody determines whether encryption protects data from the party that operates the storage. Confirm in writing who generates, stores, rotates and recovers keys, and whether any party can decrypt without the entity's approval.

Let the risk analysis drive the decision

HHS OCR guidance treats whether and how to use encryption under 164.312(a)(2)(iv) and (e)(2)(ii) as a decision the risk analysis should inform. The analysis should record each store, the threat it faces, the likelihood and impact, and the reasoning behind either encryption or a documented equivalent measure. A conclusion that encryption is unnecessary needs the same rigor as a conclusion that it is required.

Check what encryption covers in each platform

Some platforms encrypt file contents but not file names or folder structure. Nextcloud server-side encryption, for example, protects file contents at rest on local and external storage with keys kept on the server, and does not encrypt file names or folder structure. Metadata that reveals patient identity or care context may still be ePHI. Confirm the exact coverage of each product in the environment and record the gap in the risk analysis.

Account for mixed and legacy systems

Older applications, appliances and embedded devices may not support modern encryption at rest or key management. Mixed estates need a per-system decision, with compensating measures such as access restriction, network isolation or a planned retirement date recorded where encryption is not reasonable and appropriate. Confirm which legacy systems hold ePHI, which vendors can enable encryption, and whether a migration plan exists.

Document key management services

Secrets and keys used to encrypt ePHI need their own inventory. Transit-style services such as OpenBao's transit secrets engine can encrypt and decrypt application data without storing it, and support versioned keys with rotation. Scope the key service itself, its access controls, its backups and its audit trail, since a weak key store undermines every encrypted store it serves. Ask the team to confirm rotation procedures and who may request decryption.

How an assessor tests encryption of ePHI at rest

This table sets out how an assessor typically tests the encryption decision for stored ePHI, what evidence they request for each test, and the gaps they most often find. Read it as a checklist to run before an assessment, not as a list of what an assessor must do. Each row covers one area of the review, from the risk analysis record through key handling to backups and endpoints.

Test area	Assessor approach and evidence requested	Common findings
Risk analysis decision	Confirm the risk analysis records a decision on encryption for each store of ePHI, with the reasoning behind it. Request the risk analysis, the risk management plan and the asset inventory that lists ePHI locations.	Encryption not addressed for some stores, or the decision is stated without reasoning or a date.
Storage sampling	Select a sample of databases, file shares, object storage, virtual disks and application stores, then check configuration for encryption at rest. Request configuration exports or screenshots dated within the audit period.	Newly provisioned or test-to-production copies left unencrypted, or encryption enabled on one tier but not another.
Key management	Review who can read, export or delete encryption keys, where keys are stored, and how they are rotated. Request key policies, access lists and rotation logs.	Keys stored on the same disk or in the same file as the data they protect, or broad administrator access to key material.
Documented exceptions	Where encryption was not implemented, check for a written rationale, the equivalent alternative measure and a review date. Request the exception record and evidence the alternative is operating.	Exceptions with no documented reason, alternatives that were never implemented, or exceptions that outlived the system they covered.
Backups and copies	Confirm backup sets, replicas, snapshots and archives follow the same encryption decision as the source system. Request backup configuration and a restore test record.	Unencrypted backup copies, or backup encryption keys held by the same administrators with no separation of duties.
Endpoints and removable media	Check that laptops, workstations and removable media that store ePHI follow the same decision, and that lost or decommissioned devices are covered. Request device management reports and disposal records.	Local caches or downloaded files on unmanaged devices, or encryption reported as enabled without a recovery key process.

How to implement encryption for ePHI stores, step by step

This sequence takes an organization from knowing where ePHI rests to a documented, tested and periodically checked encryption setup, with each step producing evidence an assessor can review. The organization owns the decisions and records; an implementation partner or internal engineers can carry out the technical work.

Inventory ePHI stores and backups
List every place ePHI is stored at rest, including databases, file shares, object storage, endpoints, removable media, email archives, logs that contain ePHI, and backup sets and their offsite copies. Assign each store an owner and note the system, location and data type. Mark stores that are copies of other stores so they are not missed. The output is an encryption register draft that the security official signs off, which confirms the scope the rest of the sequence covers.
Record the encrypt-or-document decision
Using the risk analysis, decide for each store whether encryption at rest is reasonable and appropriate. HHS guidance on risk analysis names this encryption decision as one the analysis should inform. Record the decision, the reasoning and the risk it addresses in the register. Where the answer is yes, the store moves to the next step. Where the answer is no, the record must explain why and identify the equivalent alternative measure, which is covered in a later step. The output is a signed decision record per store.
Choose the encryption mechanism per store
For each store that will be encrypted, select a mechanism. Platform-native encryption, such as full-disk or volume encryption and server-side storage encryption, is often the simplest fit for file and database stores. Application-level encryption fits data that must stay protected from the platform operator. A key service fits cases where many applications need controlled encryption and decryption without holding keys themselves. Confirm each option's capabilities with the vendor or project documentation for your version, because encryption of file names, metadata or indexes often differs. The output is a mechanism table linked to each register entry.
Establish key lifecycle controls
Write a key management procedure covering how keys are generated, where they are stored, who can access them, how they are rotated and how they are recovered or destroyed. Keep keys separate from the data they protect, and limit key administration to named roles, which links to the access control and unique user identification specifications. Where a key service is used, record its rotation settings and audit logging. The output is an approved key management procedure and an access list for key administrators.
Enable and verify encryption with test evidence
Turn on encryption for each store according to the procedure and confirm it works. Capture configuration exports or screenshots showing the setting is active, and run a test that shows the data is unreadable without the key, for example by inspecting raw storage or reading a backup without the key material. Include the restore test for backups so you know encrypted copies can be recovered. Store the evidence with the register entry, dated and attributed to the engineer who performed it. The output is a verification record for each store.
Document equivalent alternatives and their review
For any store where encryption is not implemented, document the reason and the equivalent alternative measure, such as access restriction, physical controls or segregation, and show that it is reasonable and appropriate for that store. Name the owner who approves the exception and set a review trigger tied to changes in the risk analysis. The output is an exception record in the register that an independent assessor can trace back to the decision in step two.
Set up recurring checks
Schedule recurring checks that confirm encryption remains enabled, keys are rotated as the procedure requires, new ePHI stores are added to the register and exceptions are reviewed. Configure alerts for configuration drift where your tooling supports them, and feed the results into the audit log review process. Record each check with its date and result. The output is a recurring checklist and a log of completed checks, which together show the safeguard operates over time and not only on the day it was set up.

Which evidence shows ePHI is encrypted and how to keep it current

Encryption under 164.312(a)(2)(iv) is only as credible as the records behind it. The cards below cover the artifacts an assessor or OCR investigator is likely to ask for, and they connect back to the risk analysis that justifies each encryption decision.

Encryption register tied to risk analysis

List every system, database, file store, backup and endpoint that holds ePHI, and record for each whether encryption at rest is enabled, who owns it, and which risk analysis entry supports that status. An assessor will compare this register against the risk analysis, so a store missing from either document raises questions. Review the register whenever a new system or storage location is added. Confirm each store's status against its configuration, not against the original design.

Configuration exports for each store

Keep dated exports or screenshots showing the encryption setting for each store in the register, such as database transparent encryption status, volume encryption state and object storage default encryption. Exports should show the setting, the scope it applies to and the account or host it came from. For self-hosted Nextcloud, confirm that server-side encryption is enabled in the deployed version and note that file names and folder structure remain unencrypted, which the record should state plainly.

Key management procedure and key-use access records

Document how encryption keys are generated, stored, rotated, backed up and retired, and who may use them. Access records should show which identities used key material and when, so keys are not treated as open to every administrator. For OpenBao's transit secrets engine, confirm the versioned key and rotation behavior in the deployed release, and retain audit logs of encrypt and decrypt requests. Key access records are often the weakest evidence in a file, so review them on a schedule.

Documented decision for unencrypted stores

Where a store is not encrypted, the file must show that the entity assessed the specification as addressable, concluded encryption was not reasonable and appropriate, and documented why. It must also record the equivalent alternative measure, such as access restriction, isolation or compensating monitoring, and why that alternative is reasonable. Attach the decision to the risk analysis entry and set a review date. Without this record, an unencrypted store is hard to defend during an OCR review.

Backup encryption and restore test records

Backups copy ePHI into locations that are often forgotten, so confirm that every backup set, replica and offsite copy is encrypted and that the keys needed to restore it are kept separately from the backup media. Keep restore test records showing the date, the scope tested and whether an encrypted backup restored successfully with its keys. A backup that cannot be decrypted during an incident is a continuity failure as well as an encryption gap.

Secret detection and periodic review records

Stored keys and credentials are a common path around encryption, so review repositories for committed secrets. GitLab Community Edition pipeline secret detection writes findings to a gl-secret-detection-report.json job artifact, which supports keeping credentials out of source code, though it is not an encryption control itself. Pair these reports with dated periodic review records that show who reviewed the register, exports and key logs, and what changed. Confirm the detection rules and report behavior in your deployed version.

What meeting 164.312(a)(2)(iv) costs in money and effort

This table breaks the cost of encrypting ePHI at rest into its components, showing who is paid, whether each cost is one-time or recurring, what pushes it up and what keeps it down. No prices or durations are given because none are supplied, so use the right-hand column to structure a written quote from any vendor, integrator or auditor. The main takeaway is that the inventory of where ePHI is stored usually drives total effort more than the encryption technology itself.

Cost component	One-time or recurring, and who is paid	What drives it up, and what keeps it down
Licenses or tooling	Mostly recurring for commercial key management or storage encryption. Open-source options can remove license spend but still carry hosting and staff time.	Up: number of key services and clouds. Down: platform-native encryption already included in your existing contracts, and open-source components reviewed against your risk analysis.
Engineering time to enable and verify encryption across stores	One-time, mostly internal staff or an implementation partner paid under a fixed-scope agreement.	Up: many databases, file shares, backups, endpoints and legacy systems. Down: a current data inventory and standard configurations applied through automation.
Key management setup and operation	One-time setup, then recurring operation by your staff or a managed service provider.	Up: multiple key hierarchies, manual rotation, and hardware-backed key storage requirements. Down: a single key service with documented rotation and access rules.
Documentation and the risk analysis entry	One-time for the initial record, recurring when systems or keys change. Usually internal staff, with optional outside consultant review.	Up: no existing asset inventory, so each store must be described from scratch. Down: reusing a maintained risk analysis and change records.
Evidence upkeep	Recurring. Internal staff collect configuration snapshots, key rotation logs and exception records.	Up: manual screenshots and ad hoc exports. Down: scheduled exports from logging and configuration tools into a single evidence location.
Documented exceptions and alternative measures	Recurring review cost tied to the risk analysis cycle. Internal staff or counsel, sometimes an outside advisor.	Up: many stores where encryption is declined and must be justified. Down: a short, consistent rationale template and a defined compensating control for each exception.
External testing or review	Optional and recurring. Paid to a security testing firm or consultant, separate from any audit.	Up: broad scope covering many systems and cloud accounts. Down: a written scope that names the encrypted stores and key services under test.
Auditor or assessor sampling time	Recurring if you use an external assessment. Paid to the assessor based on the agreed sampling approach.	Up: inconsistent configuration across systems, forcing larger samples. Down: uniform configuration and a clear list of in-scope stores that the assessor can sample from.

Who owns encryption, who can help, and where the auditor stops

Your organization owns the encryption decision under 45 CFR 164.312(a)(2)(iv). Because the specification is addressable, the Security Rule requires you to assess whether encryption of stored ePHI is reasonable and appropriate, and to record the reasoning. That assessment belongs in your risk analysis, and it must be approved by people who can accept the residual risk. No vendor or consultant can make that call for you.

Risk analysis decision: Document where ePHI is stored, which systems hold it, and whether encryption at rest is reasonable for each one, citing the risk analysis as the basis.
Key custody: Decide who holds encryption keys, where they are stored, who can rotate or revoke them, and how key access is logged.
Alternative measures: If you decide encryption is not reasonable for a system, document why and record the equivalent measure you chose.
Business sign-off: Get written approval from the security official and the accountable executive for the decision and the residual risk.
Operations ownership: Keep the encryption configuration running, monitored and reviewed after the partner hands over the system.

Check that your risk analysis names each system holding ePHI and that the encryption decision for each one has a dated owner and approval.

What the 2025 proposal would change about mandatory encryption

The main change is that encryption would stop being a judgment call. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. Under the proposal, covered entities and business associates would have to encrypt all electronic protected health information at rest and in transit, subject to limited exceptions set out in proposed 164.312(b)(2). Today the same expectation sits in the addressable specification at 164.312(a)(2)(iv), where your risk analysis decides whether encryption is reasonable and appropriate and, if it is not, what equivalent measure you document. The proposal would remove that decision for most systems, so a documented decision not to encrypt would no longer satisfy the rule in the way it does now.

Keep the current addressable documentation in place. The proposal was not final as of October 2026. Until a final rule is published, the existing requirement still governs, and OCR will judge your position against the text in force. Your records of encryption decisions, alternative measures and their justification remain the evidence you would show an investigator. Confirm the current status in the Federal Register before you change policy, because a proposal can be revised substantially before it becomes final.

Plan for a mandatory requirement now, without treating the proposal as settled. The latest Unified Agenda lists the rule under Long-Term Actions with final action projected for July 2027, so the timing is uncertain. Practical steps include inventorying every store of ePHI, including backups, laptops, removable media and cloud object storage; checking which platforms already encrypt at rest and in transit and which need configuration; and estimating what gaps would cost to close. Ask your implementation partner or vendors to confirm in writing which encryption features are available in your versions and whether key management is under your control, since that determines how much of a mandatory requirement you can meet.

Where encryption programs usually fall short and how to close each gap

Most encryption programs fail on paperwork and coverage long before they fail on cipher strength. The gaps below share a root cause: the organization never wrote down what it decided, what it covers, or how it knows the setting is still in force. Each fix is a control the organization owns, and an assessor will test it.

No documented decision for the addressable specification

Because 164.312(a)(2)(iv) is addressable, the rule requires a documented assessment of whether encryption of ePHI at rest is reasonable and appropriate. Many programs enable encryption without recording why, or document a decision not to encrypt with no equivalent alternative. The fix is a written decision tied to the risk analysis, naming each ePHI store, the reasoning, and any alternative measure. Check that the record is dated and reviewed when systems change.

Stores missing from the inventory

Encryption usually covers the primary database and file share, while backups, endpoint disks, application logs, and manual exports stay in plain form. These copies are often created by tooling nobody listed as holding ePHI. The fix is to map every location where ePHI is written, including snapshots, scratch space and report exports, and to confirm each one has an encryption decision in the risk analysis.

Keys stored alongside the data

Encryption offers little protection when the key sits next to the ciphertext, such as in the same volume, configuration file or container image. Server-side schemes that keep keys on the same server protect against some threats but not against a compromised host. The fix is to decide where keys live, restrict who can read them, and document the threat each arrangement does and does not address. Ask the vendor which key custody model the product uses.

Configuration assumed rather than verified

Teams often believe encryption is on because it was on in a test environment, a template or an earlier release. Settings drift during upgrades, new storage mounts and restores. The fix is a recurring check that reads the live configuration of each system and records the result, so the evidence reflects the current state rather than the original intent. Include restored and newly provisioned systems in the check.

No rotation or access review for keys

Keys that are never rotated, and key administrators who are never reviewed, turn encryption into a static secret. Departing staff may keep the ability to decrypt data for years. The fix is a key lifecycle procedure covering creation, rotation, revocation and who may use or export keys, with periodic access reviews. Confirm that the platform supports versioned keys and that rotation does not leave old ciphertext unreadable without a documented plan.

Evidence collected once, not kept current

A screenshot taken during an assessment proves the setting existed on one day and nothing after. Auditors and OCR investigators ask how the organization knows encryption stayed on through the review period. The fix is to automate evidence capture on a schedule, store results with timestamps, and tie each result to the documented decision. Ask whether the evidence can be exported in a form an independent assessor can re-check.

What buyers ask about cost, effort and outside help for encryption

Can our own staff handle HIPAA encryption work without outside help?

Yes, a small team can often handle the work if it has someone who understands both the Security Rule and the systems that hold ePHI. The work falls into three parts: deciding where ePHI is stored and whether encryption is reasonable and appropriate, configuring and operating the encryption mechanisms, and writing down the decisions. The first part depends on the risk analysis, which the organization owns and must keep current. The second part needs administrators who can manage keys, backups and recovery. The third part needs someone who can produce clear records. If any of these three roles is missing, an outside implementation partner can fill that gap under a written scope, while the organization keeps ownership of its decisions.

What drives the time it takes to encrypt stored ePHI?

The timeline depends on how many systems hold ePHI, how many storage locations each one uses, and how much of the environment already supports encryption at rest. Other drivers include whether keys must be managed in a separate service, how many backups and replicas need the same protection, and whether applications must be changed or only reconfigured. Migrating existing data to an encrypted store often takes longer than configuring a new one, and testing recovery from encrypted backups adds time. The organization's own change approval process and staff availability also set the pace. Ask any provider to break its schedule down by system and by phase.

Does encrypting data alone satisfy the HIPAA Security Rule?

No. Encryption is one mechanism under the technical safeguards, and it is addressable, so the organization must decide whether it is reasonable and appropriate. That decision belongs to the risk analysis, which also covers access control, audit controls, integrity, authentication, backup and workforce practices. Encrypted data that is copied to an unmanaged laptop or shared with a user who holds the key still exposes ePHI. An encrypted store also does not replace the administrative and physical safeguards. Treat encryption as a control that supports the rest of the program, not as the program itself.

Can we leave an encrypted store out, and how do we document that decision?

The rule allows an entity to decline an addressable specification if it documents why the specification is not reasonable and appropriate and implements an equivalent alternative measure, provided that measure is itself reasonable and appropriate. Your documentation should name the system, the ePHI it holds, the risk analysis finding behind the decision, the alternative controls in place, and the date of the next review. Simply writing that encryption is too costly does not meet the standard. Have counsel or a compliance lead review the record, because an assessor will test whether the reasoning holds up against your actual environment.

What can an outside partner certify about our encryption controls?

An implementation partner can configure encryption, prepare system documentation and collect evidence, but it cannot certify HIPAA compliance. HHS states that no Security Rule standard requires a certification and that it does not endorse or recognize private certifications. Only the organization can make compliance determinations, and an independent assessor can give an opinion on a defined scope. Any third-party assessment reflects the scope and the evidence provided at the time, so it cannot guarantee future compliance or protect against an OCR finding. Be wary of any provider that offers a HIPAA certificate.

What should a written scope for encryption work include?

A written scope should identify the systems and data stores in scope, the encryption mechanisms and key management approach, the environment where the work runs, and the responsibilities of each party. It should list deliverables such as configuration records, runbooks, test results, backup and recovery verification, and the documentation for any addressable decision. Ask for an explicit list of exclusions, the acceptance criteria, the change control process, and how handover to your staff will happen. Confirm who holds administrative and key access after the engagement ends, and which support or retainer terms apply once the work is complete.

What recurring work follows the initial encryption setup?

Encryption needs ongoing operation after the first deployment. Keys must be rotated and protected, new systems and backups must be brought under the same controls, and configurations must be checked after upgrades. Staff turnover and changes in the risk analysis may require the addressable decision to be revisited. Recurring costs typically include internal staff time, any licensing or hosting for key management, and support or retainer hours if an outside partner handles upgrades. Ask any provider which of these items are included in the quote and which will be billed separately.

How DeployOpen scopes and prepares encryption evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the encryption configuration that protects stored ePHI. We prepare the systems, settings and evidence that your risk analysis and your own compliance team can review, while your organization keeps ownership of the decision and the control.

How we scope

Each engagement starts with a written scope that names the systems, data stores and backups holding ePHI in scope for encryption at rest.
We record the encryption decision your risk analysis reached, including any documented reason for an alternative measure under the addressable rules.
Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope.

How we build

We configure server-side encryption at rest where the platform supports it, and confirm which metadata, such as file names, stays unencrypted.
We set up key management with a documented owner, storage location and rotation procedure, so key handling can be shown during review.
We test that encrypted stores hold no readable ePHI and that keys cannot be retrieved by unauthorized accounts, then record the results.

How we hand over

You receive configuration records, key custody procedures and test results that map each encrypted store to its in-scope ePHI.
Documentation covers how the settings are reviewed, who approves changes and how encryption status is checked after upgrades.
Your compliance lead or independent assessor receives evidence packages; DeployOpen prepares them but does not issue any report or attestation.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering encryption settings across platform changes.
We recheck encryption configuration when you add storage, move data or change key management, and update the documentation to match.
Confirm with your auditor or counsel whether a proposed rule change, such as mandatory encryption, alters the evidence you need to keep.