Izveidot kontuCreate account
‹ All playbooks
Respond to a lost or stolen laptop or phone

tech.lost-device·version 1.0.0·draft2 to verify

Respond to a lost or stolen laptop or phone

The lost device is cut off from company data within the hour, wiped, reported where required, and replaced with no data exposure left open.

TomsCTOruns itProfile ›
Whenon an event — a person reports a laptop or phone lost or stolen (device-lost event)
Who actsthe agent acts after approval
Time30–60 min active in the first hour; follow-ups over up to 72 h
CountryLatvia
Sign in to run thisThis playbook opens inside Brain Club. Sign in to read and run it.

When to use

A laptop, phone or tablet that holds or reaches company data is lost or stolen. Not for a device that still works but misbehaves — that is tech.security-audit territory. Not for a compromised *account* with no device involved — revoke credentials, but there is nothing to wipe; use tech.password-rotation alongside. If phishing is suspected as the cause, also file tech.phishing-report.

Before you start

  • The person who lost it is reachable and can answer: locked or not, encrypted or not, last seen when/where.
  • The device inventory (infra module) shows the serial, the user and the management enrolment status.
  • You know the admin channel for remote wipe: MDM for laptops, the phone platform's device admin for phones.
  • The owner on call is named — wipe and notification are their calls, not the agent's.

What a run requires4

  • Approval · S3 · ownerthe run stops until a named person records the decision
  • Irreversible · S4an agent never closes it alone
  • Approval · S6 · ownerthe run stops until a named person records the decision
  • Approval · S7 · ownerthe run stops until a named person records the decision

Any step can wait until a date and reopens by itself; every closed step leaves evidence (a note, a link, a number).

The trail9 steps

  1. Confirm and start the clockagent

    Record the report time, the device, the user, locked/unlocked, encrypted/unencrypted. Note the time in the incident record — the GDPR 72 h clock and the wipe clock both start here.

    Done when the incident record exists with report time and device facts.

  2. Cut access before anything elseagent

    Revoke the user's active sessions and tokens (mail, file storage, admin panels, VPN), force a password reset through the paroles module, and remove the device from trusted-device lists. If the device held bank or payment apps, tell the owner immediately — those need the bank's own blocking.

    Done when the user's old sessions fail on a live device and the new password is set.

    ⛔ Changing the password is not enough — sessions already open on the device may survive a password change.

  3. Decide on wipeownerneeds approval · owner

    Approval · S3 · owner — the run stops until a named person records the decision

    Present: what the device could reach, whether it was encrypted and locked, and the chance of recovery.

    Done when the owner has said wipe now or hold for X hours to try to recover it.

    ⛔ Never let "maybe it turns up" hold an unencrypted device's access open past the hour.

  4. Wipeagentirreversible

    Irreversible · S4 — an agent never closes it alone

    Issue the remote wipe from the device management channel (MDM console for laptops; the phone platform's device admin for phones). If the device is offline, queue the wipe — it fires on next connection — and record that it is pending, not done.

    Done when the management console shows the wipe issued, with a timestamp, or pending with a queue time.

  5. Map what the device touchedagent

    Use bc mail search to list recent mail activity from the user's mailbox (last sign-ins, rules created, forwarding addresses) in the window before the loss. Check for new inbox rules or forwarding — classic signs the mailbox was already abused. Check the infra module for what else was signed in on that device.

    Done when the mailbox activity list is in the incident record and anomalies are flagged.

  6. Report and claimownerneeds approval · owner

    Approval · S6 · owner — the run stops until a named person records the decision

    If stolen: file a police report (Latvia: the nearest state police station or the online portal at polisis.lv) — ⚠ verify the current online reporting address on polisis.lv. If insured or company-leased, notify the insurer or lessor within their deadline — ⚠ verify the notification deadline in the company's insurance policy or lease terms before filing.

    Done when the report/claim reference numbers are recorded.

    ⛔ An agent never files with the police or the insurer — this step is the owner's, with the agent preparing the facts.

  7. Assess GDPR breachownerneeds approval · owner

    Approval · S7 · owner — the run stops until a named person records the decision

    Decide within the 72 h window: did the device hold or reach personal data, and was it protected (strong lock + encryption)? If a breach is likely, notify the Datu valsts inspekcija via edi.gov.lv — the agent prepares the draft, the owner approves and sends.

    Done when the record shows either "notified <date>, reference <id>" or "assessed, not notifiable, because …".

    ⛔ "It was probably locked" is not an assessment — write down what the assessment is based on.

  8. Replace and restoreagent

    Prepare the replacement: enrol it in device management, disk encryption on, screen lock enforced, restore from the backup, and re-issue access the person needs. If no spare exists, open bc tasks add for the purchase and hand the approval to the owner.

    Done when the person works on an enrolled, encrypted device, or a dated task exists for the purchase.

  9. Close the recordagent

    Write the timeline into the incident record: report → access revoked → wipe → reports → assessment → replacement, with times. Link it to the device inventory entry and mark the device as lost/wiped.

    Done when a reader can reconstruct the hour and every decision from the record alone.

Checks — how we know it worked

  • The user's old password and sessions fail; only the replacement device is signed in.
  • The management console shows the lost device wiped (or wipe pending, with the queue time recorded).
  • Mailbox shows no foreign rules, forwarding addresses or sign-ins after the loss time.
  • The incident record has: report time, wipe time, police/insurer references if any, GDPR assessment.
  • The device inventory marks the device lost; it no longer appears as active anywhere.

If it goes wrong

SymptomResponse
Device offline, wipe cannot fireQueue the wipe, record it pending, and treat access revocation (S2) as the real protection; the wipe completes on next connection.
Mailbox rules or forwarding found in S5Treat as a suspected account compromise, not just a lost device: remove the rules, rotate passwords again, escalate to tech.security-audit.
72 h deadline close and assessment unfinishedNotify within 72 h anyway with what is known; a late or amended notification is recoverable, a missed one is not.
Device held bank tokens or payment cardsBlock through the bank first, before S3 — the bank's blocking line is faster than any internal step.
The device was personal (BYOD)Wipe only the work container/profile, not the whole device; record the scope of the wipe in the incident record.

What each step leaves behind

  1. S1the incident record exists with report time and device facts.
  2. S2the user's old sessions fail on a live device and the new password is set.
  3. S3the owner has said wipe now or hold for X hours to try to recover it.
  4. S4the management console shows the wipe issued, with a timestamp, or pending with a queue time.
  5. S5the mailbox activity list is in the incident record and anomalies are flagged.
  6. S6the report/claim reference numbers are recorded.
  7. S7the record shows either "notified <date>, reference <id>" or "assessed, not notifiable, because …".
  8. S8the person works on an enrolled, encrypted device, or a dated task exists for the purchase.
  9. S9a reader can reconstruct the hour and every decision from the record alone.

Evidence to keep

Incident record id · report and wipe timestamps · management console wipe confirmation · mailbox activity search output from S5 · police report number (if any) · insurer claim reference (if any) · GDPR assessment and notification reference (if any) · the owner's decisions in S3, S6, S7 (who, when).

How this playbook improves

After every 5 runs ask: how long from report to access revoked — and what delayed it? Did any wipe stay pending longer than a week? Did any S5 search find abuse the first password reset missed? Were all GDPR assessments finished inside 72 h? A new version changes the step that caused the delay or the miss, and says so in its change note.