The incident response guide

Mastering Incident Response

How to run the first 20 minutes of an incident with agreed alert levels: decide who to activate, reach the right people in one move, and rehearse it before the day it matters.

The first 20 minutes

An incident is won or lost before the real work starts

When something goes wrong, the first twenty minutes rarely go on fixing it. They go on two questions, asked under pressure, usually for the first time.

Decision 1

Who do we activate?

Which teams drop what they are doing and respond: leadership, IT, security, on-call. One level change should mobilise exactly those, and no one else.

Decision 2

How do we reach them?

The right people, reached fast, on a channel they will actually see. Not a scramble through a stale contact list.

Both are better decided in advance, when nobody is panicking. That is the whole idea behind running incidents with alert levels: agree what each level means and who it tells, once, and the hardest minutes of an incident become a single clear choice.

A shared language

Alert levels turn severity into one word everyone understands

The idea is borrowed from the military's DEFCON system: a small, fixed ladder of readiness states. Adapted to incident response, a level is a shorthand that a board member and an engineer read the same way. Say "we are at DEFCON 2" and everyone knows the severity, the posture, and roughly who is now involved, with no technical briefing.

A good scale runs from calm to critical, each step raising readiness and widening who is told. The exact number of levels and their wording are yours to set; five is a common, comfortable choice.

Define your levels

Five levels, in your own words

Here is the scale as a public board, on the DEFCON naming: the current level at the top, then all five below it, each with what it means and the action it calls for, written down before they are ever needed.

A public board on the DEFCON scale, from critical at the top to normal at the base.

Keep the DEFCON names or write your own; the discipline is the same either way. Each level carries a clear meaning, what triggers it, and who it alerts.

Make it yours. Some organisations run the scale the other way, with their most severe state at the top of the number line. Whatever the numbering, write down each level's meaning, what triggers it, and exactly who it alerts. In Defcon-App that is a few minutes of setup, and it becomes the backbone of everything below.

Build around the levels

Decide the response once, on paper, in the calm

A level is only useful if raising it does something. Attach three things to your scale ahead of time, so an incident runs itself rather than being improvised.

  • A one-page grab sheet. For each level: who it alerts, the people and numbers behind them, and the running order of the first calls. The single reference a tired responder reaches for at 3am.
  • Groups, not individuals. Leadership, IT and security, facilities, on-call. A level alerts groups, so the list stays right as people come and go.
  • Clear roles with backups. Who decides to escalate, who contacts whom, and who stands in when the first name does not answer.

Settled in advance, these turn a level change into one action with a predictable, rehearsed result.

Reach the right people

Alerting that works when everything else does not

One action, everyone informed

Raising the level alerts every group it should, at once. No dialling round, no building a recipient list mid-incident.

Independent of your own systems

If your network or email is down, that is exactly when you need to reach people. Alerting that runs on its own infrastructure still works when yours does not.

On a channel they will see

SMS reaches any phone. For the top level, a critical alert can take over the screen of the people who must respond, even on silent or locked.

The current level and the whole scale, in everyone's pocket.

Coordinate the response

Everyone in one war room

Once the alert is out, the response needs one place to run from: a war room. It can be physical, a room people walk into; virtual, a bridge everyone dials into; or both at once, with the people on site and the people at home in the same conversation.

Defcon-App gives you the virtual side: a meeting bridge everyone joins straight from the alert, by a link, a short code, or a phone. It is an alternative to Teams, Google Meet or whatever you normally meet on, and because it does not run on your own infrastructure it is still there when that is exactly what is down or compromised.

  • One tap in. The people you alerted join from the notification itself, or with a short code anyone can type on a phone.
  • On site, at home, or both. Remote responders are in the same room as the people in the building, so nobody is briefed twice.

Keep a shared picture

Short briefings, and a record of what was decided

In anything longer than a few minutes, a response drifts the moment people stop sharing what they know. The fix is a rhythm: short, timeboxed briefings at a set cadence, each one covering what changed, what is next, and who owns it.

