Segregation of Duties Conflict Matrix
Provides a ready-built conflict matrix for the roles and transactions where SoD breaks most often, so teams do not start from a blank sheet.
Available soon
- Format
- Excel
- Size
- 102 KB
- Length
- 11 sheets
- Version
- 1.0
- Updated
What's inside
- Instructions
- Conflict Catalogue
- Duty Grid
- Our Assessment
- Summary
- Lists
- Definitions
- Framework References
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Read the Conflict Catalogue. Each row is a pair of duties that should not sit with one person (SD-01), with what that person could do and hide, a rating and the compensating controls that usually work when the duties cannot be split. Filter on Process or Applies where to see the conflicts that matter to you. |
| 2 | Tailor the catalogue once, when you adopt it: remove conflicts that cannot arise in your organisation, change a rating only with a recorded reason, and add conflicts of your own on the blank rows (new duties go in the Duty list on the Lists sheet first). The catalogue is reviewed annually, and after any restructure or new core system (SD-02). |
| 3 | Look at the Duty Grid. It draws the same catalogue as duties against duties, with the rating where two duties conflict. Read along a duty's row to see every duty that must not be combined with it. It is calculated — do not type in it. |
| 4 | On Our Assessment, delete the EXAMPLE rows, then add one row per conflict in the catalogue: type or pick its Conflict ID and the duties and rating fill in. Answer 'Applies to us?' — Yes if one person, account or supplier in your organisation holds, or could hold, both duties. |
| 5 | For each conflict that applies, name who holds both duties and choose how it is handled: Separated (the duties now sit with different people), Mitigated (they cannot be split, so a compensating control is in place — SD-04) or Not yet addressed. A mitigated conflict is approved and recorded as an exception in the Security Exception Register; put its reference in Exception reference. |
| 6 | Before anyone is given a new role or access, check it against the grid and this sheet (SD-03). Emergency and privileged access follow SD-06. |
| 7 | Review each applicable conflict at the frequency set by its rating (SD-05): High — quarterly; Medium — every six months; Low — annually, at the matrix review. Separated conflicts are re-checked at the annual matrix review. Enter the Last review date; the Next review due and Review status follow. The SoD Conflict Review & Compensating Control Procedure explains how to run the review. |
| 8 | Clear every Record check that does not say OK. Set the As-at date on the Summary sheet (it shows today; type a fixed date to freeze a report). |
| 9 | Each month, copy the 'Unmitigated SoD conflicts' figure from the Summary into the Exception Ageing & Expiry Dashboard. Keep this workbook, with its review dates, as the record SD-07 requires. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Ratings (Security Exception & Waiver Standard): High: one person could make and hide an unauthorised change, payment or access grant with no second person seeing it. Medium: one person could make an unauthorised change that another control would probably, but not certainly, detect later. Low: the combination is undesirable but the damage is small or detected quickly by routine checks.
The catalogue rows are the template's content, not examples: keep, change or remove them as you tailor it. Only the rows on Our Assessment marked EXAMPLE are to be deleted.
Tailoring — small organisation: with two or three IT staff many High conflicts cannot be separated. That is normal. Mitigate them with a control someone outside IT carries out — a finance or operations manager reviewing a report each week is often enough — and record each one as an exception rather than leaving it unrecorded.
Tailoring — regulated entity (NIS2, DORA): link each conflict to the access control policy, keep the review evidence for supervisors, and make sure the ICT risk control function is independent of the people it oversees (see SOD-SO-04 and the exception management conflicts). Financial entities under DORA should keep SOD-EM-01 separated rather than mitigated, and should not let whoever operates a compensating control approve the exception that relies on it (SOD-EM-02).
Tailoring — IT run by a service provider: many duties sit with the provider. Record the provider as the holder, ask for their own segregation arrangements in the contract, and keep at least one duty of each High conflict — usually approval or review — inside your organisation.
Duty Grid: the grid covers the first 40 duties on the Lists sheet. If two catalogue rows name the same pair of duties, the grid shows the lower row's rating.
Conflict Catalogue
The ready-built catalogue: 20 conflicts, grouped by process. Tailor it once (Instructions, step 2); add your own on the blank rows. Review frequency is calculated from the rating (SD-05).
| Conflict ID | Process | Duty A | Duty B | Why it conflicts — what one person could do and hide | Rating | Typical compensating controls when the duties cannot be separated | Review frequency (calc) | Applies where | Framework cross-references |
|---|---|---|---|---|---|---|---|---|---|
| SOD-IT-01 | IT administration | Create or change user accounts and permissions | Approve access requests | One person could give themselves, or someone else, access they should not have and approve the request, so the record shows an authorised grant that nobody else agreed. | High | Every access change needs a ticket approved by the line manager or system owner, not the administrator; a weekly report of new accounts and group changes, taken straight from the directory, is reviewed by someone outside IT. | quarterly | All organisations | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b); NIS2 Art. 21(2)(i) |
| SOD-IT-02 | IT administration | Create or change user accounts and permissions | Review access rights (periodic access review) | The person who granted excessive or unauthorised access would be the one checking whether access is appropriate, and could pass their own mistakes or misuse. | High | System owners or line managers review access for their own people from a report generated by the system, not prepared by the administrator; an independent reviewer re-performs a sample each year. | quarterly | All organisations | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b); NIS2 Art. 21(2)(i) |
| SOD-IT-03 | IT administration | Administer a system with privileged access | Review a system's audit logs | An administrator could misuse privileged access and then overlook, change or delete the log entries that record it. | High | Logs are sent to a central log store the administrator cannot change or delete; alerts on clearing logs or changing audit settings go to someone else (for example a managed security service); a second person samples the privileged activity log monthly. | quarterly | All organisations | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b) |
| SOD-IT-04 | IT administration | Make changes to production systems | Approve changes to production systems | One person could make an unauthorised or untested change to a live system and approve it themselves, so the change record looks complete and nobody questions it until it fails or is misused. | High | A second person approves each change before it is made, even in a small team; emergency changes are reviewed after the event within a set time; configuration monitoring reports unplanned changes to the IT manager. | quarterly | All organisations | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
| SOD-IT-05 | IT administration | Develop or change code | Deploy code to production | A developer could add unreviewed code — a hidden back door, a changed calculation or a disabled check — and release it to live systems without anyone else seeing it. | High | Code is merged only after review by a second developer, enforced in the code repository; deployments run only from the reviewed main branch through the build pipeline; the deployment log is reviewed each month. | quarterly | In-house software development | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g), 21(b) |
| SOD-IT-06 | IT administration | Run and manage backups | Test and sign off restores from backup | Failing backups could be hidden by reporting restore tests as passed; the damage appears only when a restore is really needed, but routine test evidence usually shows it. | Low | Restore test evidence (the restored files or system and the job log) is attached to the record and checked by the IT manager; at least one restore test a year is watched by a second person. | annually, at the matrix review | All organisations | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
| SOD-IT-07 | IT administration | Maintain the IT asset inventory | Dispose of IT equipment and storage media | One person could remove a laptop, disk or server holding data and delete it from the inventory, so its loss is never noticed; stock checks would probably, but not certainly, find the gap. | Medium | Disposal needs a signed request and a certificate of data destruction from the disposal company, checked against the inventory by a second person; the inventory is reconciled with the device-management tool each quarter. | every six months | All organisations | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
| SOD-SO-01 | Security operations | Grant privileged access | Review access rights (periodic access review) | The person who grants administrator rights could give them without justification and then confirm, in the review, that every privileged account is appropriate. | High | Privileged access is reviewed by the system owner or an independent reviewer using a list exported from the system; privileged accounts are time-limited and expire unless re-approved. | quarterly | All organisations | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b); NIS2 Art. 21(2)(i) |
| SOD-SO-02 | Security operations | Configure security tools and detection rules | Triage and close security alerts | One person could switch off or tune out the detection of their own activity and would be the one to close any alert that still fired, so nothing reaches anyone else. | High | Changes to detection rules and tool settings are logged and alert a second person or the managed security service; tamper protection is on; alerts about the security team's own accounts go to their manager. | quarterly | Security tools operated in-house | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
| SOD-SO-03 | Security operations | Run vulnerability scans and report results | Make changes to production systems | The person who fixes systems could leave their own systems out of the scan or mark findings closed without a fix; another scan or an audit would probably, but not certainly, find it. | Medium | Scan scope is reconciled with the asset inventory by someone else each month; findings close only when a later scan confirms the fix; scan reports go straight to the IT manager as well. | every six months | All organisations | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
| SOD-SO-04 | Security operations | Investigate security incidents | Administer a system with privileged access | An administrator investigating an incident on their own systems could play down their own mistake or misuse and remove evidence before anyone else looks. | Medium | Evidence is preserved by, or copied to, someone other than the administrator before the investigation starts; the incident report is reviewed by the Head of Information Security or an external responder. | every six months | All organisations | ISO/IEC 27001 A.5.3; RTS 2024/1774 Art. 2(2)(g); DORA Art. 6(4) |
| SOD-FI-01 | Finance-facing IT | Create or change suppliers and their bank details in the finance system | Approve payments | One person could set up a false supplier, or change a real supplier's bank details to their own, and then approve the payment to it. | High | Every bank-detail change is confirmed by a call-back to a known number by someone else; a report of supplier changes is reviewed by the Finance Manager before each payment run; the bank requires two people to release a payment. | quarterly | Finance system administered in-house | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b) |
| SOD-FI-02 | Finance-facing IT | Maintain payroll master data | Approve the payroll run | One person could add a fictitious employee or change pay or bank details and approve the payroll that pays them. | High | Starters, leavers and pay changes are reconciled with HR records each month by someone outside payroll; a variance report against the previous run is signed off by the Finance Director. | quarterly | Payroll processed in-house | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b) |
| SOD-FI-03 | Finance-facing IT | Administer the finance system's users and roles | Post transactions in the finance system | The finance system administrator could give themselves posting or approval rights, make a transaction and remove the rights again, leaving little trace in the ordinary reports. | High | Administrator and business accounts are separate, and the administrator account posts no transactions; a report of role changes and administrator activity is reviewed monthly by the Financial Controller. | quarterly | Finance system administered in-house | ISO/IEC 27001 A.5.3, A.5.15; CSF PR.AA-05; RTS 2024/1774 Art. 21(b) |
| SOD-FI-04 | Finance-facing IT | Raise purchase orders for IT goods and services | Confirm IT goods or services were received | One person could order goods or services that were never delivered, or not for business use, and confirm receipt so the invoice is paid; invoice matching would probably, but not certainly, catch it. | Medium | Finance matches order, receipt and invoice before paying; the budget holder reviews IT spend against budget each month; equipment received is added to the asset inventory by someone else. | every six months | All organisations | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
| SOD-EM-01 | Exception management | Request a security exception | Approve a security exception | The requester could approve their own exception, leaving a control switched off with nobody independent weighing the risk. | High | An exception is never approved by its requester: when the requester is the approver for the band, it goes to the next approval level up (EX-05); information security assesses the risk independently (EX-04). | quarterly | All organisations | ISO/IEC 27001 A.5.3; RTS 2024/1774 Art. 2(2)(g), 2(2)(c); DORA Art. 6(4) |
| SOD-EM-02 | Exception management | Approve a security exception | Operate a compensating control | The person who runs the compensating control an exception relies on would be judging whether that control is enough, and could approve an exception that rests on a weak or untested control of their own; the independent risk assessment (EX-04) would probably, but not certainly, notice. | Medium | The operator of a compensating control is never an approver of the exception that relies on it: another approver at the same band, or the next level up, decides (EX-05); information security confirms the control has been tested before approval (EX-07). | every six months | All organisations | ISO/IEC 27001 A.5.3; RTS 2024/1774 Art. 2(2)(g), 2(2)(c); DORA Art. 6(4) |
| SOD-EM-03 | Exception management | Assess the risk of a security exception | Request a security exception | The requester could score their own exception low enough to fall into a band with a more junior approver and a longer duration; the monthly register review (EX-11) would probably, but not certainly, notice. | Medium | A second person in information security checks any score that sits at a band boundary; the Exception Risk Scoring & Expiry Model's scoring rules are applied as written and the reasoning is recorded on the form. | every six months | Security exceptions process in use | ISO/IEC 27001 A.5.3; RTS 2024/1774 Art. 2(2)(g); DORA Art. 6(4) |
| SOD-EM-04 | Exception management | Maintain the security exception register | Request a security exception | The register keeper could extend the expiry of their own exception, or mark it closed without evidence, so it drops off every report. | Medium | Register changes are kept in the file's version history; the monthly review (EX-11) is done by someone other than the keeper; closure needs recorded evidence (EX-13); expiry dates are checked against the approved Security Exception Request & Approval Form. | every six months | Security exceptions process in use | ISO/IEC 27001 A.5.3; RTS 2024/1774 Art. 2(2)(g), 2(2)(c); DORA Art. 6(4) |
| SOD-EM-05 | Exception management | Operate a compensating control | Test that a compensating control works | The person running a compensating control could report it as effective when it is not, so the exception's lowered risk score (EX-07) rests on a check nobody else made. | Medium | Someone other than the operator tests the control before the exception is approved and at each renewal, and attaches the evidence; information security samples compensating controls at the monthly register review. | every six months | Security exceptions process in use | ISO/IEC 27001 A.5.3; CSF PR.AA-05; RTS 2024/1774 Art. 2(2)(g) |
Duty Grid
Duty grid — duties against duties
Calculated from the Conflict Catalogue. Where a row's duty and a column's duty conflict, the cell shows the rating; read along a row to see every duty that must not be combined with it. Column codes match the row codes. Do not type in the grid.
| Code | Duty | D01 | D02 | D03 | D04 | D05 | D06 | D07 | D08 | D09 | D10 | D11 | D12 | D13 | D14 | D15 | D16 | D17 | D18 | D19 | D20 | D21 | D22 | D23 | D24 | D25 | D26 | D27 | D28 | D29 | D30 | D31 | D32 | D33 | D34 | D35 | D36 | D37 | D38 | D39 | D40 | Conflicts (count) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| D01 | Create or change user accounts and permissions | — | High | High | 2 | |||||||||||||||||||||||||||||||||||||
| D02 | Approve access requests | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D03 | Review access rights (periodic access review) | High | — | High | 2 | |||||||||||||||||||||||||||||||||||||
| D04 | Administer a system with privileged access | — | High | Medium | 2 | |||||||||||||||||||||||||||||||||||||
| D05 | Review a system's audit logs | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D06 | Make changes to production systems | — | High | Medium | 2 | |||||||||||||||||||||||||||||||||||||
| D07 | Approve changes to production systems | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D08 | Develop or change code | — | High | 1 | ||||||||||||||||||||||||||||||||||||||
| D09 | Deploy code to production | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D10 | Run and manage backups | — | Low | 1 | ||||||||||||||||||||||||||||||||||||||
| D11 | Test and sign off restores from backup | Low | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D12 | Maintain the IT asset inventory | — | Medium | 1 | ||||||||||||||||||||||||||||||||||||||
| D13 | Dispose of IT equipment and storage media | Medium | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D14 | Grant privileged access | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D15 | Configure security tools and detection rules | — | High | 1 | ||||||||||||||||||||||||||||||||||||||
| D16 | Triage and close security alerts | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D17 | Run vulnerability scans and report results | Medium | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D18 | Investigate security incidents | Medium | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D19 | Create or change suppliers and their bank details in the finance system | — | High | 1 | ||||||||||||||||||||||||||||||||||||||
| D20 | Approve payments | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D21 | Maintain payroll master data | — | High | 1 | ||||||||||||||||||||||||||||||||||||||
| D22 | Approve the payroll run | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D23 | Administer the finance system's users and roles | — | High | 1 | ||||||||||||||||||||||||||||||||||||||
| D24 | Post transactions in the finance system | High | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D25 | Raise purchase orders for IT goods and services | — | Medium | 1 | ||||||||||||||||||||||||||||||||||||||
| D26 | Confirm IT goods or services were received | Medium | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D27 | Request a security exception | — | High | Medium | Medium | 3 | ||||||||||||||||||||||||||||||||||||
| D28 | Approve a security exception | High | — | Medium | 2 | |||||||||||||||||||||||||||||||||||||
| D29 | Assess the risk of a security exception | Medium | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D30 | Maintain the security exception register | Medium | — | 1 | ||||||||||||||||||||||||||||||||||||||
| D31 | Operate a compensating control | Medium | — | Medium | 2 | |||||||||||||||||||||||||||||||||||||
| D32 | Test that a compensating control works | Medium | — | 1 |
D33
D34
D35
D36
D37
D38
D39
D40
Ratings: High, Medium, Low — see the Definitions sheet. The colour only repeats the word. — marks a duty against itself.
Our Assessment
One row per conflict in the catalogue. Yellow columns are yours; the rest calculate. Delete the five EXAMPLE rows first.
| Example | Conflict ID | Duty A (calc) | Duty B (calc) | Rating (calc) | Applies to us? | Who holds both duties | Separated or mitigated | Compensating control in place | Exception reference | Last review date | Review every (months, calc) | Next review due (calc) | Review status (calc) | Record check (calc) | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | SOD-IT-01 | Create or change user accounts and permissions | Approve access requests | High | Yes | IT Operations Manager (one of two IT staff) | Mitigated | Weekly report of new accounts and group changes, exported from the directory, reviewed and signed by the Finance Director | EX-2026-013 | 15 Jul 2026 | 3 | 15 Oct 2026 | Due soon | OK | Second IT post approved for 2027; separate then |
| EXAMPLE | SOD-IT-03 | Administer a system with privileged access | Review a system's audit logs | High | Yes | Both IT administrators | Mitigated | Server logs forwarded to the managed security service's log store, which administrators cannot change; the provider alerts on log clearing | EX-2026-016 | 10 Apr 2026 | 3 | 10 Jul 2026 | Overdue | OK | Review overdue — last done in April |
| EXAMPLE | SOD-IT-05 | Develop or change code | Deploy code to production | High | Yes | — | Separated | EX-2025-022 (closed) | 28 Apr 2026 | 12 | 28 Apr 2027 | On track | OK | Deployment moved to the build pipeline with required code review in April 2026; exception closed | |
| EXAMPLE | SOD-FI-01 | Create or change suppliers and their bank details in the finance system | Approve payments | High | Yes | Finance Manager | Not yet addressed | 3 | Not reviewed | Separate or mitigate (SD-04) | Found at this assessment; raised with the Finance Director | ||||
| EXAMPLE | SOD-IT-06 | Run and manage backups | Test and sign off restores from backup | Low | No | Not applicable | OK | Backups and restore tests are run by different people at the managed service provider |
Summary
Segregation of duties summary
Calculated from Our Assessment as at the date shown. Copy the first figure into the Exception Ageing & Expiry Dashboard each month.
| As-at date | 28 Sep 2026 | Shows today. Type a fixed date to freeze a report. |
Headline
| Measure | Result | Target | Status | What it means | ||
|---|---|---|---|---|---|---|
| Unmitigated SoD conflicts (headline metric) | 2 | 0 | Action needed | Known High conflicts with no compensating control recorded and reviewed in the last quarter. Separated conflicts are not counted. | ||
| Applicable conflicts not yet addressed | 1 | 0 | Action needed | Separate the duties, or mitigate and record the approval (SD-04). | ||
| Reviews overdue | 1 | 0 | Action needed | Review at the frequency set by the rating (SD-05). | ||
| Rows with a record check to resolve | 1 | 0 | Action needed | Any row on Our Assessment whose Record check does not say OK. | ||
| Catalogue conflicts not yet on Our Assessment | 15 | 0 | Action needed | Every conflict in the catalogue gets a row, even when the answer is 'No'. | ||
Conflicts by rating and how they are handled
| Rating | Separated | Mitigated | Not yet addressed | Applies, not yet chosen | Does not apply | Not answered |
|---|---|---|---|---|---|---|
| High | 1 | 2 | 1 | 0 | 0 | 0 |
| Medium | 0 | 0 | 0 | 0 | 0 | 0 |
| Low | 0 | 0 | 0 | 0 | 1 | 0 |
| All ratings | 1 | 2 | 1 | 0 | 1 | 0 |
EXAMPLE rows are counted until you delete them. Review frequency by rating (SD-05): High — quarterly; Medium — every six months; Low — annually, at the matrix review.
Lists
| DutyCode | Duty | Process | AppliesWhere | SodRating | ReviewText | ReviewMonths | SeparatedReviewMonths | DueSoonDays | Handling | YesNo |
|---|---|---|---|---|---|---|---|---|---|---|
| D01 | Create or change user accounts and permissions | IT administration | All organisations | High | quarterly | 3 | 12 | 30 | Separated | Yes |
| D02 | Approve access requests | Security operations | In-house software development | Medium | every six months | 6 | Mitigated | No | ||
| D03 | Review access rights (periodic access review) | Finance-facing IT | Finance system administered in-house | Low | annually, at the matrix review | 12 | Not yet addressed | |||
| D04 | Administer a system with privileged access | Exception management | Payroll processed in-house | |||||||
| D05 | Review a system's audit logs | Security tools operated in-house | ||||||||
| D06 | Make changes to production systems | Security exceptions process in use | ||||||||
| D07 | Approve changes to production systems | |||||||||
| D08 | Develop or change code | |||||||||
| D09 | Deploy code to production | |||||||||
| D10 | Run and manage backups | |||||||||
| D11 | Test and sign off restores from backup | |||||||||
| D12 | Maintain the IT asset inventory | |||||||||
| D13 | Dispose of IT equipment and storage media | |||||||||
| D14 | Grant privileged access | |||||||||
| D15 | Configure security tools and detection rules | |||||||||
| D16 | Triage and close security alerts | |||||||||
| D17 | Run vulnerability scans and report results | |||||||||
| D18 | Investigate security incidents | |||||||||
| D19 | Create or change suppliers and their bank details in the finance system | |||||||||
| D20 | Approve payments | |||||||||
| D21 | Maintain payroll master data | |||||||||
| D22 | Approve the payroll run | |||||||||
| D23 | Administer the finance system's users and roles | |||||||||
| D24 | Post transactions in the finance system | |||||||||
| D25 | Raise purchase orders for IT goods and services | |||||||||
| D26 | Confirm IT goods or services were received | |||||||||
| D27 | Request a security exception | |||||||||
| D28 | Approve a security exception | |||||||||
| D29 | Assess the risk of a security exception | |||||||||
| D30 | Maintain the security exception register | |||||||||
| D31 | Operate a compensating control | |||||||||
| D32 | Test that a compensating control works |
D33
D34
D35
D36
D37
D38
D39
D40
Yellow cells: add your own duties here; they appear in the grid and the Duty A / Duty B lists.
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Segregation of duties (SoD) | Dividing a task between two or more people so that no one person can both carry out and conceal an error or a wrong act (SD-01). |
| Duty | A task or permission a person holds, such as approving payments or administering a system. A role is usually a bundle of duties. |
| Conflict | Two duties that should not sit with the same person, because together they let that person do something wrong and hide it. |
| Conflict ID | The conflict's stable reference: SOD-IT (IT administration), SOD-SO (security operations), SOD-FI (finance-facing IT), SOD-EM (exception management), then a number. Keep IDs when you tailor the catalogue so reviews and exceptions still point to the right row. |
| Rating — High | One person could make and hide an unauthorised change, payment or access grant with no second person seeing it. |
| Rating — Medium | One person could make an unauthorised change that another control would probably, but not certainly, detect later. |
| Rating — Low | The combination is undesirable but the damage is small or detected quickly by routine checks. |
| Applies where | The kind of organisation in which the conflict can arise. Filter on it to leave out conflicts that cannot happen in yours. |
| Compensating control | A check that reduces the risk when two duties cannot be separated — usually a second person reviewing what the first did, after the event, from evidence the first person cannot change. |
| Separated | The two duties now sit with different people (or accounts), so the conflict no longer exists. |
| Mitigated | The duties still sit with one person, a compensating control is in place, and the arrangement is approved and recorded as an exception (SD-04). |
| Not yet addressed | The conflict applies and nothing has yet been done about it. |
| Who holds both duties | The role, person or supplier who holds both duties. Use a role where you can, so the record stays true when people change jobs. |
| Exception reference | The reference of the approved exception in the Security Exception Register under which a mitigated conflict is accepted. |
| Review frequency | How often a conflict that applies is reviewed, set by its rating (SD-05): High — quarterly; Medium — every six months; Low — annually, at the matrix review. A separated conflict is re-checked at the annual matrix review (SD-02). |
| Review status | Overdue: the next review date has passed. Due soon: due within 30 days (DueSoonDays on the Lists sheet). Not reviewed: no review date yet. Not applicable: the conflict does not apply. |
| Unmitigated SoD conflicts | Known High conflicts with no compensating control recorded and reviewed in the last quarter. Target: zero. One of the pack's four headline metrics. |
| Privileged access | Access that can change a system's configuration, security settings or other users' access, such as an administrator account. |
| Risk owner | The accountable business executive for the service affected by an exception, who accepts its remaining risk. |
| As-at date | The date review statuses are measured against. Set on the Summary sheet; it defaults to today. |
| EX-nn, SD-nn | Requirement numbers in the Security Exception & Waiver Standard: EX for exceptions, SD for segregation of duties. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| EXAMPLE row | A worked example on Our Assessment showing how a completed row looks. Delete before approval. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Conflict Catalogue, Duty Grid, Our Assessment |
| ISO/IEC 27001:2022 | Annex A 5.15 — Access control | Access conflicts (SOD-IT-01 to SOD-IT-03, SOD-SO-01), checking access against the grid (SD-03) |
| NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | Conflict Catalogue, Duty Grid, reviews by rating |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Access control conflicts and their review |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 21(b) — an access control policy with segregation of duties that prevents combinations of access rights able to circumvent controls | Conflict Catalogue, Duty Grid: combinations of access rights that could get round controls |
| DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(g) — ICT security policies specify segregation-of-duties arrangements to avoid conflicts of interest | The workbook as a whole: documented segregation-of-duties arrangements |
| DORA — Regulation (EU) 2022/2554 | Article 6(4) — a control function for ICT risk, independent enough to avoid conflicts of interest, and segregation of ICT risk management, control and internal audit functions | Exception management and incident conflicts (SOD-EM-01 to SOD-EM-05, SOD-SO-04) |
Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774