Lost Laptop Tabletop Exercise: Stolen from a Car Overnight

A lost laptop tabletop exercise walks a small team through the most ordinary data incident there is: a work device goes missing and nobody can say for certain what was on it or whether it was protected. It tests device management, evidence of encryption, breach risk assessment and notification decisions in about 90 minutes.

This stolen laptop data breach scenario is deliberately low-tech. There is no sophisticated attacker, just a car break-in, an HR spreadsheet in a downloads folder and a compliance dashboard nobody has checked for months. It is a good first exercise for legal, HR and IT teams, and a useful reality check for anyone who assumes "all our laptops are encrypted". If this is your first tabletop, read how to run a tabletop exercise before you start.

Scenario at a glance

Exercise objectives

1. Confirm the reporting path for a lost or stolen device and how quickly it reaches IT, security and privacy.
2. Establish, with evidence rather than assumption, whether full-disk encryption was enforced on the device at the time of loss.
3. Decide who can approve a remote lock or wipe, and how that decision is balanced against evidence and recovery.
4. Carry out a documented breach risk assessment covering the data categories, the individuals affected and the likelihood of access.
5. Decide whether notification to a regulator or to individuals is required, and within which deadlines.
6. Identify policy and technical fixes that would make the next lost laptop a non-event.

Starting situation

Read this aloud to players:

It is Tuesday, 07:45. Sam, a regional operations manager, calls the IT service desk from home. Their car was broken into overnight outside their house, and their work laptop bag, left on the back seat, is gone. Sam has already reported the theft to the police and has a crime reference number.

Sam manages a team of 40 and last week was helping HR with an annual pay review. The laptop was last used yesterday evening at home. Sam thinks it was "locked", but is not sure whether it was shut down or just asleep.

Injects timeline

Module 1 — Report and first facts (T+00:00 to T+00:30)

Inject 1. Sam calls the service desk and gives the laptop's asset tag from an old email. The service desk analyst follows the lost-device script: disable the device in MDM, reset the user's password and log a ticket. The script does not say whether to inform security or privacy.

Inject 2. The endpoint administrator checks MDM. The device last checked in five weeks ago, around the time Sam was travelling. Its encryption compliance field reads "unknown": the reporting agent was reinstalled after an operating system update and never re-reported. There is a recovery key escrowed for the device, but it is dated eight months ago.

Discussion questions:

• Who needs to know about a stolen laptop, and in what order? Does your lost-device script include security and the DPO?
• Is a password reset enough, or do you also need to revoke sessions and tokens?
• What would count as proof that the disk was encrypted at the time of theft? Does an escrowed recovery key prove it?
• Why had nobody noticed a device that had not checked in for five weeks?

Module 2 — What was on it, and could anyone get in (T+02:00 to T+24:00)

Inject 3. Sam remembers downloading the pay-review spreadsheet from the HR system to work on it offline. It contains names, employee numbers, current salaries, proposed increases and a column of performance ratings for about 40 staff. Sam's email client was set to cache the mailbox for offline use, including several months of messages with HR.

Inject 4. The security lead reviews identity-provider logs. There have been no sign-ins from unfamiliar locations since the theft. However, refresh tokens issued to the laptop's email client and collaboration app are still valid, because the password reset did not revoke existing sessions.

Inject 5. At 07:50 the next morning, the laptop checks in to MDM from a residential internet connection in a city 200 km away. The pending lock command has not executed yet. The endpoint administrator asks whether to send a wipe now, or to wait so that location data can be passed to the police.

Discussion questions:

• Which categories of personal data were on the device? Does performance data change the risk assessment compared with contact details?
• Who owns the data inventory for this device: IT, HR or the employee?
• Are tokens now revoked for every application? How do you confirm it?
• The device has come online. Does that suggest the disk was readable? What does it tell you, and what does it not?
• Who approves the wipe? What do you capture first, and do you tell the police before or after?

Module 3 — Notification and fixing the gaps (T+30:00 to T+48:00)

Inject 6. The DPO has opened a breach record and asks legal for a decision on notification to the supervisory authority. The DPO notes that the organisation became aware of the loss of personal data on Tuesday morning, so the GDPR 72-hour window for notifying the regulator, where notification is required, ends on Friday morning. Some affected employees live in the United States, where state breach laws also apply.

Inject 7. Rumours travel fast. An employee on Sam's team emails HR: "Someone told me a laptop with everyone's salaries on it was stolen. Was mine on it? Why wasn't I told?"

Discussion questions:

• On the evidence you have, is the breach likely to result in a risk to the employees? A high risk? Who signs off that assessment and where is it recorded?
• If you cannot prove encryption, do you treat the device as unencrypted? What would change your conclusion?
• Do any US state laws that apply to your employees treat encrypted and unencrypted data differently? Who would check?
• Do you tell the 40 employees now, even if you do not have to notify them formally? Who writes the message, and who answers questions?
• Which policy and technical fixes come out of this: encryption enforcement, compliance alerting, offline caching, data downloads, travel guidance?

Discussion questions

Consolidated themes for the hotwash:

• Evidence of controls: Could you prove encryption for any laptop in the fleet today, or only assume it? Who looks at the compliance report, and how often?
• Authority: Who can approve a remote wipe, and is that written into the lost-device procedure?
• Data sprawl: Why was HR data on a line manager's laptop? Is downloading from HR systems necessary, and is it logged?
• Notification: Was the risk assessment documented with enough reasoning that a regulator would understand it? See the data breach notification scenario for a deeper treatment.
• People: Was Sam treated as a witness who could help, or as someone at fault? Would the next person report as quickly?

Curveballs / optional injects

Use one if the group finishes Module 2 early:

• The laptop bag also contained a paper printout of the pay review, annotated by hand.
• Sam admits the laptop password was written on a sticky note in the bag.
• A second manager reports that they also downloaded the pay-review spreadsheet, and their laptop has not checked in for three months.
• The police call to say they have recovered a batch of stolen laptops and ask you to identify yours.

Facilitator notes

Expected decisions. A well-prepared team routes the report to security and privacy within the first hour, revokes sessions as well as resetting the password, establishes quickly that encryption cannot be proven, and treats the device as potentially readable until evidence says otherwise. It approves a wipe with a named approver once location data has been captured and shared with the police, completes a written risk assessment before the 72-hour deadline and gives affected employees a short, honest message from HR.

Common pitfalls.

• Closing the ticket after the password reset, so security and the DPO hear about the theft days later.
• Treating "we have a policy requiring encryption" as proof that the device was encrypted.
• Wiping immediately without recording device details, or waiting indefinitely for police action that never comes.
• Deciding not to notify without writing down why, which leaves nothing to show a regulator later.
• Leaving HR to answer employee questions without a script, so different people hear different stories.

On regulatory detail. Keep legal discussion at the level of principles. GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal-data breach, where feasible, unless it is unlikely to result in a risk to individuals, and notification to individuals when the risk is high. US state breach laws vary, and several treat properly encrypted data differently. Players should know who would confirm the details; the exercise is not legal advice.

Adapting the audience. For a technical group, spend longer on Module 1: how the compliance gap arose, how to query encryption state for the whole fleet, and how token revocation works across applications. For a legal and HR group, summarise Module 1 in a briefing and give the time to injects 3, 6 and 7. You can run this scenario live with the free exercise runner, which releases each inject to players' phones and collects decisions for the after-action report.

Evaluating the exercise

Related

• Data breach and regulatory notification scenario
• Insider threat tabletop scenario
• Tabletop exercises for small businesses
• Writing the after-action report
• Glossary: inject, hotwash, playbook