# ISMS Roles, Responsibilities and RACI: [Organization name]

> Defines who does what in the information security management system
> (ISMS): the roles, their responsibilities and authorities, the deputies,
> and a RACI matrix across the ISO/IEC 27001 clause 4 to 10 processes and
> the key Annex A processes. It supports ISO/IEC 27001:2022 + Amd 1:2024
> clause 5.3 (organizational roles, responsibilities and authorities) and
> Annex A controls A.5.2 (security roles and responsibilities), A.5.3
> (segregation of duties) and A.5.4 (management responsibilities for
> security), with guidance from ISO/IEC 27002:2022. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it when you start an ISMS, after a reorganisation, when a key role
  holder leaves, and before a certification audit. Auditors read it to
  check that clause 5.3 is met: responsibilities are assigned,
  communicated and understood, and someone reports ISMS performance to top
  management.
- Fill section 3 (role definitions) and section 11 (assignment register)
  first. The RACI matrices in sections 5 and 6 only make sense once each
  role has a named holder and a deputy.
- Main pitfall: a RACI where "IT" or "the security team" is Accountable for
  everything. Accountability sits with one named role per activity, and
  risk ownership sits with people who have the budget and authority to act.
- Second pitfall in small organisations: one person holds roles that check
  each other (for example ISMS manager and internal auditor). Section 9
  gives the guardrails.
- Related templates: `isms/isms-steering-committee-charter`,
  `isms/isms-policy-framework`, `isms/isms-manual`,
  `isms/isms-competence-training-matrix`, `compliance/risk-methodology`,
  `compliance/internal-audit-program`, `compliance/management-review`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Treat this as a controlled document. A change of role holder is a minor version; a change of authority (for example who may accept High risks) is a major version and needs top management approval. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-006 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ceo or top management sponsor], [@ciso], [@hr-lead], [@internal-auditor] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (clause 5.3, A.5.2 to A.5.4); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (at least every [12] months and after any reorganisation) |