The other half of a good briefing is the record. Keep a running timeline of what happened and when, and log the decisions as they are made and by whom. You want both during the incident, to stay coordinated and to bring anyone who only joins at the second or third briefing up to speed without re-explaining it all, and afterwards, to review honestly and to show what you did.

The tool helps with that. Hold the briefing in the war room and keep the timeline and decision log in Defcon-App as you go, so the record is built during the incident, not pieced together from memory the week after. When it is over, that record becomes the incident report, ready to review and to share.

Bring in outside help

Add an external without adding friction

Real incidents reach past your own team: a supplier, a consultant, an authority, the partner whose system is involved. They need to be in the room fast, and only in the room you asked them into.

  • A link or a code. Invite an external with a single shared link, or a join code they type on their phone. No account to create, nothing to install.
  • Scoped to the moment. They join the one room you invited them to, for this incident, and nothing more.

Keep the documents reachable

Your plan, available when your own systems are not

The playbook, the contact sheet, the grab sheet: if they live on the drive or in the inbox that the incident just took down, they are gone exactly when you reach for them. The point is not to keep the documents near the incident; it is to keep them somewhere the incident cannot reach.

Independent by design. Defcon-App holds your incident documents on its own infrastructure, separate from yours, so the plan and the files you rely on are still a click away when your network, drives or email are down.

Rehearse and improve

A plan you have never used is a guess

The teams that stay calm in a real incident are the ones that have run a fake one. Three habits keep a response honest:

  • Exercise it. A tabletop, a notification test, a full drill. You find the stale number and the missing decision in the rehearsal, not the emergency.
  • Keep the history. Every level change and incident logged, so you can see what happened and when, and prove it afterwards.
  • Measure readiness. Treat readiness as a number you watch, not a feeling. Reachable contacts, a current plan, a tested cascade. Fix the gaps while it is quiet.

Start with a score. Our two-minute readiness scorecard shows where you stand on clarity, reach, speed and resilience, before you change a thing.

In practice

Two incidents, level by level

Illustrative examples of what each level looks like in a real incident, from critical at the top to normal at the base. The levels do the coordinating; people make the decisions.

Illustrative · Ransomware

From an odd log entry to a contained outbreak

DEFCON 1Production at risk. Full emergency: restore from backup, legal and communications engaged, everyone who must act is alerted at once.
DEFCON 2Encryption begins on several machines. The breach is confirmed, affected systems are isolated, leadership is in.
DEFCON 3Suspicious software on a workstation. Access to critical systems is restricted; the response team moves to standby.
DEFCON 4IT spots unusual file-access attempts and raises the level. Security on-call is alerted and starts watching closely.
DEFCON 5Normal operations. Monitoring runs as usual and nothing has triggered a raise.

Outcome: contained and recovered without paying, because the escalation was rehearsed, not improvised.

Illustrative · Phishing

Catching a campaign before it lands

DEFCON 1Reserved for confirmed customer-data impact. Here it was never reached, because the earlier levels did their job.
DEFCON 2One person clicks and enters credentials. The account is locked immediately; no further access is found.
DEFCON 3Employees report a convincing fraudulent link. Security blocks the URLs across systems.
DEFCON 4A rise in phishing emails reaching staff. A clear, organisation-wide warning goes out.
DEFCON 5Normal operations. Mail filtering and reporting carry on as usual.

Outcome: contained early, trust intact, because severity was named and acted on at each step.

Putting it together

The short version

  • Define your levels and what each one means, triggers and tells, in the calm.
  • Attach the response to each level: a grab sheet, groups, roles with backups.
  • Make alerting reliable: one action, independent of your own systems, on a channel people see.
  • Rehearse and review, and watch readiness as a number.

Defcon-App is built to do exactly this

Define your levels, keep a one-page grab sheet, alert the right groups in one action, and reach people even when your own systems are down.