The call usually comes at the worst possible time

Ransomware incidents rarely announce themselves during office hours. In my experience, the first call tends to come late on a Friday, early on a Sunday or in the middle of a holiday period, because that is when attackers know defenders are thinnest. By the time someone notices encrypted file shares or a ransom note on a server console, the intruders have usually been inside for days or weeks, mapping the network, escalating privileges and, increasingly, copying data out before they encrypt anything.

What follows is how I structure the first 72 hours. It is not a substitute for a tested incident response plan, but it reflects what consistently separates organisations that recover in an orderly way from those that make the situation worse.

Hours 0 to 4: stop the bleeding, preserve the evidence

The instinct in the first minutes is to start rebuilding or to power everything off. Both can be mistakes. Powering off machines destroys volatile memory, which often holds the attacker's tools, encryption keys or command-and-control details. Rebuilding before you understand how the attacker got in simply invites them back.

The priorities in the first hours are:

• Contain, do not destroy. Isolate affected systems from the network rather than shutting them down where possible. Segment or disconnect the most critical environments, and consider cutting external connectivity if exfiltration may still be in progress.

• Protect the backups. Attackers deliberately target backup systems. Confirm immediately whether offline or immutable copies exist and disconnect them from anything that might be compromised.

• Assume identity is compromised. Domain administrator and service accounts are often in the attacker's hands. Plan credential resets carefully, because resetting everything in the wrong order can lock out your own responders.

• Switch to out-of-band communication. If the attacker controls your email or collaboration platform, they may be reading your response. Move the core team to a separate channel.

• Start the log. From the first minute, someone should keep a timestamped record of every decision, action and observation. That record matters later for regulators, insurers, lawyers and your own lessons learned.

Hours 4 to 24: understand what you are dealing with

Once the immediate spread is contained, the work shifts to scoping. This is where digital forensics earns its place. The questions are simple to state and hard to answer: how did they get in, how far did they go, what did they take, and are they still here?

Typical initial access routes I encounter include exposed remote access services without multi-factor authentication, unpatched internet-facing appliances, and credentials harvested through phishing or bought from access brokers. Determining the entry point early shapes everything else, because it tells you which controls failed and what needs closing before restoration.

In parallel, the crisis management structure needs to form. I recommend a small decision group, typically the CEO or a delegate, legal counsel, the CISO or incident lead, communications and a business operations owner, meeting at fixed intervals with a clear agenda. Ad hoc calls with thirty participants waste the most valuable resource in the room: the attention of the people doing the technical work.

This is also the window to notify your cyber insurer if you have a policy. Many policies require prompt notification and have panel providers for forensics, legal and negotiation. Engaging outside the policy terms can create avoidable coverage disputes.

The regulatory clock starts earlier than most people think

Several reporting obligations may run at the same time, and they are triggered by awareness, not by the completion of the investigation.

• GDPR: if personal data is affected, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to individuals. Where the risk to individuals is high, those individuals must also be informed without undue delay.

• NIS2: in-scope essential and important entities must provide an early warning to the national CSIRT or competent authority within 24 hours of becoming aware of a significant incident, followed by an incident notification within 72 hours and a final report within one month.

• DORA: financial entities must classify ICT-related incidents and report major ones to their competent authority under the timelines set in the regulation and its technical standards.

The practical lesson is that legal counsel must be in the room from the first hours, and that draft notifications should be prepared on the basis of what is known, with the expectation that they will be updated. Waiting for certainty before notifying is the most common way organisations miss these deadlines.

Hours 24 to 48: the ransom question and the communications plan

By the second day, leadership will be asking whether to engage with the attackers. That is a business, legal and ethical decision, not a technical one, and I am careful to keep it that way. Considerations include whether viable backups exist, whether data was exfiltrated, sanctions exposure (paying certain groups may be unlawful in some jurisdictions), insurance terms and the reliability of the threat actor. Paying does not guarantee working decryption, and it does not guarantee stolen data will be deleted. Whatever the decision, it should be documented with the reasoning behind it.

Communications become critical at this stage. Employees will talk, customers will notice outages and journalists may be contacted by the attackers themselves as a pressure tactic. I advise preparing holding statements for staff, customers, partners and the media early, keeping them factual and avoiding premature claims such as "no data was accessed" until forensics supports it. A statement that has to be retracted does more reputational damage than the incident.

Hours 48 to 72: plan the recovery, do not rush it

By the third day, the pressure to restore operations is intense. Recovery should be sequenced by business priority, not by whichever team shouts loudest. That requires knowing in advance which services are critical and what they depend on: identity, DNS, core databases, network infrastructure.

• Rebuild identity first. If Active Directory or the equivalent was compromised, restoring applications on top of it is building on sand.

• Restore into a clean environment. Validate backups before restoring them, and scan restored systems for persistence mechanisms the attacker may have left behind.

• Close the door they came through. Patch the exploited vulnerability, enforce multi-factor authentication on remote access and remove any accounts or tools the attacker created.

• Increase monitoring. Attackers frequently attempt to regain access during recovery. Heightened detection on endpoints, identity and network egress is essential for weeks, not days.

What separates good responses from bad ones

Having worked incidents across banking, telecoms and critical infrastructure, I have found that the outcome is decided less by the attacker's sophistication than by the victim's preparation. The organisations that come through well share a few traits: they have offline or immutable backups that they have actually restored from in testing; they know who has authority to make decisions at 3 a.m.; they have pre-agreed relationships with forensic, legal and communications support; and they have rehearsed the regulatory reporting decision, not just the technical response.

The ones that struggle typically discover during the incident that their backups were reachable from the compromised domain, that no one is sure who can authorise taking a critical system offline, and that the incident response plan lives on a file server that is now encrypted.

The one thing I would ask every executive to do

Print your incident response plan, the contact list and the decision authorities, and keep a copy somewhere that does not depend on your network. Then run a tabletop exercise in the next quarter that forces your leadership team through these 72 hours. It is far cheaper to discover the gaps in a conference room than in the middle of the real thing.