Prepare decision-making before the pressure arrives
An incident plan should identify who can make containment, communication, expenditure and recovery decisions. Titles alone are not enough: record alternates, contact methods and decision thresholds. Assume ordinary email, collaboration or identity services may be unavailable and maintain a protected out-of-band contact list. Everyone involved should understand who leads the response and how technical, legal and business authority connect.
Define a simple severity model based on operational impact, information exposure, spread and uncertainty. The model should trigger appropriate escalation without forcing responders to prove every fact first. Establish when executives, insurers, external specialists and critical suppliers are contacted, subject to actual contracts and advice.
Know the systems and evidence you will need
Map critical services, dependencies, owners and recovery priorities. For each plausible scenario, identify which identity, endpoint, cloud, network and application evidence could help establish what happened. Confirm that logs are enabled, retained for a useful period, time-synchronised and accessible to authorised responders during degraded operations.
Preservation needs discipline. Record collection time, source and handling, and avoid making unnecessary changes to affected systems before evidence requirements are considered. Qualified legal advisers should guide privilege, notification and regulatory judgement where relevant. Technical responders provide facts; they should not improvise legal conclusions.
Create playbooks for the first practical actions
Detailed plans become difficult to navigate under pressure. Build concise playbooks for likely situations such as compromised mailboxes, ransomware indicators, stolen devices, cloud credential exposure and supplier compromise. Each playbook should cover validation, initial containment, evidence, internal escalation, communication and criteria for recovery. Avoid irreversible actions until their operational and evidential consequences are understood.
Containment must be proportionate. Isolating one device may be safe; disabling an identity platform or disconnecting a production network can create additional harm. Pre-authorise common low-risk actions and define who approves disruptive measures. Keep a decision log so the team can coordinate and later explain why actions were taken.
Engineer recovery, not just response
Recovery priorities should follow business dependence. Test restoration of data, configuration, identity and supporting infrastructure, and confirm that rebuilt systems are trustworthy before reconnecting them. Backups should be protected from the same credentials and paths that can affect production. Alternative manual processes may be necessary while technical recovery continues.
Communication is part of recovery. Prepare adaptable messages for employees, customers and suppliers without pre-writing claims that may be inaccurate. Decide who approves statements and how updates will be shared if normal channels are compromised. Keep factual certainty separate from working hypotheses.
Exercise, learn and fund the gaps
Tabletop exercises reveal unclear authority, missing contacts and hidden dependencies without creating a real outage. Use a plausible scenario, release information in stages and require participants to make decisions with incomplete facts. Include executives, technology teams and relevant business owners rather than treating the exercise as a security-only event.
Capture actions with owners and dates, then track them through governance. Repeat targeted technical exercises for containment and restoration. After real events and exercises, review the system rather than assigning blame: what signal was missed, which decision was delayed, what safeguard failed and what investment would materially change the next response?
What to do next.
- ✓Name incident leaders, alternates and decision authorities.
- ✓Maintain out-of-band contacts and access procedures.
- ✓Confirm critical logs, retention and responder access.
- ✓Create concise playbooks for the most plausible scenarios.
- ✓Protect and test restoration of critical dependencies.
- ✓Run tabletop exercises and track every improvement action.
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 writer