| ISMS scope | [Reference to DOC-ISMS-002 ISMS scope] |
| Organisation size tier | [Small / Medium / Large or multi-site] |
| Related documents | DOC-ISMS-005 policy framework, DOC-ISMS-007 steering committee charter, DOC-ISMS-010 risk methodology, DOC-ISMS-026 competence and training matrix |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS owner (prepared by) | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| Top management sponsor | [@ceo] | [Approved / Approved with changes] | YYYY-MM-DD |
| HR lead (role descriptions) | [@hr-lead] | [Reviewed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@isms-manager] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Governance structure](#2-governance-structure)
- [3. Role definitions](#3-role-definitions)
- [4. Authorities and decision rights](#4-authorities-and-decision-rights)
- [5. RACI: ISMS clause processes](#5-raci-isms-clause-processes)
- [6. RACI: key Annex A processes](#6-raci-key-annex-a-processes)
- [7. Independence of internal audit](#7-independence-of-internal-audit)
- [8. Deputies and continuity of roles](#8-deputies-and-continuity-of-roles)
- [9. Combining roles and conflict-of-interest guardrails](#9-combining-roles-and-conflict-of-interest-guardrails)
- [10. Size tiers](#10-size-tiers)
- [11. Role assignment register](#11-role-assignment-register)
- [12. Communication and acceptance of roles](#12-communication-and-acceptance-of-roles)
- [13. Records and evidence](#13-records-and-evidence)
- [14. Review and maintenance](#14-review-and-maintenance)
- [15. References](#15-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Say which organisation, legal entities and sites the roles cover. If the ISMS scope is narrower than the company, say whether roles outside the scope (for example group HR) still carry ISMS duties. -->

This document says who does what, and who may decide what, to set up,
run and keep improving the ISMS of
[Organization name] within the scope defined in DOC-ISMS-002. It answers
three questions an auditor and every role holder will ask:

1. Who keeps the ISMS in line with ISO/IEC 27001, and who tells top
   management how well it is working (clause 5.3)?
2. Who decides: who approves policies, accepts risks, grants exceptions,
   approves the Statement of Applicability and releases budget?
3. Who does the work in each ISMS process and each key control area, and
   who checks it?

| Item | Value |
|---|---|
| Organisation and legal entities covered | [Organization name, legal entities] |
| Sites covered | [Sites from DOC-ISMS-002] |
| Roles outside the ISMS scope that carry ISMS duties | [Group HR, group legal, shared service desk] |
| Out of scope | [Business units outside the ISMS scope; their own role charts apply] |
| Effective from | YYYY-MM-DD |

Job descriptions and employment contracts reference the roles here; the
security terms of employment are covered by the employee security
handbook (DOC-ISMS-073, `isms/employee-security-handbook`).

## 2. Governance structure

<!-- Guidance: Draw the reporting lines that matter for the ISMS, not the whole organisation chart. Show who reports ISMS performance to top management and that internal audit reports independently. -->

The diagram shows the reporting and escalation lines for information
security. Solid arrows point from a role to the body it reports to; dotted
lines show coordination without line management (risk, asset and control
owners report through their own line managers). Internal audit reports
directly to top management (or the audit committee) and not through the
ISMS manager.

```mermaid
flowchart TD
  TM["Top management (CEO and executive team)"]
  SC["ISMS steering committee (DOC-ISMS-007)"]
  CISO["CISO or security lead"]
  IM["ISMS manager"]
  IA["Internal auditor"]
  RO["Risk owners"]
  AO["Asset owners"]
  CO["Control owners"]
  DPO["DPO or privacy lead"]
  SUP["Supporting functions: HR, legal, IT operations, procurement"]
  SC -->|"reports to"| TM
  CISO -->|"reports to"| SC
  CISO -->|"reports to"| TM
  IM -->|"reports to"| CISO
  DPO -->|"direct access"| TM
  IA -->|"independent reporting"| TM
  IM -.->|"coordinates"| RO
  IM -.->|"coordinates"| AO
  IM -.->|"coordinates"| CO
  SC -.->|"coordinates"| SUP
```

| Body or role | Reports to | Reporting content | Frequency |
|---|---|---|---|
| ISMS manager | CISO (or top management where no CISO exists) | ISMS performance, risks, objectives, nonconformities | [Monthly] |
| CISO or security lead | Steering committee and top management | Security posture, High and Critical risks, incidents, budget | [Quarterly] |
| Steering committee | Top management | Decisions, escalations, inputs for management review | [Quarterly] |
| Internal auditor | Top management or audit committee | Audit results, independence statement | [Per audit and annually] |
| DPO or privacy lead | Top management (with direct access as required by applicable privacy law) | Privacy risks, data subject requests, breaches | [Quarterly] |

## 3. Role definitions

<!-- Guidance: One row per role, with what the role is for, its key responsibilities and the authority that goes with it. Questions to answer: can each holder actually do what the row says (time, access, budget)? Pitfall: listing duties without the authority to carry them out. Auditors compare this with interviews. -->

Every role below has a purpose, responsibilities, authorities and a
minimum competence. Competence requirements and the evidence for them are
kept in the competence and training matrix (DOC-ISMS-026,
`isms/isms-competence-training-matrix`), as clause 7.2 requires.

### 3.1 Governance roles

| Role | Purpose | Key responsibilities | Authorities | Minimum competence |
|---|---|---|---|---|
| Top management | Lead and commit to the ISMS (clause 5.1) | Set direction, approve the information security policy (DOC-ISMS-001), make resources available, chair or attend management review (9.3), accept High risks | Approve policy, budget, objectives and High or Critical risk acceptance | ISMS awareness briefing for executives |
| ISMS steering committee | Coordinate security decisions between management reviews | Track objectives and risks, approve topic-specific policies, prioritise treatment, prepare management review inputs | Decision rights defined in DOC-ISMS-007 | Members briefed on the risk method |
| CISO or security lead | Own the security strategy and the security function | Security strategy, security architecture, incident escalation, risk reporting, budget proposal | Stop a change or release that creates an unacceptable risk; declare a security incident | Senior security qualification or equivalent experience |
| ISMS manager | Run the management system day to day | Ensure the ISMS conforms to ISO/IEC 27001, keep documented information, run the risk cycle, coordinate the SoA, track corrective actions, report ISMS performance (clause 5.3 a and b) | Request evidence from any role, schedule ISMS activities, raise nonconformities | ISO/IEC 27001 implementer training; knowledge of ISO/IEC 27005 |

### 3.2 Ownership roles

| Role | Purpose | Key responsibilities | Authorities | Minimum competence |
|---|---|---|---|---|
| Risk owner | Own named information security risks (clause 6.1.2 c) | Choose the treatment option, approve treatment plan entries, accept residual risk within delegated limits (6.1.3 f) | Accept Low residual risks, and Medium together with the department head, per DOC-ISMS-010; spend from own budget on treatment | Risk method briefing |
| Asset owner | Own information and associated assets in the inventory (A.5.9) | Classify information (A.5.12), approve access to the asset, review access rights, confirm the inventory entry | Approve or refuse access requests to the asset | Classification and handling training |
| Control owner | Operate and evidence one or more controls | Implement the control, keep its records, report failures, attend audits | Define the operating procedure for the control within policy | Training for the specific control |
| Process owner | Own an ISMS process (for example change, supplier management) | Keep the process documented, measured and improved | Approve changes to the process procedure | Process training |

### 3.3 Assurance and specialist roles

| Role | Purpose | Key responsibilities | Authorities | Minimum competence |
|---|---|---|---|---|
| Internal auditor | Provide independent assurance (clause 9.2) | Plan and perform audits per the audit programme (DOC-ISMS-082), report results, verify corrective actions | Access to all records, people and sites in scope; report directly to top management | ISO/IEC 27001 auditor training; ISO 19011:2026 principles |
| DPO or privacy lead | Oversee personal data protection (A.5.34) | Advise on privacy risks, DPIAs and breach assessments, act as contact for authorities and data subjects where required | Escalate privacy risks to top management directly | Data protection qualification relevant to applicable law |
| Incident manager | Coordinate incident response (A.5.24 to A.5.28) | Triage, coordinate response, preserve evidence, run post-incident reviews | Mobilise responders; invoke the incident response plan (DOC-ISMS-020) | Incident handling training and exercises |
| Security operations | Monitor and respond to events (A.8.15, A.8.16) | Monitor alerts, triage events, contain incidents, manage vulnerabilities | Isolate devices and accounts under the incident procedure | Technical security training |

### 3.4 Supporting functions

| Role | ISMS responsibilities | Main controls |
|---|---|---|
| HR | Screening, contract terms, onboarding and offboarding, disciplinary process, awareness records | A.6.1, A.6.2, A.6.3, A.6.4, A.6.5 |
| Legal and compliance | Legal register, contract security clauses, intellectual property, regulator notifications | A.5.31, A.5.32, A.5.20 |
| IT operations | Identity lifecycle, endpoints, backup, configuration, capacity, change implementation | A.5.16, A.8.1, A.8.6, A.8.9, A.8.13, A.8.32 |
| Engineering and development | Secure development, code review, test data, separation of environments | A.8.25 to A.8.29, A.8.31, A.8.33 |
| Procurement and vendor management | Supplier selection, due diligence, contract records, supplier register | A.5.19 to A.5.22 |
| Facilities | Perimeters, entry control, utilities, equipment siting | A.7.1 to A.7.8, A.7.11 |
| Finance | ISMS budget, insurance, payment controls against fraud | Clause 7.1 resources |
| All staff and contractors | Follow policies, complete training, report events (A.6.8) | A.5.10, A.6.3, A.6.8 |

### 3.5 Suppliers and external parties

| External role | ISMS responsibilities | How assigned |
|---|---|---|
| Critical suppliers and cloud providers | Meet agreed security requirements, notify incidents, support audits | Supplier security agreement (DOC-ISMS-068) and register entry (DOC-ISMS-066) |
| Outsourced developers | Follow the outsourced development requirements | DOC-ISMS-077 |
| External internal-audit provider | Perform audits independently and confidentially | Engagement letter with independence statement |
| Managed security service provider | Monitoring and response tasks defined in the service contract | Contract schedule, RACI annex |

Responsibility for a control stays with [Organization name] even when a
supplier operates it. Name an internal control owner for every
outsourced control.

## 4. Authorities and decision rights

<!-- Guidance: This table is what people look up when they need a decision. Keep it consistent with the risk methodology (DOC-ISMS-010), the steering committee charter (DOC-ISMS-007) and the exception procedure. Pitfall: two documents giving different approvers for the same decision. -->

| Decision | Prepared by | Decided by | Limit or condition | Record |
|---|---|---|---|---|
| Approve the information security policy (5.2) | ISMS manager | Top management | Whole policy | Approval block in DOC-ISMS-001 |
| Approve topic-specific policies | Policy owner | Steering committee | Per DOC-ISMS-005 approval levels | Committee minutes |
| Approve standards and baselines | Control owner | CISO or ISMS manager | Within approved policy (DOC-ISMS-005 section 4) | Document approval block |
| Approve procedures and operating instructions | Process or control owner | Owner's line manager | Within approved policy and standards (DOC-ISMS-005 section 4) | Document approval block or workflow |
| Approve the risk methodology and criteria | ISMS manager | Top management | Major changes only | Approval block in DOC-ISMS-010 |
| Accept Low residual risk | Risk owner | Risk owner | Score 1 to 4, within appetite | Risk register DOC-ISMS-016 |
| Accept Medium residual risk | Risk owner | Risk owner plus department head; top management if the category is Averse (DOC-ISMS-015 section 9 rule 1) | Score 5 to 9 | Risk register DOC-ISMS-016; DOC-ISMS-019 if above the category appetite |
| Accept High residual risk | Risk owner | Top management, with a treatment decision | Score 10 to 16 | Risk acceptance record DOC-ISMS-019 |
| Accept Critical residual risk | Risk owner and CISO | Top management, documented decision only | Score 17 to 25 (in practice 20 and 25), exceptional | DOC-ISMS-019 and minutes |
| Approve the Statement of Applicability | ISMS manager | CISO and top management sponsor | Each version | Approval block in DOC-ISMS-011 |
| Grant a policy exception | Requester and control owner; CISO or ISMS manager assesses | By residual risk, as for risk acceptance: Low by the risk owner, Medium by the risk owner plus department head, High by top management with a treatment decision; Critical not approvable | Low or Medium up to [12] months, High up to [6] months, reassessed at expiry; same limits as DOC-ISMS-005 section 7, DOC-ISMS-007 section 6 and DOC-ISMS-122 section 7 | Exception request DOC-ISMS-122; DOC-ISMS-019 for High |
| Release ISMS budget | CISO | Steering committee, with the finance lead voting, up to USD [50,000] per item; CEO above *(Example)* | Within approved annual budget (DOC-ISMS-031); same limit as DOC-ISMS-007 section 6 | Committee minutes or budget approval record |
| Declare a security incident and invoke the response plan | Security operations | Incident manager or CISO | Any time | Incident register DOC-ISMS-021 |
| Stop a release or change for security reasons | Any reviewer | CISO or delegate | Until the risk owner decides | Change record |
| Appoint the internal auditor | ISMS manager proposes | Top management | Independence confirmed (section 7) | Appointment letter |

Risk acceptance limits follow DOC-ISMS-010 and the risk appetite and
criteria (DOC-ISMS-015): scores 1 to 4 are Low, 5 to 9 Medium, 10 to 16
High and 17 to 25 Critical (in practice 20 and 25).

## 5. RACI: ISMS clause processes

<!-- Guidance: R = Responsible (does the work), A = Accountable (one per row, signs off), C = Consulted, I = Informed. Keep exactly one A per row. Questions to answer: does every process have an owner who can be interviewed? Auditors pick a row and ask the A and the R to walk them through the last cycle. -->

Legend: **R** responsible, **A** accountable (exactly one per row),
**C** consulted, **I** informed. Column abbreviations: TM top management,
SC steering committee, CISO, IM ISMS manager, RO risk owners, AO asset
owners, CO control owners, IA internal auditor, DPO, HR, LEG legal, ITO IT
operations.

| Clause | Process | TM | SC | CISO | IM | RO | AO | CO | IA | DPO | HR | LEG | ITO |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 4.1, 4.2 | Context, interested parties and requirements (DOC-ISMS-003) | I | C | A | R | C | | | | C | | C | |
| 4.3 | Define and maintain ISMS scope (DOC-ISMS-002) | A | C | C | R | | | | I | | | C | C |
| 4.4 | Define ISMS processes and interactions (DOC-ISMS-004) | I | C | A | R | | | C | | | | | C |
| 5.1 | Leadership and commitment | A | R | R | C | | | | | | | | |
| 5.2 | Information security policy (DOC-ISMS-001) | A | C | R | R | | | | | C | C | C | |
| 5.3 | Roles, responsibilities and authorities (this document) | A | C | C | R | I | I | I | I | I | C | | I |
| 6.1.1 | Plan actions for risks and opportunities | I | C | A | R | C | | | | | | | |
| 6.1.2 | Information security risk assessment | I | I | A | R | R | C | C | | C | | | C |
| 6.1.3 | Risk treatment and SoA (DOC-ISMS-011, DOC-ISMS-013) | C | C | A | R | R | | C | | | | | C |
| 6.2 | Objectives and plans (DOC-ISMS-024) | A | R | R | R | | | C | | | | | |
| 6.3 | Planning of changes to the ISMS (DOC-ISMS-025) | I | A | C | R | C | | | | | | | |
| 7.1 | Resources | A | C | R | C | | | | | | C | | |
| 7.2 | Competence (DOC-ISMS-026) | I | | C | A | | | | | | R | | |
| 7.3 | Awareness | I | | C | A | | | | | | R | | |
| 7.4 | Communication (DOC-ISMS-027) | I | C | C | A | | | | | C | R | C | |
| 7.5 | Documented information (DOC-ISMS-028) | | | I | A | | | R | | | | | C |
| 8.1 | Operational planning and control | I | | C | A | | | R | | | | | R |
| 8.2 | Risk assessment at planned intervals and on change | I | I | A | R | R | C | C | | | | | |
| 8.3 | Implement risk treatment plan | I | I | A | C | R | | R | | | | | R |
| 9.1 | Monitoring, measurement, analysis and evaluation (DOC-ISMS-080) | I | I | A | R | | | R | | | | | C |
| 9.2 | Internal audit (DOC-ISMS-082) | A | I | I | C | | | C | R | | | | |
| 9.3 | Management review (DOC-ISMS-085) | A | C | R | R | | | | C | C | | | |
| 10.1 | Continual improvement (DOC-ISMS-088) | I | C | A | R | | | R | | | | | |
| 10.2 | Nonconformity and corrective action (DOC-ISMS-087) | I | I | C | A | C | | R | C | | | | |

Notes on the matrix:

- Internal audit (9.2) is Accountable to top management, not to the ISMS
  manager. The ISMS manager is Consulted on scheduling and is audited like
  any other process owner.
- The CISO is Accountable for risk assessment; risk owners are Responsible
  for scoring their own risks and accepting residual risk within limits.
- Where no CISO exists, the ISMS manager takes the CISO column and top
  management takes the Accountable entries for 6.1.2, 6.1.3 and 9.1.

## 6. RACI: key Annex A processes

<!-- Guidance: Pick the control areas that need several functions to cooperate. Single-owner controls only need a control owner in the SoA. Pitfall: forgetting suppliers; name the internal owner who manages the supplier's part. -->

Column abbreviations as in section 5, plus DPO, PRC procurement, ENG
engineering, FAC facilities, SUP supplier, ALL all staff.

| Control area | Process | CISO | IM | AO | CO | HR | LEG | DPO | ITO | ENG | PRC | FAC | SUP | ALL |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A.5.9, A.5.12 | Asset inventory and classification | C | A | R | | | |  | R | | | | | I |
| A.5.15 to A.5.18 | Access control and access reviews | A | C | R | | C | |  | R | | | | | |
| A.5.19 to A.5.22 | Supplier security lifecycle | C | C | | | | C |  | | | A | | R | |
| A.5.23 | Cloud service use | A | C | C | | | C |  | R | R | C | | C | |
| A.5.24 to A.5.28 | Incident management | A | C | | R | | C | C | R | R | | | C | I |
| A.5.29, A.5.30 | Continuity and ICT readiness | A | C | | R | | |  | R | R | | C | C | |
| A.5.31, A.5.32 | Legal, regulatory and contractual requirements | C | C | | | | A | C | | | C | | | I |
| A.5.34 | Privacy and PII protection | C | C | C | | C | C | A | | | | | | I |
| A.6.1 to A.6.5 | People lifecycle: screening to leaving | C | C | | | A | C | C | R | | | | | |
| A.6.3 | Awareness, education and training | C | A | | | R | |  | | | | | | R |
| A.6.8 | Reporting security events | A | C | | R | | | I | | | | | | R |
| A.7.1 to A.7.4 | Physical entry and monitoring | C | C | | | | |  | | | | A | C | I |
| A.8.7, A.8.8 | Malware and vulnerability management | A | C | | R | | |  | R | R | | | C | |
| A.8.13 | Backup and restore testing | C | C | C | | | |  | A | R | | | C | |
| A.8.15, A.8.16 | Logging and monitoring | A | C | | R | | |  | R | R | | | C | |
| A.8.25 to A.8.29 | Secure development | C | C | | | | |  | | A | | | C | |
| A.8.32 | Change management | C | I | | | | |  | A | R | | | C | |

Replace the matrix with the control areas that apply to your SoA, and keep
exactly one A per row.

## 7. Independence of internal audit

<!-- Guidance: Clause 9.2 only works if auditors have no stake in what they audit. Auditors check that nobody audited their own work. Pitfall: the ISMS manager auditing the ISMS processes they run. -->

Auditors must not audit their own work. [Organization name] secures
objectivity and impartiality (clause 9.2.2) as follows:

| Safeguard | Rule | Evidence |
|---|---|---|
| Reporting line | The internal auditor reports results to top management or the audit committee, not to the ISMS manager | Audit report distribution list |
| No self-review | An auditor does not audit a process they designed, operate or managed in the last [12] months | Independence declaration per audit |
| Rotation | Auditors are rotated across process areas at least every [3] audit cycles *(Example)* | Audit programme assignments |
| External support | Where no independent internal resource exists, an external auditor or a peer from another business unit audits the ISMS manager's processes | Engagement letter |
| Access | Auditors have unrestricted access to records, people and systems in scope | Audit charter clause |
| Escalation | An auditor who meets interference escalates directly to top management | Audit charter clause |

Independence declaration *(Example)*:

| Audit ID | Auditor | Areas audited | Prior involvement in last 12 months | Declared independent | Date |
|---|---|---|---|---|---|
| IA-2027-01 *(Example)* | [@internal-auditor] | Clauses 6.1, 8.2, 8.3; A.5.15 to A.5.18 | None | Yes | 2027-03-08 |
| IA-2027-02 *(Example)* | [@external-auditor] | Clauses 4 to 10 processes run by the ISMS manager | None (external) | Yes | 2027-03-15 |

## 8. Deputies and continuity of roles

<!-- Guidance: Every role that makes decisions or runs a time-critical process needs a deputy with the same access and authority, written down. Questions to answer: who accepts a High risk when the CEO is on leave? Who leads incident response at night? -->

| Role | Primary holder | Deputy | Deputy authority | Handover trigger |
|---|---|---|---|---|
| CISO or security lead | [@ciso] | [@isms-manager] | Full, except budget above USD [10,000] *(Example)* | Absence over [2] working days |
| ISMS manager | [@isms-manager] | [@security-engineer] | Run ISMS activities, raise nonconformities | Absence over [5] working days |
| Incident manager | [@incident-manager] | [On-call rota per DOC-ISMS-020] | Full during the incident | Out of hours, absence |
| DPO or privacy lead | [@dpo] | [@legal-counsel] | Advice and authority contact | Absence over [2] working days |
| Top management risk acceptance | [@ceo] | [@coo] | Accept High risks; not Critical | Absence over [5] working days |
| Internal auditor | [@internal-auditor] | [External provider] | Perform scheduled audits | Unavailability or conflict |

Rules for deputies:

1. Deputies have the access, training and authority needed before they
   act, not after. Record their competence in DOC-ISMS-026.
2. A deputy's decisions are recorded under the deputy's name with the
   reason for acting.
3. The primary holder reviews decisions taken in their absence within [5]
   working days of return.
4. When a role holder leaves, the deputy acts until a successor is
   appointed, and the ISMS manager updates section 11 within [10] working
   days.

## 9. Combining roles and conflict-of-interest guardrails

<!-- Guidance: A.5.3 is about not letting one person both do and approve (or both do and check) the same sensitive task. In small organisations full separation is often impossible; record which roles are combined, the conflict it creates and the compensating control. Auditors accept combined roles with documented compensation; they do not accept silent self-approval. -->

### 9.1 Incompatible combinations

| Combination | Conflict | Allowed? | Compensating control if combined |
|---|---|---|---|
| ISMS manager and internal auditor of ISMS processes | Self-review | No | External or peer auditor for processes the ISMS manager runs |
| Requester and approver of the same access | Self-approval | No | Second approver; automated workflow blocks self-approval |
| System administrator and log reviewer for own activity | Can hide own actions | Only with compensation | Logs forwarded to a store the administrator cannot alter; monthly review by another person |
| Developer and production deployer of own code | Unreviewed change | Only with compensation | Mandatory peer review and pipeline approval before deployment |
| Risk owner and risk acceptor above own limit | Accepting own High risk | No | Escalate to top management per section 4 |
| Exception requester and exception approver | Self-granted exception | No | Approver at the next level for the residual risk band (DOC-ISMS-122 section 7) |
| Finance payment approver and supplier master-data editor | Fraud risk | Only with compensation | Dual control on bank detail changes; monthly reconciliation |
| CISO and head of IT operations | Security oversight of own operations | Allowed in small and medium tiers | Steering committee reviews security metrics; internal audit covers IT operations each year |

### 9.2 Combining roles in a small organisation

In a small organisation one person often holds several roles. Record each
combination in the register below with the reason and the compensating
control. Review it at every management review.

| Combination ID | Person | Roles combined | Conflict | Compensating control | Approved by | Review date |
|---|---|---|---|---|---|---|
| CMB-001 *(Example)* | Head of Engineering Operations (Quillmere Analytics) | ISMS manager (0.5 FTE), control owner for backup and change | Assesses the controls they operate | Internal audit of these controls by an external auditor; CEO reviews backup test results quarterly | CEO | 2027-06-30 |
| CMB-002 *(Example)* | CTO (Quillmere Analytics) | CISO role, engineering lead | Security oversight of own engineering decisions | Monthly leadership meeting acting as steering committee (CEO, CTO, COO, Head of Engineering Operations) reviews security metrics; release approvals logged | CEO | 2027-06-30 |
| CMB-003 *(Example)* | COO (Quillmere Analytics) | Privacy lead, HR lead | Advises on own HR data processing | External privacy counsel reviews HR data processing annually | CEO | 2027-06-30 |

## 10. Size tiers

<!-- Guidance: Show how the role model scales. The standard does not require a CISO, a committee or a full-time ISMS manager; what matters is that every security duty has a named holder who knows about it. These tiers are the library's working tiers, not official definitions. -->

| Topic | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| ISMS manager | Head of Engineering Operations, part time (0.5 FTE) | Full-time ISMS manager | Group ISMS manager in the CISO office, with site ISMS coordinators |
| Security function | No separate team; CTO holds the CISO role | ISMS manager plus a 3-person security team | CISO with a 14-person security office |
| Steering body | Monthly leadership meeting with a security agenda item, chaired by the CEO | ISMS steering committee, quarterly | Group security council plus site committees; integrated with the 9001 and 22301 governance |
| Risk owners | Executives own all risks (about 5 people) | Department heads | Site directors and group function heads; OT risks owned by plant managers |
| Internal audit | External auditor engaged per audit | Trained staff from quality plus an external auditor for ISMS manager processes | Group internal audit with ISMS-trained auditors; integrated audits |
| DPO or privacy lead | COO with external privacy counsel | Designated privacy lead; DPO where law requires (processor and controller roles) | Group DPO network with local privacy contacts in each country |
| Deputies | Pairs among executives | Named deputy per role | Deputy per role per site, recorded in the group role register |
| Combined roles | Several, recorded in section 9.2 | Few, mainly CISO and IT operations oversight | Rare; full separation expected |
| RACI granularity | Section 5 only, Annex A owners in the SoA | Sections 5 and 6 | Sections 5 and 6 per site, plus a group overlay for shared services |

## 11. Role assignment register

<!-- Guidance: Name the holder of every role, with the date they accepted it. This register is the quickest evidence for clause 5.3. Use role mailboxes or handles in shared copies if names are sensitive. -->

| Assignment ID | Role | Holder | Deputy | Scope (sites, systems) | FTE share for ISMS | Accepted on | Competence record |
|---|---|---|---|---|---|---|---|
| ROLE-001 *(Example)* | ISMS manager | Head of Engineering Operations | Senior platform engineer | Whole scope | 0.5 | 2027-01-11 | DOC-ISMS-026 row COMP-004 |
| ROLE-002 *(Example)* | CISO role | CTO | Head of Engineering Operations | Whole scope | 0.2 | 2027-01-11 | DOC-ISMS-026 row COMP-002 |
| ROLE-003 *(Example)* | Risk owner: customer data platform | VP Product | CTO | Analytics platform, both cloud regions | 0.05 | 2027-01-18 | Risk briefing 2027-01-18 |
| ROLE-004 *(Example)* | Asset owner: customer datasets | Head of Data | VP Product | Customer data stores | 0.05 | 2027-01-18 | Classification training 2027-01-20 |
| ROLE-005 *(Example)* | Internal auditor | External ISMS auditor (contract) | Second external auditor | ISMS processes run by internal staff | Contract | 2027-02-01 | Auditor certificate on file |
| ROLE-006 *(Example)* | Privacy lead | COO | External privacy counsel | Customer and staff personal data | 0.1 | 2027-01-11 | Privacy course record |
| [ROLE-NNN] | [Role] | [Holder] | [Deputy] | [Scope] | [0.0] | YYYY-MM-DD | [Reference] |

The FTE shares in this example total 0.9 FTE of internal time, plus the
contracted auditor.

## 12. Communication and acceptance of roles

<!-- Guidance: Under clause 5.3 a role that nobody has been told about does not count. Show how people learn about their role and how you know they accepted it. Pitfall: a RACI that only the ISMS manager has read. -->

1. Publish this document on [intranet or document system] and link it from
   the ISMS manual (DOC-ISMS-008).
2. Each role holder receives a role letter or an entry in the HR system
   with the role, responsibilities, authorities and deputy, and confirms
   acceptance (date recorded in section 11).
3. New role holders receive a handover briefing from the outgoing holder
   or the ISMS manager within [10] working days.
4. All staff learn the reporting route for security events (A.6.8) and the
   name of the ISMS manager in onboarding and annual awareness training.
5. Changes to roles are announced through the channels in the
   communication plan (DOC-ISMS-027).
6. Supplier roles are communicated through contracts and kick-off meetings,
   recorded in the supplier register (DOC-ISMS-066).

## 13. Records and evidence

<!-- Guidance: List the records that prove the role model is in place and working. Link each to the control evidence matrix (DOC-ISMS-033, `isms/control-evidence-matrix`) so the evidence index for audits stays in one place. -->

| Record | Proves | Kept by | Where | Retention *(Example)* |
|---|---|---|---|---|
| Approved version of this document | Roles and authorities assigned by top management (5.3) | ISMS manager | Document management system | Current plus [3] previous versions |
| Role assignment register (section 11) with acceptance dates | Roles communicated and accepted | ISMS manager | This document or HR system | [3] years after role ends |
| Role letters or HR role entries | Individual communication | HR | HR system | Employment plus [3] years |
| Combined-role register (section 9.2) with approvals | Segregation of duties handled (A.5.3) | ISMS manager | This document | [3] years |
| Auditor independence declarations | Objective and impartial audits (9.2) | Internal auditor | Audit file | [3] years or one certification cycle |
| Deputy decisions log | Continuity of authority | Each deputy | Decision log or minutes | [3] years |
| Competence records for role holders | Competence (7.2) | HR and ISMS manager | DOC-ISMS-026 | Employment plus [3] years |
| Management review minutes covering role changes | Top management oversight | ISMS manager | DOC-ISMS-085 | [3] years |

Map these records to A.5.2, A.5.3, A.5.4 and clause 5.3 in the control
evidence matrix (DOC-ISMS-033).

## 14. Review and maintenance

<!-- Guidance: Name the triggers that force an update, so the document does not drift after a reorganisation. -->

- Planned review every [12] months, before the management review.
- Unplanned review when: a role holder leaves or changes job; the
  organisation is restructured; the ISMS scope changes (DOC-ISMS-002); a
  new site, legal entity or major supplier is added; an audit finding
  concerns roles, independence or segregation of duties; a role combination
  is added in section 9.2.
- After each review, update the assignment register, re-confirm deputies,
  and record the change in the revision history.

## 15. References

<!-- Guidance: Cite the editions you used and check them at every review. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Current (https://www.iso.org/standard/82875.html, Amd 1: https://www.iso.org/standard/88435.html) | Clauses 5.1, 5.3, 7.2, 9.2; A.5.2, A.5.3, A.5.4 |
| ISO/IEC 27002:2022 | Current (https://www.iso.org/standard/75652.html) | Guidance on roles, segregation and management responsibilities |
| ISO/IEC 27003:2017 | Current; a revision is in progress, check for a newer edition (https://www.iso.org/standard/63417.html) | ISMS implementation guidance on leadership and roles |
| ISO/IEC 27014:2020 | Current; a new edition is at FDIS stage in 2026 (https://www.iso.org/standard/74046.html) | Governing body and executive responsibilities |
| ISO/IEC 27021:2017 + Amd 1:2021 | Current (https://www.iso.org/standard/61003.html) | Competence of ISMS professionals |
| ISO 19011:2026 | Current (https://www.iso.org/standard/88984.html) | Auditor independence and competence principles |

Related templates: `isms/isms-steering-committee-charter`,
`isms/isms-policy-framework`, `isms/isms-manual`,
`isms/isms-competence-training-matrix`,
`isms/isms-communication-plan`, `compliance/risk-methodology`,
`compliance/statement-of-applicability`,
`compliance/internal-audit-program`, `compliance/management-review`,
`security/security-exception-request`, `isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clause 5.3 and
Annex A controls A.5.2 to A.5.4), with guidance from ISO/IEC 27002:2022,
ISO/IEC 27003:2017, ISO/IEC 27014:2020 and ISO 19011:2026. The text,
tables, RACI matrices and examples are original. No ISO/IEC text is
reproduced: clause and control numbers are cited with short labels written
for this template, not official titles. Obtain the official standards from
ISO, IEC or your national standards body to implement and audit the ISMS,
and check the current edition before use (ISO/IEC 27003 and ISO/IEC 27014
are under revision). Quillmere entities are fictional.

Template licence: MIT.