Week 5 of 8
Security roles and segregation of duties
Finance and Operations security is layered: permissions roll up into privileges, privileges into duties, duties into roles, and users get access only through roles. Segregation of duties rules pair two duties that one person should not hold.
Here is the catch. Microsoft states that compliance with SoD rules is not verified when you create a rule; existing roles and user assignments can already conflict. Someone has to run that validation, and testing is the natural owner.
This week: build a role test matrix with negative tests
- List the business roles you will deploy (standard roles you keep, copies you modify, custom roles) and the duties in each.
- For each role, write positive tests (can post a vendor invoice) and negative tests (cannot approve its own payment proposal, cannot see another legal entity).
- Enter your SoD rules, then validate existing roles and user assignments against them. Record every conflict with an owner and a decision.
- Run UAT with production roles, one test user per tester. Never test with the System administrator role.
- Repeat the role tests after every service update; Microsoft can change standard roles.
Number of the week
Not verified
is SoD compliance at the moment you create a rule. Existing roles and user assignments must be checked separately.
Source: Microsoft Learn, Set up segregation of dutiesUse this week
- Dynamics 365 Security Role & SoD Test Matrix →
Positive and negative tests per role, SoD rules with validation status, and Business Central permission set tests.
- Defect Severity & Triage Matrix →
Shared severity definitions, so an SoD conflict is triaged like the control failure it is.
Next week: integrations, dual-write, SIT and UAT. Where go-lives actually break.
Get the playbook in your inbox, one week at a time
Subscribe free and every template in the library is yours.