Incident Response Role Cards Template: Duties for Lead, Comms, Legal and Tech

An incident plan that lists role names but not what each person does in the first hour leaves people improvising, duplicating work or waiting for permission. Role cards fix that: one page per role that someone can pick up at 3am, read in two minutes and act on. This template gives you ready-to-use cards for the incident lead, deputy, scribe, technical lead, identity workstream lead, communications lead, legal and privacy lead, executive sponsor and liaison, each with the same fields so people can swap between them. It is written for incident response managers and CISOs who already have a plan and want it to work under pressure. The command model behind the cards is explained in the Incident Commander Role Guide; this page is the printable layer that sits on top of it.

How to use this template

• Replace text in square brackets, such as [Organisation], [Severity 1] and [30 minutes], with your own names and values. Timings in the cards are NHI Mgmt Group recommendations, not requirements from any standard.
• Print each card on one page and keep copies offline, in the out-of-band channel and in the incident kit. A card stored only on the SharePoint site that has just been encrypted is no use.
• Name a primary and at least one deputy for every card. NCSC advises: "Always provide for 'deputies' - people who will cover if a critical person or persons are unavailable."
• One person may hold several cards in a small team, but the incident lead card and the technical lead card should not be held by the same person on a [Severity 1 or 2] incident.
• Keep the contact details, severity definitions and call tree in the Incident Response Plan Template and the Incident Response Contact and Call Tree Template. The cards refer to them rather than copying them, so there is one place to update.

1. Card format

Every card uses the same eight fields, in the same order. Consistency matters more than wording: someone taking over a role mid-incident should find the same thing in the same place.

2. Incident lead (incident commander)

• Mission: One source of truth and one set of objectives for the response, from declaration to stand-down.
• Activated when: An incident is declared at [Severity 3] or above, or when the on-call analyst asks for one.
• First 30 minutes:
  1. Confirm the declaration and severity using the [severity matrix]. Announce "I am incident lead" on the incident channel.
  2. Open the incident record and decision log. See the Incident Log and Decision Record Template.
  3. Decide whether normal channels are trusted. If identity, email or chat may be compromised, move to the [out-of-band channel].
  4. Assign the scribe, technical lead, communications lead and legal lead cards. Hold any card not yet assigned.
  5. Set the first objectives (for example: contain, preserve evidence, keep [service] running) and the next update time.
• Owns: Objectives and priorities, role assignments, meeting rhythm, approval of internal updates, the decision to request external help under the [IR retainer].
• Escalates: Taking revenue-generating or safety-critical systems offline beyond [delegated threshold], any external statement, any ransom or extortion contact, law enforcement referral: to the [executive sponsor].
• Does not: Run commands, read logs or fix systems. PagerDuty's guidance puts it plainly: "Delegate all repair actions, the Incident Commander is NOT a resolver."
• Inputs and outputs: Receives status from each lead every [30 or 60 minutes]; produces a situation report on the same cadence and a briefing for the executive sponsor every [2 to 4 hours].
• Handover: Brief the incoming lead on objectives, open decisions, risks and the next three deadlines (including notification clocks). Stay until they confirm they have command, then announce the change to everyone on the response.

3. Deputy incident lead

• Mission: Keep the response moving so the incident lead can think, and be ready to take command at any moment.
• Activated when: [Severity 1 or 2], or any incident expected to run past one shift.
• First 30 minutes: Join the bridge; take the action tracker; chase owners for overdue actions; check that every assigned card has a named deputy; start the shift rota if the incident may run beyond [12 hours].
• Owns: Action tracking, timekeeping on meetings, rota and welfare breaks, logistics (access, devices, food, travel).
• Escalates: Anything that changes objectives or priorities: to the incident lead.
• Does not: Start a parallel command line or give contradicting instructions.
• Inputs and outputs: Receives the action list; produces an overdue-actions call-out at each status meeting and the rota.
• Handover: Open actions with owners and due times, rota for the next 24 hours, any staff who must be stood down to rest.

4. Scribe

• Mission: A complete, time-stamped record that a regulator, insurer, court or post-incident review could rely on.
• Activated when: At declaration, every time.
• First 30 minutes: Start the timeline in UTC; record who declared, when and why; record each role assignment; capture the first objectives and any containment action already taken.
• Owns: The timeline, the decision log (decision, options considered, rationale, decision maker, time), the attendance list for each call.
• Escalates: Gaps in the record (for example a decision taken in a side conversation): to the incident lead.
• Does not: Editorialise, speculate on cause, or record legal advice in the general log. Legal advice goes in the legal lead's privileged record. See the Legal Privilege in Incident Response Guide.
• Inputs and outputs: Receives everything said on the bridge; produces the live log and a clean copy at each shift change.
• Handover: The log, its location, and a list of entries still awaiting confirmation.

