Encryption at Rest

Encryption at rest means PHI and other sensitive data must be encrypted wherever it is stored (databases, file systems, backups, and removable media) using FIPS 140-2 validated cryptographic modules. To operationalize it, you need a complete data-at-rest inventory, a standard encryption architecture per storage type, strong key management, and evidence that the crypto modules used are FIPS 140-2 validated. ¹

Key takeaways:

• Scope is “stored anywhere,” not just production databases: include backups, snapshots, endpoints, and removable media. ¹
• “Encryption” is not enough; the cryptographic module must be FIPS 140-2 validated. ¹
• Auditors will ask for proof: data inventories, technical configurations, and key management artifacts, not policy language.

As a Compliance Officer, CCO, or GRC lead, you need a fast way to turn the encryption at rest requirement into an auditable control that engineering can implement consistently. HICP Practice 4.3 is explicit: encrypt PHI and sensitive data at rest using FIPS 140-2 validated encryption modules. ¹

This requirement is operationally “sticky” because it cuts across many platforms and ownership boundaries: cloud storage defaults, database teams, endpoint management, backup operators, and third parties that store or process PHI. Most gaps show up in the edges: exports to shared drives, analytics copies, unmanaged removable media, legacy SAN/NAS volumes, and backups that predate your current controls.

This page gives requirement-level implementation guidance you can hand to system owners: what’s in scope, what to implement for each common storage type, how to handle key management, what evidence to retain, and what auditors tend to challenge. The goal is simple: you can demonstrate that PHI and sensitive data is encrypted at rest with FIPS 140-2 validated modules across your environment, and you can prove it on demand. ¹

Regulatory text

Requirement (HICP Practice 4.3): “Encrypt PHI and sensitive data at rest using FIPS 140-2 validated encryption modules.” ¹

Operator interpretation:

1. Identify where PHI and sensitive data is stored (including backups and removable media). ¹
2. Ensure encryption is enabled for those storage layers.
3. Verify the cryptographic modules that perform encryption are FIPS 140-2 validated (not merely “industry standard”). ¹
4. Run key management like a controlled security service: defined ownership, restricted access, rotation approach, and recovery procedures that do not introduce plaintext exposure.

Plain-English requirement: what “encryption at rest” means

Encryption at rest means stored data is unreadable without access to cryptographic keys. Practically, auditors expect this to cover:

• Databases (managed and self-hosted)
• File systems (servers, NAS/SAN, shared drives)
• Object storage (cloud buckets, blob stores)
• Backups and snapshots (including offsite copies)
• Removable media (USB drives, external disks) ¹

“Sensitive data” commonly includes PHI and other regulated or high-impact data classes your organization defines (for example, payer data, clinical trial datasets, credentials, and secrets). HICP’s text is explicit about PHI and sensitive data and calls out the major at-rest storage locations. ¹

Who it applies to (entity and operational context)

Entity types in scope: Healthcare organizations and health IT vendors. ¹

Operational contexts where this requirement typically applies:

• EHR/EMR platforms, patient portals, revenue cycle systems, and care management apps
• Data warehouses, analytics lakes, and reporting extracts that contain PHI
• Backup platforms (cloud backup, tape, snapshot systems)
• Workforce endpoints that store local PHI (clinical laptops, shared workstations)
• Third parties that host, store, process, transmit, or back up PHI on your behalf (your contracts and due diligence must align with this control expectation)

Trigger question to set scope quickly:
“If a device is stolen, a disk is copied, a snapshot is leaked, or a backup is exfiltrated, would the data be intelligible?” If the answer is yes, encryption at rest is not effective.

What you actually need to do (step-by-step)

Step 1: Establish a storage inventory for PHI and sensitive data

Create a living inventory that answers four fields per system:

• System name/owner
• Storage type(s) (DB, file, object, backup, endpoint, removable media)
• Data classes stored (PHI yes/no; other sensitive classes)
• Encryption mechanism and status (enabled/disabled/partial) ¹

Implementation note: teams often have an “application inventory” but not a “PHI at-rest inventory.” Audits hinge on the latter because encryption is applied at the storage layer, not the app diagram.

Step 2: Standardize encryption patterns by storage layer

Pick standard patterns that system owners must follow. Examples:

