The Lost or Stolen Field Device SOP

Purpose

A missing field phone or tablet is signed into the shop's job software, email, often the card reader app and sometimes the password manager, and it may hold customer addresses, photos of their homes and their access codes. This procedure guarantees that within a few hours of a device going missing, nothing on it can be used: the device is locked or wiped, every account it touched has been cut off from it, and the shop has a written record of what was exposed and who needs to be told. Without it, a tech spends the evening hoping it turns up and the office finds out the next morning.

Scope

Covers every company-owned phone and tablet, and every personal phone enrolled with a work profile, used for shop work. On a personal phone the shop wipes the work profile only, never the whole device, and this procedure never asks an employee to surrender a personal device.

Does not cover: an account broken into without a device going missing (see related: The First Hour After a Suspected Breach SOP); how devices are set up so this procedure works (see related: Setting Up Field Phones and Tablets So a Lost One Is a Nonevent); and laptops kept in the office, which follow the breach SOP.

Roles and responsibilities

After hours, the owner is the backup device admin. Both have the device management console login and can act from their own phones.

Procedure

1. Report it within one hour of noticing it is missing

The tech calls the device admin from another phone (a co-worker's, a customer's landline, the truck partner's) within 1 hour of first noticing the device is gone, and gives four facts: the time they noticed, where and when they last used it, whether it was lost or taken (left on a tailgate versus pulled from a truck), and which apps were signed in. Acceptance: the admin has written down all four facts and the time of the call. What wrong looks like: "I'll check the truck again tonight and call if it doesn't turn up." Stop rule: the search does not delay the report; a report made late is still made, and the delay is written into the record rather than hidden. Hazard: the tech does not make the call while driving; pull over somewhere off the traveled lane first. Nobody searches a dark roadside shoulder or a closed commercial property for a lost device.

2. Read the device's location once, and decide who goes

The admin opens the device management console or the platform's find-device page and reads the last reported location and its timestamp. Acceptance: a location with a time is written down, or "offline, last seen at (time, place)" is. If the device shows at a place it was plausibly left (the last customer's driveway, the supply house, the shop yard), the tech may retrieve it during business hours with the property owner's knowledge. If it shows at an address nobody recognizes, or is moving, it is treated as stolen. Stop rule: nobody from the shop goes to an unknown address to recover a device; the location goes into the police report in step 7. Hazard: confronting a person holding stolen property is how a lost tablet becomes an assault, and no device is worth it.

3. Lock it and put the office number on the screen

Within 15 minutes of the report, the admin sends a remote lock with a lost-mode message: "This device belongs to (shop). Please call (main office number)." Acceptance: the console shows the lock command acknowledged by the device, with a time. What wrong looks like: the command shows as pending, which means the device is offline and has not received it. Stop rule: a pending lock is treated as no lock at all; the admin goes straight to step 5 without waiting for the acknowledgment, and checks the lock status again every hour until it changes or the wipe in step 4 lands. Hazard: none at this step, it is a console action at a desk.

4. Wipe when any one criterion is met, after location has been recorded

The admin queues a remote wipe (on an enrolled personal phone, a work-profile wipe) if any one of these holds: the device is believed stolen, it showed at an unknown address in step 2, it had no enforced screen lock, or it has not been recovered within 4 hours of the report. Before wiping, the admin checks the console for the last sync of photos and signatures, because a wipe destroys anything not yet uploaded. Acceptance: the wipe command is acknowledged by the device, or is queued and recorded as pending. What wrong looks like: wiping at once because it feels decisive, which ends location reporting before step 2 has been done and the police have the address. Stop rule: if none of the criteria are met and the admin is unsure, the owner decides within the 4-hour window, and silence from the owner counts as wipe. Hazard: none physical, it is a desk decision; the consequence is lost unsynced work, which is recorded.

5. Cut the device off from every account it was signed into

Working from the tech's list in step 1 plus the device's app list in the console, the admin ends the device's session in each account, in this order: the card reader or payment app, email, the password manager, the field service software, then shop messaging and anything else. Payment and email go first because payment moves money and email resets everything else. Where an app offers "sign out this device", use it; where it does not, reset that user's password and re-register their multifactor. Acceptance: each account on the list has a line in the record reading "session revoked" or "password reset", with a time. What wrong looks like: an app nobody can find the admin setting for. Stop rule: that account's password is reset regardless, and the gap is noted for the setup review. Hazard: none at this step, it is console work at a desk.

6. Suspend the line with the carrier

For a device with a cellular line, the admin calls the carrier, reports it lost or stolen, suspends the line, and if stolen asks the carrier to block the device's hardware identifier (its IMEI) so it cannot be reactivated on another plan. Acceptance: a carrier ticket or reference number, written down. Why this step exists even after a wipe: a SIM card moved into another phone receives the shop's text-message sign-in codes. What wrong looks like: the carrier asks for the account PIN and nobody knows it. Stop rule: the owner, as account holder, calls within the hour; the line is not left active overnight. Hazard: none at this step.

