The device fleet: encryption, key escrow, and a handover record

A device that carries company email and files is a company asset, even when only one employee ever uses it.

The three steps

Step 1: join it to the company identity. Once the device knows it belongs to the company, policies apply to it, and it can be disconnected the day employment ends.

Step 2: encrypt the disk and escrow the key. Encryption alone is not enough; the question that decides everything is where the recovery key lives. If the employee is the only one holding it, a lost device plus a departed employee means unrecoverable data. Escrow the key automatically to the company account.

Step 3: take a signed handover record. It names the device, its serial, what is on it, and the employee's responsibility. Without a record, recovering the device at the end of employment is a negotiation; with one it is a procedure.

What I always add

A standard device name, for a start. Not DESKTOP-4F9K2: a name that identifies the holder, so the device list tells you whose is whose without searching.

Fully updated before handover, OS and drivers both. A machine that goes out behind on updates tends to stay behind for months.

And a standard application set, so every device leaves with the same baseline.

The recurring trap

An employee leaves and there is data on their device. A fast confiscation misses the point. Keep files in organisational storage from day one and the device only ever holds a synchronised copy; it is a window onto the files, nothing more.

Why this is not administrative work

This work usually gets filed under IT support. On the ground it is applied information security policy: encryption, key escrow and a custody record are the first things a review asks about, and the first things anyone looks for after an incident.

Related reading

• Turning a vague client request into an executable scope
• A private offer page instead of an attachment: what you gain