Security RACI Matrix Template: who decides, acts and is told

Most security failures that look technical are accountability failures: nobody was sure who could isolate the payment server, who owned the leaked service account key, or who had to tell the regulator. A RACI matrix answers those questions before the incident, by naming for each activity who is Responsible for doing it, who is Accountable for the outcome, who must be Consulted and who must be Informed. NIST CSF 2.0 asks that roles, responsibilities and authorities for cybersecurity risk management are established, communicated, understood and enforced (GV.RR-02), and NIST SP 800-53 expects the same through controls such as PM-2, IR-8 and PS-9. This template gives a ready RACI for the security incident lifecycle, from triage to post-incident review, plus a programme-level matrix for routine decisions such as risk acceptance and access reviews. It is written for CISOs, security managers, incident response leads and GRC teams.

How to use this template

• Replace placeholders: text in square brackets, such as [Organisation], [CISO] and [Head of IT Operations], is for your own role titles. Use roles, not names, in the matrix, and keep names in the contact list in section 2.
• Keep one A per row: every activity has exactly one Accountable role. Two A entries mean nobody is accountable; no A means the activity will not be done.
• Read the codes as: R = Responsible (does the work, can be several roles), A = Accountable (owns the outcome and signs off, one role), C = Consulted (two-way, before the decision), I = Informed (one-way, after the decision).
• Tailor the columns: the default roles in section 2 suit a mid-sized organisation. Small organisations can merge columns (for example IT operations and security operations); large ones can split them by business unit or region.
• Align with other documents: severity levels come from your severity matrix, contacts from your call tree, and decision rights from your governance charter. See the Incident Severity Classification Matrix Template and the Security Governance Committee Charter Template.
• "Must" and "should": "must" is mandatory; "should" is recommended practice where a justified exception may apply.

1. Scope and triggers

1.1 This RACI matrix applies to [Organisation] and its subsidiaries, to all information systems it owns or operates, and to services operated for it by third parties under contract.

1.2 It covers human and non-human identities, including service accounts, API keys, workload identities and AI agents that hold credentials or act on systems.

1.3 The incident sections (3 to 8) apply when a security event is raised for triage. The programme matrix in Implementation guidance applies to routine security governance activities.

1.4 The matrix must be reviewed and re-approved:

• at least every [12] months;
• after any [Severity 1 or 2] incident, as part of the post-incident review;
• after a reorganisation, a change of CISO or a change of managed security provider;
• when a new regulatory reporting duty applies to [Organisation].

1.5 Owner of this document: [CISO]. Approver: [Security Governance Committee].

2. Roles and contacts

2.1 The following roles are used as columns in sections 3 to 8. Each role must have a named primary and deputy in the contact list held at [location], reviewed every [quarter].

2.2 Where a role is outsourced, the contract must state which R activities the provider performs; the A must remain with an [Organisation] role.

2.3 Every non-human identity in scope must have a named human owner who acts as SO for decisions about that identity. See the NHI Ownership Guide.

3. Detection and triage

3.1 The SOC must be able to escalate directly to the [CISO or deputy] for suspected [Severity 1] events, without waiting for business hours.

3.2 Legal must be consulted at declaration where privilege is to be claimed over the investigation.

4. Containment

4.1 The IRL is pre-authorised to isolate any single endpoint or server, and to disable any account, without further approval. Taking a service listed as [business critical] offline requires EXE approval, which may be given by phone and recorded afterwards.

4.2 Credential revocation must include non-human identities found in the investigation. Unrotated machine credentials are a common path back in: in the Cloudflare Thanksgiving breach, one service token and three service account credentials not rotated after an earlier breach let an attacker return.

5. Eradication

5.1 The system owner is accountable for fixing the weakness in their service; security is accountable for confirming that the attacker is gone. Keep these separate so that the team that fixes is not the only team that verifies.

6. Recovery

6.1 Restore order must follow the recovery priorities in the [business continuity plan]. Disputes on order are escalated to EXE.

7. Communication and notification

7.1 Notification deadlines differ by law and sector and some run from the time [Organisation] becomes aware, so LEG must be informed at declaration of any incident that may involve personal data or a regulated service. Record the time of awareness in the incident record.

7.2 No one outside COM and EXE may make external statements about the incident.

8. Post-incident review

8.1 The review must be held within [10] working days of the end of recovery for [Severity 1 and 2] incidents and must ask whether any R, A, C or I in this matrix was wrong, missing or ignored.

Implementation guidance

Programme-level RACI

Incidents test the matrix, but most accountability gaps are in routine work. Extend the template with a second matrix for the security programme. The rows below are a starting point.

Risk acceptance belongs to the business owner of the risk, not to the CISO; the CISO advises and records. See the Security Exceptions and Risk Acceptance Guide.

Rollout steps

1. Draft with role titles you actually have. Replace the default columns, then remove any role that does not exist. A matrix that names a role nobody holds fails in the first incident.
2. Check the rules. One A per row; at least one R per row; no role with A but no authority to act; no role whose column is all C and I.
3. Walk it through with each role holder. Agree each R and A one to one. Disagreement is the point of this step: resolve it now.
4. Test it in a tabletop exercise. Pick a scenario with a machine credential leak and a regulatory notification, and see whether people act as the matrix says. Record every deviation.
5. Approve and publish. The [Security Governance Committee] approves; publish the matrix with the IR plan and the call tree, and train new role holders on it.
6. Roll back if needed. Keep the previous approved version. If a change causes confusion in an exercise or incident, revert to it until the review is complete.

Framework mapping

Common failure patterns

• Two accountable roles: security and IT both believe the other owns isolation, so it waits.
• Accountability without authority: the IRL is accountable for containment but needs a change ticket to isolate a host.
• Machine identities with no owner: the matrix says IAM revokes credentials, but nobody can say which team owns a given API key, so rotation stalls.
• Outsourced accountability: the MSSP is listed as A for triage; the contract only says R.
• A matrix nobody has read: it is approved once and never tested. The tabletop exercise in step 4 is what makes it real.

Measuring whether it works

• Coverage: percentage of rows with exactly one A and at least one R (target 100%).
• Currency: days since last approved review, and role holders confirmed in the last quarter.
• Exercise deviations: number of actions in tabletops or incidents taken by a role other than the one the matrix names, trending down.
• Time to decision: time from declaration to containment approval for business-critical services.
• Machine identity ownership: percentage of non-human identities in scope with a named owner. See the Service Account Inventory Template.

Small vs large organisations: a small organisation may have one person in four columns; the value of the matrix is then in the C and I entries, especially legal, insurer and provider contacts. A large organisation should keep one enterprise matrix and allow business units to add rows, not to change who is accountable for enterprise decisions.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Incident Response Plan Template · Incident Response Contact and Call Tree Template · Security Governance Committee Charter Template · NHI Ownership Guide