• Managed databases: require platform-native at-rest encryption, backed by a customer-managed key where feasible. Confirm the underlying cryptographic module is FIPS 140-2 validated. ¹
• Self-hosted databases: use full-disk encryption for the host plus database-native encryption for sensitive tablespaces where needed; validate the crypto module. ¹
• File systems / network shares: encrypt volumes, enforce access controls, and prevent plaintext “PHI shares.” Confirm FIPS 140-2 validated modules in the encryption stack. ¹
• Object storage: enforce default encryption on buckets/containers; block uploads to non-encrypted locations; validate crypto module compliance. ¹
• Backups/snapshots: require encryption before storage and throughout replication; verify both backup media encryption and any transport/handling processes that can create plaintext. ¹
• Removable media: prohibit storage of PHI unless encrypted with approved tooling; require device-level encryption controls and tracking. ¹

Step 3: Implement key management as a control, not a feature

Encryption at rest fails in practice when keys are mishandled. Minimum operational requirements to define and enforce:

• Key ownership: a named team owns key management (often security engineering).
• Access control: limit who can use or administer keys; log key usage and administrative actions.
• Separation of duties: avoid a single individual controlling both encrypted data and keys.
• Key lifecycle: define how keys are generated, stored, rotated, revoked, and recovered.
• Escrow and recovery: document recovery steps and test them without exposing plaintext broadly.

Your audit story should be: “Systems are encrypted; keys are protected; and access to keys is controlled and logged.”

Step 4: Validate “FIPS 140-2 validated encryption modules”

HICP Practice 4.3 explicitly requires FIPS 140-2 validated encryption modules. ¹

Operationalize this with a validation workflow:

• For each encryption implementation (database service, disk encryption product, backup encryption, HSM/KMS), collect vendor documentation stating the cryptographic module is FIPS 140-2 validated.
• Record the product/service version and configuration that corresponds to the validated module claim.
• Where a cloud service offers a “FIPS mode,” document whether it is enabled and where it applies.

If you cannot prove the module is FIPS 140-2 validated, treat it as a gap and track remediation. HICP’s language is binary on the validation requirement. ¹

Step 5: Close the “shadow PHI storage” paths

Common places where PHI ends up unencrypted:

• Ad hoc exports to spreadsheets or CSVs stored on shared drives
• Debug logs or application traces containing identifiers
• Analytics extracts copied to developer workspaces
• Old backup sets and long-retention archives
• Data copied into third-party support systems

Address this operationally:

• Create approved encrypted locations for exports and require teams to use them.
• Add DLP-style monitoring where feasible and set clear handling rules for PHI data extracts.
• Ensure retention/disposal processes cover encrypted backups and that legacy unencrypted sets are remediated or retired.

Step 6: Monitoring and proof

Define how you will continuously prove encryption at rest:

• Configuration monitoring for encryption settings on storage services
• Periodic sampling checks for servers/endpoints
• Backup job configuration reviews
• Exception register for systems pending remediation, with compensating controls and timelines

Required evidence and artifacts to retain

Store evidence in a way you can produce quickly during an assessment.

Core artifacts (auditor-ready):

• Encryption at rest policy/standard specifying scope (PHI and sensitive data), storage types, and FIPS 140-2 validated module requirement. ¹
• PHI/sensitive data at-rest inventory (systems, owners, encryption status, mechanism).
• System configuration evidence (screenshots or exports) showing encryption enabled for each storage type.
• Key management documentation (roles, access controls, logging, rotation/recovery procedures).
• FIPS 140-2 validation attestations from product/service documentation for each cryptographic module in use. ¹
• Exception register with risk acceptance and compensating controls for any gaps.

Third-party specific evidence:

• Contract clauses or security exhibits requiring encryption at rest with FIPS 140-2 validated modules for PHI storage.
• Due diligence responses and supporting documentation from the third party showing the control is implemented.

Common exam/audit questions and hangups

Expect these, and prepare crisp answers plus artifacts:

