Lost and Stolen Devices: The First Hour Is About the Data

Tuesday, 06:40, at Harbourview Clinic. Grace, a community nurse, rings the early-shift number from a borrowed phone. "I've left my work phone on the bus. I only noticed when I got to the first visit." Tom has been on shift for ten minutes and has not finished his coffee. The phone has her work mail on it, the authenticator app that lets her into everything, and the visit app with the day's patient list. Grace is already apologising. Tom has a decision to make in the next five minutes, and it is not about the phone.

A lost or stolen device event is the hour between the report and containment. And it is a security ticket that happens to involve hardware rather than a hardware ticket with a security flavour. The desk's job in that hour is to make whatever the phone holds useless to whoever holds it. Lock it, end its sessions, reset what it knew, and only then think about the handset. This article is part of our Mobile Device Support series. It is written from the defender's side only. The desk triages and contains. Anything beyond that, the investigation, the evidence and the legal process, belongs to the security function and is handed over, not attempted.

It covers why this is a security event before it is a hardware ticket, then the report, what to ask and what not to. Next come the lock-or-wipe decision and who makes it, then the account, password reset and session revocation in plain words. We cover the carrier and the SIM, then the police report where the organisation requires one. Next come discretion and no blame, the hour, minute by minute, and what happens after the hour. We finish with a short war story and the lost-device runbook to copy, in that order.

A Security Event Before It Is a Hardware Ticket

The handset is the smallest number on the ticket. What makes a lost phone matter is what it is signed into. There is a mailbox, open and readable. There is the authenticator app, which is the key to every other account the organisation has protected with a second factor. There is the VPN client, if one was installed, which reaches the office network. There are saved passwords in the browser and any work app with customer, patient or financial data in it. Until the phone is locked, wiped, or known to be at the bottom of a harbour, all of that is potentially in someone else's hands. The handset is replaceable in a day. The mailbox was readable in a minute.

This ticket jumps the queue, and the desk should decide that in advance rather than at 06:40. On a fictional desk of four, a lost device is the one ticket type that outranks everything but a major incident. The technician who takes the report does the containment steps before touching anything else. The ticket is logged at once, with the time of the report and the time the user thinks the phone was lost. Those two times will be asked for later by people who were not on the call. A desk that logs the ticket after the containment has lost the one record that matters.

The user is not the problem. Phones are lost on buses, left in taxis, lifted from restaurant tables and dropped in rivers, and the organisation's arrangements are supposed to survive it. The only outcome that genuinely causes harm is a late report. And the surest way to produce late reports is to make the last reporter feel foolish. Everything in this article is written on that assumption: the desk's tone in the first minute sets the organisation's cost for the next year.

The Report: What to Ask and What Not To

Ask for the facts that change what the desk does next, and nothing else. Is it a company phone or a personal one with a work profile? When was it last seen, roughly, and where? Was it locked with a passcode, a fingerprint or a face, or was it open? What work was on it: mail, the authenticator, the VPN client, any app with customer or patient data? Is there a real chance it is misplaced rather than lost, in the car or the other coat? Has the carrier been told? And, so the desk can reach them, what number or device is the user on now? Seven questions, two minutes, written into the ticket as they are answered.

Do not ask how it happened, why the passcode was off, or anything that begins with "why didn't you". The answers do not change the containment steps and the questions change whether the next person reports at 06:40 or on Monday. If the organisation needs the story for an insurance claim or a review, someone else asks for it later, in writing, calmly. The desk's script is "thank you for ringing straight away; here is what I'm doing now", and it is said before the first question.

The caller has just lost their usual proof of identity along with the phone, and the desk should notice. The second factor is gone, the voice may be unfamiliar, and the number they are calling from is not theirs. That matters less than it seems for the first steps. Locking a device and ending its sessions remove access and are safe to do on anyone's say-so. Nobody rings a help desk to have their own phone locked as a prank, and if they did, the cost is an unlock. It matters a great deal for the later steps, the password reset and the re-enrolment, which grant access. Those are done only after the caller has been confirmed by another route. The standard for that confirmation is in Verifying Identity Before You Reset Anything. For Grace it was her manager, reached on a number the desk already held.

The Lock-or-Wipe Decision, and Who Makes It

