A file that no longer opens, a ransom note on the screen, a colleague receiving strange emails from your address. When you notice a cyber incident, the instinct is to put everything back as fast as possible. That is understandable, but a hasty recovery can erase exactly the information needed to understand what happened, close the gap and, if necessary, prove it to others.
Two goals to pursue together
In the first hours you work on two fronts that sometimes seem to conflict:
- limiting the damage, stopping the attack from spreading to other systems or more data from leaking;
- preserving the traces, so you can reconstruct events and make informed decisions.
The typical mistake is to sacrifice the second goal entirely for the first. With a little method, you can achieve both.
The first actions
1. Write everything down immediately
Open a document, even on paper, and record the time you noticed the problem, what you saw, who was informed and every action taken, with the time. This timeline will be invaluable for whoever analyses the incident and for any mandatory notifications.
2. Isolate, do not switch off
In most cases it is best to disconnect the affected computers from the network, by unplugging the cable or turning off Wi-Fi, without switching them off. Shutting a system down loses the contents of memory, which may hold running processes, open connections, encryption keys and traces of the malicious program.
There are exceptions: if ransomware is actively encrypting files and there is no other way to stop it, cutting the power can limit the damage. It is a decision to make knowing what you lose.
3. Photograph the screens
Ransom notes, error windows and unusual notifications should be photographed with a phone before touching anything. They often contain identifiers, contact addresses and information about the type of attack.
4. Protect the accounts
If credential theft is suspected, change the passwords of critical accounts from a safe device, not the compromised one. Enable two-step verification where it is missing. Before doing so, if possible, export the sign-in logs of the affected accounts, because some changes can make them harder to consult.
5. Preserve the logs
Firewalls, routers, mail servers, cloud services and antivirus software keep logs that can be overwritten within days. Export them or extend the retention period before they are lost.
What not to do
- Do not reinstall the system straight away: every trace of the intrusion is wiped.
- Do not run cleaning tools at random: they may delete files useful for analysis without guaranteeing complete removal.
- Do not contact the attackers without a strategy: every exchange should be assessed and documented.
- Do not use the compromised mailbox to coordinate: whoever has access to it could read your communications.
- Do not pay a ransom on impulse: it guarantees neither recovery of the data nor deletion of what was stolen.
Aligning recovery and analysis
A good solution is to split the work. Before restoring a system, make a forensic copy of its drive and, if possible, of its memory. Recovery can then proceed on clean systems or from backups, while analysis works on the copies.
| Activity | Who | On what |
|---|---|---|
| Containment | IT manager | Network and accounts |
| Acquisition | Forensic consultant | Drives, memory, logs |
| Recovery | IT manager | Verified backups |
| Analysis | Forensic consultant | Acquired copies |
Before restoring from backups, check that they are not compromised too and that the restore point predates the intrusion, not just the encryption. Attackers often stay in systems for days or weeks before revealing themselves.
The questions the analysis must answer
- Where did the attacker get in, and when?
- Which systems and accounts did they reach?
- Did they steal data? Which data?
- Are they still present in any system?
- What needs to change to stop it happening again?
The answers are needed not only for repair but also to assess obligations towards customers, partners and authorities. If the incident involves personal data, the GDPR requires the controller to consider notifying the supervisory authority within 72 hours of becoming aware of it: one more reason to document times and facts precisely.
Preparing in advance
The best time to think about an incident is before it happens. A list of people to call, verified backups stored separately, active logs with adequate retention and a short written procedure greatly reduce the chaos of the first hours.
In short
- Record every fact and action with the time from the very first moment.
- Isolate systems from the network without switching them off, except for good reason.
- Photograph screens and preserve logs before they are overwritten.
- Take forensic copies before restoring, and verify the backups.
- Prepare contacts, backups and a written procedure in advance.