Full Disk Encryption

Full disk encryption (FDE) means you must enable device-level encryption on every endpoint—especially laptops and mobile devices—so data at rest is unreadable if a device is lost, stolen, or accessed without authorization. Under HICP Practice 2.6, your job is to turn on FDE, enforce it through centralized management, and keep proof that all in-scope devices stay encrypted over time. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Key takeaways:

• FDE is an endpoint control: enforce encryption on laptops, mobile devices, and other endpoints that store or cache sensitive data. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• “Turn it on once” is not enough; you need continuous compliance reporting, exception handling, and offboarding controls. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Audit success depends on evidence: device inventory, encryption status reports, policy, and exceptions with approvals.

Full disk encryption requirement questions usually come down to one operational reality: endpoints walk out the door. Laptops get lost. Phones get stolen. Workstations get reassigned. If protected health information (PHI) or other sensitive data is on the device (or cached by email, browsers, EHR clients, remote access tools, or file sync), the device becomes a breach vector.

HICP Practice 2.6 sets a straightforward expectation: enable full disk encryption on all endpoints, with priority on portable devices, to protect data at rest. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this is to treat FDE like a managed compliance control with four parts: defined scope, technical enforcement, exception governance, and durable evidence.

This page gives requirement-level guidance you can hand to IT/Security and then test as a control owner: what must be encrypted, how to prove it, what auditors ask, where teams fail, and how to execute quickly without losing control of edge cases like BYOD, shared devices, and break-glass accounts.

Regulatory text

HICP Practice 2.6 (excerpt): “Enable full disk encryption on all endpoints, particularly mobile devices and laptops, to protect data at rest.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operator interpretation (what you must do):

1. Define “endpoints” in-scope for your environment (corporate laptops/desktops, mobile devices, virtual desktops with local storage, clinical workstations where applicable).
2. Enable and enforce FDE through centrally managed configuration (not “user discretion”).
3. Prioritize portable endpoints (laptops and mobile devices) because they are most exposed to loss/theft.
4. Maintain proof of continuous compliance: current encryption state for all in-scope endpoints, plus an exception process for anything that cannot be encrypted. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Plain-English requirement

If someone steals a device, they should not be able to read what’s on the drive. Full disk encryption makes the entire storage volume unreadable without the correct credentials/keys. Your compliance outcome is simple: every endpoint that could store PHI or sensitive data is encrypted, and you can prove it on demand. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Who it applies to

Entity types

• Healthcare organizations
• Health IT vendors (including those providing software or services where staff endpoints may access customer environments or PHI) (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operational contexts where auditors expect FDE

• Workforce laptops used for EHR/claims/billing access, revenue cycle, scheduling, imaging workflows, or support.
• Mobile devices used for email, secure messaging, MFA apps, or clinical communications.
• Administrative workstations that store downloads, exports, screenshots, or cached documents.
• IT/admin endpoints with privileged access (these often present the highest blast radius).

Common scoping decision

• If a device can access PHI, assume it can store PHI (downloads, caches, offline files) and include it unless you can demonstrate a strong technical reason it cannot store data locally.

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

1) Set the control statement and scope

Create a short control statement that you can test:

• “All company-managed endpoints must have full disk encryption enabled and enforced. Portable endpoints (laptops and mobile devices) must be encrypted before access to production systems that store or process PHI.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Define scope categories:

• Managed endpoints: Corporate-owned, centrally managed.
• Unmanaged/BYOD: Personally owned or not enrolled in management.
• Special-purpose devices: Shared kiosks, clinical carts, imaging workstations, lab devices (decide case-by-case).

2) Build a complete endpoint inventory

You cannot prove “all endpoints” without an inventory.

• Establish a system of record: your MDM/UEM platform, endpoint management, or asset management system.
• Reconcile data sources: directory services, procurement records, EDR console, MDM/UEM console.
• Identify stragglers: devices with recent logins but missing from management.

Deliverable: an “in-scope endpoint list” with owner, device type, OS, and management status.

3) Choose encryption standards per platform (and document them)

Your policy should specify what “encrypted” means per OS family, using native mechanisms where feasible:

• Windows: BitLocker (with recovery key management)
• macOS: FileVault (with escrowed recovery keys)
• iOS/iPadOS/Android: device encryption enforced via MDM/UEM settings

Keep the requirement high-level in the policy (FDE required), and keep platform specifics in a standard/configuration baseline that Security/IT can update without reissuing the policy every time.

4) Enforce encryption through centralized management

Implementation expectations auditors look for:

• Encryption is required by policy and enforced by technical controls.
• Users cannot permanently disable it.
• Recovery keys are escrowed to an enterprise-controlled system.
• Devices that are non-compliant are blocked from access (where feasible) or quarantined.

Practical enforcement patterns:

• Conditional access gate: allow access to sensitive apps only from compliant (encrypted) devices.
• Enrollment gate: no device management enrollment, no corporate access.
• Compliance monitoring: automated reporting of encryption status.

5) Handle exceptions without losing the control

Some devices fail encryption for legitimate reasons (legacy OS, operational constraints, vendor-managed clinical endpoints). Do not let this become a quiet loophole.

Minimum exception mechanics:

• Written exception request with business justification and device identifiers.
• Compensating controls (examples: no PHI stored locally, VDI only, tightened physical security, restricted accounts).
• Time-bound approval and periodic review.
• A plan to remediate or replace.

6) Operationalize ongoing compliance (the part most teams miss)

Turn FDE into a routine control:

• Daily/weekly monitoring of encryption status (frequency is your choice; make it consistent and defensible).
• Joiner/mover/leaver workflows:
  • New device: encryption enforced before production access.
  • Repair/reimage: encryption re-verified.
  • Offboarding: keys and device custody handled; confirm device is returned or remotely wiped if allowed.