A remote lock uses the management profile to lock the phone from the organisation's side. Usually there is a message on the screen and a number to ring. The lock is reversible: the data stays on the phone, encrypted behind the passcode, and an unlock restores everything if the phone comes back. A remote wipe erases the device, and on a company phone that means everything, personal photos included. On a personal phone with a work profile it means the work profile only. That is the organisation's whole reach and leaves the rest of the phone untouched. Lock is cheap and undoable. Wipe is final and certain. The decision between them is the only real decision in the hour. And it should not be made by the technician alone or for the first time at 06:40.

Write the decision rule down, with a name against it. On the fictional desk, the technician locks a company phone immediately on any report, with no approval, because a lock costs nothing to reverse. The technician removes the work profile from a personal phone immediately for the same reason, because the user's own data is not touched. The wipe of a company phone is decided by a named role, the security lead or the desk lead, within a stated window. The decision is at once if the phone was stolen rather than lost, or if it held regulated data. Otherwise it is after a short wait for the misplaced phone to turn up, measured in tens of minutes rather than days. The table below is the shape of that rule; the names and the window are the organisation's to fill in.

The trap is the wait. The user thinks it will turn up, and the technician does not want to erase three years of someone's photos. The window stretches to a day, and then the weekend. The rule fixes the window so that nobody is choosing under pressure. The handover message on the day the phone was issued said that a company phone can be wiped. It said that personal data on it is at the owner's risk. That is the subject of What the Desk Supports on a Phone. The wipe is kinder than it feels. The alternative is a stranger reading the mailbox while everyone waits to see.

The Account: Password Reset and Session Revocation in Plain Words

A session is the signed-in state a service remembers so that the user is not asked for a password every time they open the app. And a lost phone carries a live session for every work app on it. Locking the phone does not end those sessions on the server; it stops the screen being used. Wiping ends the sessions on the device, once the wipe lands, which it cannot do if the phone is switched off or out of signal. So the desk ends them from the other side, centrally, in each service that issued one. That includes the mail service, the file service, and the chat tool. It includes the identity service that handles the organisation's single sign-on and the VPN. Each has a way to sign a user out everywhere. The mechanics are the same as for a leaver, where the full list of places to revoke is set out in The Offboarding Checklist. Keep that list by the phone, because this is the same list run at 06:50.

Reset the password as well, by a route that has confirmed the caller. A phone may have had the password saved in its browser or visible in a note. And a reset on its own does not end sessions in many services. Do both, in the order revoke then reset, and test on your own services which one actually signs the phone out. Tools differ and the answer is not always what the documentation implies. Then remove the lost phone as a registered second factor, so that codes or approvals from it stop counting. Leave the user with a temporary way back in through the route the organisation already uses for a lost authenticator. The re-enrolment on the replacement phone comes last and is verified like any other. That runbook is in Second-Factor Problems, and this article only fixes its place in the order.

Each action goes in the ticket with the time, in the technician's own words, as it is done. For example: "06:44 device locked; 06:49 mail and file sessions revoked; 06:52 identity service signed out everywhere; 06:55 second factor removed; 07:05 password reset after manager confirmed by phone." The times are what the review will ask for and what the data protection owner needs to decide whether anything was exposed. If you run QuerySolv, the ticket's event history already records when each note and reply was written. In that case, the timestamps are the tool's and not the technician's memory. In any tool, the internal note carries the actions and the times and never the new password. The password goes to the user by the reset route and nowhere else.

The Carrier and the SIM

The SIM is a second, smaller device inside the first, and it keeps working after everything else is locked. It receives text messages, including any codes the organisation or the user's own services still send by text. It carries the number, which someone holding the phone can use to look like the user. The carrier can block the SIM and issue a replacement on the same number. For a company phone that is done by whoever holds the carrier account. That should be a name on the runbook with the account reference beside it. For a personal phone the user does it, and the desk's job is to say so in the first ten minutes and ask whether it has been done.

If anything in the organisation still relies on a text message as a second factor, the SIM block is urgent rather than tidy. Until the SIM is blocked, those codes are arriving on a phone the organisation does not hold. The longer-term answer is the authenticator app rather than text for anything the organisation controls. That is a decision for the security function. The desk's part is to know which services still use text, so that the carrier call moves up the list when one of them is involved. The platform's own locate-and-lock feature, which many users have switched on for themselves, is worth asking about too. It can show where a misplaced phone is and lock it. A user who has it may find the phone in the car before the desk has finished the first note.

