Stabilise before you optimise
The first 24 hours dictate the trajectory of the entire recovery effort. Acting too hastily can destroy forensic evidence, while acting too slowly allows an attacker to pivot and escalate privileges.
Initial containment: Disconnect affected systems from the network, but do not power them down. Powering off devices purges volatile memory (RAM), which often contains decryptors, active malware processes, and attacker IP addresses needed for investigation.
Evidence preservation: Isolate logs immediately. Ensure your firewall, VPN, domain controller, and EDR logs are sequestered so they cannot be wiped by the attacker. Export audit logs from identity providers, email platforms, and cloud services before making any changes.
- Record exactly when the issue was first noticed and by whom
- Identify who has authority to approve containment actions
- Do not wipe systems, delete mailboxes, or reimage devices before evidence is captured
- Screenshot suspicious activity, alerts, emails and configurations
- Save email headers, not just email bodies
Establish out-of-band communications
Set up a communication channel outside your corporate environment immediately. The attacker may be monitoring your corporate email, Slack, or Teams. Use Signal, WhatsApp, or a separate tenant for the crisis team.
Nominate a single communications lead. All internal updates should go through one channel. All external communications should be approved by a named person before release. Do not let technical staff make public statements. Do not let PR staff make technical claims.
Create an incident timeline
A simple timeline is one of the most useful artefacts during an incident. It does not need to be perfect — it needs to be started immediately and updated as new information emerges.
Capture: detection time, escalation time, who was notified, containment decisions made, affected users and systems, any external notifications, and the current state of each affected system (isolated, operational, unknown).
Protect identity and access
Review privileged accounts, active sessions, suspicious sign-ins, MFA changes, forwarding rules, OAuth grants and recent account recovery actions. In most breaches, the attacker's persistence mechanism is identity-based — they have a password, a session token, or an OAuth app grant that lets them back in even after you think you have contained the incident.
- Check for unauthorised inbox rules — forwarding rules are the most common BEC persistence mechanism
- Review OAuth app consents — attackers maintain access through malicious app permissions, not just passwords
- Reset compromised passwords AND revoke all active session tokens across all devices
- Review recent MFA changes and account recovery actions
Decision authority
The most damaging delays in incident response come from nobody being sure who can approve containment actions. "Should we disable the CEO's account?" is a question that needs a pre-decided answer, not a 45-minute discussion while the attacker is still active.
Define authority in advance for: system isolation, account disablement, external communications, legal engagement, insurer notification, regulator notification, and customer notification. Make sure alternates are named for every role.
What not to do
- Do not reboot or reimage affected systems before forensic evidence is captured
- Do not mass-reset all passwords until you understand the scope — this alerts the attacker that you have detected them
- Do not communicate via compromised channels — assume the attacker can read corporate email
- Do not pay a ransom without legal advice and formal decision authority
- Do not make public statements until facts are confirmed — speculation creates liability