NCSC asks responders to record "decisions made, actions taken, data captured (or missing)" throughout, because those records are what you show a regulator later.

5. Technical lead

• Mission: Establish what happened, stop it spreading and restore systems to a known good state, without destroying evidence.
• Activated when: At declaration.
• First 30 minutes:
  1. Confirm the incident is real and summarise what is known, what is suspected and what is unknown.
  2. Decide on immediate containment within [delegated authority], for example isolating hosts through EDR or disabling an account.
  3. Start evidence preservation before rebuilds: memory and disk where needed, logs exported before retention expires. See the Evidence Handling and Chain of Custody Guide.
  4. Split work into named workstreams (for example identity, endpoint, cloud, recovery) with one lead each when more than [five] people are working.
• Owns: Investigation plan, containment and eradication actions, technical change control during the incident. Google's SRE guidance states that the operations team "should be the only group modifying the system during an incident".
• Escalates: Containment that takes down business services beyond [threshold], rebuild versus restore decisions, any evidence that personal data was accessed (to the legal lead at once).
• Does not: Talk to customers, press or regulators; make business trade-offs alone.
• Inputs and outputs: Receives findings from workstreams; produces a technical status (condition, actions, needs) for each status meeting, the indicators of compromise list and the scope statement used by legal.
• Handover: Current hypothesis, confirmed scope, open containment actions, evidence locations and any changes made that will need reverting.

6. Identity workstream lead

Many serious incidents involve stolen credentials, tokens or keys, so in our view this card is worth a named owner rather than a line in the technical lead's list.

• Mission: Remove the attacker's access through every credential, session and machine identity, and keep the response team's own access trustworthy.
• Activated when: Any incident with suspected credential, token, identity provider or privileged account involvement.
• First 30 minutes: Confirm break-glass accounts work and are not compromised; list identities seen in attacker activity; revoke sessions and refresh tokens for those identities; identify service accounts, API keys and OAuth grants reachable from compromised hosts; agree rotation order with the technical lead so rotation does not tip off the attacker before containment is ready.
• Owns: Revocation and rotation plan, conditional access emergency changes, privileged access during the incident.
• Escalates: Mass password resets or rotation that will break production integrations: to the technical lead and incident lead.
• Does not: Rotate everything at once without an order and an owner for each integration.
• Inputs and outputs: Receives identities from the investigation; produces a revocation tracker (identity, action, time, verified by).
• Handover: Tracker status, credentials still pending rotation, any temporary exceptions granted.

See the Identity Incident Response Playbook for the full revocation sequence.

7. Communications lead

• Mission: Accurate, timely and consistent messages to staff, customers, partners and media, with nothing released that the facts do not support.
• Activated when: Impact is or may become visible outside the response team, and always at [Severity 1 or 2].
• First 30 minutes: Pull the pre-approved holding statements from the Incident Communication Plan Template; send the staff message (do not discuss externally, how to report, where updates will come from); brief the switchboard and service desk with a script; set the update cadence; confirm the named spokesperson.
• Owns: Drafting all messages, the status page, the media log, the internal Q&A.
• Escalates: Every external message: content to the legal lead, approval to the incident lead (and to the executive sponsor for media statements).
• Does not: Speculate about cause, attacker or data, or confirm anything the technical lead has not confirmed.
• Inputs and outputs: Receives confirmed facts from the incident lead; produces approved messages and a log of what was said to whom and when.
• Handover: Messages sent, commitments made ("next update by"), open media enquiries.

NCSC advises organisations to "Identify individuals in your organisation to act as official spokespeople" and to train them before an incident.

8. Legal and privacy lead

• Mission: Meet every legal and regulatory obligation on time and protect the organisation's legal position.
• Activated when: Any suspected personal data exposure, criminal activity, extortion, regulated service impact or contractual notification duty.
• First 30 minutes:
  1. Record the time the organisation became aware, because several notification clocks run from awareness rather than confirmation.
  2. Decide whether to structure the investigation under privilege and instruct external counsel and forensics accordingly.
  3. Open the notification register: each regulator, the trigger, the deadline, the owner. Use the Regulator Notification Template Pack for initial reports.
  4. Notify the insurer as the policy requires, before engaging vendors the insurer may need to approve.
