Most day-to-day security work is done by IT teams, not the security team, and the gaps sit between them: the server team assumes security tracks the patch deadline, security assumes the cloud team rotates the key, and nobody owns the log source that went quiet. This template splits routine security operations by IT function, so that patching, human and machine accounts, keys, secrets and certificates, and logging each have one accountable owner per platform. It complements the Security RACI Matrix Template, which covers incident response and programme decisions, and the Shared Responsibility Matrix Template, which splits duties between you and your providers. NIST CSF 2.0 expects roles, responsibilities and authorities to be established, communicated, understood and enforced (GV.RR-02). It is for CIOs, CISOs, IT operations leads and GRC teams.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation] and [Head of Infrastructure], is for your own titles. Use roles in the matrix and keep names in a separate contact list.
- Read the codes: R = Responsible (does the work), A = Accountable (one role, owns the outcome and signs off), C = Consulted before the action, I = Informed after it.
- Merge or split columns: the nine columns in section 2 suit a mid-sized organisation. A small organisation may have one IT team covering EUC, INF and NET; a large one may split CLD by cloud provider. Keep one A per row after merging.
- The assignments are defaults: every R and A below is an NHI Mgmt Group starting point, not a standard. Change them to match who actually holds the access to act.
- Accountability follows the platform, oversight follows security: the team that runs a platform is usually accountable for doing the security task on it; the security function sets the standard, checks it and escalates. If that pattern does not hold for you, write down why.
1. Purpose and scope
1.1 This matrix assigns responsibility for routine security operations across IT functions at [Organisation]. It applies to all systems [Organisation] owns or operates and to services run for it under contract.
1.2 It covers human accounts and non-human identities: service accounts, API keys, workload identities, certificates, secrets and AI agents that hold credentials.
1.3 Incident response roles are in the [Security RACI Matrix]. Provider and customer duties for cloud and managed services are in the [Shared Responsibility Matrix]. Where they conflict, the incident matrix applies during a declared incident.
1.4 Owner: [CIO]. Co-owner: [CISO]. Approver: [IT and Security Governance Board]. Review at least every [12] months and after any reorganisation, outsourcing change or audit finding about ownership.
2. Roles
| Code | Role | Typical scope |
|---|---|---|
| EUC | [End-User Computing Lead] | Laptops, desktops, mobile devices, endpoint management |
| INF | [Head of Infrastructure] | Servers, hypervisors, directory servers, storage, backup |
| NET | [Network Lead] | Firewalls, routers, switches, VPN, wireless, DNS |
| CLD | [Cloud Platform Lead] | Cloud accounts, subscriptions and projects, Kubernetes, landing zones |
| APP | [Application Owner] | Business applications and SaaS, including their integrations |
| IAM | [Identity and Access Lead] | Identity provider, directories, access reviews, PAM, NHI inventory |
| SOC | [Security Operations Lead] | SIEM, detection content, alert triage, vulnerability scanning |
| SEC | [CISO or Security Governance Lead] | Standards, risk acceptance advice, assurance, metrics |
| BO | [Business or System Owner] | Owns the business risk of a system and accepts residual risk |
3. Patching and vulnerability remediation
| Activity | EUC | INF | NET | CLD | APP | IAM | SOC | SEC | BO |
|---|---|---|---|---|---|---|---|---|---|
| Set patch SLAs by severity and exposure | C | C | C | C | C | C | A/R | I | |
| Scan and report vulnerabilities | I | I | I | I | I | A/R | I | ||
| Patch endpoints and mobile devices | A/R | I | I | ||||||
| Patch servers, hypervisors and directory servers | A/R | C | C | I | I | I | |||
| Update network and edge device firmware | A/R | I | I | ||||||
| Update container images and cloud-managed services | A/R | C | I | I | |||||
| Update application code, libraries and SaaS settings | C | A/R | I | I | |||||
| Apply an emergency out-of-band patch | R | R | R | R | R | C | A | I | |
| Accept risk of a missed SLA or unsupported system | C | C | C | C | C | R | A | ||
| Verify remediation and report SLA performance | I | I | I | I | I | R | A | I |
3.1 Patching the patching tools: credentials held by endpoint management, configuration management and patch deployment systems are privileged non-human identities. They are owned by the platform team that runs the tool (R/A) and inventoried by IAM (C). See the Patch Management Guide and the Emergency Out-of-Band Patching Playbook.
3.2 An emergency patch is directed by [CISO] (A) because it overrides normal change windows; each platform team remains Responsible for its own systems.
4. Human accounts and access
| Activity | EUC | INF | NET | CLD | APP | IAM | SOC | SEC | BO |
|---|---|---|---|---|---|---|---|---|---|
| Provision joiner accounts from HR events | I | R | A/R | C | |||||
| Change access for movers | R | A/R | C | ||||||
| Disable leavers in the identity provider and local systems | R | R | R | R | R | A | I | I | |
| Approve access to a system | C | R | A | ||||||
| Run periodic access reviews | C | C | C | C | R | I | A | ||
| Manage privileged admin accounts on the platform | R | R | R | R | R | A | I | C | |
| Manage emergency (break glass) accounts | R | R | R | R | C | A |
4.1 Platform teams are Responsible for removing local, non-federated accounts on their own systems; IAM is Accountable that leavers are fully removed. See the Joiner-Mover-Leaver Guide.
5. Non-human identities, keys, secrets and certificates
| Activity | EUC | INF | NET | CLD | APP | IAM | SOC | SEC | BO |
|---|---|---|---|---|---|---|---|---|---|
| Name a human owner for every service account, API key and workload identity | R | R | R | R | A | I | C | ||
| Maintain the NHI inventory | C | C | C | C | A/R | C | I | ||
| Run the secrets manager and its access policy | C | A/R | C | C | C | ||||
| Rotate a secret or key on schedule | R | R | R | R | C | I | A | ||
| Revoke a leaked credential | R | R | R | R | C | A | I | I | |
| Issue and renew TLS and code signing certificates | R | R | R | R | A | I | |||
| Manage cryptographic key policy and HSM or KMS administration | R | R | A | ||||||
| Review third-party app and OAuth grants | C | R | R | C | I | A | |||
| Decommission NHIs when a system or integration is retired | R | R | R | R | C | I | A |
5.1 Rotation is Accountable to the business or system owner because a failed rotation is an outage of their service; IAM sets the standard and checks it. Revocation of a leaked credential is Accountable to security operations, because speed matters more than service continuity at that point.
5.2 See the NHI Ownership Guide, the Secrets Management Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.
6. Logging and monitoring
| Activity | EUC | INF | NET | CLD | APP | IAM | SOC | SEC | BO |
|---|---|---|---|---|---|---|---|---|---|
| Define required log sources and retention | C | C | C | C | C | C | R | A | C |
| Turn on and forward logs from the platform | R | R | R | R | R | R | A | ||
| Detect and fix a silent log source | R | R | R | R | R | R | A | I | |
| Write and tune detection rules | C | C | C | C | C | A/R | I | ||
| Protect log integrity and SIEM admin access | C | A/R | C | ||||||
| Pay for log licensing and storage tiers | C | R | A | C |
6.1 Some SaaS audit logs depend on licence tier. The application owner is Consulted on licensing and Responsible for turning logging on. See the SaaS Audit Log Retention and Licensing Guide and the SIEM Log Source Onboarding Checklist.
7. Backups and recovery credentials
| Activity | EUC | INF | NET | CLD | APP | IAM | SOC | SEC | BO |
|---|---|---|---|---|---|---|---|---|---|
| Back up systems and test restores | A/R | R | C | I | C | ||||
| Isolate backup admin accounts and service credentials | R | R | C | C | A | ||||
| Set recovery objectives | C | C | C | C | A/R |
8. Exceptions, sign-off and review
8.1 A team that cannot meet a Responsible duty must raise an exception through [exception process], naming the compensating control and an end date. The BO accepts the residual risk; SEC records it.
8.2 Each role holder signs the matrix on approval. Unsigned rows are treated as unowned and reported to the [IT and Security Governance Board].
8.3 Changes to an A require approval by both [CIO] and [CISO].
Implementation guidance
Rollout steps
- Start from real access. For each row, check who holds the permissions to act. If the accountable role cannot perform or direct the task, the matrix is wrong.
- Fill gaps first. Rows with no R, and platforms with no owner (often SaaS, shadow cloud accounts and old service accounts), are the findings worth escalating.
- Walk it through. Agree each A one to one with the role holder, then in a joint IT and security session.
- Test with two scenarios. A critical edge device vulnerability with a 48-hour deadline, and a leaked cloud API key found in a public repository. Record where people acted differently from the matrix.
- Publish and embed. Link the matrix from the patch, access, key management and logging policies, and from job descriptions (CSF GV.RR-04).
- Roll back. Keep the previous approved version; if a change causes confusion, revert until the next review.
Framework mapping
| Section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Roles and sign-off | GV.RR-02, GV.RR-04 | PM-2, AC-5 |
| 3. Patching | ID.RA-01, PR.PS-02 | SI-2, SA-22 |
| 4. Human accounts | PR.AA-01, PR.AA-05 | AC-2, PS-4, PS-5 |
| 5. NHIs, keys and certificates | PR.AA-01 | IA-5, SC-12, SC-17 |
| 6. Logging | PR.PS-04, DE.CM-09 | AU-6, AU-9, AU-11 |
| 7. Backups | PR.DS-11 | CP-9 |
Metrics
- Rows with exactly one A: target 100%.
- Service accounts, keys and certificates with a named owner: target 100% for production.
- Patch SLA met, by platform team: reported monthly per column, not as one IT figure.
- Required log sources reporting in the last 24 hours: target above 98%, with silent sources assigned to an owner.
- Open exceptions past end date: target zero.
Common failure patterns
- Security as the default owner: every unclear row goes to SEC, which has no admin access to fix it.
- One IT column: "IT" is Accountable for all patching, so no platform lead is measured.
- Owners of people, not machines: every leaver row is assigned, but nobody owns the service account the leaver created.
- SaaS left out: application owners are missing from the matrix, so SaaS logging and OAuth grants have no R.
For how teams fit together more broadly, see the Security Operating Model and Organisation Design Guide and the Identity Team Operating Model and Workforce Planning Guide.
Related NHI Mgmt Group resources: Security RACI Matrix Template · Shared Responsibility Models Guide · NHI Ownership Guide · Patch Management Policy Template