The Police Report, Where the Organisation Requires One

Whether a police report is made is the organisation's policy, not the desk's judgement. The policy usually says when: a theft rather than a loss, or an insurance claim on the handset. Another usual case is a device that held personal data about customers or patients. In that case, a regulator may need to be told and will ask whether the police were. The desk's part is to know what the policy says and to tell the user to make the report where it applies. The desk puts the reference number in the ticket when it arrives. The desk does not investigate, does not contact anyone who might have the phone, and does not try to recover it. A technician who turns detective is a liability to everyone including themselves.

Where the phone held regulated data, the data protection owner is told within the hour, with the facts and the times and nothing else. The decision about what to tell a regulator or a customer is theirs. The route for handing a ticket like this to the security function, and what the desk keeps doing in the meantime, is set out in Other Security Tickets the Desk Will See. The desk contains and reports. The assessment is someone else's job, and the desk should be glad of it.

Discretion and No Blame

The people who are told are the people who need to act. That includes the user's manager, for the replacement and the cover, and the security lead. It includes the data protection owner where the data warrants it, and the carrier account holder. The team chat is not told. The ticket is visible to the desk and is written as a record of facts and times, not as an account of carelessness. "Phone left on a bus, reported at 06:40" is the whole of the story the ticket needs. An executive's lost phone adds nothing to the procedure and one thing to the discretion, which is the subject of Discretion and the Executive's Devices and Data. The containment steps do not change for anyone.

The found phone deserves a sentence, because it will happen. A phone that spent a night in unknown hands does not come back into service without a wipe and a fresh enrolment, however relieved everyone is. The user is told this gently and in advance: "if it turns up, that's great, and we'll still wipe it and set it up again, because we can't know what happened to it overnight." The review afterwards notes that it was found. Nothing on it is trusted.

The organisation's cost from lost phones is set almost entirely by the number of hours between the loss and the report. And that number is set by how the last person who reported one was treated. A desk that says "thank you for ringing straight away" and means it will get its reports at 06:40. A desk that sighs will get them on Monday, which is the war story below.

The Hour, Minute by Minute

The timeline below is what a rehearsed desk does. The minutes are from a fictional desk that has run it a dozen times. A desk running it for the first time should expect the same steps to take three times as long. Most of the extra is spent finding where in each service the sign-out-everywhere control lives. That is the argument for the runbook at the end of this article having, beside each step, the place it is done. The hour is generous. The first fifteen minutes are the ones that count.

Grace's hour at Harbourview ran close to the table because Tom had done it before. The lock went on at 06:44 from the management service, and the sessions were revoked by 06:52. Her manager confirmed her by phone at 07:02 and the reset went through at 07:05. And the SIM was blocked by the practice administrator who held the carrier account at 07:20. The visit app's data was on the server, so the patient list was never only on the phone. At 10:15 the bus company rang to say a phone had been handed in. It was wiped that afternoon anyway.

After the Hour: Replacement and the Review

The user needs a phone by the time the hour is over. A desk that keeps a loan pool has one. The case for a small pool of spares and the rules for lending from it are in The Loaner and Spares Strategy. Phones belong in the same pool as laptops. The replacement is enrolled by the same guide and the same three checks as any new phone. That is the subject of Enrolment and Setup Without a Visit. The second factor is re-registered on the new phone after the user has been confirmed. The wipe of the old phone is confirmed in the management service, not assumed. A wipe that was sent to a phone that was switched off is a wipe that has not happened yet, and the management service says which.

The user is told, plainly, what happened to their own data. On a company phone, the wipe took it, which the handover message warned about and which is still worth saying with some kindness. On a personal phone, the work profile went and nothing else was touched. That is the promise the organisation made when the profile was set up and the one the user is most relieved to hear kept. Either way the user is told the ticket is closed, what was done, and that nothing further is expected of them.

