The first 24 hours of an incident.

Most damage in a security incident comes not from the attacker but from the response: machines wiped before anyone captured evidence, systems restored straight onto the same hole, stakeholders told nothing until it was a crisis. A checklist exists to stop that. This one follows the phases in the NIST SP 800-61 incident-handling guide, compressed into what to actually do in the first 24 hours.

It is written for a small team or a solo responsible person — the situation most people are actually in when something goes wrong. Read it before you need it.

Phase 1 — Confirm and record

Before acting, establish what you know. Panic acts; discipline records first.

• Confirm it is real. Is this a genuine incident or a false alarm? A single odd log line is not yet an incident. Corroborate before escalating.
• Start a timeline. Open a document and note the time, what you saw, and what you did — from the very first minute. This record is worth more than you expect, for both the investigation and any later report.
• Note who has been told. Decide early who needs to know (a manager, a data-protection lead) and log when you informed them.

Phase 2 — Contain

Containment limits the damage without destroying the evidence you will need. The order matters:

• Isolate, do not wipe. Disconnect the affected machine from the network (pull the cable, disable the interface) but leave it powered on where possible. Wiping destroys evidence; isolation stops spread while preserving it.
• Preserve volatile evidence. If you have the skills, capture memory and running-process state before anything reboots. If not, simply not powering off already preserves a great deal.
• Rotate exposed credentials. If accounts or keys may be compromised, change them — from a known-clean machine, not the suspect one.

Phase 3 — Eradicate and recover

Only once the scope is understood do you remove the problem and restore service:

• Find the root cause first. Restoring before you know how they got in just invites them back through the same door. Understand the entry point.
• Rebuild clean. Where feasible, restore from a known-good backup or rebuild from scratch rather than trusting a machine you believe was cleaned. "Probably clean" is not a security state.
• Verify before reconnecting. Confirm the hole is closed and monitoring is in place, then bring the system back — watching it closely.

Phase 4 — Learn

The phase everyone skips and everyone regrets skipping:

• Hold a blameless review. What happened, what worked, what did not, what would have caught it sooner. Blameless, because hindsight-blame just teaches people to hide incidents.
• Turn findings into changes. Every incident should produce at least one concrete improvement — a new detection rule in your SIEM, a patched gap, a fixed process.
• Update this checklist. The best version of this document is the one you have revised after using it.

The mistakes this checklist prevents

It is easier to remember the order when you know what each step is guarding against. The four most common — and most expensive — first-day errors:

• Powering off or wiping too fast. The instinct to "clean it and move on" destroys the evidence that tells you scope. Isolate instead; you can always rebuild later, but you cannot un-delete a memory image.
• Restoring onto the same hole. Bringing a system back before you understand the entry point just resets the clock for the attacker. Root cause comes before recovery, always.
• Silence. Not telling the people who need to know — a manager, a data-protection lead, sometimes a regulator — turns a handled incident into a trust and compliance failure. Decide the notification path early and log it.
• No record. Relying on memory instead of a written timeline. Under stress, memory is unreliable and undefensible; a timestamped log is the single most valuable artefact you produce.

Notice that three of the four are about restraint, not action. That is the counter-intuitive heart of incident response: in the first 24 hours, the disciplined slow move usually beats the fast reflex. The checklist exists to make the disciplined move the default one, so you are not improvising judgement while adrenaline is high.

Scaling it to your situation

This is deliberately minimal so it fits a solo responder or a small team. A larger organisation layers more on top — defined roles, legal and PR involvement, formal forensics — but the phases do not change, and the NIST guide scales the same skeleton up. Start with this, and add structure as your responsibilities grow rather than trying to adopt an enterprise playbook you do not yet need.

The single most important idea here is sequence: confirm, contain, understand, then restore — with a written timeline running the whole way through. An incident handled in that order is recoverable and defensible. One handled by reflex usually is not.