A Reimaged Laptop and a 30-Day Retention Clock
An analyst at the EU subsidiary of a US company resigns on a Friday and hands back a Windows 11 laptop. On Monday the security team learns from a peer that the analyst forwarded more than 40 client pricing spreadsheets to a personal Gmail address over the previous three weekends. Legal opens a matter and wants a forensic report within 10 days. By then: IT has already reimaged the laptop and issued it to a new hire; the M365 tenant uses 30-day default retention with no litigation hold, and the mailbox was converted to shared; USB device history would have lived in a registry hive that no longer exists; the badge system retains 90 days; the proxy retains 14 days of full URLs; and the EU works council agreement requires notification before monitoring employee communications. The employee is in a jurisdiction where consent to device search is not implied by the employment contract.
1. What evidence is still recoverable, and in what order do you collect it?
Read the worked answer
Order by retention expiry, not by apparent importance. The laptop is gone; the cloud data is on a clock.
- Immediately: apply an eDiscovery or litigation hold to the mailbox and OneDrive. This stops the 30-day deletion, preserves versions, and takes minutes - it is the only action that prevents further loss.
- Within 14 days (proxy window): export full URL and upload records for the analyst's account and device, plus any DLP or CASB alerts for gmail.com destinations. Capture the three weekends now, before they age out while you are still scoping.
- M365 unified audit log: search Send, MailItemsAccessed, FileDownloaded, and sharing events. Confirm the tenant's audit retention - often 90 or 180 days, but it can be shorter than the mailbox hold and is a separate clock.
- Endpoint telemetry: Intune/Defender for Endpoint cloud history may still hold process, file, and network events for the reimaged device (vendor retention is commonly 30 days). Export by device ID.
- Badge records: 90-day window, quick to pull, corroborates physical presence on the weekends in question.
- The laptop: check for a retained old disk, a deployment tool's pre-imaging backup, or Windows.old - and check whether the device was BitLocker-protected with an escrowed recovery key, because without the key a recovered disk is unreadable.
The 40 forwarded files may be provable from the cloud side alone; that is exactly why the order matters.
2. How do you handle the fact that IT reimaged the laptop? What do you document, and how do you write the report?
Read the worked answer
Document the loss honestly; do not present the device as evidence.
Record facts: who reimaged it, when, under which ticket, what the IT offboarding procedure said, and whether anyone had been instructed to preserve it. That is a factual statement, not an accusation - and it will be requested if the matter reaches a court or a regulator.
Recover what remains: the reimage may not have destroyed everything. Check for a retained drive, a deployment tool's pre-image backup, Windows.old, a migrated profile on the new hire's device, and cloud-side records from the endpoint agent. Flag the new hire's device as hold-relevant if the old profile was carried across.
Write the report with explicit limits. State that local artifacts - USBSTOR history in the SYSTEM hive, recent-file LNKs, browser history, the local OST - were unavailable because the device was reimaged on a specific date, and that findings rest on server-side and network records. “We could not determine X because the device was reimaged on date Y” is a stronger and more defensible conclusion than an inference stitched from incomplete data.
Fix the process: add a legal-hold flag in the asset and identity systems so a returned device is quarantined, and place a hard stop between HR offboarding and IT reimaging. Recommend it in the report; it is the same failure that will otherwise happen on the next case.
3. What legal and procedural constraints change the collection, and how do you keep the report usable?
Read the worked answer
Two constraints reshape the plan, and both require legal involvement before collection, not after.
Works council and monitoring. The agreement requires notification before monitoring employee communications. Pulling and reading a mailbox is monitoring. Get legal to confirm the applicable basis - commonly the employer's defense of legal claims, which can override some data-subject objections - and whether the works council must be informed or consulted in advance. If consultation is required and skipped, the collection may be unusable and the company faces a separate labor-law exposure larger than the original theft.
Minimization and auditability. Collect only what the allegation requires: the 40 spreadsheets, the recipients, the dates. Not the whole mailbox. Use eDiscovery search terms, review inside a tool with an audit trail, log every export with hash, custodian, and time, and keep the reviewer list small and documented.
Jurisdiction. Do not assume the US parent's policy applies; local law governs this employee's data. Check whether consent is valid in an employment relationship (often it is not). Keep the report factual - what was found, where, and what could not be determined. No conclusions about intent. Give legal a defensible record and let them characterize culpability.