Respond · Reference sheet

Incident Kickoff Toolkit

The first hour of an incident: the moment it's declared through the first status brief. Use it to build the incident-response section of your DR/BC plan — or hand it out as-is.

In a live incident, keep the quick reference card at hand instead. This document is for building your organization's own procedures ahead of time.

1. Incident Start Checklist

Run this once, at the moment an incident is declared. The goal is a fast, consistent kickoff — not a perfect one.

1.1 Is it incident-shaped?

Check the situation against the severity matrix before you open an incident. If it's clearly a P4, it may just be a ticket.

Level	Criteria	Response
P1 — Critical	Business outage, all users affected.	Immediate fix required.
P2 — High	Major impact, multiple users/services down.	Fast resolution needed.
P3 — Medium	Limited impact, workaround possible.	Handled in normal SLA.
P4 — Low	Minor issue, cosmetic or single user.	Planned resolution.

Not sure which level? Default to P3 and re-triage once you know more. It's easier to stand a response down than to catch up from behind.

1.2 Apply STOP before acting

• Stop — don't act on the first thing you see.
• Take it all in — get the full picture before committing.
• Observe — check what's actually happening, not what's assumed.
• Proceed — act, now that the picture is clear.

1.3 The checklist

• Confirm it's incident-shaped and assign a priority level (above). Log the decision and who made it.
• Apply STOP.
• Name an Incident Commander. This is the first and most important decision — everything else follows from it.
• IC assigns roles as needed from the table below. Not every incident needs every role — right-size the team to the incident, not the org chart.
• Open a single incident channel or bridge. All coordination happens there — no side channels, no DMs with decisions in them.
• Start the clock. Log: start time, how the incident was detected, and who declared it.
• Open the incident log (Run Sheet — Section 3) and, if required, the incident Detail Form.
• Notify stakeholders per the escalation path for this priority level.
• Schedule the first status brief (Section 2) before ending the kickoff call.

1.4 Roles in incident response

Based on the Incident Command System (ICS). Assign only what the incident needs.

Role	Owns
Incident Commander	Owns the response. Makes the call others can't or shouldn't. One person, full authority, for the duration.
Public Information Officer	Owns external and stakeholder-facing communication. Nobody else talks to customers or press.
Safety Officer	Watches the responders — sleep, stress, physical and operational safety. Can pause the response.
Liaison Officer	Coordinates with outside parties: vendors, partners, other internal teams not directly responding.
Operations Section Chief	Runs the technical response — the people actually fixing the problem.
Planning Section Chief	Tracks status, next steps, and the parking lot of things to deal with later.
Logistics Section Chief	Gets responders what they need — access, tools, food, rest.
Finance Section Chief	Tracks cost and contractual impact — SLAs, vendor spend, credits owed.

Decision-making structure: authority runs through the Incident Commander. Section Chiefs run their sections; they escalate decisions outside their authority to the IC, not around them.

2. Briefing Checklist

A brief keeps leadership, stakeholders, and responders aligned without pulling responders off the fix. It is a sync, not a status meeting — keep it short and keep it moving.

2.1 Who's in the room

Incident Commander, active Section Chiefs, the Public Information Officer, and one stakeholder representative. Anyone actively fixing the problem should not be in the brief — send someone in their place, or get the update from the Run Sheet.

2.2 Cadence

Set the default cadence by priority level, and confirm the next brief time at the end of every brief. Adjust to what your organization can sustain.

Priority	Suggested cadence
P1 — Critical	Every 30 minutes
P2 — High	Hourly
P3 — Medium	Once per shift
P4 — Low	As needed

2.3 Agenda — same order, every time

• Situation — current state, in plain language.
• Impact — who or what is affected, right now.
• Actions taken since the last brief.
• Actions in progress, and who owns each one.
• Blockers / asks — what's needed from someone outside the room.
• Set the time of the next brief before you close.

2.4 Ground rules

• Be kind — everyone makes mistakes, and it probably wasn't a single person's fault.
• Be clear — keep it simple, avoid misunderstandings.
• Be honest — when everyone has the full picture, solutions are easier to find.

Stick to facts. Blame slows the response down and makes people less likely to surface bad news early — which is when it's most useful.

2.5 Stakeholder update (separate from the internal brief)

Shorter, plainer, and less technical than the internal brief. Owned by the Public Information Officer. Three lines, no more:

• What happened.
• What we're doing about it.
• When we'll update again.

Draft this before the first external update goes out, and reuse the same three-line structure for every update after — consistency reads as competence.

3. Run Sheet Template

A single chronological record of what happened, when, and who did it. It's the incident's source of truth: it feeds the stakeholder updates, the post-mortem, and any required documentation.

3.1 How to use it

• Log every material action or decision in real time — while it happens, not from memory afterward.
• One line per event. Timestamp everything in 24-hour time.
• Anyone on the response can add a line. The Planning Section Chief owns keeping it current and complete.
• Don't edit history — if something changes, add a new line rather than rewriting an old one.

3.2 Fields

Field	What goes here
Time	24-hour clock, to the minute.
Action / Event	What happened or what was done — one clear sentence.
Owner	Who did it or is doing it.
Status	Logged / In progress / Done / Blocked.
Notes	Anything needed for context later — links, error codes, decisions made.

3.3 Example

Time	Action / Event	Owner	Status	Notes
09:14	Alert fired — payments API error rate > 20%.	J. Alvarez	Logged	Auto-detected via monitoring.
09:17	Incident declared, P1. IC assigned.	J. Alvarez	Done	IC: J. Alvarez
09:22	Ops began rollback of latest deploy.	R. Osei	In progress	ETA 10 min

3.4 Template — for use

Time	Action / Event	Owner	Status	Notes

After the incident: this log is the primary input to the post-mortem (what happened, how we found out, how we responded, how we recovered, what we're doing about it) and to any required incident documentation.