Organisations should use separate matrices when business models, transaction flows, or risk exposures differ enough that one generic control model would miss real conflicts. A manufacturing unit with inventory transactions faces different SoD risks from a services unit focused on project accounting. The matrix should be tailored to the location, process, and business unit so it captures the conflicts that matter most.
Why separate SoD matrices become necessary
Separate segregation of duties matrices are warranted when the same control pattern no longer describes the real conflict landscape. Different business units often use different systems, approval chains, transaction types, and exception paths, so a single matrix can look consistent on paper while missing the combinations that actually create fraud, error, or override risk.
The practical test is whether one unit’s roles, workflows, or access paths create materially different duty conflicts from another’s. If the answer is yes, then SoD should be modeled at the level where decisions, postings, and approvals really happen, not at a generic enterprise headline level.
That usually means separating matrices by business unit, location, or process family when those dimensions change how a conflict appears. A role that is harmless in one unit may be toxic in another because the underlying transaction sequence is different, even if the job titles look similar.
Where the control model is too broad, organisations tend to overstate coverage. A generic matrix can satisfy a governance checklist while failing to catch unit-specific combinations such as setup plus approval, vendor creation plus payment release, or journal entry plus reconciliation in a process that only exists in one part of the business.
What should drive the split
The strongest reasons to split matrices are differences in business model, transaction flow, system design, and risk exposure. If two units run distinct operating models, the conflicts worth preventing will also differ, because the same permission can produce very different outcomes depending on how the unit books revenue, handles inventory, manages projects, or settles transactions.
Location can matter as much as function. Regional entities often have different legal entities, approval hierarchies, and local system permissions, so the same access bundle may create a real SoD issue in one jurisdiction and no meaningful issue in another.
Different transaction types: inventory, payroll, procurement, project accounting, and treasury each generate different conflict pairs.
Different systems or modules: ERP, CRM, and local tooling often expose different duty combinations.
Different control tolerance: a unit with higher fraud exposure or tighter regulatory obligations usually needs a more specific model.
Different exception handling: manual overrides, emergency access, and local workarounds often create the real conflict.
When those differences are material, a tailored matrix is not duplication, it is the only way to make the control meaningful. A unit-specific matrix also gives reviewers a clearer way to certify access because they are validating the actual workflow, not a generic abstraction.
Risk and Threat Considerations
When organisations force one SoD matrix across materially different business units, the common failure is false assurance. Conflicts can be hidden inside unit-specific processes, especially where approvals are embedded in ERP roles, local super-user access, or compensating controls that exist only in one operating model.
Failure mechanism: the control model is too coarse to reflect the real combination of setup, approval, execution, and review rights in a specific unit, so conflicting access is approved, tolerated, or never detected during recertification.
Impact: the organisation can miss fraud paths, erroneous postings, unauthorized overrides, and audit findings, while believing the SoD program is stronger than it really is.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Separate SoD matrices support least-privilege access decisions by business process. |
| 8 — Audit Log Management | Unit-specific SoD depends on logging the conflicting actions that matter in each process flow. | |
| Recommendation — Apply Control 6 to align entitlements with the specific duties and approvals of each business unit. Use Control 8 to log the actions needed to detect conflicting role combinations and overrides. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | SoD matrices are an access-control governance mechanism that depends on accurate role and entitlement design. |
| Recommendation — Define access rules by business unit so role assignment matches the actual duties being performed. | ||
Practitioner Guidance
What to verify: confirm whether each business unit has distinct transaction classes, approval paths, and system entitlements before deciding that one matrix is enough. If the conflict pairs are not identical in practice, the matrix should not be identical either.
Decision rule: if a unit uses different posting, approval, or exception workflows, build a separate matrix for that unit or process family and review it against actual role assignments, not job descriptions alone.
What good looks like: the matrix maps to real duties that operators and auditors can recognize immediately, and exceptions are explainable in the context of the unit’s own workflow rather than by reference to a generic enterprise model.
Practitioner takeaway: the right level of SoD design is the level where conflicts become operationally real; if business-unit differences change how transactions are initiated, approved, or overridden, the matrix should change with them.
Related resources from NHI Mgmt Group
- Why do segregation of duties controls matter when organisations manage privileged business processes?
- What do organisations get wrong when deploying qualified electronic signatures across different business units?
- How should organisations implement segregation of duties without slowing down core business workflows?
- How should organisations implement zero trust when IT, cybersecurity, and business units all own different parts of the environment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
