What to do (and not do) in the first hour of an incident

When a company discovers that something is wrong, an encrypted machine, a strange login at midnight, a transfer no one recognises, what happens in the first sixty minutes shapes much of what comes afterwards.

It is also the moment when most mistakes get made, because the instinctive reaction is almost never the right one. The first impulse is usually to switch off what is failing, fix it quietly and not alarm anyone. All three, done carelessly, can cost you dearly.

This is what is worth doing in that first hour. And, above all, what not to do.

Do not switch the machine off

It is the most common reflex and one of the most damaging. Faced with a compromised machine, switching it off to cut things short seems like the natural move.

The problem is that much of the information an analyst needs to understand what happened lives in the machine’s memory while it is running. Running processes, open connections, encryption keys not yet written to disk. When you switch off, all of that disappears. You will have stopped the incident, but you will also have erased the traces that explain how they got in and how far they reached.

Isolating is not the same as switching off. And isolating is what you should actually do.

Isolate without destroying

What you want is to cut off the attacker’s access without losing the state of the system. Disconnect the machine from the network, pull the cable or disable the wifi, but leave it running. If it is a virtual machine, suspend it instead of shutting it down, which preserves the memory.

The idea is the same for the whole first hour. Contain the damage without touching more than strictly necessary. Every improvised action on the affected system is a clue that gets lost or, worse, evidence that gets contaminated if the incident ends up in a legal complaint or an insurance claim.

Timestamp everything from minute zero

As soon as you suspect there is an incident, open a document and start recording. What was seen, at what time, who saw it, what was done in response and at what time.

It looks like bureaucracy in the middle of an emergency, but that timeline is worth gold afterwards. It is what lets you reconstruct the incident, justify the decisions you made and answer the questions from the insurer, the regulator or an affected client. People’s memory warps under stress. A record written in the heat of the moment does not.

Notify in the right order

This is where most teams improvise, and where a plan made in advance really shows.

The person who spots the problem is almost never the one who should decide, so the first step is to escalate to whoever has the authority to make decisions. From there come the technical team that will contain it and the management that takes on the business decisions. Depending on the case, the legal adviser and the insurance company come in too. If personal data is involved, the clock on notifying the data protection authority is already running.

What you must not do is message the attacker, or touch anything that gives away that you have noticed, until the technical team has a clear picture of the situation.

Do not improvise the quick fix

The “I will sort it out in five minutes” is understandable and tends to come out very expensive.

Deleting the ransomware files, reinstalling the server or restoring a backup over the compromised system without first understanding how they got in has two consequences. You destroy the information that explains the attack and you very likely leave open the door they came through, so they will be back. First you understand the scope, then you clean up. In that order.

With ransomware there is an added rule. Do not pay or reply to anything on impulse. That decision is made with legal and technical advice, never at two in the morning with the fright still in your body.

Prepare before you need it

Everything above is far easier if it is decided beforehand. Who escalates to whom, which phone numbers are used if the corporate email is down, where the backups are and who can restore them, which external provider you call if it gets beyond you.

And here it is worth recalling something we already covered when we wrote about why passing a compliance audit does not mean you are secure. Having a response plan written in a document is not the same as being able to execute it under pressure. The plan gets rehearsed, just like a fire drill. The first time you try it should not be the real day.

The first hour of an incident is chaotic by definition. You will not live through it calmly, but you can live through it methodically. And method, almost always, is the difference between a bad day and a crisis remembered for years.

---

If you want to prepare your organisation to respond well when the moment comes, write to us at [email protected].