Encryption at rest

At rest describes a data state

Data is at rest when stored rather than actively moving across a network. Examples include database rows, object storage, file systems, laptops, mobile devices, removable media, backups, snapshots, logs, exports, and vendor support copies.

Encryption in transit protects data moving between systems. Application-level or field-level encryption can add narrower protection inside a database. Full-disk encryption protects a powered-off or locked device under defined conditions. These layers address different threats.

Inventory the storage path

Start with where sensitive data actually resides. Include production, test, analytics, AI tools, temporary exports, email attachments, local downloads, caches, queues, logs, backups, replicas, and retired systems. Record owner, data class, location, vendor, method, key custody, effective date, and evidence.

A vendor may encrypt its primary database while leaving support exports or customer-managed backups outside the claim. Ask for the exact services, environments, algorithms or validated modules where relevant, key arrangement, exceptions, and customer configuration duties.

Key management determines practical protection

Encryption depends on keys. Define generation, storage, access, separation, rotation, revocation, backup, recovery, and destruction. Restrict key-administration roles and log their actions. Avoid storing keys beside the encrypted data under the same credentials.

Plan for personnel changes, vendor termination, suspected compromise, lost devices, corrupted key stores, and emergency access. Test that authorized recovery works before an incident.

HIPAA treats encryption as addressable under the current rule

For covered entities and business associates, current 45 CFR 164.312(a)(2)(iv) lists encryption and decryption as an addressable implementation specification under access control.

HHS explains that addressable does not mean optional. A regulated entity evaluates whether the specification is reasonable and appropriate, implements it when it is, or documents why it is not and implements an equivalent alternative when reasonable and appropriate.

This rule boundary does not answer every other state, contract, payer, insurance, or consumer-health requirement. Record the source and analysis for the actual data and system.

Encryption cannot replace other safeguards

Encryption helps protect confidentiality if storage or media is accessed without the key. It does not decide who should receive authorized access. Use unique identities, role-based permissions, multi-factor authentication where appropriate, audit controls, device security, change management, and prompt access removal.

It also does not prove data integrity or availability. Malware can corrupt encrypted data after an authorized system decrypts it. Lost keys can make intact data unusable. Backups, integrity checks, monitoring, incident response, and disaster recovery remain necessary.

A fictional storage inventory

Morgan’s practice locks an inventory of 30 storage locations. Twenty-seven have current evidence for data class, encryption method, key owner, access, backup coverage, and recovery test: 27 of 30, or 90%.

Three remain held: an analyst export lacks a deletion date, one backup lacks key-recovery evidence, and a vendor log claim omits the support environment. They stay in the denominator with owners and deadlines. The ratio measures evidence completeness rather than compliance or resistance to every attack.

Cloud responsibility follows function

HHS cloud guidance explains that a cloud provider maintaining ePHI for a covered entity or business associate can itself be a business associate even if it holds encrypted data without the key. The customer and provider retain duties appropriate to their roles.

Document who configures encryption, manages keys, reviews alerts, backs up data, investigates incidents, returns data, and verifies deletion. A BAA allocates required terms; it does not certify the selected configuration.

Monitor evidence and change

The NIST Cybersecurity Framework 2.0 provides voluntary general risk-management guidance. In an operating program, track stores with current evidence divided by stores due for review, failed encryption or key events, overdue rotations, unauthorized exports, and successful recovery tests.

Reassess after new systems, migrations, vendor changes, mobile deployment, backup redesign, key changes, incidents, or material legal and contract updates. Keep exceptions time-limited, approved by the proper authority, and paired with compensating safeguards and a resolution plan.

Ask for evidence that matches the claim

Request configuration evidence for the exact tenant, storage service, device, backup, and environment. Review key ownership, administrative access, rotation, recovery tests, exceptions, and alerting. A policy statement or vendor questionnaire can support diligence, while deployed settings and test results show what the practice actually uses.

Sample a locked inventory on a schedule. Count stores with complete, current evidence divided by stores due for review. Report exceptions by data sensitivity, exposure, owner, age, and compensating safeguard. Include temporary exports and newly created analytics stores rather than waiting for the annual review.

When a store fails the gate, stop new sensitive data from entering when safe and feasible, preserve incident evidence, and route the risk to authorized security and privacy roles. Restore service only after the required controls and validation are complete. Record any temporary exception with scope, approval, expiration, monitoring, and a resolution date.