DEV Community

Hive80-lab
Hive80-lab

Posted on

The First 30 Minutes of an Incident: a checklist small teams can actually run

#security #infosec #tutorial

The First 30 Minutes of an Incident: a checklist small teams can actually run

Most incident response advice is written for organisations with a security
team, an on-call rotation, and a war room. If you run a small business, you
have none of that. What you have at 2am is three people in a group chat, one
of whom just noticed something is very wrong.

The good news: the first 30 minutes of an incident don't need a 40-page plan.
They need a short checklist, a named decision-maker, and a log. Here is the
version we hand to small teams — minute by minute, designed to be run by
ordinary people under stress, not by security professionals.

Minute 0-2: Declare it

An incident starts when someone says it starts. The most common small-team
failure is spending 40 minutes "just checking whether it's really a problem"
while the clock runs.

One person says the sentence out loud (or in the group chat): "I'm
declaring an incident: [what we see], [when we first saw it]. I'm running
this until someone takes over."

That single sentence does three things: it gives the event a start time, it
names an owner, and it gives everyone else permission to act on it. You can
stand down in 20 minutes if it turns out to be a false alarm. You cannot
recover a lost half-hour.

Minute 2-5: Open the log

Start one running log, in one place everyone can see — a shared doc, the
group chat pinned message, whatever you have. Not six scattered threads.

Every entry gets a timestamp and initials. The log format is deliberately
boring:

  • 14:05 JT — customer reports "we can't open invoices" (email quote)
  • 14:07 JT — file server shows ransom note; screenshot saved to inc-0911/
  • 14:09 PM — decided: payments provider will be disconnected (see M10-20)

Write down what you saw, not what you conclude. The log is what you'll use
to reconstruct the timeline for your insurer, your lawyer, and your own
post-incident review. Screenshots go in an incident folder before anything
gets touched. Memory degrades; a timestamped log doesn't.

Minute 5-10: Set the floor

Now make one decision: how bad is this? Don't build a 5-level matrix in
the moment — three levels are plenty, and only one of them should be allowed
to interrupt anything:

  • Sev 1 — business stopped or data being actively destroyed. Wake people up. Disconnect first, ask questions later.
  • Sev 2 — degraded, contained. Work it during business hours, tell the people who need to know.
  • Sev 3 — noise, no customer impact. Log it, fix it in the normal queue.

If you genuinely can't tell, treat it as Sev 1 for the next 20 minutes. It's
much cheaper to over-declare for half an hour than to under-declare an
active intrusion.

And in the same breath: name who has authority to disconnect things. Not
"who can" — anyone can pull a cable. Who decides. If that name isn't
written down before tonight, the decision gets made by whoever panics first.

Minute 10-20: Contain — disconnect, don't destroy

Containment in a small team is mostly one repeated action: separate the
affected thing from everything else. In rough priority order:

  1. Disconnect the affected machine(s) from the network (unplug or disable Wi-Fi). Powered off is not the goal — a powered-on, disconnected machine preserves the evidence in its memory.
  2. Pause the integrations that talk to it: backups, sync folders, file shares, payment connections. Ransomware loves a live sync channel.
  3. Check the backups exist and are isolated — before anyone promises a restore. If your backup destination was mapped on the same file server, assume it's reachable too.
  4. Do not delete, wipe, "clean up", or reinstall anything yet. That hard drive is now evidence.

One person does the disconnecting. Everyone else feeds that person
information. Two people improvising in parallel is how the wrong server
gets rebooted.

Minute 20-25: Say something — to staff and to customers

By minute 20 you need two short messages, and both get easier if they exist
as templates written on a calm day.

To staff: what's happening, what they must do right now (usually "don't
open files from the shared drive, report anything strange"), and where
updates will appear. Half a page, no jargon.

To the first affected customer: you know there's an issue, you're
investigating, here's the workaround if one exists, here's when you'll next
update them. Notice what's missing: a cause. Say "we don't know yet" — it's
more credible than an early confident guess that turns out to be wrong.

Silence is the expensive option. Rumour fills the gap faster than facts do.

Minute 25-30: Fix the clock and hand off

Close the first 30 minutes by scheduling the next update — "next check-in
15:30, owner PM" — and writing it in the log. Open-ended incidents eat
teams; a named next-check-in time keeps people from doom-scrolling the log
and lets the owner sleep in 90-minute blocks if it runs long.

If the incident is real and growing, this is also the moment to make the
phone calls you can't make at 3am alone: external IT support, your insurer's
hotline (many cyber policies require you to notify them promptly — check the
number before you need it), and whoever in the family/business needs to
know the day's plan has changed.

The whole thing on one page

  1. Declare — one sentence: what, when, who's running it.
  2. Log — one shared log, timestamps + initials, screenshots saved first.
  3. Sev it — three levels; when unsure, act Sev 1 for 20 minutes; name who may disconnect.
  4. Contain — disconnect, pause syncs/backups, verify backups exist isolated, touch nothing else.
  5. Tell — staff message + first-customer message, "we don't know yet" is allowed.
  6. Clock — next check-in named, owner named, escalation numbers dialed.

That fits on one printed page, which is the point. A checklist nobody can
read at 2am is decoration.

What you should do on a calm day instead

Everything above works better when 80% of it is pre-written: the declaration
sentence, the two comms templates, the disconnect order, and the severity
definitions with named people filled in. That's 30 minutes of homework that
saves you the first 30 minutes of every incident.

We put that homework into the First 30 Minutes free one-page checklist —
print it and put it where you'll find it:

This is general guidance, not legal or regulatory advice — adapt it to your
own environment and obligations.

We're Hive80 Lab, a small ops lab writing templates for teams with no
security staff. If you've lived through a real small-team incident: what did
your first 30 minutes actually look like? The comments are open — I'd
genuinely like to know how far your experience matched this sequence.

Top comments (0)