Segregation of duties is the idea that no single person should control a process end to end. The person who creates a vendor shouldn't also approve payments to that vendor. The person who counts the inventory shouldn't be the one adjusting the counts. It's common sense — and in SAP, it's a formal discipline with its own tooling, because "common sense" doesn't scale to ten thousand users.
What makes a combination "toxic"
A toxic combination is a pair (or trio) of permissions that are each innocent on their own but dangerous together. The textbook example: create/change vendor master (XK01/XK02) plus post invoice (MIRO/FB60) plus execute payment run (F110). One person with all three can invent a fake vendor, post a fake invoice, and pay themselves — with the system happily recording every step as "authorized."
Other classics: create purchase order + goods receipt + invoice verification (the full procure-to-pay chain in one pair of hands), or maintain exchange rates + post journal entries. The pattern is always the same — the ability to both create the thing and approve or settle it.
Note that toxicity lives at the role and user level, not the transaction level. MIRO isn't dangerous. XK01 isn't dangerous. A user holding both is.
Key takeaway: SoD isn't about blocking transactions — it's about making sure no one user holds the complete chain of a sensitive process. Design it out at role level; don't try to police it user by user.
Designing SoD out of your roles
The cheapest place to handle SoD is during role design, before anyone is assigned anything. Map your end-to-end processes — procure-to-pay, order-to-cash, hire-to-retire — and mark the steps that must be split. Then make sure no single role spans a split.
This is where the PFCG role types earn their keep. Build single roles per process step (vendor maintenance, invoice posting, payment execution as three separate roles), and only combine them in composite roles where the business genuinely requires it — with sign-off. When the auditor asks "who can do the whole P2P chain?", the answer should be a short, documented list, not a shrug.
Derived roles help too: the same step-role derived per company code keeps the SoD structure intact while scoping the data. The split is by function; the derivation is by organization. Don't confuse the two.
GRC Access Control: the systematic approach
For larger landscapes, spreadsheets don't cut it, and that's where SAP GRC Access Control comes in. Its core is Access Risk Analysis: you load SAP's (or your own) ruleset of toxic combinations, and it scans every user and role, reporting exactly who holds what risk and at which level (critical, high, medium).
Two concepts do most of the heavy lifting. Mitigating controls are documented compensating measures for risks you accept — "yes, the plant manager holds both, and here's the monthly review that catches misuse." Emergency Access Management (the old "firefighter") gives selected users temporary elevated access for incidents, with every action logged for review. Both exist because the real world sometimes needs exceptions — the point is that exceptions are visible and approved, not invisible.
GRC also watches the provisioning side: when a new role assignment would create a toxic combination, it can block or flag it before it's granted. Prevention beats detection every time.
One more thing worth doing early: run risk analysis on your roles, not just your users. A role that internally contains a toxic combination is a landmine — every user who gets that role inherits the risk silently. Cleaning the roles first means every subsequent user assignment starts from a safe baseline, and your user-level reports stay mercifully short.
The conversation to have with the business
Here's the uncomfortable truth about SoD: the security team can't define it alone. Only the business knows which combinations are actually dangerous in their processes. A toxic combination in a manufacturing company's P2P flow might be irrelevant in a services company — and vice versa.
So the practical move is a workshop, not a tool purchase. Walk through each core process with the process owners, agree on where the splits must be, document the decisions, and then encode them in roles and GRC rules. The tool enforces the policy; the business has to write the policy first.
Done right, SoD is invisible — users get the access their job needs, risks are designed out, and the audit is a non-event. Done wrong, it's either a straitjacket that blocks legitimate work or a fiction nobody enforces. Aim for the first one.