Define the operational boundary
Ransomware creates decisions that extend beyond technical containment: which services stop, what evidence is preserved, when customers are informed and how recovery priorities change. An executive exercise should reveal authority and dependencies, not test whether participants remember a scripted answer.
Document the systems, identities, information and external dependencies inside the decision. The most important failure paths are unclear incident authority, communications dependent on affected systems, recovery priorities without business agreement, assumptions about backups or supplier availability. Assign one accountable owner and record any boundary that remains outside the current work. This prevents a technically sound control from being mistaken for protection of a wider process it cannot actually cover.
Design controls around the real workflow
Build a scenario around the organisation’s real identity, backup, supplier and communication paths. Introduce information in stages and distinguish confirmed facts from attacker claims. Include unavailable email, uncertain data theft and a critical service whose fastest restoration path may reintroduce the compromised trust boundary.
Build the control path from decision and contact matrix, alternate communications, service recovery priorities, qualified external coordination, evidence-led situation reporting. Each layer should have a stated purpose, an implementation owner and a safe failure mode. Test ordinary work as well as privileged and emergency journeys. Where the strongest option cannot yet be used, document the temporary safeguard, residual consequence and date by which the design will be reconsidered.
Operate from evidence
Use current contact details, decision thresholds and alternative communication methods. Observers should record delays, conflicting authority, missing evidence and assumptions about insurance or suppliers. Keep legal, regulatory and payment questions within qualified advice; the exercise should identify who coordinates those decisions rather than invent universal answers.
Useful operational evidence includes decision timestamps, contact-path results, recovery assumptions, communication approvals, improvement retests. Protect that evidence from routine administrators where practical, define how long it remains useful and make gaps visible. Measures such as time to establish leadership, unresolved authority conflicts, critical contacts reached, exercise actions verified should trigger a review, escalation or investment decision; a dashboard without an accountable response path is only decoration.
Prepare for failure and misuse
Push the scenario beyond the primary recovery plan: an administrator account is compromised, a backup is incomplete or a key supplier cannot respond. Require leaders to prioritise services with imperfect information and explain the residual risk of reconnection. Convert lessons into owned changes and re-run the most difficult decision.
Exercise a scenario that removes a trusted dependency or exposes an abused privilege. Require the team to use real contacts, alternate authority, preserved records and recovery procedures. Capture what was known, what remained uncertain and which decision changed the outcome. Improvements should be verified through a repeated technical check rather than closed when a document is approved.
Move from a pilot to sustained control
Begin with one representative service and complete the sequence: select a realistic service impact, confirm participants and authority, run staged injects, record decisions and uncertainty, verify improvements in a focused rerun. Publish the minimum standard, the exception route and the evidence required for acceptance. Expand only after the pilot shows that owners can operate the control without hidden manual work or unsafe workarounds.
Review the design after major platform, supplier, identity or business-process changes. Retire obsolete access and configuration rather than carrying every historical exception forward. Report progress in terms of reduced attack paths, faster verified recovery and clearer ownership. This keeps the programme connected to operating risk instead of measuring activity alone.
What to do next.
- ✓Use real services and dependencies.
- ✓Distinguish facts from attacker claims.
- ✓Test alternate communications.
- ✓Exercise service-priority decisions.
- ✓Identify qualified legal and external contacts.
- ✓Re-run the hardest corrected decision.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.
Thandiwe Jacobs
Business Resilience ContributorWrites about incident preparation, service recovery and the decisions organisations need to make before disruption.
More from this writerAisha Petersen
Detection & Response ContributorFocuses on useful telemetry, investigation readiness and the operational decisions that help teams respond with evidence.
More from this writerLerato Molefe
Security Strategy ContributorConnects technical assurance, resilience evidence and investment decisions for executives, boards and transformation leaders.
More from this writer