SoD controls are segregation of duties checks that prevent a single user or role from holding conflicting permissions across sensitive business activities. In SAP migrations, these controls must be rebuilt or validated against the target process design so that risk is assessed in the new environment, not assumed from the old one.
Expanded Definition
Segregation of duties controls, often shortened to SoD controls, are preventive checks that ensure no single person or role can complete a sensitive process end to end without meaningful oversight. The point is not only to split tasks, but to separate compatible and incompatible permissions so that authorisation, approval, execution, and review do not collapse into one account or one business function.
In practice, SoD controls are used in finance, procurement, payroll, access administration, and other high-impact workflows where concentration of power creates fraud, error, or compliance exposure. In SAP environments, the control model is frequently tied to transaction codes, role design, and business process steps, which means a migration can invalidate the old risk picture even when the source system looked clean.
There is a common boundary mistake here: teams sometimes treat SoD as a static report rather than a design property of the target process. That is why reassessment matters after replatforming, redesigning approvals, or changing role structures.
Examples and Use Cases
SoD controls appear wherever the same actor could otherwise initiate, approve, and conceal an action. They are most useful when the business process itself creates the conflict, not just the system role name.
- In procurement, one user can request a supplier, approve the vendor record, and release payment unless the workflow separates those steps.
- In payroll, the same administrator should not be able to create an employee, change bank details, and approve the salary run.
- In SAP migrations, legacy role mappings are often revalidated against the target process so that obsolete combinations do not survive into the new environment.
- In access management, an identity team may need one role for provisioning and another for approval, especially when elevated access is involved.
- In internal controls testing, auditors look for conflicting permission sets that allow a single role to bypass review or create unlogged exceptions.
The tradeoff is operational complexity. Stronger separation usually means more workflow steps, more approvers, and more exceptions to manage, so organisations need a control design that is strict enough to reduce abuse but still workable for day-to-day operations.
Security Implications
When SoD controls are weak or outdated, the result is not only a policy gap but a practical trust failure. A single account with conflicting permissions can approve its own work, hide changes from review, or create transactions that should have been blocked by a second set of eyes. That increases fraud risk, weakens accountability, and makes post-event reconstruction harder because the same role may have touched every stage.
In modern enterprise systems, the failure mode is often subtle: the controls may exist on paper, but the effective permissions in the live environment no longer match the intended process. This is common after mergers, ERP upgrades, role redesign, and cloud migrations. The observable symptoms are recurring exceptions, broad compensating controls, and audit findings that keep reappearing in different business units.
For NHIMG readers, the key practitioner observation is that SoD drift often begins with a legitimate business exception and then becomes normalised. Once that happens, control testing can miss the true blast radius because the issue is embedded in the process, not in one obvious privileged account.
Domain and Governance Relevance
SoD controls sit at the intersection of identity governance, process design, and assurance. In broader cybersecurity terms, they reduce privilege concentration and limit what a compromised account can do without detection. In identity-heavy environments, they also help distinguish who may request, who may approve, and who may execute an action, which is a core governance concern rather than a purely technical one.
When SoD is applied to non-human identities, the same principle still matters, but the conflict surface changes. Service accounts, automation roles, and integrations can concentrate permissions across systems just as easily as human users can, so the control question becomes whether an automated actor can both trigger and authorise sensitive outcomes. That is especially important where machine identities interact with finance, infrastructure, or privileged administration.
For SAP-centric and enterprise workflow environments, SoD is ultimately about whether the target process can prove independence of control after change. If the process design cannot demonstrate that separation, the organisation should treat the control as unproven rather than inherited.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | SoD controls enforce incompatible access separation across sensitive workflows. |
| Recommendation — Review conflicting permissions and remove access combinations that let one role complete sensitive tasks alone. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Management | SoD is a permissions governance control that limits excessive functional authority. |
| GV.RM — Risk Management Strategy | SoD design reflects enterprise decisions about acceptable control conflict and exception risk. | |
| Recommendation — Define and enforce role separation so no single identity can approve and execute the same sensitive action. Treat SoD conflicts as governed risk decisions and document compensating controls for approved exceptions. | ||
| NIST SP 800-63 | 5.1.2 — Binding and Lifecycle Considerations | Lifecycle changes can invalidate role separation when identities or permissions are reassigned. |
| Recommendation — Revalidate access separation whenever identities, roles, or process ownership change. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Non-human identities can accumulate conflicting permissions across automation and approval paths. |
| Recommendation — Inventory machine and service identities that can both initiate and approve sensitive actions. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
