Does HIPAA require encryption? Addressable status and the breach safe harbor

Data at rest covers ePHI stored on application servers, database engines, file shares, backup media, endpoints such as laptops, and removable media. The organization decides which repositories hold ePHI, whether each is encrypted, which key management service holds the keys, and who can administer them. HHS points to NIST SP 800-111, the guide to storage encryption technologies for end user devices and storage, when describing protection for stored data. The safe harbor also depends on keeping the decryption key separate from the data it protects.

• Inventory the repositories: Map every system that stores ePHI, including backups, replicas, logs and developer copies, since an unencrypted copy is enough to make a breach reportable.
• Choose the layer: Decide between application-level, database-level, volume-level or full disk encryption, and confirm which layer protects data when the system is powered on and logged in.
• Separate key custody: Store keys in a key management system or hardware security module with its own access controls, not beside the encrypted data.
• Confirm validated modules: Ask whether cryptographic modules are FIPS 140-2 or FIPS 140-3 validated and record the validation certificate for the assessor.
• Collect configuration evidence: Keep screenshots or exported configuration showing encryption enabled on each volume, database and backup target, plus key rotation records.

Confirm with your platform team whether encryption is enforced by policy or by default configuration, because an assessor will sample systems and check the setting itself.

Data in motion covers ePHI moving between users and applications, between services, between sites, and to third parties through APIs, file transfers and remote access VPNs. The organization decides which protocols are permitted, which endpoints must enforce them, and how legacy connections are retired or documented. HHS lists NIST SP 800-52 for TLS, SP 800-77 for IPsec VPNs and SP 800-113 for SSL VPNs among the informational publications in its Security Rule guidance, and it names FIPS 140-2 validated processes as an acceptable basis for protecting data in transit.

• Set protocol baselines: Document which TLS versions and cipher suites are allowed for web, API and database connections, following SP 800-52 as the reference.
• Cover internal traffic: Encrypt service-to-service and clinician-to-server traffic inside the network, not only traffic crossing the internet edge.
• Govern remote access: Choose an IPsec or SSL VPN design aligned with SP 800-77 or SP 800-113, and confirm the vendor's cryptographic module status.
• Address email and file transfer: Identify where ePHI leaves by email or SFTP and enforce encryption on those paths, or document the alternative measure.
• Collect scan results: Keep TLS scan reports, VPN configuration exports and certificate inventories that show protocol versions in use.

Confirm with your network team whether any legacy clients or partner endpoints still negotiate weaker protocols, since one such connection can undermine the documented baseline.

Encryption claims are only as strong as the records behind them. An assessor testing addressable encryption typically asks for the risk analysis entry that drove the decision, the configuration showing the setting is enabled, and the key management records. For any repository where encryption was not implemented, the organization must show the documented reason and the equivalent alternative measure. Evidence should be current, dated and tied to specific systems rather than general statements in a policy.

• Risk analysis decision: Retain the entry that rated encryption reasonable and appropriate, or that justified an alternative, with its date and owner.
• System-level configuration: Export settings from each platform showing encryption on, rather than a single screenshot from one server.
• Key lifecycle records: Keep logs of key generation, rotation, access and separation from the data.
• Exception register: Track any unencrypted path, its compensating control and the review date.
• Vendor attestations: Obtain cryptographic module validation details from hosting and software providers that handle ePHI.

Before an audit, ask your team to pick three random systems holding ePHI and produce the configuration and key records for each within a day.

The covered entity or business associate holds the legal obligation under 45 CFR 164.302 and must decide, for each addressable encryption specification, whether encryption is reasonable and appropriate. That decision starts in the risk analysis, is recorded in writing, and is revisited when systems or threats change. If encryption is not adopted, the organization must document why and put an equivalent alternative in place where that is reasonable and appropriate. The organization also decides who holds the keys and makes the breach determination if an incident occurs.

• The addressable decision: Record whether encryption at rest and in transit is reasonable and appropriate for each system holding ePHI, with the reasoning behind it.
• Key custody: Decide who generates, stores and rotates keys, and confirm that decryption keys are not held alongside the data they protect.
• Breach determination: Assess whether an incident involved unsecured PHI and carry out the four-factor risk assessment, since a vendor's encryption claim does not settle this.
• Policies and documentation: Maintain the written policies and the documentation that show the decisions were made and kept current.
• Vendor oversight: Obtain business associate terms that cover encryption responsibilities for any hosting or software provider.

Before relying on any encryption claim, check that the organization can show its own decision record and key custody arrangements.

An implementation partner such as DeployOpen plans, configures and documents encryption inside the client's own cloud accounts, data centers or air-gapped networks. The partner works to the decisions the client has already made and turns them into working configurations, tested settings and evidence the client can hand to an assessor. The partner does not decide whether encryption is reasonable and appropriate for the client, does not own the keys, and does not make breach determinations. Work is normally scoped in writing before it starts.

• Configuration: Enable and document encryption for storage, databases, backups, and transport layers such as TLS and VPNs, using settings the client approves.
• Key management setup: Build the key handling the client has chosen, with separation between keys and data, and document the procedures.
• Evidence preparation: Produce configuration baselines, test results, change records and screenshots or exports that show the controls operate.
• Documentation support: Draft system descriptions and procedure text for the client to review and adopt as its own.
• Ongoing support: Maintain the configuration through upgrades and changes, where the client has contracted for retainer support.

Before engaging a partner, ask for the written scope, the list of deliverables and the evidence artifacts each one produces.

An independent assessor or auditor tests whether the controls work as described and reports on what it found. Assessors may be hired by the organization for a readiness or third-party assessment, or they may be OCR investigators in an enforcement context. Only an independent party can issue a report, but a report is not a HIPAA certificate: HHS does not endorse or recognize private certifications, and such reports do not stop OCR from later finding a violation. DeployOpen does not issue audit reports, attestations or certifications.

• Testing: Sample configurations, review key management records, and check whether encrypted settings match the documented decision.
• Reporting scope: Confirm exactly which systems, periods and requirements the assessment covers and what it does not cover.
• Independence: Keep the assessor separate from the team that built the controls, so the findings carry weight.
• No certification: Avoid describing any assessor output as HIPAA certification, and treat the report as evidence, not a legal finding.
• Engagement terms: Agree the assessor's scope, sampling method and report format in writing before fieldwork begins.

Before accepting any assessment report, confirm its scope statement and what it explicitly excludes.