The incident response guide
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
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.
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.
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
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
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.
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
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.
Settled in advance, these turn a level change into one action with a predictable, rehearsed result.
Reach the right people
Raising the level alerts every group it should, at once. No dialling round, no building a recipient list mid-incident.
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.
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.
Coordinate the response
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.
Keep a shared picture
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
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.
Keep the documents reachable
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
The teams that stay calm in a real incident are the ones that have run a fake one. Three habits keep a response honest:
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
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.
Outcome: contained and recovered without paying, because the escalation was rehearsed, not improvised.
Outcome: contained early, trust intact, because severity was named and acted on at each step.
Putting it together
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.