A laptop is compromised and two instincts fire at once: wipe it so the person can work, and keep it so somebody can find out what happened. Those are in direct conflict, and the order you resolve them in is the single decision that matters most in the first hour.

TL;DR

  • Get the person working on a different machine first. That removes the pressure that causes bad decisions.
  • Isolate the affected device rather than wiping it, because wiping is the one step you cannot undo.
  • The real decision is rebuild, preserve, or retire, and it depends on what was on it and who is asking.
  • A rebuild is not a clean machine unless it comes from a known-good image, not from a backup of the compromised state.
  • Decide in advance who has authority to retire hardware, or a 1,500 laptop waits three days for a signature.
  • Write down what was done and when, because the timeline is the thing you will be asked for.

Get the person working before you decide anything

This sounds like the least technical step and it is the most useful one. Somebody unable to work creates pressure, and pressure is what produces an irreversible decision taken in the first twenty minutes.

Hand them a spare. Then the compromised machine can sit isolated for as long as the decision genuinely needs, rather than being wiped at speed because somebody has a client call at two o’clock and no laptop. This is the practical reason a spare pool earns its keep, and it is a better argument for holding stock than the failure rate anybody usually cites.

If you’ve no spare in that market, say so early and expect the timeline to compress. The decision quality drops with every hour the person can’t work, and that’s worth flagging to whoever is asking for a careful investigation.

Isolate, don’t wipe

Isolation preserves every option. Take it off the network, leave it powered in whatever state it is in if you can, and stop anything automated that might act on it.

Wiping closes options permanently. The uncomfortable part is that you often can’t tell in the first hour whether anybody will want the contents later. An incident that looks like a single phishing click on Tuesday can turn into a question about what was accessed on Thursday, and the machine is the only place that answer lives. So the default is to keep it until somebody with the authority to decide says otherwise.

Be careful with the automation here too. A device marked as compromised in one system may trigger a wipe in another, and that’s exactly the kind of helpful integration that destroys evidence while everybody is in a meeting about it.

The three outcomes

Rebuild and return it. Right for the common case: a credential compromise, a phishing click, malware that your tooling can account for. The condition is that the rebuild comes from a known-good image rather than from a backup taken after the compromise, which is the mistake that puts the same problem back on the same desk.

Preserve it. Right where there’s any prospect of a dispute, a regulatory question or an insurance claim. It costs you a laptop out of circulation for months, and the mechanics are the same as any legal hold: separate list, separate place, recorded access.

Retire it. Right when you can’t establish what happened, when the device is old enough that the rebuild cost approaches its value, or when firmware-level compromise is a live possibility. Retiring is sometimes the cheapest honest answer and it is the one teams reach for last, usually because nobody has authority to write off hardware without a conversation.

Decide the authority question now

Here’s a delay that’s entirely self-inflicted. The technical work takes an afternoon and the decision to retire a machine waits three days for an approval nobody was ever going to refuse.

What to do:

  • Name a role that can retire one device up to a stated value without further approval.
  • Name who decides between rebuild and preserve, and make them reachable out of hours.
  • Pre-agree that isolation needs no approval at all. It is reversible.
  • Write the three outcomes down so the conversation starts from a shared list.

The limit matters more than the name. A standing authority for one machine up to a modest value costs nothing until it is used and removes about a day from the typical case.

A company that changed one thing

A 340-person company handled 17 device incidents in a year, most of them minor. Their average time from report to the person working again was 4 days.

Almost all of that was waiting. Waiting for a decision on whether to preserve, then waiting for approval to issue a replacement, then waiting for the replacement to arrive because there was no local spare. They changed two things, a standing authority for one replacement up to a set value and three spare machines held in each of their two main markets, and the average came down to 11 hours.

No new tooling was involved. The whole improvement was removing two approval waits and holding six machines, which is a useful reminder of where the time in an incident actually goes.

Record the timeline as you go

Write it down during, not after. What was reported, when, what was done to the device, by whom, and at what time, including the steps that didn’t work.

The reason is that the chronology is the thing you’ll be asked for, and it is the one thing that can’t be reconstructed afterwards with any confidence. A rough contemporaneous note beats a careful reconstruction written a fortnight later, and it takes about ninety seconds per entry at the time.

Keep access to an isolated device restricted to the smallest number of named people. Then the access record is short, which is the point.

Where a lifecycle platform helps, and where it does not

Two parts of this are logistics. Getting a replacement to the person quickly, and getting the affected device somewhere controlled, both across whatever countries you operate in.

RemoAsset is our own product. It handles procurement and retrieval across 80+ countries and records each device through issue and return, which covers the replacement-out and device-in halves of an incident and keeps the register straight while both are happening. Pricing is published, from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges.

It plays no part in the security work. It has no network discovery, so it won’t tell you a device exists that your register never knew about. It has no software licence management. And only the Subscription tier publishes a figure, with pay-as-you-go quoted. It detects nothing, isolates nothing, and makes no judgement at all about what was compromised or how far it reached.

Workwize, Firstbase, GroWrk, allwhere and Deel IT operate on broadly similar lines, and not one of the five publishes a rate card. The live Workwize domain is goworkwize.com.

Checklist

Checklist:

  • A spare available in each market with meaningful headcount.
  • Isolation agreed as needing no approval, because it is reversible.
  • A named authority for retiring one device up to a stated value.
  • A known-good image to rebuild from, tested recently.
  • Automated wipe triggers reviewed so a compromise flag cannot fire one.
  • A timeline template somebody can fill in while the incident is running.

Final Thoughts

Replace, isolate, then decide. Getting the person working removes the pressure, isolation preserves the options, and the rebuild-preserve-retire choice is far easier to make calmly than at speed.

Most of the delay in these cases is approval rather than technical work. So the preparation worth doing is a standing authority and a spare machine, both of which cost nothing until the day they save a week.

Frequently asked questions

Should a compromised laptop be wiped immediately?

No, isolate it instead. Wiping is the one step you can’t reverse, and in the first hour you usually cannot tell whether anybody will want the contents later, because an incident that looks minor on Tuesday can become a question about what was accessed by Thursday. Take it off the network and keep it until somebody with authority decides otherwise.

What are the possible outcomes for the device?

Rebuild and return, preserve, or retire. Rebuild suits the common cases where your tooling can account for what happened, preserve applies where a dispute or regulatory question is possible, and retire is right when you cannot establish what occurred or the machine is old enough that rebuilding approaches its value. Writing the three down in advance makes the conversation much faster.

Can we rebuild from a backup?

Only from before the compromise. In practice that means rebuilding from a known-good image instead. Restoring a backup taken after the event puts the same problem back on the same desk, which is the most common way a handled incident recurs a fortnight later. Test the image occasionally so you know it still produces a working machine.

Why does approval authority matter so much here?

Because it is usually the longest step. The technical work often takes an afternoon while the decision to retire or replace a machine waits days for a signature nobody was ever going to withhold. A standing authority for one device up to a stated value costs nothing until used and typically removes a day from the case.

What should we write down?

The chronology, recorded while it happens. What was reported and when, what was done to the device, by whom, at what time, including the steps that failed. That timeline is the thing you will be asked for and the one thing that cannot be reconstructed credibly afterwards, and it costs about ninety seconds per entry at the time.

Does holding spares really help with incidents?

More than the failure rate suggests. The value is not replacing broken hardware, it is removing the pressure that causes somebody to wipe a machine at speed so a colleague can get back to work. A spare in each market with meaningful headcount is what makes a careful decision possible at all.