Incident Commander Handbook Template

Incident Commander Handbook: [Organisation name]

Handbook for the incident commander (IC) and the other incident response roles: deputy, scribe, operations lead, communications lead, customer liaison, internal liaison and subject matter experts. Covers the role RACI, how to declare an incident and take command, how to hand over command, the battle rhythm and status cadence, the decision log, escalation, closing the incident and handing over to the postmortem, and a one-page IC checklist. Structure aligned with the roles and practices of the PagerDuty Incident Response documentation (Apache-2.0) and based on the Incident Command System concepts in the FEMA National Incident Management System (NIMS), Third Edition (October 2017). Severity levels SEV1 to SEV4 come from the Incident Severity Matrix (ops/incident-severity-matrix). Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS commerce platform.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and principles
2. Incident command concepts
3. Roles and responsibilities
4. RACI matrix
5. Staffing by severity
6. Declaring an incident and taking command
7. Battle rhythm and status cadence
8. Decision log
9. Escalation
10. Handover of command
11. Closing the incident and handover to postmortem
12. Security incidents
13. One-page IC checklist
14. Training, qualification and metrics
15. Glossary and references
16. Standard and licence note

1. Purpose, scope and principles

1.1 Purpose

During an incident many people want to help at once. Without structure they duplicate work, change the same system in conflicting ways and forget to tell customers. This handbook gives one person, the incident commander, the authority to coordinate, and gives every other responder a clear role, so that the organisation restores service quickly, communicates predictably and learns afterwards.

1.2 Scope

• Every SEV1 and SEV2 incident uses the full structure in this handbook with a dedicated IC from the IC rotation.
• SEV3 and SEV4 incidents are run by the primary on-call engineer, who acts as IC and uses the parts of the handbook that help, at minimum the decision log and closing steps.
• Security incidents follow this handbook plus the variations in section 12 and the Incident Response Plan (compliance/incident-response-plan).

1.3 Principles

1. Command is a role, not a rank. While the incident is active the IC outranks everyone on incident matters, including executives. Executives who join contribute through the internal liaison or the executive update, not by directing responders.
2. The IC does not fix. The IC coordinates, decides and communicates. If the IC has to perform technical work, the IC first hands command to someone else.
3. Mitigate first. Restore service by the safest available action (roll back, fail over, disable a feature, shed load) before looking for root cause.
4. One voice outward. Only the communications lead publishes external updates; only the internal liaison briefs stakeholders outside the response.
5. Say it, then write it. Every decision is spoken on the bridge and written in the decision log.
6. Blameless throughout. Responders say what they see and what they did without fear; the postmortem looks for system causes.

2. Incident command concepts

The Incident Command System (ICS), part of the FEMA National Incident Management System (NIMS), Third Edition (October 2017), lists management characteristics that make incident response work across organisations. The table maps the ones that matter most for software incidents to the practice in this handbook. Descriptions are original summaries.

3. Roles and responsibilities

Each responder reports to exactly one person. Roles are filled by rotation, not by seniority.

4. RACI matrix

5. Staffing by severity

5.1 Minimum staffing

5.2 Span of control and workstreams

Keep the number of people reporting directly to any one person small, about five (Example rule), in line with the NIMS guide. When the operations lead coordinates more than five SMEs, split the work into workstreams (for example "database recovery", "traffic failover", "customer data reconciliation"), each with its own lead, a separate sub-channel and a single report into the operations lead.

6. Declaring an incident and taking command

6.1 Who declares and when

Anyone may declare an incident when an event meets a criterion in the Incident Severity Matrix (ops/incident-severity-matrix). The usual trigger is a page under the Alerting Policy (ops/alerting-policy) or a customer report escalated by support. Declare first, then refine.

6.2 Steps to declare (first 5 minutes)

6.3 Steps to take command

When the IC joins, the IC says on the bridge and writes in the channel:

"This is [name]. I am the incident commander for INC-NNNN. Current severity is SEV[n]. [Name] is operations lead, [name] is scribe, [name] is communications lead. Next update at HH:MM UTC."

Then, within 10 minutes (Example):

