A ransomware exercise should not be a disaster movie with a PDF at the end. Most organisations already understand, in theory, that compromise is possible. The useful question is what happens between the first foothold and the moment people realise the business is under pressure.

That middle part is where resilience lives. Did defenders see the right signals? Did they understand them quickly enough? Did escalation work? Did identity controls slow the attacker down? Did backup confidence change the decision-making? Did anyone know which systems had to be protected first? A good exercise gives you answers to those questions without turning the environment into a theatre set.

Start with the objective, not the malware

A ransomware scenario does not have to begin with simulated encryption. In many cases, that is the least interesting part to test and the riskiest part to stage. The better starting point is the attacker objective: reach backup infrastructure, discover sensitive shares, stage access to critical systems, obtain broad identity privilege, disrupt a business process, or create enough pressure that leadership has to make decisions.

Once the objective is clear, the exercise can be designed safely. Some steps can be executed. Some can be proven and then paused. Some can be simulated with markers, screenshots, or controlled evidence. The point is to make the path real enough to learn from without confusing realism with recklessness.

You need a timeline, not just an ending

A useful ransomware exercise should produce a timeline that both attackers and defenders can recognise. Initial access. Privilege escalation. Credential access. Lateral movement. Discovery. Attempts to reach backups or high-value data. Defensive alerts. Triage decisions. Escalation moments. Containment choices. Missed opportunities.

Exercise timeline

Foothold

Phishing, exposed service, stolen VPN credential, or another agreed initial-access route.

Expansion

Credential access, privilege escalation, lateral movement, and discovery of sensitive systems.

Pressure

Backup reachability, containment choices, business-owner escalation, and restore confidence.

That timeline is more valuable than the final headline. "Attackers could have encrypted systems" is not enough. Which systems? Through which path? What would have stopped it earlier? Which alert was present but not understood? Which team needed to be involved sooner? Which decision took too long because ownership was unclear?

Detection gaps are not all the same

Some signals are missing because telemetry is not collected. Some are missed because the alert is too noisy. Some are seen but not escalated. Some reach the right team but lack the context needed to decide. A good debrief separates those cases. Otherwise "improve monitoring" becomes the kind of recommendation everyone agrees with and nobody can execute.

The exercise should also show what worked. If endpoint controls forced the attacker to change approach, that matters. If identity hardening stopped one path but left another open, that matters too. Defenders need to know which investments created friction, not only where the attacker eventually succeeded.

Decision bottlenecks matter as much as detections

Ransomware response is not purely technical. Someone may need to isolate a business-critical system. Someone may need to call a supplier. Someone may need to decide whether a backup is trusted. Someone may need to tell leadership that containment will hurt operations in the short term. Those decisions can be harder than the detection work.

A realistic exercise exposes where those decisions stall. Maybe the SOC can escalate but the business owner is unreachable. Maybe the incident process assumes a crisis lead who is not on call. Maybe backup ownership sits with a different provider. Maybe legal, communications, and technical response have never practised the same timeline. Those are not side issues. They are part of the attack surface of the response.

Backups deserve more than a checkbox

Backup confidence changes the whole incident. If teams know what can be restored, how quickly, from which point in time, and under whose authority, they can make containment decisions with less panic. If nobody knows whether backups are reachable, immutable, tested, or clean, every choice becomes slower.

A ransomware exercise should not casually attack backup systems without careful boundaries. But it should test the assumptions around them. Can attackers reach backup administration? Are backup credentials isolated? Are restore procedures known? Has anyone practised restoring the systems that matter most, not just a convenient test server?

The report should create work people can own

A good report has more than narrative. Security engineering needs the technical path and the control gaps. Detection teams need the signals, missing telemetry, and rule opportunities. Incident responders need the timeline and escalation friction. Leadership needs the decisions that would affect business continuity. Infrastructure and identity teams need the changes that break the path.

Those outputs should not be buried in one generic recommendation list. The strongest reports separate immediate path-breaking actions, detection improvements, response-process changes, and longer-term resilience work. They also explain why the order matters.

The exercise should make the next attempt harder

If everyone leaves impressed by the red team but unsure what to change, the exercise missed the point. The goal is not to prove that attackers are clever. The goal is to make the next attempt easier to detect, harder to move through, faster to contain, and less confusing for the people who have to make decisions under pressure.

That may be less dramatic than a simulated ransom note. It is also far more useful.

If you want to know what your defenders would actually see during a high-pressure intrusion, we can help design the exercise. The goal is not a dramatic story. The goal is a better next response.