Laptops get left in taxis, taken from cars, and lost in airports. When it happens, the question that decides how bad the day gets is not what was on the laptop. It is whether the disk was encrypted, and whether you can prove it.
If you can, a lost laptop is usually an asset write-off and a short incident record. If you cannot, it may be a reportable breach, because you have no way to show the data on it was protected.
This article covers what the frameworks say, what "encrypted" has to mean in practice, why recovery keys are part of the control, how to prove coverage on every device, how to handle personal devices, and what to do when a laptop goes missing.
What the frameworks say
Full-disk encryption is rarely named outright, but every major framework reaches it.
ISO 27001:2022 Annex A 8.1 covers protecting information stored on, or accessible through, user endpoint devices. Annex A 8.24 covers the use of cryptography.
The HIPAA Security Rule lists encryption of ePHI as an addressable implementation specification at 45 CFR 164.312(a)(2)(iv), and device and media controls at 164.310(d)(1). Addressable means you must implement it or document why an equivalent alternative is reasonable. For a laptop that leaves the building, that is a hard case to make.
SOC 2 covers it under CC6.1, which includes protecting information assets through logical access controls, and CC6.7, which covers protecting information when it is moved or removed.
GDPR Article 32 names encryption as an example of an appropriate security measure.
The HIPAA position deserves more detail. HHS guidance on rendering protected health information unusable, unreadable, or indecipherable treats ePHI encrypted in line with NIST SP 800-111 (for data at rest) as not "unsecured". Breach notification duties apply to unsecured PHI, so a properly encrypted lost laptop generally does not trigger them, provided the key was not compromised with it. GDPR has a similar effect for notifying individuals: Article 34(3)(a) removes that duty where the data was unintelligible to anyone not authorized to access it, such as through encryption. Confirm with counsel how either applies to a specific incident. HIPAA technical safeguards for SaaS teams puts the encryption specification alongside the rest of 164.312.
What "encrypted" has to mean
The control is the operating system's built-in full-disk encryption, turned on, covering the system volume, and enforced by policy rather than left to the user. Mainstream desktop operating systems include it, though some editions limit how centrally it can be managed.
A few details decide whether it protects what you think it does:
Encryption protects a device that is off. Once a user has signed in, the disk is readable. A stolen laptop that is powered on and signed in is not protected by disk encryption at all. Screen lock with a short idle timeout carries that part of the load, which is why the two controls are usually checked together.
Sleep is not the same as off. A sleeping laptop may keep its encryption key in memory. That is one more reason to require a password on wake and a short automatic lock.
Linux is easier at install than after. On many Linux distributions, full-disk encryption is straightforward to choose during installation and much harder to add to an existing system. If engineers run Linux, make encryption part of the build standard rather than a later check.
Every volume counts. Secondary internal drives and removable media hold data too. Decide whether your policy covers them, and say so.
Recovery keys are part of the control
Every full-disk encryption scheme has a recovery key that can decrypt the disk if the user's password is lost. Where it lives matters in two ways.
If the only copy is with the user, a forgotten password means lost data. It also means you cannot prove anything about the device centrally.
If recovery keys are escrowed to a central management system, the company can recover the device and confirm its status. That escrow then becomes sensitive: access to it should be restricted, logged, and reviewed, because anyone who can read recovery keys can read every disk.
Proving every laptop, not most
The auditor's test is completeness. They will want the population of devices used to access in-scope systems, and the encryption status of each.
That needs three things to line up:
A device inventory that is complete. Reconcile it against your list of active staff and contractors. Every person with access to company data should map to at least one known device.
A per-device encryption status from a system that reads it from the device, with the time of the last check. A self-reported checklist from each employee is weak evidence.
An exceptions list for any device that is not encrypted, with the reason and the date it will be fixed or retired.
Check new devices before first use, not at the next quarterly sweep. A laptop that ships unencrypted and is set up over a weekend has already held company data by Monday.
For Type II audits, keep the status over time. A monthly export of per-device encryption, dated, shows coverage across the period. The approach mirrors patch management evidence: recurring snapshots answer a question a single report cannot.
Personal devices and contractors
Bring-your-own-device policies make this control harder, because you cannot always enforce settings on hardware you do not own.
There are three workable positions:
Require company devices for anyone accessing in-scope systems. The simplest to evidence.
Allow personal devices that meet a standard, verified by an agent or check that reports encryption status before access is granted. Make it a condition of access, written into the acceptable use policy.
Restrict what personal devices can reach, for example web access to email and chat without downloads, and no production or customer data.
Contractors raise the same choice. Whichever you choose, document it, and make sure the device inventory reflects it. An auditor will ask how a contractor laptop is covered.
When a laptop goes missing
Treat a lost device as a security incident, even if it turns out to be minor.
Record the loss with the device, the user, and when and where it was lost.
Confirm its encryption status from the last check-in before the loss. This is the moment the evidence earns its keep.
Revoke sessions and credentials the device held: identity provider sessions, tokens, and any certificates or keys stored on it.
Issue a remote lock or wipe if the device is managed and comes online.
Assess notification duties. With confirmed encryption and an uncompromised key, this is usually short. Without it, it is not.
Close the record with the outcome.
How TrustLynce helps
The TrustLynce device agent reports disk encryption, firewall, screen lock, and patching status from each laptop, and continuous monitoring routes any failing device to its owner. Each check is dated, so coverage can be shown across the period rather than on the day of the audit.