1. Get a 60-second briefing from the declarer: impact, timeline, actions taken, current hypothesis.
2. Confirm or change the severity using the severity matrix.
3. Assign every role required by section 5.1. Unfilled roles are escalated, not skipped.
4. State the first objective ("stop the errors", not "find the bug").
5. Confirm the communications lead has the first status post scheduled within the severity matrix's deadline.
6. Ask the scribe to record the command time.

7. Battle rhythm and status cadence

7.1 Cadence by severity

External and stakeholder cadences are set by the Incident Severity Matrix (ops/incident-severity-matrix, section 5.2). The internal tactical loop below is owned by this handbook.

7.2 Tactical update format

At each tactical update the IC asks each lead in turn and then sums up:

1. Situation: current impact and trend (better, same, worse).
2. Objectives: what we are trying to achieve before the next update.
3. Actions: what is in progress, by whom, expected result.
4. Decisions needed: options, risks, recommendation.
5. Next update: time in UTC.

7.3 Written status update

The scribe or deputy posts this in the channel after each tactical update; the internal liaison reuses it for stakeholders.

INC-NNNN | SEV[n] | Status: [Investigating / Identified / Mitigating / Monitoring / Resolved]
Impact: [who is affected and how, with numbers]
Since: [HH:MM UTC]   Current: [better / same / worse]
Doing now: [action, owner]
Decisions: [decision taken, time]
Next update: [HH:MM UTC]
IC: [name]   Ops lead: [name]   Comms: [name]

7.4 Long-running incidents

• Plan shifts when an incident is likely to last more than [4] hours. Responders rotate out after no more than [8] hours (Example).
• Name the next IC early and hand over with section 10.
• Hold a short planning check every [2] hours: are the objectives still right, are the right people involved, should severity change?

8. Decision log

Record every decision that changes the response, the system or the communication. Use IDs DEC-NNN within the incident.

The Example incident (a different one from the checkout incident in the Postmortem template, dev/postmortem) started at 09:12 with the deployment, was declared at 09:17 (5 minutes after impact started) and mitigated by 09:38. Time to mitigate from impact start is 26 minutes. Initial severity SEV2, peak severity SEV1. DEC-005 skips SEV2 on the way down, which the severity matrix allows once the lower criteria have been met for 30 minutes (09:38 plus 30 minutes is 10:08).

9. Escalation

When working with an external provider during a shared incident, agree joint objectives and a single point of contact on each side. This is a lightweight form of unified command.

10. Handover of command

10.1 When to hand over

• The IC has been in command for [4] hours at SEV1 (Example) or wants a break.
• The IC needs to do hands-on technical work.
• A more experienced IC or the security incident lead takes over because the nature of the incident has changed.
• The shift ends; for planned shift handover see also Shift Handoff (ops/shift-handoff).

10.2 Handover steps

10.3 Handover briefing

Use this structure for every handover, spoken and then pasted in the channel, so the incoming IC can check nothing was missed.

Incident: INC-NNNN, SEV[n], declared HH:MM UTC
Impact now: [who, how many, trend]
Timeline highlights: [3 to 5 key events]
Current objectives: [list]
Actions in progress: [action, owner, expected time]
Open decisions: [decision, options, recommendation]
Roles: Ops [name], Comms [name], Scribe [name], Liaisons [names]
Commitments made: [next status page post HH:MM, customer promises, executive briefing]
Risks: [what could make it worse]

11. Closing the incident and handover to postmortem

11.1 States

The incident record moves through these states. This handbook owns the status words for the library: the On-call Handbook (ops/on-call-handbook), Incident Communication (dev/incident-communication) and the status page use the same five public words (Investigating, Identified, Mitigating, Monitoring, Resolved); Closed is internal only. Use the same words in status updates so readers know exactly where the response stands.

11.2 Criteria to resolve

• Customer impact has ended and the service has met its SLO indicators for at least [30] minutes at SEV1 or SEV2 (Example).
• No temporary mitigation needs active human attention, or the remaining attention is handed to a named owner with a ticket.
• The communications lead has published the resolution post.

