In a serious incident the technical team usually knows what to do; what stalls is the decision nobody is sure they own: who starts the regulator clock, who approves taking the payment system offline, who speaks to the press and who talks to the insurer before anyone engages a forensics firm. This template is a RACI for a declared incident, built around the non-technical decisions that carry legal and business risk: privilege, evidence, regulator and customer notification, executive and board decisions, ransom demands, staff communications and third parties. It sits under your incident response plan and alongside your programme-wide RACI, which covers routine security governance. It is for CISOs, incident managers, general counsel, privacy officers and communications leads who need to agree in advance who decides, who acts and who must be told.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [General Counsel] and [Crisis Management Team], is for your own titles. Use roles in the matrix; keep names and numbers in the call tree. See the Incident Response Contact and Call Tree Template.
- Codes: R = Responsible (does the work), A = Accountable (owns the outcome, exactly one per row), C = Consulted (before the decision), I = Informed (after the decision).
- Scope: this template covers declared incidents only. For the programme-wide matrix of routine security activities, use the Security RACI Matrix Template; for IT and security operations ownership, the IT and Security RACI Template.
- Severity drives activation: sections 4 to 7 apply in full to [Severity 1 and 2] incidents as defined in your Incident Severity Classification Matrix Template. Lower severities use the technical rows only.
- Legal review: the regulatory rows in section 5 are a starting point. [General Counsel] must confirm which regimes apply to [Organisation] and the deadlines in each.
1. Purpose and scope
1.1 This RACI defines who is responsible, accountable, consulted and informed for each decision and activity during a declared cyber security incident at [Organisation], from declaration to closure.
1.2 It applies to incidents affecting [Organisation]'s systems, data or services, including those operated by suppliers, and to incidents involving human and non-human identities such as service accounts, API keys, workload identities and AI agents.
1.3 Where this RACI conflicts with a legal or regulatory obligation, the obligation prevails and [General Counsel] must be informed.
1.4 Owner: [CISO]. Approver: [Executive Committee]. Legal sections approved by: [General Counsel].
2. Incident roles
| Code | Role | Default holder | Authority during the incident |
|---|---|---|---|
| IC | Incident commander | [Head of Security Operations] or rota | Runs the response, sets priorities, owns the incident log, can direct any technical team |
| TL | Technical lead | [Senior responder or IR retainer lead] | Investigation, containment and eradication actions within IC direction |
| IAM | Identity lead | [IAM lead] | Disables accounts, revokes sessions and tokens, rotates human and machine credentials |
| CISO | Chief Information Security Officer | [CISO] | Declares and classifies, escalates to executives, approves technical containment beyond IC limits |
| LEG | Legal counsel | [General Counsel] with [external breach counsel] | Privilege, notification decisions, law enforcement, contracts and regulatory correspondence |
| DPO | Data protection officer or privacy lead | [DPO] | Personal data risk assessment and supervisory authority liaison |
| COM | Communications lead | [Head of Communications] | Media, public, customer and staff messaging; owns all external wording |
| CMT | Crisis management team | [CEO or COO] as chair | Business decisions: shutting down services, ransom decisions, major spend, public position |
| BRD | Board or board committee | [Chair of Audit or Risk Committee] | Oversight; approval where the governance charter requires it |
| HR | Human resources | [HR Director] | Staff communications, insider cases, wellbeing of responders |
| FIN | Finance and insurance | [CFO] and [Risk and Insurance Manager] | Insurer notice, approved vendors and spend, financial impact |
| BO | Business owner of affected service | [Service owner] | Accepts business impact; confirms restore priorities |
| 3P | Third parties | [IR retainer], [MSSP], [cloud provider], [key suppliers] | As set out in contract |
2.1 Every role must have a named primary and deputy. The IC must not also be the TL in a [Severity 1] incident.
2.2 When the CMT is convened, the IC reports to the CMT chair through the CISO, and the CMT does not direct technical work directly.
3. Decision rights and pre-authorisations
| Decision | Accountable | Must consult | Pre-authorised? |
|---|---|---|---|
| Declare an incident and set severity | CISO | IC | Yes, IC may declare out of hours and inform CISO |
| Isolate a host or disable an account, human or machine | IC | BO where production | Yes |
| Take a business-critical service offline | CMT | CISO, BO, LEG | No, may be given by phone and recorded |
| Engage external counsel and forensics under privilege | LEG | CISO, FIN (insurer panel) | Yes, for panel firms |
| Decide whether a notification duty is triggered | LEG | DPO, CISO | Not applicable |
| Contact law enforcement | LEG | CISO, CMT | No |
| Respond to an extortion demand | CMT | LEG, CISO, FIN, insurer | No; no one may communicate with the threat actor without CMT approval |
| Publish any external statement | CMT | LEG, COM, CISO | Holding statement pre-approved in [communication plan] |
| Declare the incident closed | CISO | IC, LEG, BO | Not applicable |
4. RACI by incident phase
| Activity | IC | TL | IAM | CISO | LEG | DPO | COM | CMT | BRD | HR | FIN |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Open incident log and record time of awareness | A | R | I | I | I | ||||||
| Assess whether personal data or a regulated service is affected | R | R | C | A | R | ||||||
| Issue legal hold and preserve evidence | R | R | C | I | A | C | |||||
| Contain: revoke sessions, tokens and machine credentials | A | R | R | I | |||||||
| Notify insurer under policy terms | I | C | C | I | A/R | ||||||
| Brief the crisis management team | C | A/R | C | C | C | I | |||||
| Brief the board | R | C | A | I | |||||||
| Staff communication | C | C | C | R | I | A | |||||
| Customer and partner communication | C | C | C | C | R | A | |||||
| Media statement and enquiries | C | C | R | A | I | ||||||
| Recovery priorities and restore sign-off | R | R | R | C | I | A | |||||
| Post-incident review and regulator final report input | R | R | C | A | C | C | C | I | I |
4.1 The time of awareness recorded in the incident log is the start point for notification clocks that run from awareness. LEG must be told at declaration of any incident that may involve personal data or a regulated service.
4.2 Containment includes non-human identities found in the investigation. The IAM lead owns a list of every service account, key and token revoked or rotated, with its owner informed. See the Identity Incident Response Playbook.
5. Regulatory and contractual notification
5.1 LEG is accountable for every notification decision. The table lists common regimes; [General Counsel] must add sector and national rules that apply to [Organisation].
| Regime | Trigger and deadline (from the source text) | R | A | C |
|---|---|---|---|---|
| EU GDPR Article 33 | Personal data breach: notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless unlikely to result in a risk; give reasons if later | DPO | LEG | CISO, COM |
| EU GDPR Article 34 | Breach likely to result in a high risk to individuals: communicate to data subjects without undue delay | COM, DPO | LEG | CMT |
| EU GDPR Article 33(2) | Where [Organisation] is a processor: inform the controller without undue delay | DPO | LEG | BO |
| NIS2 Article 23 (as transposed nationally) | Significant incident: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month of the notification, to the CSIRT or competent authority | CISO | LEG | CMT |
| US SEC Form 8-K Item 1.05 (registrants) | Material cybersecurity incident: generally due four business days after determining the incident is material | LEG | CMT | CISO, FIN, BRD |
| Contracts and insurance | As stated in customer, supplier and policy terms | FIN, LEG | LEG | BO |
5.2 A determination that no notification is required is a decision and must be recorded with reasons, the facts relied on and the date. GDPR Article 33(5) requires controllers to document every personal data breach, its effects and the remedial action taken, whether or not it is notified.
5.3 The materiality determination for SEC purposes is accountable to the CMT with LEG advice, and the time of determination must be recorded. NIS2 deadlines vary by national transposition. See the Breach Notification Laws by Country Guide and the SEC Cybersecurity Disclosure Rules Guide.
6. Incident-type variations
- Ransomware and extortion: the CMT is accountable for any response to a demand; LEG is responsible for sanctions screening and law enforcement contact; FIN for insurer consent. See the Ransomware Payments and Sanctions Guide.
- Personal data breach without disruption: the DPO is responsible for the risk assessment; COM is not activated for media unless LEG decides individuals must be told.
- Leaked machine credential or compromised service account: IAM is responsible for revocation and rotation, the service account owner is consulted on impact, and LEG is informed if the credential reached personal or customer data.
- Insider incident: HR is accountable for employment actions, LEG for evidence and law enforcement, and the IC limits the investigation team to named people.
- Supplier incident: the supplier is responsible for its own containment under contract; the BO is accountable for [Organisation]'s exposure and LEG for contractual notices.
7. Handovers and escalation
7.1 The IC role is handed over in writing in the incident log, with open actions, decisions pending and the next notification deadline.
7.2 Any role holder who cannot meet a deadline in section 5 escalates to the accountable role at once, not at the next scheduled call.
7.3 Only COM, under CMT approval, communicates externally. Responders must not discuss the incident on channels the attacker may be able to read; use the out-of-band channel named in [IR plan].
8. Review and approval
8.1 This RACI is reviewed every [12] months, after every [Severity 1 or 2] incident and exercise, and when a new notification regime applies.
8.2 Every review records any row where the actual decision-maker differed from the matrix, and why.
Implementation guidance
Rollout steps
- Start from real roles. Map each column to a role that exists today, with a deputy. Remove columns nobody holds.
- Agree decision rights with the CMT chair and General Counsel first. Section 3 is where disagreements surface; settle them before the technical rows.
- Confirm the regulatory table. LEG lists applicable regimes and deadlines, including national NIS2 transpositions and sector regulators.
- Test it in a tabletop. Use a scenario with a personal data breach, a leaked service account key and a media enquiry inside the first 24 hours. See the Tabletop Exercise Guide.
- Approve and publish with the IR plan, call tree and communication plan, in a location available when corporate systems are down.
- Roll back if needed: keep the previous approved version; if a change causes confusion in an exercise, revert until the review is complete.
Common failure patterns
- No recorded time of awareness: notification clocks are argued about after the fact.
- Forensics engaged before counsel: reports are produced outside any privilege arrangement counsel would have set up.
- Insurer told late: policy conditions on notice or approved vendors are breached in the first hours.
- The CMT runs the keyboard: executives direct technical work and the IC loses control of priorities.
- Machine credentials missed: human accounts are reset, but service account keys and tokens stay valid.
Measuring whether it works
- Decision latency: time from declaration to each section 3 decision in exercises and incidents.
- Notification timeliness: notifications made inside the applicable deadline, target 100%.
- Matrix deviations: rows where someone other than the named role decided, trending down.
- Role coverage: roles with a trained primary and deputy confirmed in the last quarter.
Framework mapping
| Framework | Reference | What this template supports |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02 | Roles, responsibilities and authorities established and enforced |
| NIST CSF 2.0 | RS.MA-01, RS.MA-04 | Executing the plan with third parties; escalation |
| NIST CSF 2.0 | RS.CO-02, RS.CO-03, RC.CO-04 | Stakeholder notification, information sharing and public recovery updates |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, IR-8 | Incident handling, reporting and a plan with defined roles |
| NIST SP 800-53 Rev. 5 | IR-3 | Testing the matrix through exercises |
NIST SP 800-61 Rev. 3 (April 2025) frames incident response as part of CSF 2.0 risk management and replaces Rev. 2. See the Incident Response Guide and the Incident Commander Role Guide.
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: Cybersecurity Framework 2.0
- EUR-Lex: Regulation (EU) 2016/679 (GDPR)
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure rules
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Security RACI Matrix Template · Incident Response Plan Template · Incident Communication Plan Template · Crisis Management Guide. This guide summarises notification duties under GDPR, NIS2 and the SEC rules and is not legal advice.