Auditors rarely find segregation of duties failures by reading policy; they find them by joining your access data to a list of conflicting functions, and most organisations do not have that list written down. This template is that list: a segregation of duties (SoD) ruleset for finance processes, ERP administration and IT administration, with a risk rating and a mitigating control for each conflict. NIST SP 800-53 Rev. 5 control AC-5 asks organisations to identify and document duties of individuals that require separation and to define system access authorisations to support it; this matrix is the documentation that control expects. It is written for identity governance, internal audit, finance systems and ERP security teams. The concepts, preventive and detective approaches are explained in the Segregation of Duties Guide; this page is the working ruleset to adapt.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [ERP system] and [Head of Financial Control], is for your own systems and role titles.
- Define functions before mapping roles: section 3 lists business functions (create supplier, approve payment). Map each function to the technical entitlements in each system (roles, transactions, permission sets, groups) in section 4 before running any analysis. A conflict is defined between functions, not between role names, because role names change and roles bundle many functions.
- Read the codes as: H = high risk (direct path to fraud or misstatement, prevent wherever possible), M = medium (detect and mitigate), L = low (monitor). Ratings in this template are a starting point; your process owners must confirm them.
- Include non-human identities: service accounts, integration users, RPA bots and AI agents that run finance or admin tasks are subject to the same rules. A bot that can both create and approve a payment is a conflict, whoever wrote it.
- Approve and version: the ruleset is owned by [Head of Financial Control] for finance rules and [CISO] for IT rules, approved annually and after any major system change.
1. Purpose and scope
1.1 This ruleset defines the combinations of business functions that no single identity, human or non-human, may hold at [Organisation] without an approved mitigating control.
1.2 It applies to [ERP system], [payroll system], [banking and treasury platform], [identity provider], [cloud platforms] and any system that records, approves or moves financial value or controls access to those systems.
1.3 It supports [Organisation]'s internal control over financial reporting and access control obligations, including NIST SP 800-53 AC-5 Separation of Duties and NIST CSF 2.0 PR.AA-05 (access permissions defined in policy, managed, enforced and reviewed).
2. Roles and ownership
| Role | Responsibility |
|---|---|
| [Head of Financial Control] | Owns finance rules, approves risk ratings and accepts residual risk for finance conflicts |
| [CISO] | Owns IT administration rules and accepts residual risk for IT conflicts |
| Process owners ([AP Manager], [Payroll Manager], [Treasurer]) | Confirm functions and entitlement mapping for their process; perform mitigating control reviews |
| [Identity Governance team] | Maintains the entitlement mapping, runs conflict analysis, enforces preventive checks in the access request process |
| [Internal Audit] | Tests the ruleset, the analysis and the mitigating controls independently |
| System owners | Provide entitlement extracts and implement technical restrictions |
3. Function definitions
3.1 Use these function codes in the matrix. Add rows for processes specific to [Organisation].
| Code | Function | Process |
|---|---|---|
| P1 | Create or change supplier master data (including bank details) | Procure to pay |
| P2 | Create or approve purchase orders | Procure to pay |
| P3 | Record goods receipt | Procure to pay |
| P4 | Enter or post supplier invoices | Procure to pay |
| P5 | Release or approve payments, run the payment proposal | Procure to pay |
| O1 | Create or change customer master data and credit limits | Order to cash |
| O2 | Enter sales orders and issue credit notes | Order to cash |
| O3 | Record cash receipts and apply payments | Order to cash |
| G1 | Create or post manual journal entries | Record to report |
| G2 | Approve manual journal entries | Record to report |
| G3 | Maintain chart of accounts and open or close periods | Record to report |
| H1 | Create or change employee master data and bank details | Payroll |
| H2 | Process or approve payroll runs | Payroll |
| T1 | Initiate bank transfers | Treasury |
| T2 | Approve bank transfers | Treasury |
| T3 | Perform bank reconciliation | Treasury |
| A1 | Create users and assign roles in [ERP system] | ERP administration |
| A2 | Change ERP configuration or develop and transport code to production | ERP administration |
| A3 | Execute business transactions in production | ERP administration |
| I1 | Administer the identity provider or directory (create accounts, assign privileged roles) | IT administration |
| I2 | Approve access requests | IT administration |
| I3 | Administer audit logging or the SIEM (change retention, delete or disable logs) | IT administration |
| I4 | Develop code or infrastructure changes | IT administration |
| I5 | Approve and deploy changes to production | IT administration |
| I6 | Administer secrets stores and key management | IT administration |
4. Entitlement mapping
4.1 For each function, record the technical entitlements that grant it in each system. Keep this table in the identity governance tool as the machine-readable ruleset.
| Function | System | Entitlement (role, transaction, permission set, group) | Owner |
|---|---|---|---|
| P1 | [ERP system] | [supplier master maintenance role or transactions] | [AP Manager] |
| P5 | [banking platform] | [payment approver profile] | [Treasurer] |
| I3 | [SIEM] | [log administration role] | [SOC Manager] |
| [...] | [...] | [...] | [...] |
4.2 Map at the lowest practical level (transaction or permission plus the data scope, such as company code), because a role that looks harmless can include one sensitive permission.
5. Conflict matrix
5.1 No identity may hold both functions in a row unless section 6 records an approved mitigating control.
| ID | Function A | Function B | Risk | Rating |
|---|---|---|---|---|
| SOD-01 | P1 Supplier master | P5 Release payments | Create a fictitious supplier or change bank details, then pay it | H |
| SOD-02 | P1 Supplier master | P4 Post invoices | Create a supplier and invoice it | H |
| SOD-03 | P2 Purchase orders | P3 Goods receipt | Order and confirm receipt of goods never delivered | M |
| SOD-04 | P2 Purchase orders | P5 Release payments | Order from a favoured supplier and pay without challenge | H |
| SOD-05 | P4 Post invoices | P5 Release payments | Post and pay a false or duplicate invoice | H |
| SOD-06 | O1 Customer master and credit | O2 Sales orders and credit notes | Raise credit limits and ship or credit without approval | M |
| SOD-07 | O2 Credit notes | O3 Cash receipts | Divert a customer payment and hide it with a credit note | H |
| SOD-08 | G1 Post journals | G2 Approve journals | Post and approve own manual journal to misstate results | H |
| SOD-09 | G1 Post journals | G3 Periods and chart of accounts | Reopen a closed period and post unreviewed entries | M |
| SOD-10 | H1 Employee master | H2 Payroll runs | Create a ghost employee or change bank details and pay | H |
| SOD-11 | T1 Initiate transfers | T2 Approve transfers | Move funds without a second person | H |
| SOD-12 | T1 or T2 Transfers | T3 Bank reconciliation | Conceal an unauthorised transfer in the reconciliation | H |
| SOD-13 | A1 ERP user administration | A3 Business transactions | Grant self any finance function and use it | H |
| SOD-14 | A2 ERP configuration or transports | A3 Business transactions | Change tolerances or code, then transact under the changed rules | H |
| SOD-15 | I1 Identity administration | I2 Approve access | Request, approve and provision own privileged access | H |
| SOD-16 | I1 Identity administration or any privileged admin | I3 Audit log administration | Act and erase the evidence; NIST AC-5 guidance names this split explicitly | H |
| SOD-17 | I4 Develop changes | I5 Approve and deploy to production | Deploy unreviewed code or infrastructure changes | H |
| SOD-18 | I6 Secrets and keys administration | A3 or T1 Business or payment transactions | Retrieve integration credentials and act as a service account | M |
| SOD-19 | Any finance function | Ownership of the integration or bot that performs the same function | Change the automation to perform the other half of a conflict | M |
5.2 Conflicts are evaluated across systems. A user with P1 in [ERP system] and P5 in [banking platform] breaches SOD-01 even though no single system shows both.
6. Mitigating controls
6.1 Where a conflict cannot be removed, for example in a small team, record one or more of these controls in the exceptions register with the reviewer, frequency and evidence.
| Control | Applies to | Frequency | Evidence |
|---|---|---|---|
| Independent review of supplier master changes, especially bank details, with call-back to a known contact | SOD-01, SOD-02 | Each change or weekly | Change report signed by [Finance Controller] |
| Review of payments to new or recently changed suppliers before release | SOD-01, SOD-04, SOD-05 | Each payment run | Approved payment run report |
| Duplicate invoice and three-way match exception report | SOD-03, SOD-05 | Weekly | Exception report with resolution notes |
| Manual journal review above [threshold] by an independent approver | SOD-08, SOD-09 | Monthly close | Journal listing with approver sign-off |
| Payroll variance and new joiner report reviewed by HR | SOD-10 | Each payroll run | Signed variance report |
| Dual authorisation enforced in the banking platform | SOD-11 | Continuous (system enforced) | Platform configuration export |
| Emergency or firefighter access with time limit and post-use log review | SOD-13, SOD-14, SOD-15 | Each use | Session log and reviewer sign-off within [2] working days |
| Audit logs forwarded to a store the administrator cannot alter | SOD-16 | Continuous | Log pipeline configuration; NIST AU-9 |
| Change approval by a second person enforced in the pipeline | SOD-17 | Each change | Pipeline approval records; NIST CM-5 |
6.2 Every exception records: identity, conflict ID, business reason, mitigating control, reviewer, start date and an expiry no later than [12] months.
7. Enforcement and review
7.1 Preventive: the access request process checks requests against this ruleset and blocks or routes high-risk conflicts to [Head of Financial Control] or [CISO]. Identity governance tools support this; for example, Microsoft Entra entitlement management lets an access package list incompatible access packages and incompatible groups, and blocks requests from users who already hold them.
7.2 Detective: run a full conflict analysis across all in-scope systems at least [quarterly] and after any role redesign, and include the results in user access reviews (NIST AC-6(7) Review of User Privileges).
7.3 Violations without an approved exception are remediated within [30] days for H and [60] days for M ratings.
Implementation guidance
- Start with high-risk rules in one process. Procure to pay usually has the most direct fraud paths (SOD-01, SOD-04, SOD-05). Agree the functions and entitlement mapping with the process owner before expanding.
- Extract entitlements, not role names. Pull user-to-permission data from each system, including service accounts and integration users, and resolve nested roles and groups.
- Run the first analysis in report-only mode. Expect a large number of hits; most come from a few over-broad roles. Fix the roles before chasing individual users.
- Triage with process owners. For each remaining conflict decide: remove access, redesign the role, or accept with a mitigating control from section 6.
- Turn on preventive checks in the access request process for H rules once the backlog is manageable, with an escalation path rather than a hard block for urgent business cases.
- Test before audit. Ask internal audit to sample conflicts and mitigating control evidence before the external auditor does.
- Roll back safely: if a preventive rule blocks critical work, switch that rule to detect and approve for a defined period rather than deleting it, and record the decision.
Common failure patterns
- Single-system analysis: conflicts that span the ERP and the banking platform are never seen.
- Bots and service accounts excluded: an integration user holds supplier maintenance and payment release because "it is only a system account". See the NHI Ownership Guide.
- Firefighter access without review: emergency access is logged but nobody reads the logs.
- Permanent exceptions: mitigations approved once and never re-tested or expired.
- IT administrators out of scope: finance rules are enforced while directory and log administrators hold every IT conflict in the matrix.
Measuring whether it works
- Open H conflicts without an approved exception (target zero).
- Exceptions past expiry or without current mitigating control evidence.
- Blocked requests at the preventive check, as a sign the rules are live.
- Time to remediate new conflicts after a role change.
- Non-human identity coverage: share of service accounts and bots in scope that are included in the analysis.
Small vs large organisations: a small finance team cannot separate every function, so it relies on section 6 controls, especially independent review of supplier changes and payment runs, and dual authorisation in the bank. A large organisation should enforce H rules preventively in the identity governance tool and treat exceptions as rare. See the SOX IT General Controls (ITGC) Guide for how auditors test these controls, and the RBAC Role Matrix Template for designing roles that avoid conflicts in the first place.
Standards and references
- NIST: SP 800-53 Rev. 5 (AC-5 Separation of Duties, AC-6(7), AU-9, CM-5)
- NIST: Cybersecurity Framework 2.0
- PCAOB: AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
- ISACA Journal: Implementing Segregation of Duties: A Practical Experience Based on Best Practices
- Microsoft Learn: Configure separation of duties checks for an access package in entitlement management
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Segregation of Duties Guide · Identity Governance Maturity Model · AI Agents and SOX Controls · Security RACI Matrix Template