• Owns: Notification decisions and filings, contact with regulators and law enforcement, review of all external messages, privilege.
• Escalates: Any decision to notify or not notify a regulator, and any ransom or extortion matter: to the executive sponsor.
• Does not: Delay containment for privilege set-up, or let a deadline lapse while waiting for full facts. Under GDPR Article 33, information may be provided in phases.
• Inputs and outputs: Receives scope statements from the technical lead; produces the notification register, filed reports and advice to the incident lead.
• Handover: Register status, deadlines in the next 72 hours, regulator reference numbers and contacts.

9. Executive sponsor

• Mission: Make the business decisions the incident lead cannot, quickly, and shield the response from distraction.
• Activated when: [Severity 1 or 2], or when the incident lead escalates a decision.
• First 30 minutes: Take a briefing; confirm delegated authority for containment; agree the next briefing time; inform the [CEO and board chair] as the escalation matrix requires.
• Owns: Business trade-offs, spending beyond [budget], ransom and extortion decisions (with the board), invoking crisis management or business continuity.
• Escalates: Matters reserved to the board.
• Does not: Join the technical bridge, give direct instructions to responders, or ask for updates outside the agreed cadence.
• Inputs and outputs: Receives the incident lead's briefing; produces recorded decisions with rationale.
• Handover: Decisions pending, board commitments, next briefing.

NCSC states that "The people escalated to must have the authority to make critical decisions". If the sponsor cannot decide, name someone who can. See the Crisis Management Guide for when the sponsor hands over to a crisis team.

10. Liaison (third parties and law enforcement)

• Mission: One managed channel to every outside party involved in the response.
• Activated when: An IR retainer, insurer, supplier, cloud provider, CSIRT or law enforcement is engaged.
• First 30 minutes: Activate the [IR retainer] if the incident lead asks; open a ticket with affected suppliers; agree with the retainer's lead that [Organisation]'s incident lead keeps command; log every contact and reference number.
• Owns: Supplier and retainer coordination, data requests to providers, sharing indicators with partners where agreed.
• Escalates: Any external party asking for decisions or data beyond the agreed scope: to the incident lead and legal lead.
• Does not: Share evidence or indicators externally without legal approval.
• Inputs and outputs: Receives requests from leads; produces a contacts and requests log.
• Handover: Open requests, expected responses, contacts.

In the UK, report fraud and cyber crime to Report Fraud (which replaced Action Fraud on 4 December 2025) at reportfraud.police.uk or on 0300 123 2040; in Scotland, report to Police Scotland on 101.

11. Activation by severity

This activation pattern is an NHI Mgmt Group recommendation. Align it with your own definitions in the Incident Severity Classification Matrix Template.

Implementation guidance

Rollout

1. Map cards to people: fill a roster with a primary and two deputies per card, covering out of hours. NCSC suggests that key contact lists ideally include at least two contact methods and two or more people.
2. Tailor the "Owns" and "Escalates" fields: copy the delegated authority from your Incident Response Policy Template so the cards and the policy agree.
3. Brief each holder: a 30-minute walk-through per card, including where the offline copy lives.
4. Test in a tabletop: hand out cards at random, including to deputies, and see whether the first 30 minutes happen without coaching. See the Tabletop Exercise Guide.
5. Revise after every exercise and real incident: anything people did that was not on a card, or did not do that was, becomes an edit.

Small and large organisations

• Small teams (under [20] IT and security staff): combine scribe with deputy, and legal with an external counsel on retainer. Keep the incident lead separate from hands-on work for anything serious; an IR retainer can supply the technical lead.
• Large or multi-region organisations: add workstream cards (endpoint, cloud, OT, recovery), a regional communications card per jurisdiction and a dedicated notification manager under the legal lead.

Measures that show the cards work

Common failure patterns

• Commander who fixes things: the incident lead disappears into a console and nobody holds the overall picture.
• Cards online only: the cards, contact list and plan sit on systems the attacker has encrypted or controls.
• No deputies: a long incident burns out the only person who knows the role.
• Legal joins late: the awareness time is never recorded and a 72-hour clock is half spent before anyone looks at it.
• Executives on the bridge: senior people ask for updates in the technical channel and responders stop working to answer.

Framework mapping

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Creating an incident response team
• NCSC: Cyber incident response processes
• NCSC: Effective communications in a cyber incident
• Report Fraud: Report Fraud service goes live
• PagerDuty: Different roles for incidents
• Google: Site Reliability Engineering, Managing Incidents

Related NHI Mgmt Group resources: Incident Commander Role Guide · Incident Response Plan Template · Incident Communication Plan Template · Incident Log and Decision Record Template · Out-of-Band Communications Plan Template