> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Endpoint Encryption Audit

> Audit disk-encryption coverage across a client's endpoints — BitLocker on Windows, FileVault on Macs — flag unencrypted devices, and verify recovery keys are actually escrowed somewhere retrievable. Use for "are all their laptops encrypted", compliance evidence, or after a lost laptop raises the question.

<Info>
  **Category:** Devices & Infrastructure · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/devices-and-infrastructure/endpoint-encryption-audit/SKILL.md)
</Info>

**Connectors:** `NinjaOne` `Liongard` `IT Glue` `Hudu`

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner)

**Outcome:** Risk & Compliance

**When to use:** "Are all of \<client>'s laptops encrypted?" for compliance/insurance, a lost-device breach-severity question, or "do we actually have the BitLocker keys for these machines?"

**Run it:** across a client's endpoint fleet, on demand (not a Flow — it's an audit/evidence pass, not a per-ticket event).

## Prompt

```
Two mandatory questions: is every endpoint's disk encrypted, and if a device died tomorrow could the desk retrieve its recovery key? Coverage without escrow is a lockout; escrow without coverage is a breach.

1. Build the endpoint population from the RMM (pull the device list, verify workstation/laptop class in the details — don't trust a class filter) — this is the denominator. If listings may have capped, the denominator is "at least N" and the audit says so.
2. Gather encryption state per device, best source first: RMM device details where they expose encryption/volume status; the environment's posture in Liongard via its Windows and M365/Entra inspectors (confirm the inspector exists and last ran successfully, then read BitLocker status and escrowed-key presence — state dataprint age); documentation (IT Glue / Hudu) last, with staleness named. Devices with no encryption evidence go in an "unknown" bucket — unknown is not unencrypted, and it is definitely not encrypted.
3. Bucket the fleet: encrypted with key escrowed, encrypted with NO escrow evidence (one dead motherboard from permanent data loss), not encrypted, and unknown. Macs: FileVault status typically needs MDM data (a Liongard/Intune path or MDM export); if no Mac source exists, the Mac fleet is "unknown", stated plainly.
4. Escrow verification — evidence, not assumption: identify where keys should live (Entra/AD, MDM, doc-platform flagged fields, per client policy from docs) and verify presence for audited devices. Presence of a key object is the pass bar; confirming a key unlocks its volume is a hands-on test — recommend it for a sample, never claim it.
5. Flag and route: unencrypted -> remediation ticket (enabling encryption is policy/hands-on, and old hardware without TPM needs per-device assessment); encrypted-without-escrow -> "capture key before anything else" ticket flagged urgent-quiet (no reboots, no firmware updates on that device until the key is escrowed); unknowns -> a verification pass. Check ticket history for an existing encryption project before opening duplicates.
6. Output: coverage summary (encrypted+escrowed / encrypted-no-escrow / unencrypted / unknown, with percentages against the stated denominator), per-bucket device lists, evidence source and freshness per claim, tickets opened. Leave the plain-text summary as a note (no markdown/emojis). For compliance requests, state clearly this is a point-in-time technical audit, not a compliance certification.

Guardrails: recovery keys are NEVER reproduced in any output, note, or ticket — location and existence only (a key pasted into a ticket is itself a security incident). "Unknown" is its own honest bucket — never fold it into either side. Encrypted-without-escrow devices must not be rebooted, firmware-updated, or have TPM changes until the key is captured. Every encryption claim carries its evidence source and age; Liongard data is used only when the inspector shows a successful recent run. This skill enables nothing and rotates nothing. If neither the RMM nor Liongard is available, degrade to docs + ticket history and label it "unverified — evidence-gathering pass required".
```


## Related topics

- [Data & Encryption](/security-billing/data-encryption.md)
- [Security & Compliance Owner](/start-here/roles/security-compliance-owner.md)
- [Sophos Endpoint Alerts](/skill-library/vendor-runbooks/sophos-endpoint-alerts.md)