Incident roles: incident commander, communications lead and scribe

When an incident requires more than one person, the work splits into coordinating, fixing, communicating, and recording. Named roles ensure each job has exactly one owner. This guide covers the three roles most processes share: incident commander, communications lead, and scribe. It also explains supporting roles, role combinations, command handoffs, and provides one-page cards for each role. For declaring an incident and the overall flow, see incident response basics.

Where the roles come from

Software incident roles originate from the Incident Command System (ICS). FIRESCOPE, an interagency task force in California, developed ICS in the 1970s. Fast-moving wildfires had exposed unclear lines of command, inconsistent terminology and unclear objectives (USDA Forest Service).

ICS now forms part of FEMA's National Incident Management System. FEMA describes ICS as organized around functional areas, starting with Command, Operations, and Planning (NIMS components).

Google built its incident process on ICS. The Managing Incidents chapter of the Google SRE book defines four roles: incident command, operational work, communication, and planning. The SRE workbook names them incident commander (IC), communications lead (CL), and operations lead (OL).

PagerDuty publishes its process openly, formerly at response.pagerduty.com and now in the PagerDuty incident response guide. Its roles page defines incident commander, deputy, scribe, subject matter expert, customer liaison, and internal liaison.

The names vary, but the split is the same in each: one person coordinates, others fix the system, one person handles external communication and someone records the timeline.

Incident commander

The incident commander (IC) directs the response effort. PagerDuty describes the IC as the single source of truth for the current state and next steps.

The role involves:

Announcing the role on the call and in the incident channel, and naming the deputy and scribe (during an incident).
Gathering status from responders, deciding on the next action, and delegating every repair action to a named person.
Approving external messages before they are posted.
Keeping the live incident state document current. Google calls this the commander's most important responsibility.
Holding every role that has not been delegated. The SRE workbook says the IC assumes all undelegated roles by default.
Deciding when the incident is over, ending the call, and assigning an owner for the postmortem.

PagerDuty's IC training states the IC does not perform remediations, check graphs, or read logs. Those tasks go to subject matter experts. The IC does not need to be the deepest technical expert in the room.

Habits from the same training:

Time-box tasks: name the person, give a limit in minutes, and confirm they understood. Never ask "can someone...", because nobody owns it.
Before a decision, ask whether there are any strong objections, pause, then proceed. The IC's decision is final, but objections are noted.
With incomplete information, pick an option and act. PagerDuty's view is that a wrong decision beats no decision.
If an executive starts directing the response, ask whether they want to take command. If yes, hand over formally. If no, ask them to let the IC run it.

Communications lead

The communications lead keeps people outside the response informed so the fixers stay focused. Google calls this role the public face of the response team, issuing periodic updates. PagerDuty splits the work into two distinct roles.

The customer liaison drafts external messages, picks templates, and tells the incident commander how many customers are affected. This person posts publicly only after the incident commander approves (roles page).

The internal liaison brings in more responders and other departments when the incident commander asks. This person answers stakeholder questions and posts a short summary for executives about every 30 minutes (during an incident).

What the communications lead must not do: post publicly without the incident commander's approval, guess, or promise a resolution time. PagerDuty's customer liaison training says never lie or guess, do not estimate resolution times, and leave out internal component names. What to write is covered in what to write on a status page.

Scribe

The scribe maintains the timeline used for the postmortem (scribe training).

The job:

Record the call if possible.
Log key actions, owners, status reports, decisions, and outcomes in the incident channel.
Record decision results, not debates. "Polled for a rolling restart. A is proceeding" suffices.
Mark follow-ups with TODO: for easy collection later.

The scribe must not remediate, check graphs, read logs, or record every word.

The supporting roles

Deputy (PagerDuty): Supports the IC and takes over command if needed. Tracks timers and reminds the IC of incident duration every 10 minutes to review severity. Pages people when instructed (deputy training). The deputy does not remediate.
Subject matter experts (SMEs) or operations lead: Investigate and fix issues. PagerDuty asks SMEs to report findings to the IC and not act unless told. Google states only the operations team changes the system during an incident.
Planning (Google): Handles longer-running work such as filing bugs, arranging shift handoffs, and noting changes from normal for potential reversion.

When one person holds several roles

Combining roles is expected. PagerDuty states not every role needs a different person. Its example is a deputy who also acts as scribe and internal liaison. The SRE workbook says the communications role can fold back into the IC when an incident gets small enough.

A recommended default by number of responders (a starting point, not a standard):

Responders	Suggested split
1	One person holds every role. Still post updates in the incident channel as you go, so there is a timeline.
2	One person fixes. The other is IC, communications lead and scribe.
3-5	IC on their own. One person is communications lead and scribe. The rest are SMEs.
6 or more, or several teams	Every role filled separately, plus a deputy. Split SMEs into sub-teams with their own leads.

The one combination to avoid is IC plus hands-on fixing. Once the IC is debugging, nobody is coordinating.

Handing off command

Hand off command when the incident commander is tired, at the end of a shift, or when the incident grows beyond their capacity. A personal reason is also valid. A more senior person joining the call is not by itself a reason to switch (IC training).

Follow these steps, from PagerDuty and the Google SRE book:

Brief the new IC out of band, in a direct message or a side call. Cover current state, what is in progress, who holds which role, and the next decision due.
Get explicit acceptance. Google says the outgoing IC stays until the new one clearly confirms.
Announce it on the call and in the channel. PagerDuty's wording: "Everyone on the call, be advised, at this time I am handing over command to [X]."
The new IC introduces themselves as if starting a new call.
The scribe records the time of the handoff.

A handoff brief to paste in the side channel:

Handing over IC for <incident name>.
Status:      <one line on user impact now>
Severity:    <SEV level>, last reviewed <time>
In progress: <task> - <owner> - due back <time>
Roles:       Comms <name>, Scribe <name>, Deputy <name>
Next update: <status page / stakeholders> at <time>
Open decision: <what needs deciding next>
Reply "I have command" to accept.

Role cards

One card per role, to print or pin in the incident channel.

INCIDENT COMMANDER
Job:     Coordinate. Decide. Delegate every fix to a named person.
Start:   "This is <name>, I am the incident commander." Name deputy and scribe.
Loop:    Get status, pick the next action, assign it with a time limit,
         ask "any strong objections?", proceed.
Approve: Every external message before it is posted.
Do not:  Debug, read logs, run commands, or ask "can someone...".
End:     Declare the incident over, close the call, assign a postmortem owner.
Hand off: Brief out of band, get "I have command", announce it.

COMMUNICATIONS LEAD
Job:     Keep customers and stakeholders informed so responders are not interrupted.
First:   Post an initial status update as soon as the IC confirms impact.
Loop:    Draft update, get IC approval, post, set the time of the next update.
Track:   Affected customers and components; questions from support and leadership.
Do not:  Post without IC approval, guess at causes, give an ETA, use internal names.
End:     Post the resolved update; draft the customer-facing summary for the postmortem.

SCRIBE
Job:     Keep the timeline in the incident channel.
Record:  Time, what was seen, what was done and by whom, each decision and its outcome.
Mark:    Follow-ups with "TODO:" so they can be collected later.
Do not:  Fix, read graphs or logs, or record the whole debate.
End:     Post "Call is over", hand the timeline to the postmortem owner.

Tools

Incident management tools create channels, assign roles, and keep the timeline. See the incident management directory and the tools filtered by incident response. The timeline feeds the blameless postmortem.