The review is short and happens within the week. What was on the phone that should not have been only on the phone? Was the passcode on? How long between the loss and the report, and why? Which step was slow and where was the control that nobody could find? Each answer is a line in the runbook, a line in the setup guide, or a line in the handover message. And the review's job is to put it there. The review is not about the user and the user is not in the room. It is about the organisation's arrangements, which are the only thing the organisation can change.

A Short War Story: The Weekend at Greenway Coaches

At Greenway Coaches, the sales director, Piotr, had his company phone taken from a restaurant table on a Friday evening. He did not report it until nine on Monday morning. As he said when he rang, he had not wanted to bother anyone over the weekend. The desk locked the phone and revoked the sessions within a quarter of an hour of the call. Then the security lead read the sign-in history and found the mailbox had been read from the phone through Saturday afternoon. That included a tender for a contract the firm was bidding on. The tender had to be declared to the client as exposed. The security lead lost a day to the write-up. And the handset was the cheapest line on a ticket whose real cost was a client's trust and a bid the firm did not win. The review had one finding. Nobody at Greenway had ever been told that losing a phone was something to report at once, on any day, to a number that was answered. The desk's out-of-hours number went on the back of every company phone the following week. The cost of a lost phone is set by the hours between the loss and the report. And those hours are set by whether people know, and feel safe, to ring.

The Lost-Device Runbook

The runbook below is kept where the technician on the early shift can reach it without searching. The organisation's own names and account references are filled in against each line. The place each action is done is written beside it, because the first-time delay is almost entirely spent looking for controls. Section A is the report, and B is the containment, done on the caller's word. Section C is the decision and the named decider, D is the people told, and E is the close and the review. Rehearse it twice a year with a test account and a spare phone, and the hour becomes fifteen minutes.

LOST OR STOLEN DEVICE — THE FIRST HOUR
Ticket: ________   Reported at: ________   Lost at (approx): ________   By: ______________   Reachable on: ______________

A. THE REPORT (two minutes; no "why")
   [ ] Company phone / personal phone with work profile
   [ ] Last seen where and when: ______________________
   [ ] Passcode, fingerprint or face lock on?  yes / no / unsure
   [ ] Work on it: mail [ ]  authenticator [ ]  VPN [ ]  apps with customer or patient data: ______________
   [ ] Could it be misplaced (car, coat, desk)?  yes / no
   [ ] Carrier told?  yes / no        Platform locate feature on?  yes / no

B. CONTAINMENT (on the caller's word; these remove access)
   [ ] Lock the company phone / remove the work profile ...... done at ______  where: ______________
   [ ] Revoke sessions:  mail ______  files ______  chat ______  identity / single sign-on ______  VPN ______
   [ ] Remove the phone as a registered second factor ........ done at ______  where: ______________
   [ ] Confirm the caller by another route (manager / known number / ______________) .... by ______
   [ ] Reset the password through the reset process ........... done at ______
   [ ] Temporary way back in given to the user ................ done at ______

C. THE WIPE DECISION
   Rule:  stolen, no passcode, or regulated data = wipe at once
          otherwise = wipe if not found within ______ minutes
   Decider (name, role): ______________________   Decision: ______________   at ______
   Wipe sent at ______   Wipe confirmed in the management service at ______
   Personal phone: work profile removed only; nothing else touched. User told: [ ]

D. WHO IS TOLD (facts and times, nothing else)
   [ ] User's manager (cover, replacement)       [ ] Security lead
   [ ] Data protection owner, if regulated data   [ ] Carrier account holder: ______________  SIM blocked at ______
   [ ] Police report required by policy?  yes / no   Reference: ______________

E. CLOSE AND REVIEW
   [ ] Loan or replacement phone issued at ______; enrolled by the guide; second factor re-registered after verification
   [ ] If found: wiped and re-enrolled anyway; nothing on it trusted
   [ ] User told what happened to their own data, and that the ticket is closed
   [ ] Review within the week: what was only on the phone; passcode; hours to report; the slow step
   [ ] Runbook, setup guide or handover message updated with each finding

Tom closed Grace's ticket at four that afternoon, with the found phone wiped and a loan phone in her bag since nine. The one line in the review that changed anything said that the carrier account reference had taken eight minutes to find. The carrier account reference is now printed on the runbook. Grace rang the following month to say a colleague had lost hers, and that she had told her to ring straight away. That was the most useful thing anyone did that day.

Frequently Asked Questions