Hours 0–4: isolate and preserve
The first play is containment with evidence intact — disconnect affected segments, snapshot infected systems before cleaning, and preserve logs. Teams that wipe first lose the indicators that tell them whether the attacker still holds access, and re-infection during recovery is the most common cause of a second, worse incident.
Hours 4–24: decide with the business, not for it
Restoring everything is rarely right; restoring too little is fatal. Rank systems by business impact, restore the minimum viable set — identity, DNS, comms, then the revenue path — and time each stage against the documented RTO. This ranking must be agreed before the incident, in an afternoon workshop, not improvised at 2 a.m.
Hours 24–72: restore, verify, communicate
Restore from the newest clean point, verify with the application owners (not just the infrastructure team), and communicate on a fixed cadence — every four hours internally, daily for customers. Silence breeds speculation, and speculation costs more trust than an honest “we restore at hour 40”.
