An incident is a bad time to figure out how you respond to incidents. The teams that come through cleanly are almost never the ones with the cleverest tools — they're the ones that decided how they'd operate before anything was on fire. A few things I keep coming back to.
1. The preparation is the work
By the time an alert fires, most of the outcome is already determined by what you set up beforehand: logging that actually captures what you'll need, access you can revoke instantly, backups you've tested restoring. You can't build these under pressure. Treat the calm periods as the real preparation.
2. Contain before you investigate
The urge to fully understand an incident before acting is natural and often wrong. If an account is compromised, disable it and revoke its sessions now; you can reconstruct the timeline after the bleeding stops. Containment buys you the time to investigate calmly.
3. Communication is half the job
A quiet, competent technical response that nobody can see reads, to a nervous organization, like nothing is happening. Give leadership a steady cadence of plain-language updates: what you know, what you're doing, what you need. It's not overhead — it's what keeps the response from being second-guessed.
4. Write it down as you go
A contemporaneous timeline — who did what, when, and why — is worth more than memory, both for the post-incident review and for any legal or compliance follow-up. Capture it live; you will not reconstruct it accurately later.
5. The review is where you actually get better
The point of a blameless post-incident review isn't to relive the bad day. It's to turn each incident into one or two concrete changes that make the next one smaller. An incident you don't learn from is just damage.
Originally published at athanasiuswahbah.com by Athanasius Wahbah.
Top comments (0)