Vai al contenuto

Incident response for companies

Isolate, do not power off. Do not restore until you know how they got in. And decide all of it before three in the morning.

In breve

In the first hours of an attack, instinct says power everything off and restore, and those are the two moves that make things worse: powering off destroys the traces, and restoring without knowing how they got in brings the problem back. The correct order is to isolate, verify which copy is intact, change privileged credentials from a clean machine, and document as you go.

Isolate, do not power off

Pulling the network stops the spread. Powering off abruptly destroys the information needed to understand what happened.

Do not restore immediately

In most cases the attacker had been inside for weeks. Restoring blind brings them back along with the data.

Decided beforehand, not at three in the morning

Who calls whom, who decides to stop the systems, who talks to clients. This is the part that is almost always missing.

The correct order is counter-intuitive

Almost everything instinct suggests in the first hours makes the situation worse. It is worth knowing the right sequence before you need it, because at the moment you need it there is no time to learn it.

1. Isolate, do not power off

Disconnecting the affected machines from the network stops the spread. Powering them off abruptly destroys information needed to establish what happened and how they got in — and sometimes destroys the only chance of recovering anything.

It is the difference between an incident that can be reconstructed and one that is left unexplained, with the consequence that nobody even knows whether it has really been closed.

2. Look at the backups before touching them

Establish which copy is intact, and protect it before doing anything else. If the copies are reachable from the compromised network, isolate them too: modern ransomware hunts for the backups before encrypting anything, and they may already have been reached.

3. Do not restore until you know how they got in

This is the most expensive mistake. If the attacker has been inside for three weeks — and in most cases they have — the copies from that period already contain their access. Restoring blind means putting the company and the attack back on their feet together, and finding out the following week.

4. Change privileged credentials, from a clean machine

Domain administrators, access to the virtualisation systems, the backup console, remote access. From a computer known not to be compromised, otherwise the new credentials end up in the same place as the old ones.

5. Document as you work

Times, actions, evidence. You need it to understand what happened, and you need it if a notification is required: the GDPR requires notification within seventy-two hours of becoming aware, where the breach poses a risk to individuals.

The part that is almost always missing

It is not technical. It is knowing who does what, and it has to be decided while nothing is happening.

That last point is more common than it sounds: credentials kept in a manager that only opens from the computer the ransomware has locked are credentials you do not have.

On paying the ransom

It is a decision for management and we do not give generic advice, but three things belong on the table before it is discussed.

Payment does not guarantee recovery: the decryption tool supplied is often slow, partial or faulty. It does not remove the access: if nobody has established how they got in, the attacker is still inside and can come back. And it changes nothing about the obligations: where personal data is involved, the assessment and any notification remain exactly the same.

What we prepare beforehand

A plan that holds is short and concrete: one page with the names, the phone numbers and the sequence. To that are added the three things that make reconstructing an incident possible, and which have to be enabled while nothing is happening.

The logs, enabled and retained for long enough. Without them, the question “how did they get in” has no answer.

The inventory, because without knowing what you have you do not know what to check.

An unalterable copy, which is the only thing that makes restoring a choice rather than a hope. We cover it under off-site backup.

The rest

See also what to do after a data breach for the regulatory side, cybersecurity and NIS2 for governance, and IT security for the defences that reduce the chance of needing any of this.

If it is happening now

Call us before you power anything off or restore anything. The first piece of advice is free, and it is the one that decides how this ends.

Frequently asked questions

What do we do in the first minutes if we suspect an attack?

Isolate the affected machines from the network without powering them off, because an abrupt shutdown destroys information needed to establish how the attacker got in and how long they have been there. Then do not touch the backups until you have verified which copy is intact, and protect that one. Then change high-privilege credentials from a machine known to be clean. And write down everything as you go, with times.

Why is restoring immediately a bad idea?

Because if you do not know how the attacker got in and how long they have been there, the restore brings them back too. In the incidents we reconstruct, the time spent inside before anything becomes visible is almost always days or weeks: which means the copies from that period may already contain the access. First understand, then restore.

How long does it take to establish what happened?

It depends on what was retained. With logs enabled and an up-to-date inventory, the first evidence can be reconstructed within hours. Without logs, often no certain answer is ever reached - and that is the most concrete reason to enable them beforehand, far more compelling than any regulatory obligation.

Should we pay the ransom?

That is a decision for management and we do not give generic advice on it, but three things belong on the table. Payment does not guarantee recovery; the decryption tool supplied is often slow or partial. It does not remove the attacker's access, which remains if nobody has established how they got in. And if personal data is involved, the notification obligations are unchanged.

When does a notification to the authority have to be made?

If the breach involves personal data and poses a risk to individuals, notification must be made within seventy-two hours of becoming aware of it. That is not a deadline for having resolved everything: notification can be made in stages, adding information as it emerges. The practical problem is not the deadline but arriving at it with enough information, and that depends on what was prepared beforehand.

If it is happening now, write to us straight away

In the first hours the decisions matter more than the tools: what to isolate, what to preserve as evidence, who to notify and by when. Tell us what is going on.