Checklist
SoD Rule Design Checklist
Seven checks for writing Segregation of Duties rules that business owners can actually evaluate and enforce — not just technical entitlement pairs nobody understands.
Download (1 page)SoD rules written directly against technical entitlements are hard for the people who need to own them — business stakeholders — to evaluate. This checklist keeps rule design at a level that stays interpretable and enforceable.
- Rule is defined at the business-function level (e.g. “create payment” vs. “approve payment”), not raw technical entitlements
- A business owner is assigned to define and approve the rule — not IT alone
- The rule is evaluated preventively, at access request time, and detectively, against existing assignments
- Conflicting entitlement pairs are mapped explicitly down to the technical layer for enforcement
- An exception/mitigation process is defined for cases where the conflict is accepted with compensating controls
- Violation aging and escalation thresholds are defined
- The rule is reviewed periodically as roles, applications, and business processes change
See RBAC in Practice: Where Role Models Actually Break Down for the reasoning behind keeping SoD rules at the business-function level.