Reaģēt uz nozaudētu vai nozagtu klēpjdatoru vai tālruni

Kad izmantot

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.

Pirms sāc

• 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.

Ko izpilde pieprasa4

Ceļš9 soļi

1. S1

   Confirm and start the clockaģents

   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.

   Izdarīts, kad the incident record exists with report time and device facts.

2. S2

   Cut access before anything elseaģents

   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.

   Izdarīts, kad 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. S3

   Decide on wipeīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S3 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

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

   Izdarīts, kad 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. S4

   Wipeaģentsneatgriezenisks

   Neatgriezenisks solis · S4 — aģents to nekad nenoslēdz viens

   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.

   Izdarīts, kad the management console shows the wipe issued, with a timestamp, or pending with a queue time.

5. S5

   Map what the device touchedaģents

   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.

   Izdarīts, kad the mailbox activity list is in the incident record and anomalies are flagged.

6. S6

   Report and claimīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

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

   Izdarīts, kad 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. S7

   Assess GDPR breachīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S7 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   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.

   Izdarīts, kad 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. S8

   Replace and restoreaģents

   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.

   Izdarīts, kad the person works on an enrolled, encrypted device, or a dated task exists for the purchase.

9. S9

   Close the recordaģents

   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.

   Izdarīts, kad a reader can reconstruct the hour and every decision from the record alone.

Pārbaudes — kā zinām, ka izdevās

• 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.

Ja noiet greizi

Ko atstāj katrs solis

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.

Ko saglabāt

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).

Kā šī procedūra uzlabojas

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.