Start by mapping business processes, identifying incompatible duties, and then tailoring roles to the organisation’s hierarchy and approval flow. Use compensating controls where full segregation is not possible. Native ERP controls help, but they should be backed by access governance rules, automated workflows, and regular review so access design reflects how work actually gets done.
How to design segregation of duties around real Dynamics 365 workflows
In Dynamics 365, segregation of duties works best when it follows the way finance tasks actually move through the system, not when it is imposed as a rigid list of isolated roles. The practical goal is to separate initiation, approval, posting, and reconciliation in a way that fits the organisation’s hierarchy, while preserving the business steps needed for close, payables, receivables, and reporting.
That usually means mapping end-to-end processes first, then identifying combinations of duties that create unacceptable self-approval or self-posting risk. Once those conflicts are known, role design can be tuned to the transaction path, the approval chain, and the exceptions that finance genuinely needs to handle. A role model that ignores process flow usually creates either control gaps or operational workarounds.
One useful way to think about this is to treat SoD as a process design problem before it becomes a permissions problem. If the organisation starts with the chart of accounts, posting profiles, and menu items, it can miss the real issue, which is whether the same person can create, approve, and finalise an outcome without independent review. Lifecycle discipline matters here because access design is only stable when provisioning, review, and removal follow the same business logic as the process itself.
Where finance controls usually break down, and how to keep the business moving
The hardest cases are usually not the standard-path transactions, but the exceptions: urgent payments, month-end journal postings, master-data updates, and users who need temporary escalation to keep operations moving. If those exceptions are not designed explicitly, finance teams will create informal workarounds, such as shared approvals, overbroad roles, or permanent elevated access that quietly defeats the control.
The common failure mode is to make SoD so strict that it blocks legitimate close or approval activity, then allow ad hoc overrides when pressure builds. That creates a control that looks strong on paper but is weak in practice. A better pattern is to use compensating controls for the few conflicts that cannot be removed cleanly, such as independent review, post-transaction monitoring, or time-bound exception approval. Compensating controls should be narrow, documented, and reviewed often enough that exceptions do not become a second access model.
Finance role design also benefits from clear ownership of business exceptions. Where a person needs the ability to perform more than one sensitive step, the question is not only whether the permission exists, but whether someone else can see, challenge, and evidence the action after the fact. That is especially important for privileged admin functions and troubleshooting access, where operational convenience can drift into standing privilege if review is weak.
For broader control design, practitioners often anchor the model in ISO/IEC 27002:2022 Information Security Controls and then translate those expectations into ERP-specific roles, approval paths, and monitoring. If the control cannot be explained in business terms, it will be difficult to sustain during close cycles, audits, or staffing changes.
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 technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Dynamics 365 SoD depends on controlling who can perform sensitive finance actions. |
| 5 — Account Management | Role tailoring, temporary access and revocation are central to keeping finance duties separated. | |
| Recommendation — Restrict finance permissions to the minimum needed and review conflicting access regularly. Provision and revoke ERP access through governed account processes with timely approval. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Managed | The question centers on separating incompatible duties through managed permissions and approvals. |
| PR.PT-3 — Least Functionality | Finance roles should expose only the functions needed for each job path. | |
| Recommendation — Enforce least privilege so users cannot initiate, approve and post the same finance transaction. Limit Dynamics 365 roles to the functions required for each finance process step. | ||
| ISO/IEC 42001:2023 | 8.2 — AI System Impact Assessment | No material AI governance issue is present in this ERP SoD question. |
| Recommendation — Omit this mapping. | ||
Practitioner Guidance
What to prioritise: Build the SoD model around the highest-risk finance paths first, usually vendor setup, payment execution, journal posting, and master-data changes. Those are the areas where a single conflicting role can produce direct financial misstatement or unauthorised payment risk.
What to verify: Test whether each sensitive workflow still has an independent second set of eyes at the actual decision point, not just in the role catalogue. Verify that emergency access, approval overrides, and temporary role changes are time-bound, attributable, and reviewed after use.
Common mistake: Treating role minimisation as success even when it causes operational bypasses. In Dynamics 365, a “clean” role design that finance teams cannot use safely will usually be bypassed with shared access, manual workarounds, or standing exceptions that are worse than the original conflict.
Practitioner takeaway: The right SoD model is the one finance can execute repeatedly under pressure, because durable controls in Dynamics 365 depend on process realism as much as permission separation.
Related resources from NHI Mgmt Group
- How should organisations implement segregation of duties without slowing down core business workflows?
- How should security teams implement file sharing controls in Microsoft 365 without breaking collaboration?
- How should organisations implement segregation of duties in hybrid environments?
- How should organisations implement Zero Trust without breaking existing access workflows?
