One of the most common control problems in a growing organisation is also one of the easiest to miss. A trusted employee can create a record, approve a change, process the outcome, and tidy up the audit trail afterwards because the system was configured for convenience rather than control. In HR, that might mean changing employee details and pushing payroll changes through without a second review. In Dynamics 365, it might mean the same user can create a supplier, approve a transaction, and post it.
That's where segregation of duties, usually shortened to SoD, matters. If you've searched for what is segregation of duties, the simple answer is this: it's the practice of separating key steps in a process so one person can't control the entire transaction from start to finish.
For UK organisations using Microsoft 365, Dynamics 365, Dataverse, Power Automate, and Entra ID, this isn't just a finance topic. It affects HR master data, joiner-mover-leaver processes, payroll controls, security roles, app deployment, approvals, and audit readiness. The principle is old. The implementation problem is very modern.
An Introduction to Segregation of Duties
A familiar failure starts with a sensible shortcut. An HR administrator needs to correct a starter record quickly, the payroll deadline is close, and the same person already has the access needed to approve the change and complete it. The process gets faster. The control disappears.
Segregation of duties, usually shortened to SoD, is the practice of splitting key steps in a process so one person cannot initiate, approve, complete, and conceal the same action. The aim is straightforward. Reduce the chance of error, prevent abuse, and make independent checking possible.
In practice, SoD protects routine processes that often look harmless until something goes wrong. A user submits an expense and approves it. An HR officer creates or amends employee data and pushes through a pay-affecting change. An IT administrator assigns privileged access, signs off the request, and reviews the outcome in the same Microsoft environment. Each case leaves too much control with one account or one team.
For UK mid-market organisations, this is rarely a theory problem. It is a configuration problem. Lean teams often need broad access to keep HR, finance, and IT moving, especially across Dynamics 365, Dataverse, Power Automate, and Entra ID. The trade-off is real. Convenience speeds up operations, but it also weakens auditability and increases the chance that a bad change reaches payroll, reporting, or security before anyone spots it.
Practical rule: If one user can create, approve, and hide the same action, the process depends on trust rather than control.
That is why SoD sits at the centre of many control reviews and system redesigns. It also explains why organisations assessing software and controls together often compare leading governance risk compliance tools alongside their Microsoft setup. The principle is simple. Applying it properly in a live Dynamics 365 and Power Platform estate takes careful role design, workable approvals, and a clear view of where one person has too much reach.
The Four Pillars of Effective Internal Control
A control framework stands or falls on one question. Can one person complete a whole transaction or change from start to finish without meaningful challenge?
If the answer is yes, the process is weak, whatever the policy says on paper. In a UK mid-market business running HR and operational processes through Dynamics 365 and the Power Platform, that weakness usually appears in role design, approval routing, and audit evidence rather than in a formal control document.
Authorisation and recording
Authorisation is the approval decision. It answers whether the action should happen at all. In practice, that could be approving a salary change, a new starter, a supplier record, an access request, or an exception to standard process.
Recording is the system action. It answers who enters, updates, or posts the approved change. In Microsoft terms, that might be a user updating Dataverse records, submitting a change through a model-driven app, or posting a transaction into Dynamics 365.
These are often combined in smaller teams because it is faster. That speed comes at a cost. If the same user can approve and record a pay-related amendment, there is very little to stop an error, or a deliberate change, from passing straight into downstream reporting or payroll.
Custody and review
Custody is control over the asset, the data, or the access that matters. In HR and IT environments, that usually means sensitive employee records, approval queues, payroll-impacting data, security roles, service accounts, or privileged admin rights.
Review is the independent check after the event or at a defined control point. It confirms that the change was valid, supported, and correctly processed. In a Microsoft estate, that review may rely on approval history, audit logs, reconciliation reports, and exception reporting. It also needs retention and access controls that support broader obligations such as a GDPR compliance checklist for HR systems and data handling.
Some organisations split this model further into five control types by separating verification from managerial review. The principle stays the same. Overlapping control points should not sit with the same person or role.
| Pillar | What it means in practice | Common risk if combined |
|---|---|---|
| Authorisation | Approving the action | Self-approved transactions or changes |
| Recording | Entering or changing data | Records can be altered without proper challenge |
| Custody | Controlling the asset, data, or access | Unchecked handling of money, data, or permissions |
| Review | Independently checking accuracy and evidence | Errors or misuse stay unnoticed |
In live systems, the hard part is not naming the pillars. It is assigning them sensibly when the HR team has six people, IT has two admins, and everyone wants the process done by close of business. That is why role design, workflow approvals, break-glass access, and review evidence need to be considered together. Teams that need a broader governance view often compare their controls against leading governance risk compliance tools so they can assess policy, access review, evidence, and exception handling as one operating model rather than treating SoD as a checkbox.
Separation works when each stage answers a separate control question. Who approved it, who entered it, who held the access or data, and who checked the result?
Why SoD Matters for Compliance and Accuracy
The mistake I see most often is treating segregation of duties as a fraud-only issue. Fraud matters, obviously, but weak SoD causes operational damage long before anyone uses the word misconduct.
It reduces more than malicious risk
PwC's Global Economic Crime and Fraud Survey 2024 reports that 46% of organisations experienced economic crime in the previous 24 months, and the survey identifies internal control weaknesses as a recurring contributor (background reference to separation of duties and fraud risk). That matters because weak SoD creates exactly the sort of condition where misuse can sit unnoticed.
But the day-to-day benefit is often simpler. Separate duties and you catch more ordinary mistakes:
- Approval mistakes get spotted before payment or posting.
- Data-entry errors are more likely to be picked up during review.
- HR changes are less likely to slip through without a manager noticing.
- Access changes are easier to challenge when the requester and approver are not the same person.
It improves auditability and trust in data
Auditors rarely struggle because there's no policy. They struggle because the process in the system doesn't match the policy on paper.
If your organisation uses Microsoft 365 and Dynamics 365 heavily, accurate records depend on role separation, approval evidence, and traceable changes. That's particularly important when HR and IT are handling personal data, access rights, retention rules, and employee lifecycle actions together. A useful companion read for that wider control picture is this 2026 financial compliance essentials guide, especially if your team is aligning operational controls with broader compliance expectations.
For HR and people data, SoD also supports privacy governance because it limits who can change records, approve exceptions, and view sensitive information. That works alongside a practical GDPR compliance checklist for Microsoft-focused organisations, where access control and evidence of review matter as much as policy wording.
It keeps processes reliable under pressure
When the month-end rush hits, when payroll deadlines are tight, or when the business is onboarding at pace, weak controls tend to get bypassed first. Strong SoD doesn't stop work. It gives teams a way to keep moving without relying on memory and goodwill.
Key judgement: If a process only works when everyone behaves perfectly, it isn't controlled well enough.
Common SoD Conflicts in HR and Dynamics 365
Most definitions of segregation of duties still describe finance examples. Those are valid, but they're no longer the whole story. In a Microsoft estate, some of the most serious SoD failures sit in HR systems, identity tools, and approval workflows.
Microsoft's footprint matters here. With more than 4 million users of Microsoft 365 in the UK, access governance in cloud systems is no longer a niche issue (Ping Identity discussion of segregation of duties and modern identity risk). If one person can create users, assign roles, and approve changes in the same admin path, the control weakness is obvious.
HR conflicts that look harmless until they aren't
These are the combinations I'd treat as immediate review items in a mid-market environment:
- Create and pay. An HR or payroll user creates a worker record, updates bank details or salary-related fields, and also processes or releases payroll.
- Change and reconcile. The same person amends payroll-impacting data and then performs the reconciliation that should detect errors.
- Request and approve. A line manager raises a request, expense, or employment change and can also approve it through the same workflow path.
None of those combinations requires malicious intent to create a problem. A rushed correction, a misunderstood process, or a copied permission set can do enough damage.
Dynamics 365 and Power Platform conflicts
In Dataverse and Dynamics 365, SoD issues often come from accumulated security roles rather than one obviously dangerous permission. A user starts in operations, takes on admin duties during a project, then keeps both sets of access permanently.
Common toxic combinations include:
| Conflict | Why it matters in practice |
|---|---|
| Create supplier and approve payment | Master data manipulation can feed directly into payment approval |
| Submit expense and approve expense | The workflow has no independent challenge |
| Build app and deploy to production | Changes go live without independent review |
| Assign security roles and approve access | Privilege escalation can happen quietly |
| Amend employee data and approve related action | HR master data becomes a control bypass |
The hidden problem is usually identity
A lot of teams look for SoD conflicts only inside ERP transactions. That's too narrow. In modern Microsoft environments, identity is often the first control point.
If an administrator can create an account, assign a privileged role, and confirm the request in the same process, they may never need to touch a financial transaction directly to create risk. They can change who has power inside the system.
The modern SoD question isn't only “who can pay?”. It's also “who can grant the access that allows payment, record changes, or silent approvals?”
This is why HR, IT, and compliance need to review the same process map together rather than treating employee data, application security, and operational approval paths as separate worlds.
Practical SoD Implementation in the Microsoft Ecosystem
Knowing the theory doesn't fix the role design. Implementation does. In Microsoft environments, effective SoD usually comes from a combination of role structure, approval design, environment management, and compensating controls.
Start with roles, not job titles
A job title is not a security model. “HR Manager” or “Finance Administrator” often covers too much. In Dynamics 365 and Dataverse, roles need to reflect what a user can create, amend, approve, delete, and export.
A practical approach is to map permissions by action:
- Initiate a request or record
- Approve the action
- Process the outcome
- Review the result
- Administer the system or role assignment
Those actions shouldn't automatically sit with the same person. If your team needs a deeper grounding in access design, this guide on role-based access control in Microsoft environments is a useful place to start.
Use the Microsoft stack properly
Strong SoD in the Microsoft ecosystem usually relies on several controls working together:
- Dynamics 365 and Dataverse security roles to limit create, write, approve, and admin rights.
- Power Automate approvals to force a second step for high-risk actions.
- Microsoft Entra ID governance to control privileged access, role assignment, and review cycles.
- Environment separation so development, test, and production aren't blurred together.
- Audit history and reporting so changes can be reviewed after the fact.
What doesn't work is relying on a written policy while giving broad System Administrator rights because it's quicker during implementation.
When true separation isn't possible
Many generic articles often lose their practical value at this stage. Smaller teams cannot always perfectly separate every duty.
The practical question is what to do when one employee must handle multiple functions. That matters because the UK government estimated £2.3 billion in fraud losses annually, which is why practical compensating controls matter in real operations, not just textbook models (TechTarget overview of segregation of duties and compensating controls).
If you can't split the task fully, use compensating controls such as:
- Manager review for all exceptions, amendments, and sensitive changes.
- Workflow approvals that route to a different person or team.
- Enhanced audit logging on payroll-impacting, identity, and finance-related actions.
- Periodic access recertification so temporary access doesn't become permanent.
- Exception registers so departures from standard SoD are visible and time-bound.
What works: documented exceptions with named approvers, expiry dates, and review evidence.
What doesn't: “Jane has access because she's always done it.”
Monitoring Testing and Continuous Improvement
Segregation of duties isn't a one-off project. It drifts. Staff move roles, temporary access gets forgotten, project teams keep higher permissions, and emergency fixes become permanent.
The public-sector style approach reflected in institutional governance treats SoD as part of a continuous framework rather than a policy written once and filed away. It also makes ongoing review essential, especially where minimum separation rules are used because the team is small (continuous governance approach to segregation of duties).
What to test regularly
A sensible review cycle should look at both access and activity. One without the other leaves gaps.
Focus on:
- Access reviews to confirm users still need the roles they hold.
- Toxic combination analysis to identify conflicting permissions gathered over time.
- Approval-path testing to verify workflows still route to independent reviewers.
- Audit-log review for changes to key records, security roles, and sensitive fields.
For teams building a more structured review programme, this IT Cloud Global guide to IT audits is a useful reference point because it helps connect technical evidence, review discipline, and control assurance.
What good monitoring looks like
Good monitoring is specific. You're not looking for “suspicious activity” in the abstract. You're looking for patterns such as:
| Monitor | Why it matters |
|---|---|
| Changes to payroll-impacting fields | Detects unauthorised or unreviewed employee amendments |
| Security role changes | Shows privilege escalation and admin drift |
| Self-approval attempts | Exposes broken workflow logic |
| Out-of-hours privileged actions | Highlights activity that needs contextual review |
Keep exceptions under control
Every mid-market organisation has exceptions. The problem isn't the existence of exceptions. It's when they become invisible.
A workable rule is to insist that every SoD exception has an owner, a reason, a review date, and evidence of oversight. If your team can't answer those four points quickly, the exception is already a control weakness.
Ongoing SoD management is less about writing more policy and more about checking whether real permissions, workflows, and reviews still match the way the business operates.
Building Your Secure HR Framework with DynamicsHub
Segregation of duties is ultimately about trust built into the process, not trust placed entirely in individuals. When roles, approvals, and reviews are designed properly, your organisation is better protected against fraud, error, poor data quality, and awkward audit findings.
That matters even more in HR, where the same platform often holds employee records, approvals, compliance evidence, and sensitive personal data. Security design needs to sit alongside process design. That's also why data protection by design belongs in the same conversation as SoD, especially when HR and IT are managing lifecycle actions in shared Microsoft systems. This broader principle is explored further in this guide to data protection by design in Microsoft-based HR environments.
DynamicsHub.co.uk works with UK organisations that want HR transformation built around their business. Hubdrive's HR Management for Microsoft Dynamics 365 is the premier hire-to-retire solution, more powerful, more flexible, and more future-ready than Microsoft Dynamics 365 HR. It supports strong, configurable security controls inside the Microsoft ecosystem so organisations can enforce sensible separation of duties without creating unnecessary friction.
If you're reviewing HR controls, redesigning approval workflows, or tightening access across Dynamics 365, Dataverse, Power Platform, and Entra ID, getting the control model right at the start saves a lot of rework later.
DynamicsHub helps UK organisations design secure, practical HR and business process controls in Microsoft environments. Experience HR transformation built around your business. If you'd like help reviewing segregation of duties, implementing Hubdrive's HR Management for Microsoft Dynamics 365, or improving compliance across HR and IT workflows, call 01522 508096 today or send us a message through DynamicsHub.