1. “Show me where PHI is stored and how you know it’s encrypted.” Bring the inventory plus a few deep-dive exemplars with configs.
2. “Does this include backups and snapshots?” Yes; HICP’s summary explicitly includes backups and removable media. ¹
3. “Prove your encryption uses FIPS 140-2 validated modules.” Produce vendor/service documentation and your mapping to systems. ¹
4. “Who can access keys and how do you monitor key use?” Provide IAM roles, logs, and an access review record.
5. “How do you handle endpoints and removable media?” Show endpoint encryption enforcement and policy plus technical controls. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: Encrypting only databases, ignoring backups. Fix by making backup encryption a hard requirement in your storage standards and inventory. ¹
• Mistake: “Encrypted” with no proof of FIPS 140-2 validation. Fix by requiring FIPS documentation as a gating artifact for go-live and for third-party onboarding. ¹
• Mistake: Keys stored with the data or broadly accessible. Fix with centralized key management, least privilege, and logged administrative access.
• Mistake: Exceptions that never close. Fix with an exception register that has ownership and a remediation plan that leadership reviews.
• Mistake: Assuming cloud defaults cover every service. Fix with per-service configuration validation; “default encryption” varies by platform and resource type.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, weak encryption at rest increases impact from common failure modes: lost devices, misconfigured storage permissions, exfiltrated backups, and third-party data exposure. The compliance risk is also straightforward: HICP Practice 4.3 calls for FIPS 140-2 validated encryption modules, so missing validation evidence becomes a documented control gap. ¹

Practical execution plan (30/60/90-day)

You asked for speed. Use this plan as a control rollout sequence, not a calendar promise.

First 30 days: Establish scope, standards, and quick wins

• Appoint an owner for encryption at rest and key management.
• Build the first version of the PHI/sensitive at-rest inventory and identify “highest exposure” storage locations (backups, shared drives, removable media).
• Publish a one-page encryption-at-rest standard: required encryption methods by storage type plus the FIPS 140-2 validation requirement. ¹
• Turn on encryption where it is a safe configuration change (common with managed storage), and capture evidence.

Next 60 days: Close gaps and harden key management

• Remediate systems where encryption requires engineering work (legacy servers, bespoke databases, NAS/SAN).
• Centralize and restrict key administration; implement logging and access reviews for key use.
• Add backup and snapshot encryption verification to backup operations runbooks.
• Start third-party outreach: request proof of encryption at rest with FIPS 140-2 validated modules for any third party storing PHI. ¹

By 90 days: Make it auditable and repeatable

• Complete the inventory coverage and tie it to your system-of-record (CMDB, GRC tool, or security register).
• Implement ongoing configuration monitoring or periodic attestations by system owners.
• Operationalize exceptions: formal approval, compensating controls, and closure tracking.
• Prepare an “audit packet” per major platform (DB, file, object, backups, endpoints): standard evidence set + FIPS validation documentation. ¹

Where Daydream fits: If you manage many third parties, Daydream can centralize encryption-at-rest evidence requests, track FIPS 140-2 validation documentation, and maintain a current exception register tied to each third party and system owner. That reduces the scramble when audits ask for proof across your supply chain.

Frequently Asked Questions

Does encryption at rest include backups and snapshots?

Yes. HICP’s summary explicitly calls out PHI stored in databases, file systems, backups, and removable media as in-scope for encryption at rest. ¹

What does “FIPS 140-2 validated encryption modules” mean in practice?

You need evidence that the cryptographic module performing encryption is FIPS 140-2 validated, not just that the product “supports AES.” Collect vendor/service documentation and map it to the systems storing PHI. ¹

If our cloud provider encrypts storage by default, are we done?

Only if you can prove encryption is enabled for the specific storage services you use and you can document that the cryptographic module is FIPS 140-2 validated. Auditors usually ask for configuration evidence plus the FIPS validation artifact. ¹

Does tokenization or masking satisfy encryption at rest?

Tokenization and masking can reduce exposure, but HICP Practice 4.3 specifically requires encryption at rest using FIPS 140-2 validated modules. Treat tokenization/masking as supplemental unless your storage layer still meets the encryption requirement. ¹

How should we handle PHI on endpoints and laptops?

Treat endpoints as in-scope file systems that may store PHI (downloads, cached files, exports). Enforce full-disk encryption with an approved, FIPS 140-2 validated module and retain evidence from endpoint management reports. ¹

What evidence do auditors want for third parties that store our PHI?

Expect to provide contractual requirements plus third-party-provided documentation showing encryption at rest and FIPS 140-2 validated cryptographic modules for the in-scope services. Maintain this evidence per third party and refresh it on a defined cadence. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices