The first 24 hours after ransomware: decisions in the order they arrive

This assumes encryption has been observed and is either ongoing or recently completed. If you are reading this during an active incident, the short version is: isolate without shutting down, preserve evidence, get legal and insurance involved before you touch anything you cannot undo, and start the regulatory clock deliberately rather than by accident.

Hour 0 to 1: contain without destroying evidence

1. Isolate affected systems from the network. Disconnect network interfaces or move to a quarantine VLAN. Do not power systems off — memory contains encryption keys, process artefacts and attacker tooling that will be lost on shutdown.
2. Disable the accounts you have reason to believe are compromised, and force credential rotation for domain and cloud administrators. If you cannot tell which are compromised, treat all privileged accounts as suspect.
3. Protect the backups first. Verify they are unreachable from the compromised plane, and if they are reachable, isolate them immediately. Attackers target backups deliberately and often did so days before encryption.
4. Stop automated processes that could propagate: replication, scheduled deployments, sync agents, and backup jobs that might overwrite a clean copy with an encrypted one.
5. Start a written timeline. One person, one document, every action with a timestamp. This becomes your evidence, your regulatory submission and your insurance claim.

Hour 1 to 4: mobilise the right people

The mistake here is to keep the incident inside IT for too long, usually out of a well-intentioned desire to understand it first. Several of the clocks that matter start at awareness, not at understanding.

• Executive sponsor with authority to spend and to take the business offline. Without this, every subsequent decision stalls.
• Legal counsel — internal or external. Engaging counsel early may also affect privilege over subsequent investigation work in some jurisdictions, which is worth understanding in advance rather than during.
• Cyber insurer, if you have a policy. Most policies require prompt notification and many mandate the use of panel providers. Engaging your own incident response firm first can jeopardise cover.
• Incident response support, if you do not have the capability in-house. Forensic capture done wrong in hour two cannot be repaired in hour twenty.
• Communications lead. Not to publish anything yet, but so that staff, customer and supplier messaging is prepared before someone improvises it.

Hour 2 to 24: the regulatory clock

Two separate obligations commonly apply to European organisations and they have different triggers, deadlines and recipients. They are frequently confused.

The 24-hour early warning does not require you to understand the incident. It requires you to indicate whether it is suspected to be caused by unlawful or malicious acts and whether it could have cross-border impact. Ransomware answers the first question by definition. Waiting for clarity before submitting is the most common reason organisations miss the deadline.

The ransom decision

This is a legal and commercial decision, not a technical one, and it should never be made by the people doing the technical response.

• Sanctions screening is mandatory before any payment consideration. Paying a sanctioned entity is a criminal exposure independent of the incident.
• Payment does not reliably restore data. Decryptors are frequently slow, partial or defective, and recovery from a working backup is usually faster where one exists.
• Payment does not remove the data. If exfiltration occurred, you are paying for a promise to delete, from a party whose business model is breaking promises.
• Your notification obligations are unaffected by payment. A paid ransom does not make a personal data breach unreportable.
• Insurance frequently governs this decision contractually. Check the policy before opening a channel.

Recovery order

1. Establish a clean environment. Do not restore into the compromised one — rebuild the identity and management plane first, on known-good media, with new credentials.
2. Determine the initial access vector before restoring production. Restoring without closing the door repeats the incident, often within days.
3. Restore by business priority, not by technical convenience. Agree the sequence with the business, not within IT.
4. Scan every restored system before reconnecting it. Backups taken during the dwell period may contain the attacker's persistence.
5. Rotate every credential, key and token that existed before the incident. All of them, including service accounts, API keys and certificates.
6. Keep enhanced monitoring in place for months. Re-intrusion via retained access is common, and the second attempt is usually faster.

The three preparations that change the outcome

Almost everything above is easier if three things were done in advance, and none of them is expensive.

• Offline or immutable backups, tested by actual restoration rather than by a green tick in a console. Test a full restore of a critical system at least annually.
• An out-of-band communication channel. If your email and chat are encrypted or untrusted, you need a pre-agreed alternative with the contact list already in it.
• A one-page incident card: who to call, in what order, with numbers, printed. Digital-only runbooks are unavailable during exactly the incident they were written for.