What to Do First After a Data Breach: A Checklist

It’s 11 PM and someone just flagged unusual login activity on a shared admin account. Nobody on the call has done this before, panic is setting in, and the instinct is to start doing things — reset every password, pull the server offline, email customers immediately. Some of that instinct is right. Some of it will destroy evidence you need later, or trigger a public notification before you actually know what happened.

Incident response has a well-established order for a reason: contain first, understand second, notify third, fix the root cause fourth, review after. Skipping ahead — like notifying before you’ve contained, or remediating before you’ve assessed scope — tends to create more problems than it solves, and a small team without a dedicated security function is exactly who benefits most from having the order written down before the moment it’s needed.

What breach response actually involves

The standard shape is five phases: contain the immediate exposure so it stops getting worse, assess what data and systems were actually affected, notify the people and authorities who need to know (which often has legal deadlines attached), remediate the underlying vulnerability so it can’t happen the same way twice, and review what happened to improve the process for next time. Each phase depends on the previous one being done reasonably well — notifying before you’ve assessed scope means you might have to send a second, more alarming correction later.

None of this requires an enterprise incident response platform for a small team. It requires a checklist that doesn’t get lost in a panicked Slack thread, and enough structure that two people working the same incident aren’t duplicating or skipping steps.

Why people get stuck here

• No one owns the checklist until it’s needed. Most small teams don’t have a written incident response plan until they’re mid-incident and improvising one, which is the worst time to design a process.
• Notification deadlines are legally binding in many places. Depending on jurisdiction and what data was involved, there can be a strict clock (sometimes 72 hours) on notifying regulators or affected individuals — and that clock starts whether or not you’ve finished your assessment.
• Containment and evidence preservation conflict. Pulling a compromised server offline immediately can stop the damage but also destroy forensic evidence about how the attacker got in, which you need for the remediation phase.
• The review phase gets skipped entirely once the fire is out, which means the same gap that caused this breach is still there for the next one.

What a good response checklist looks like

Structured by phase, not just a flat list

A flat to-do list doesn’t communicate sequencing. Organizing by contain / assess / notify / remediate / review makes it obvious which actions can happen in parallel and which genuinely need to wait.

Trackable progress that survives a chaotic incident

During an active incident, people join and leave the response, shifts change, and context gets lost. A checklist with saved progress means someone picking this up hours later can see exactly what’s already been done.

Doesn’t require an account or cloud sign-up mid-incident

The last thing you want during a security incident is to create a new account somewhere to track your response to a security incident. A tool that saves progress locally avoids adding a new vendor into the mix while you’re already dealing with a breach.

Common mistakes to avoid

• Notifying the public or regulators before you’ve confirmed scope, then having to walk back or correct the notification later.
• Wiping or rebuilding a compromised system before capturing logs and evidence of how the attacker got in.
• Treating incident response as a solo effort when a small team is available to split contain/assess/notify work in parallel.
• Forgetting to check whether notification deadlines apply based on the type of data exposed and where affected individuals are located.
• Closing the incident without a review step, leaving the same gap open for a repeat.

How to use the Data Breach Response Checklist

Online Tool Store’s Data Breach Response Checklist tracks your progress through all five phases, saved locally in your browser.

1. Open the tool as soon as an incident is suspected, before you start acting.
2. Work through the Contain phase items first, checking each off as completed.
3. Move to Assess, then Notify, tracking any jurisdiction-specific deadlines as you go.
4. Finish with Remediate and Review once the immediate incident is under control.

Frequently asked questions

How fast do I need to notify people after a data breach?

It depends heavily on jurisdiction and the type of data involved — some regulations set a strict window (commonly around 72 hours) from when you became aware of the breach. Check the specific legal requirements that apply to your data and location as part of the assess phase.

Should I take the affected system offline immediately?

Usually yes for active, ongoing exposure, but be aware this can destroy evidence about how the attacker got in. If possible, capture logs and a system snapshot before or during containment rather than after.

Do I need a security team to use an incident response checklist?

No. A checklist is most valuable for teams without a dedicated security function, since it provides the structure and sequencing that an experienced incident responder would otherwise carry in their head.

Final thought

The teams that handle a breach well aren’t the ones with the fanciest tooling — they’re the ones who already knew what order to do things in before the incident started. Write the checklist down before you need it.

Try the free Data Breach Response Checklist