Separation of duties in access reviews: a short lesson
ILM Reference editors · Published 2026-04-14 · 3 minute read
TRACK: CONTROLS AND STANDARDS · LESSON 7 OF 11
Separation of duties (SoD) means one person should not hold two permissions that together let them misuse a system on their own, such as creating a supplier and approving its payment. In lifecycle terms, conflicts appear at three moments: when access is requested, when someone moves role, and when a review finds access nobody removed. A rule set of conflicting pairs, checked at all three, is the practical control.
What is separation of duties?
NIST's glossary describes separation of duty as the principle that no user should be given enough privileges to misuse the system on their own. The classic example is financial: the person who creates a vendor should not also approve payments to it. The same idea applies to IT administration, where the person who grants access should not be the only one who reviews it.
How do you define conflicts?
Start with a short list of conflicting pairs for the systems in audit scope. Each rule names two entitlements, or two roles, that one person should not hold at the same time, the business reason, and the owner who can approve an exception.
| Entitlement A | Entitlement B | Why it conflicts |
|---|---|---|
| Create or edit vendors | Approve payments | One person could create a vendor and pay it |
| Grant access in an application | Certify access in the same application | One person could grant access and approve it in review |
| Deploy code to production | Approve production changes | One person could make and approve an unreviewed change |
Keep the rule set small and specific at first. A long generic list produces many exceptions that nobody reads.
Where should conflicts be checked?
- At request. When someone asks for access, check it against what they already hold. Microsoft Entra ID Governance describes separation-of-duties checks in entitlement management; other governance platforms describe similar policy checks.
- At role change. Movers are the most common source of conflicts, because they gain the new role's access before the old access is removed. See the mover drift lesson.
- In reviews. Flag conflicting pairs in the certification campaign so the reviewer sees them as exceptions, not as two separate lines that each look reasonable.
What about disconnected applications?
A conflict check can only see the entitlements the governance platform knows about. If one side of a pair lives in a disconnected application, for example a local admin role in a legacy finance system, the check passes when it should fail. Loading those applications' accounts and roles into the review, or discovering them with a tool that maps roles inside applications, closes that gap. See disconnected applications.
What evidence do auditors look for?
- The written rule set, with owners and the date it was last reviewed.
- Each exception, who approved it, why, and when it expires.
- Review results showing that flagged conflicts were resolved or accepted.
Sources
Reviewed Sep 2026
Next lesson: Application inventory
You cannot deprovision from an application you do not know exists.