11.3 Closing steps

11.4 Handover package to the postmortem owner

The postmortem owner receives: the incident record, the timeline, the decision log, the list of responders and roles, the communications sent, dashboards and queries used, and the open questions the team had. The review itself follows the Postmortem template (dev/postmortem).

12. Security incidents

• Channel: private, need-to-know; the IC records who is in it.
• Leadership: for SEV1 and SEV2 the IC comes from the IC rotation and the security incident lead is operations lead for containment and eradication. For SEV3 and SEV4 the security incident lead may act as IC. When engineering and security both hold authority, they agree joint objectives (unified command) and record them as decisions.
• Evidence: preserve logs, disk images and access records before destructive remediation where feasible; record chain of custody per the Incident Response Plan (compliance/incident-response-plan).
• Communication: status page wording and any customer notice are approved by legal and the security lead; notification deadlines are tracked by legal and privacy from the time the security criterion is met.
• Playbooks: the operations lead uses the relevant SOC Playbook (security/soc-playbook) for scenario-specific steps.
• Lifecycle link: NIST SP 800-61 Rev. 3 (April 2025) frames incident response within the NIST Cybersecurity Framework 2.0 Functions; the incident response plan maps this handbook's steps to those Functions.

13. One-page IC checklist

On joining

• Announce yourself as IC with the incident number and severity.
• Get the 60-second briefing.
• Confirm severity against the severity matrix; upgrade if in doubt.
• Assign ops lead, scribe and comms lead (SEV1 and SEV2: separate people).
• Assign deputy, customer liaison and internal liaison for SEV1.
• Set the first objective and the next update time.

Every cycle

• Run the tactical update: situation, objectives, actions, decisions, next update.
• Check the communications cadence is being met.
• Decide; do not let options hang open without an owner and a deadline.
• Ask "should we escalate?" and "is the severity still right?"
• Make sure every decision is in the decision log.

Before risky actions

• Ops lead states the action, expected result and rollback.
• Ask for objections on the bridge; give 30 seconds.
• Record the decision, then approve.

Handing over

• Give the handover briefing; incoming IC repeats back.
• Announce the new IC and update the tool.

Closing

• Impact ended and stable for the agreed period.
• Final status posts sent.
• Postmortem owner and due date named.
• Initial and peak severity recorded.
• Responders thanked and released.

14. Training, qualification and metrics

14.1 Qualification path

Keep at least [6] qualified ICs on the rotation, so each is on duty no more than one week in six (Example), and never pair IC duty with primary service on-call in the same shift.

14.2 Metrics

Example for one quarter at Corvid Commerce: 15 SEV1 and SEV2 incidents; 14 had all roles filled within 15 minutes, giving 14 / 15 = 93.3%. Of 120 status updates due, 116 were on time, giving 96.7%.

15. Glossary and references

15.1 Glossary

15.2 Related templates

• Incident Severity Matrix (ops/incident-severity-matrix)
• Alerting Policy (ops/alerting-policy)
• On-call Handbook (ops/on-call-handbook)
• Incident Communication (dev/incident-communication)
• Runbook (dev/runbook)
• Postmortem (dev/postmortem)
• Incident Response Plan (compliance/incident-response-plan)
• SOC Playbook (security/soc-playbook)
• Game Day Plan (ops/game-day-plan) and Tabletop Exercise (security/tabletop-exercise)

15.3 References

Standard and licence note

Structure aligned with the incident response roles and practices in the PagerDuty Incident Response documentation (response.pagerduty.com, Apache-2.0, copyright PagerDuty, Inc.), adapted in original words. Based on the Incident Command System concepts in the FEMA National Incident Management System, Third Edition (October 2017), and on NIST SP 800-61 Rev. 3 (April 2025), both US Government works in the public domain. Google's Site Reliability Engineering books are cited as further reading only and no text from them is reproduced. PagerDuty is a trademark of its owner; this template is not affiliated with or endorsed by it. Corvid Commerce is fictional. This template is original text written for this collection. Check the current official versions of the sources before use. Template licence: MIT.