When I was deep in the trenches of incident response, there was one absolute rule: Only share what you know.
Every hour, we’d do a prep call with the team to get on the same page. Then, we’d jump onto an update call with the client. And without fail, every single time, they’d push for answers we didn’t have yet:
- “How long until we’re back online?”
- “Did the hackers take our data?”
- “Do we need to report this as a breach?”
And every time, our answer was the same: “We don’t have the data yet to answer that.”
Why? Because if you rush to answer before you have the facts, you’re just guessing.
Guessing leads to bad decisions.
Bad decisions lead to lawsuits.
Lawsuits lead to you getting thrown under the bus.
If you think that sounds extreme, you’ve never been on one of these calls.
Incident Response Looks Like Pure Chaos
When you’re called into an incident, you’re thrown into the middle of an active disaster.
If you follow the NIST Incident Response Framework, you know the five phases:
- Preparation
- Detection & Analysis ← This is where you show up.
- Containment
- Eradication & Recovery
- Post-Incident Activity
The problem? The client doesn’t care about the framework. They want answers now.
They’re in full panic mode, making knee-jerk decisions while you’re still piecing together the crime scene.
And if you don’t document everything, you’re flying blind.
Incident Response Without Documentation Is Dangerous
The most critical thing you can do during an incident isn’t answering client questions.
It’s documenting everything.
Make sure the incident log is updated every time you update your team. Check that every major finding actually made it into the documentation.
Why?
Because in the middle of an incident, people panic. They forget details. They miss critical steps.
And when it’s time for the post-incident review, you’ll be left wondering:
- How did the hackers get in?
- What did we do right? What did we miss?
- How do we make sure this never happens again?
Without a rock-solid incident log, you won’t have answers.
And when regulators or lawyers show up, “We think…” isn’t going to cut it.
What Goes in a Good Incident Log?
A real incident log isn’t some half-baked, scattered list of notes.
It’s a step-by-step, time-stamped record of everything that happened.
Here’s what should be in it:
- Incident Description – What happened and when?
- Who Reported It – Who discovered the breach? How?
- Response Team – Who’s involved in fixing it?
- Impacted Users & Groups – Who got hit? What systems were compromised?
- Screenshots & Audit Logs – Proof of what happened (archived for 13+ months).
- Affected Devices – What was infected? What was re-imaged?
- Password Resets – Were all impacted credentials changed?
- Company Response – What did leadership do? How was this communicated?
- Resolution Actions – A step-by-step breakdown of containment & recovery.
- Post-Incident Review – What went wrong? How do we prevent it next time?
This isn’t busywork.
It’s your insurance policy when someone comes knocking and demands:
“Why didn’t you stop this?”
Here’s the Good News: You Have Time to Prepare
In incident response, we never got a chance to prepare.
By the time we showed up, the fire was already burning.
You have an advantage.
As an MSP, you have time to:
- Build the right playbooks.
- Set up proper documentation.
- Train your team before they’re in the hot seat.
But only if you do it now.
Your Next Step
If you haven’t already, log into the portal, download the Security Incident Log, and add it to your MSP’s process.
- Review it.
- Make sure your team understands it.
- Don’t wait until you’re scrambling in the middle of a breach to get this right.
Because the only thing worse than experiencing a security incident…
…is having zero documentation when someone asks what happened.
