Segregation of Duties by Design, Not by Detection
Most SAP programs detect SoD conflicts after roles go live. Designing them out during role build is cheaper, cleaner, and audit-ready. Here is the shift.
An auditor points at a report. One user can post a payment and approve it. The finding is real, the access is live, and now a team has to unpick production role assignments while the audit clock runs. Everyone in the room knows the uncomfortable truth: this conflict was created months ago, in a spreadsheet, and nobody caught it until it was already a problem.
There is a better moment to catch it, and it is long before that report. This post is about moving segregation of duties from detection to design.
The Short Answer
Segregation of duties by design means preventing conflicting-duty combinations while roles are being built, rather than detecting them after roles are live. A rules-based engine splits incompatible access types, such as posting and approving, during role design. It is cheaper than remediation, cleaner for audit, and it stops toxic combinations before anyone holds them.
Detection is the industry default, and it is late
Most SAP SoD programs run on detection. Roles get designed, roles go live, and a governance tool periodically scans for violations. The scan produces a report, the report produces a remediation project, and the remediation project unpicks access that people are already using. It works, in the sense that conflicts eventually get found. It is expensive, and always a step behind.
The cost is not only money. A detected conflict means the toxic combination existed in production for however long it took to find it, which is exactly the window an auditor or an attacker cares about. Detection answers what went wrong. It cannot answer why it was allowed to happen.
Detection finds the conflict after someone already had it; design ensures no one ever did.
What does prevention require?
Preventing SoD conflicts during design needs three things working together, and they are mechanical, not magical:
- A vocabulary of access types. Each task classified as Display, Park, Post, Maintain, Reverse, Close, Approve, or Execute, so the engine reasons about duties, not just transaction codes.
- A compatibility matrix. Explicit rules for which access types may sit together and which may not. This is your SoD policy expressed as logic the engine enforces.
- An automatic split. When a group would combine conflicting duties, the engine separates it into compliant roles before the role is built, every time, without relying on a designer to notice.
Prevention is your SoD policy written as rules the engine cannot skip.
Prevent versus detect, side by side
| Dimension | Detection (after go-live) | Design (during build) |
|---|---|---|
| When the conflict is caught | After roles are live, in a periodic scan | Before the role is ever built |
| Production exposure | Exists until the next scan finds it | Never enters production |
| Cost to fix | Remediation project on live access | A split during design, at no extra step |
| Audit story | We find and fix violations | We prevent violations by design |
| Who has to notice | Analysts reading a report | The engine, on every role, automatically |
Detection still has a place. Estates change, mergers bring messy access, and periodic scanning catches drift. The point is not to abandon detection; it is to stop relying on it for conflicts you could have designed out in the first place.
Keep detection for drift; use design for everything you can prevent.
Prevent vs Detect: the 5-point checklist
- Are access types classified before roles are grouped?
- Does a compatibility matrix define which duties may coexist?
- Are conflicting groups split automatically during design?
- Is detection reserved for drift, not first-line defense?
- Can you show an auditor prevention, not just remediation?
Mistakes that keep you in detection mode
- Treating the GRC scan as the control. A scan is a smoke detector. It is essential, and it is not the same as not starting fires.
- Keeping the SoD policy in people's heads. If the rules live in expertise rather than a matrix, prevention depends on who is in the room that day.
- Designing roles fast, then remediating forever. Time saved skipping prevention in design is borrowed from every future remediation cycle, at a worse rate.
Frequently asked questions
What is segregation of duties in SAP?
A control that keeps conflicting responsibilities apart, so no single person can complete a sensitive process alone, for example both posting and approving a payment. In SAP it is enforced through role design and authorization structure, and it is a core focus of SOX and financial-controls audits.
What is SoD by design?
Preventing conflicting-duty combinations while roles are being designed, rather than detecting them afterward. A rules engine classifies access types and uses a compatibility matrix to split incompatible duties before a role is built, so toxic combinations never reach production in the first place.
Does SoD by design replace GRC tools?
No, it complements them. Design-time prevention stops conflicts you can foresee; detective scanning still catches drift from changes, mergers, and manual grants. The strongest programs prevent what they can during design and detect the rest continuously.
How Anugal solves it
Preventing SoD conflicts in design is exactly what Anugal's Role Build Agent does, as a built-in step, not an add-on.
THE ANUGAL ROLE BUILD AGENT
- Duties, not just transactions. Every task is classified into one of eight access types, so the engine reasons about conflicting duties directly.
- Your SoD policy as a matrix. The compatibility matrix encodes which access types may coexist, turning policy into rules the engine applies to every role.
- Automatic splitting, in design. Any group combining conflicting duties, such as posting and approving, is split into compliant roles before a role is built.
- An audit story of prevention. Because conflicts are resolved during design, the evidence shows prevention by default, not a trail of remediations.
- Detection stays available. Design-time prevention pairs with the platform's wider governance, so drift is still caught, without leaning on detection as the first line.
About Anugal. Anugal is the Agentic Identity Governance and Administration platform from Business Core Solutions (BCS). Its Role Build Agent designs clean, compliant SAP roles from business process documentation for designer review, part of a wider platform covering identity lifecycle, access requests, certifications, and emergency access across SAP and non-SAP systems.
See it on one of your processes
Bring one business process and your naming convention. We will show you the role design the Role Build Agent produces, SoD splits and all, ready for your designer to review.
Website: anugal.ai