• Incident workflow: if a device is lost/stolen, confirm encryption status quickly and preserve evidence for breach assessment.

7) Validate and test like an auditor

Run a quarterly control test (or your preferred cadence) that includes:

• A sample of devices across OS types and business units.
• Evidence of encryption enabled.
• Evidence of key escrow.
• Evidence that exceptions are approved and tracked.

If you use Daydream to run your compliance program, treat FDE as a requirement with mapped evidence requests (encryption compliance report, policy, exception register) and recurring tasks for control testing so the control stays “audit-ready” instead of “audit-on-fire-drill.”

Required evidence and artifacts to retain

Keep evidence in a form you can produce quickly, with timestamps and scope clarity.

Core artifacts

• Full Disk Encryption policy/standard referencing FDE on endpoints and prioritization of laptops/mobile devices. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Endpoint inventory export showing all in-scope endpoints.
• Encryption status report from your MDM/UEM or endpoint management tool showing:
  • device identifier
  • user/owner
  • OS
  • encryption enabled status
  • last check-in time
• Key management evidence (screenshots or exports) showing recovery keys are escrowed and access is restricted.
• Exception register with approvals, compensating controls, and review dates.
• Control test results (sampling methodology, pass/fail, remediation tickets).

Nice-to-have artifacts (often requested)

• Conditional access/compliance policy screenshots.
• Offboarding procedure showing device return/wipe steps.
• Incident runbook showing how encryption status is checked for lost devices.

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers plus evidence:

1. “Show me that all laptops are encrypted.”
   Provide an inventory + encryption compliance report with the same device counts and reconciliation notes for any delta.

2. “How do you ensure encryption stays enabled?”
   Show enforcement settings, compliance policies, and non-compliance response (block/quarantine/ticket).

3. “Where are recovery keys stored, and who can access them?”
   Provide key escrow evidence and RBAC settings. Auditors care about both availability (you can recover) and access control (keys are protected).

4. “What about BYOD or contractors?”
   Show a policy that forbids local PHI storage on unmanaged devices or requires enrollment before access. Document the access control gate.

5. “Do you encrypt desktops too?”
   If your scope includes them, show compliance. If not, document why (and be careful: “they don’t move” is not always persuasive if they can be accessed physically).

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails audits	Fix
No authoritative device inventory	You cannot prove “all endpoints”	Reconcile MDM/UEM + directory + EDR into one list and document deltas
Encryption enabled but not enforced	Users can disable; drift happens	Enforce via MDM/UEM, restrict local admin, set compliance policies
Missing key escrow	You can’t recover; key control is unclear	Escrow keys centrally and restrict access with RBAC
Exceptions handled in email/Slack	No traceability; exceptions become permanent	Use a formal exception register with approvals and reviews
BYOD allowed informally	Data-at-rest risk remains	Require enrollment or restrict to browser/VDI with no local storage
Evidence is screenshots only	Hard to validate scope/time	Prefer exports/reports with timestamps and device IDs

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should not anchor your program to a specific cited case here. Practically, the risk is straightforward: lost or stolen endpoints create exposure of PHI and other sensitive data. FDE reduces the likelihood that device loss becomes a reportable data exposure event because it makes the data unreadable without authorization. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Practical 30/60/90-day execution plan

First 30 days (establish control and stop the bleeding)

• Confirm executive owner (Security/IT) and control owner (GRC/Compliance).
• Publish or refresh the FDE policy/standard aligned to HICP Practice 2.6. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Build an initial endpoint inventory and identify unmanaged endpoints.
• Turn on FDE enforcement for newly issued laptops and enrolled mobile devices.
• Define exception workflow and create the exception register.

Days 31–60 (drive coverage and evidence quality)

• Enroll remaining endpoints into MDM/UEM or endpoint management.
• Enforce encryption for existing endpoints; remediate failures via reimage/OS upgrade where required.
• Implement conditional access gates for sensitive apps based on device compliance status.
• Produce the first “audit pack”:
  • inventory export
  • encryption compliance report
  • key escrow evidence
  • exception register

Days 61–90 (make it durable)

• Implement recurring monitoring and periodic control tests with documented results.
• Tighten privileged endpoint requirements (admin workstations and IT laptops).
• Run a tabletop for lost/stolen device response that includes encryption verification steps.
• In Daydream, set recurring evidence requests and control test tasks so reports and exceptions stay current.

Frequently Asked Questions

Do we need full disk encryption on desktops, or only laptops and phones?

HICP Practice 2.6 calls for FDE on all endpoints, with priority on mobile devices and laptops. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) If desktops can store or cache sensitive data, include them unless you can justify and document an exception with compensating controls.

Is “device passcode + MDM” enough, or does it have to be full disk encryption?

The requirement is explicitly full disk encryption to protect data at rest. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) Use MDM/UEM to enforce encryption settings; a passcode policy alone does not meet the stated control outcome.

How do we prove FDE is enabled for “all endpoints” during an audit?

Provide a complete device inventory and a current encryption compliance report from your management system that lists each device and its encryption state. Keep a reconciliation note for devices missing from the report and show how you remediate or formally exception them.

What should we do about BYOD phones used for email or MFA?

Decide whether you will require enrollment (and enforce encryption/compliance) or limit access from BYOD to low-risk use cases. Document the rule and enforce it through conditional access so exceptions do not become the default.

What belongs in an encryption exception?

The device identifier, owner, business justification, why encryption cannot be enabled, compensating controls, approving authority, and a review date. Track exceptions centrally so you can show they are controlled and temporary.

Who should be allowed to access recovery keys?

Restrict recovery key access to a small set of authorized IT administrators, and document the access control mechanism and approval expectations. Auditors typically focus on preventing broad access while preserving recoverability.