Check Bitlocker Compliance

What the BitLocker compliance audit Worklet does

This Automox Worklet™ audits BitLocker drive encryption on Windows endpoints by calling Get-BitLockerVolume and inspecting the ProtectionStatus and VolumeStatus of every fixed drive. No configuration is changed at any point. The Worklet is read-only by design, so scheduling it weekly against the entire Windows estate has no operational risk and produces fresh per-drive evidence on every pass.

Each drive is sorted into one of two buckets. Drives with ProtectionStatus On, or with VolumeStatus reporting EncryptionInProgress, are counted as compliant. Every other drive is added to the unencrypted list. The endpoint is reported compliant only when the encrypted count equals the total drive count, so a single unprotected USB-class fixed drive or recovery partition is enough to fail the check.

Targeting is controlled by the $maxSystemtype variable in evaluation.ps1. The default value of 3 evaluates Win32_ComputerSystem PCSystemType 0 through 3 (unknown, desktop, mobile, and workstation) and excludes servers. Raise the value to 8 to include enterprise servers, SOHO servers, appliance PCs, and performance servers; lower it to scope the audit to a narrower hardware class. That single variable is the only edit required to retarget the policy.

Why audit BitLocker compliance on every Windows endpoint

BitLocker is the control most regulators expect on Windows endpoints that store regulated data. Encryption-at-rest requirements show up across HIPAA, PCI-DSS, GDPR, and SOC 2 in different phrasing, but the underlying expectation is consistent: the data on the disk has to be protected with a current cryptographic standard. The hard part is evidence. An audit finding is the absence of proof, not the absence of encryption, and spot checks of endpoint configurations cannot produce a defensible posture.

BitLocker drift compounds quietly. A new hire receives an endpoint that skipped a step in provisioning, a break-fix repair adds a second drive without enabling encryption, a firmware update surfaces a recovery partition that was never in scope. Schedule this Worklet on the laptop compliance policy so Get-BitLockerVolume output streams into the Activity Log on every pass, and the next quarterly review starts from current per-drive evidence instead of a stale spreadsheet. The audit maps to NIST 800-53 SC-28, CIS Benchmark 18.9.11, and PCI-DSS requirement 3.5.

How BitLocker compliance evaluation works

1. Evaluation phase: Reads Win32_ComputerSystem.PCSystemType and compares it against $maxSystemtype. Endpoints above the threshold exit 0 with Device Excluded. Endpoints at or below the threshold call Get-BitLockerVolume, count drives where ProtectionStatus is On or VolumeStatus reports EncryptionInProgress, and exit 0 if every drive is compliant. Any unprotected drive flags the endpoint for remediation and exits 1.

2. Remediation phase: Because this Worklet is read-only, the remediation script's role is to record per-drive evidence in the Activity Log rather than to change encryption state. It re-runs Get-BitLockerVolume and writes two lines: Encrypted and Protected Drives: <mount points> and -- Unencrypted or Unprotected Status Drives: <mount points>. The next responder can target the non-compliant volume with a BitLocker enablement Worklet without re-scanning the endpoint.

BitLocker compliance audit requirements

• Windows 8 or later, including Windows 10, Windows 11, and supported Windows Server SKUs

• PowerShell v4 or higher

• Local administrator context for Get-BitLockerVolume (the Automox agent already runs at this level)

• Windows edition with BitLocker support: Pro, Enterprise, Education, or Server. Home editions return an error from Get-BitLockerVolume and the evaluation exits 1

• Optional: set $maxSystemtype in evaluation.ps1 to scope the audit. Default 3 excludes servers; 8 includes everything

Expected BitLocker audit output

After a compliant run, the evaluation script writes Device Compliant to the Activity Log and exits 0. The endpoint stays out of the remediation queue for this policy until the next scheduled evaluation. When the evaluation flags non-compliance, it writes Not Compliant - Flagging for remediation and exits 1. The remediation script then runs and appends two lines listing the encrypted mount points and the unencrypted mount points. Servers above the $maxSystemtype threshold log Device Excluded and exit 0 without calling Get-BitLockerVolume. Every outcome is timestamped and tied to the policy run, which is the evidence shape most auditors expect.

Match the audit cadence to your compliance program: daily for regulated environments, weekly for general encryption hygiene. To verify the audit on a pilot endpoint, run manage-bde -status from an elevated Command Prompt and confirm the per-drive Protection Status matches what the Activity Log reports for the same endpoint. Manual checks should agree with the Worklet output drive-by-drive.