7. File a police report when the device was taken or located somewhere unknown

If step 1 said taken, or step 2 showed an unknown address or movement, the admin or the tech files a report with the local non-emergency line or online reporting system, giving the device's serial number, the location and time from step 2, and the lost-mode message. Acceptance: a report number, written down. The carrier block, the insurance claim and any later recovery all depend on it. What wrong looks like: skipping it because "they'll never find it." Stop rule: the report is filed regardless, the same day. Hazard: if the police decide to go to the address, the shop's people do not go with them unless an officer asks, and nobody calls or texts the device.

8. Write down what the device exposed, and route it

The admin and the tech list what was on the device in readable form if the lock had failed: customer records held offline (count, and which fields), photos showing house numbers, keypads, keys or the inside of homes, notes or messages containing gate, garage, alarm or lockbox codes, and signed documents. Record whether the device was encrypted and had an enforced screen lock. Acceptance: every category has an entry, even if the entry is "none". Stop rule: if any access code was on the device, the affected customers are told the same day so they can change the code (see related: The Customer Key and Code Handling SOP); if anything beyond names, addresses and phone numbers was held, the owner takes it the same day to see related: Handling a Data Breach Notification Obligation. Hazard: none at this step, it is a desk review.

9. Reissue a device before the tech's next shift

The admin takes a spare from stock, enrolls it in device management before it leaves the office, and the tech signs into their own accounts on it and re-registers multifactor. The lost device is marked retired in the device inventory with the date. Acceptance: the tech can open the day's first job on the new device, and the inventory shows the old one retired. What wrong looks like: the tech borrows a co-worker's login for the day. Stop rule: if there is no spare, the tech works from paper tickets dispatched by phone, never on another person's login; see related: The Shared Login Problem. Hazard: the tech does not set up or sign into the new device while driving.

The record this produces

One entry per incident in the shop's security log, filled in by the device admin and kept with the device inventory. Fields: device and serial number, assigned tech, time noticed, time reported, location reads with times, lock and wipe status with acknowledgment times, each account and the time its session was revoked, carrier reference, police report number, the exposure list from step 8, who was notified, and the reissued device's serial. The owner reads it the next business day, the annual review reads it for patterns (late reports, accounts that cannot sign out a device), and the insurer reads it if a claim is made.

Worked pass: a lawn crew tablet, Thursday evening

• Step 1, FAILED its one-hour rule. The crew lead noticed the tablet missing at 6:10 in the evening, last used at 3:20 at a commercial property. He searched the truck and the shop yard and called at 7:45, an hour and 35 minutes after noticing. Stop rule taken: the admin proceeded at once and wrote "reported 1 h 35 min after noticing, delay spent searching" in the record.
• Step 2. At 7:52 the console showed the tablet at an apartment complex four miles from the last job, a place nobody recognized. Treated as stolen. Nobody went.
• Step 3, lock PENDING. Lock sent at 7:55; the console showed pending, so the tablet was offline. Stop rule taken: the admin moved straight to step 5 without waiting.
• Step 4. Criteria met (unknown address), sync checked (last upload 3:24, so only one job's photos at most could be lost), wipe queued at 8:00, recorded as pending.
• Step 5. Sessions revoked: card reader app 8:05, email 8:09, password manager 8:14, field service software 8:21, shop messaging 8:30.
• Step 6. Line suspended and identifier block requested at 8:40, carrier reference written down.
• Step 7. Online police report filed at 9:15 with the 7:52 location; report number recorded.
• Step 8. The offline cache held 212 customer records with name, address and phone. The gallery held three photos, each showing a different customer's garage keypad, and two job notes held gate codes. Encryption and a six-digit enforced screen lock were on. The owner called the five customers whose codes or keypads were on it the next morning; the 212-record cache held no financial or identity data, and the owner logged that conclusion with the reasoning.
• Step 9. Spare tablet enrolled at 7:30 Friday; the crew lead opened his first job at 7:50.
• Friday 11:20. The stolen tablet came online for under a minute and acknowledged both the lock and the wipe. The record was closed with both times.

Two findings went to the setup review: gate codes should never have been in job notes, and the crew lead had spent 95 minutes searching because nobody had told him the report comes first.

References

• Your device management platform's documentation for remote lock, lost mode, and full versus work-profile wipe
• Your mobile carrier's lost and stolen device procedure
• See related: Setting Up Field Phones and Tablets So a Lost One Is a Nonevent, The First Hour After a Suspected Breach SOP, Handling a Data Breach Notification Obligation