A ransomware plan can be technically detailed and still fail at the moment the organisation must decide whether to isolate production, notify customers, contact regulators or accept prolonged disruption.
The purpose of testing is not to prove that a document exists. It is to discover whether the organisation can coordinate when facts are incomplete and every option has consequences.
1. Define decisions, not just objectives
“Test the ransomware plan” is too broad. Select the decisions that matter: who can isolate a critical environment, who declares a crisis, what triggers executive involvement, how extortion communications are handled and who owns recovery sequencing.
2. Build a cross-functional scenario
A strong scenario should create parallel pressure. Begin with endpoint ransom notes, then add operational disruption, an exfiltration claim, a journalist request, a regulatory question and a supplier dependency. Each development should require action from more than the security team.
CISA's StopRansomware Guide explicitly connects cyber exercises with evaluating or developing an incident response plan in a ransomware context.
3. Give participants imperfect information
Real incidents do not provide a complete situation report. Participants should distinguish what is known, suspected and unresolved. The exercise should reward clear assumptions and reversible decisions rather than artificial certainty.
4. Let actions change the crisis
If teams isolate quickly, spread may slow while production stops. If they delay, operations may continue briefly while data loss and recovery complexity grow. A branching simulation makes the trade-off visible.
5. Capture evidence while the exercise runs
Record major decisions, owners, reasoning and simulated time. Observe when escalation occurred, whether regulatory triggers were recognised, how recovery priorities were agreed and which dependencies surprised the team.
6. Compare plan and performance
Do not finish with “the team completed the scenario.” Compare approved expectations with observed behaviour. An expected fifteen-minute escalation that takes thirty-four minutes is not simply a timing issue; it may expose unclear authority, unavailable contacts or an approval bottleneck.
7. Convert observations into remediation
Every material finding needs an owner, action and retest condition. Update the plan only when the change addresses the underlying behaviour. Then design the next simulation around the unresolved weakness.
A useful ransomware test creates productive discomfort
The exercise should be safe, but the decisions should feel consequential. That is how an organisation learns whether its technical response, leadership, communications, legal analysis and recovery strategy can operate as one system.
COMMON QUESTIONS
Frequently asked questions
How often should a ransomware response plan be tested?
Frequency should reflect risk, material changes and regulatory expectations. Many organisations run at least an annual cross-functional exercise and retest significant findings sooner.
Who should join a ransomware exercise?
Include security, IT, operations, continuity, legal, privacy, communications, executive leadership and relevant external providers.
What should a ransomware exercise measure?
Measure decision timing, escalation, ownership, coordination, communications, evidence handling, recovery priorities and adherence to approved processes.