Full-Disk and Removable Media Encryption Under a Compliance Deadline
A financial services firm with 1,100 laptops must demonstrate encryption of data at rest to keep its payment-card scope and to rely on the encryption safe harbour in breach-notification rules. About 200 laptops are five years old, with spinning disks and 2 GB of memory, and users report they are already slow. Roughly 40 percent of staff work remotely and may go weeks without a reliable connection to headquarters. There are 300 unmanaged USB drives in circulation, issued informally by departments. No recovery-key escrow process exists; the last attempt at a key server was abandoned because two administrators left and the keys were lost with their accounts. Twelve laptops were reported lost or stolen in the past 18 months, and legal has asked what the position would be if one were lost the week after rollout.
1. Define the encryption scope and rollout sequence, and justify what you exclude.
Read the worked answer
Scope: full-disk encryption on all 1,100 laptops as the baseline, plus removable media encryption or a managed, encrypted-USB-only policy for the 300 drives. Servers holding card data are in scope for the same programme but on a separate track, because the failure modes and reboot windows differ.
Sequence: pilot on 60 laptops spanning the oldest hardware and a sample of remote workers, then broad rollout by department with a deployment window per group. The 200 older machines go first, not last: they are the ones where performance complaints will surface, and discovering a disk-performance problem on 60 pilot devices is cheaper than on 200 production ones.
What I would exclude and why: shared kiosks and lab machines where many users log in and disk-level keys would have to be shared, and any machine that cannot complete encryption without a hardware change. Exclusions must be enumerated, time-limited, and covered by a compensating control - no card data stored locally, restricted USB, and network-only access - rather than left as an undocumented gap. An exclusion list without an expiry date becomes permanent within a year.
Performance: measure boot and application time on the pilot before committing to the remaining machines; on 2 GB devices, memory rather than disk is usually the binding constraint, so plan a refresh date alongside the encryption deadline.
2. Design the recovery-key and escrow process so that the previous failure cannot recur, and explain the controls that make it work.
Read the worked answer
Design: keys escrowed centrally in the encryption management platform, never held only by an individual, with a documented break-glass procedure that requires two authorized approvers and produces an audit record for every retrieval.
Controls that make it survive staff turnover: at least three named key-recovery administrators so that two departures cannot orphan the escrow; the escrow service hosted and backed up independently of the administrators' accounts; recovery credentials stored in a sealed, access-logged escrow separate from the management system; and a quarterly test in which a nominated laptop is recovered using only the documented procedure, performed by someone who did not write it. An untested escrow process is an assumption, not a control.
Remote workers: the client must be able to complete encryption and store its recovery material without a live connection to headquarters, syncing later. Otherwise the 40 percent who are offline for weeks will either block the rollout or end up with keys that exist nowhere but on their own disk, which defeats the purpose.
What I would tell legal: safe harbour depends on the key not being compromised and on the data being unrecoverable without it. That argument fails if keys are unaccounted for, which is exactly the previous state. Documenting the escrow and retrieval audit trail is as important as the encryption itself.
3. A laptop is reported stolen three days after rollout. What is your assessment and what do you do in the first 24 hours?
Read the worked answer
Assessment: the position depends on three facts, and I would establish them before making any statement: whether disk encryption was confirmed complete and verified on that specific device, whether the recovery key is accounted for and not exposed, and what data the device held. Encryption changes the notification analysis but does not automatically remove the obligation, and I would say that plainly rather than promising a safe harbour.
First 24 hours: confirm the encryption state from the management console rather than from the deployment spreadsheet; check whether the device has connected since the loss and whether its key was ever retrieved, and by whom; revoke the user's cached credentials and any certificates or VPN profiles on the device; and preserve the console and retrieval logs as evidence. Notify legal and the privacy office with the facts, not with a conclusion.
Reasoning about the standard: the safe harbour generally requires that the data be unrecoverable, which is where key handling matters - if the key sits unencrypted in an escrow that a departing administrator could read, the encryption is arguable at best. I would also check whether the drive was encrypted before or after the last sensitive file was written, since a partially encrypted device is a common and quietly damaging finding.