Most SoD programs fail before they start. We ship the rule set.
OpenIAM includes pre-built, industry-specific SoD rule sets for manufacturing and financial services SAP environments — mapped to SOX, IFC, and COBIT control objectives, ready to load on day one. No consultant engagement. No six-month rule set build. Connect to SAP, import your roles, see your violations.
If any of this sounds familiar, you're exactly where you need to be.
Your auditor flagged an SoD conflict in SAP. Your team didn’t catch it first.
SAP role assignments accumulate quietly over years. A user gets temporary access during a project, a role is copied for convenience, an emergency login is never revoked. Nobody set out to give one person the ability to both create a vendor and approve its payment — but it happened, and your auditor found it. Now it’s an open finding.
You know you need SoD rules. But building them from scratch takes months.
A proper SoD rule set for a mid-size SAP environment means mapping transaction codes to authorization objects, assigning risk levels, connecting each rule to a specific control objective, and writing audit-ready remediation guidance. Most teams estimate 3–4 months to do it correctly — if they have the SAP expertise. Most don’t, and most don’t have the time.
Your auditor works at the T-code level. Your SoD tool should too.
SOX audit findings reference specific SAP transaction codes. IFC management assertions are tied to specific controls over specific transactions. A SoD detection tool that works at a level above T-codes produces output that needs to be translated before an auditor can use it. That translation step is where audit cycles are lost.
SAP manages roles. It doesn't enforce what those roles can't do in combination.
SAP's authorization framework is built around individual role assignments. When a user is given a role, SAP checks that the role exists and that the assignment is valid. What SAP does not check is whether that user already holds another role that, in combination with the new one, creates a conflict — a situation where a single person can execute both sides of a transaction that should require two independent people.
This gap is not a flaw in SAP — it's a design boundary. SAP is an ERP system. Segregation of duties enforcement is a governance control that sits above the ERP. SAP GRC Access Control can enforce SoD within the SAP boundary, but only if someone has already built the rule set that defines what conflicts to check for. And SAP GRC stops at the SAP boundary — it doesn't govern what users can do in Microsoft 365, Salesforce, or any other connected system.
The result is predictable: over years of normal business operation — new starters, role copies, temporary access, organizational changes — users accumulate combinations of SAP roles that individually are appropriate but together create audit risk. By the time an auditor runs an SoD analysis, the violations are often numerous, entrenched, and require significant remediation effort to resolve before the next audit cycle.
1
A rule set
Why SAP alone doesn’t provide it
SoD enforcement requires a defined library of rules: which transaction code combinations constitute a conflict, what risk level each conflict carries, and what control objective each rule satisfies. SAP provides the authorization framework. It does not ship with a pre-built SoD rule library.
2
Cross-role analysis
Why SAP alone doesn’t provide it
A user’s SoD risk is determined by the combination of all their role assignments, not by any single role. SAP evaluates authorizations at the point of access — it doesn’t run a continuous analysis of what users could do in combination across their full role portfolio.
3
Audit-ready output
Why SAP alone doesn’t provide it
A SoD violation is only audit-useful if it names the specific T-codes in conflict, maps to a control objective, and includes remediation guidance. Raw SAP authorization data requires significant transformation before it produces the output an external auditor can evaluate.
Every SoD program stalls at the same place: building the rules.
Ask any IT Audit Manager who has tried to implement SoD in SAP without a GRC consulting engagement and they will describe the same experience. They know they need rules. They can find guidance on what SoD means and why it matters. What they cannot easily find is a practical, implementable set of rules that maps SAP transaction codes to audit control objectives — structured in a way they can load into an IGA tool and run against their actual role assignments without months of internal build work.
OpenIAM eliminates the cold-start problem entirely. Instead of beginning with a blank rule library that needs to be populated before the first scan can run, the OpenIAM SoD Accelerator ships with pre-built rule sets for manufacturing and financial services SAP environments. The rules are curated from ISACA, PCAOB, and SAP authorization documentation, mapped to SOX, IFC, and COBIT control objectives, and validated against the conflicts that appear most often in actual audit findings. The first scan runs on day one.
The practical implication: an IT Audit Manager at a manufacturing company can connect OpenIAM to their SAP ECC environment, load the manufacturing rule set, and have a violation report — formatted for audit review — within hours. No consultant engagement. No months-long rule set build. No transformation required before the output goes to an auditor.
3–4 months
Average time to build a SAP SoD rule set from scratch
Day one
Time to first violation scan with OpenIAM pre-built rule sets
45 rules
Pre-built rules in the Manufacturing Edition — covering 15 Critical conflicts
Purpose-built rule sets for the way mid-market SAP environments actually work.
Not a generic library of 200+ rules that covers every SAP module ever deployed. Pre-built, vertically specific rule sets that cover the six modules mid-market manufacturing and financial services auditors actually test — with zero rules that don't apply to your environment.
Industry-specific editions — not one-size-fits-all
The Manufacturing Edition covers the six SAP modules that matter most in a manufacturing and distribution environment: FI, MM, SD, PP, CO, and QM. The Financial Services Edition covers FI, CO, TR, FI-AA, FI-GL, and HR. Each edition is calibrated to the conflict patterns that appear in real audit findings for that industry — not theoretical risk.
T-code level detection — the level your auditors use
OpenIAM detects SoD conflicts at the T-code level — the same level your SOX, IFC, and COBIT auditors use to document findings. Every conflict maps to specific SAP transaction codes, so when a violation surfaces, you can show your auditor exactly which T-codes are in conflict and which control objective is at risk. The output is formatted for audit review from the moment it is generated.
Regulatory frameworks covered — not just one
Each rule maps to the relevant control objective across the frameworks most commonly used in mid-market compliance programs: SOX Section 404 and PCAOB AS 2201 (US), IFC under the Companies Act 2013 and ICAI auditing standards (India), and COBIT 2019 DSS06 and DORA Article 9 (EU). The same rule, usable across markets.
Extensible — start with pre-built, add your own
The pre-built rule set is the starting point, not the ceiling. OpenIAM’s rule builder allows IT Audit Managers to create custom rules using the same seven-field structure and add them alongside the pre-built sets. Custom rules can also be bulk-uploaded from an existing SAP GRC export via CSV, Excel, JSON, or XML.
On granularity — what actually matters in an audit context
T-code level is the level that produces audit-ready evidence.
Some IGA vendors lead with granularity claims — auth object level, field level, field value level detection. For mid-market SAP environments: SOX audit findings are documented at the T-code level. IFC management assertions reference T-codes. PCAOB audit workpapers reference T-codes. More granularity does not produce better audit outcomes for mid-market organizations — it produces more complex reports that take longer to interpret. OpenIAM detects at the level your auditors work at, and produces output they can use the same day.
ECC & S/4HANA compatibility
Your rule set works today on ECC. It is protected when you move to S/4HANA.
The OpenIAM SoD rule set is validated for SAP ECC 6.0 — the version the majority of mid-market SAP customers are running today. It is also fully compatible with SAP S/4HANA. When your organization migrates, the rule set migrates with it. SAP preserves the core T-codes and authorization objects across ECC and S/4HANA for the modules covered by this rule set. The migration requires a configuration update in OpenIAM — not a rule rebuild. Your violation history, remediation records, and audit evidence are preserved across the migration.
What a violation looks like — and how OpenIAM surfaces it.
The most common SoD conflict in SAP financial environments is also one of the most dangerous: a single user who can both create a vendor master record and execute the automatic payment run. Here is what that looks like in practice, and what happens when OpenIAM detects it.
Step 1 of 3 — The situation
How the conflict developed
In a typical mid-size manufacturing company, the accounts payable team lead was given the FK01 role (create vendor master) when a new supplier management process was introduced two years ago. The same user already had payment execution access from their previous role in treasury. No individual role assignment was wrong. No one set out to create a conflict. But the combination — the ability to introduce a vendor into SAP and then approve payment to that vendor — is a direct violation of the SoD control that auditors test first in a procure-to-pay cycle review. The conflict sat undetected for 26 months. It appeared in an IFC audit finding.
Step 2 of 3 — OpenIAM detects it
Rule MFG-FI-001 fires on this user immediately
The conflict is detected because the user holds roles that provide access to both Function A T-codes and Function B T-codes simultaneously. The detection runs across all active SAP users in a single scan.
Step 3 of 3 — The audit-ready output
Everything the auditor needs, produced at scan time
This entry is produced by OpenIAM at the time of the scan. No manual writing, no translation, no reformatting before it goes to an auditor.
What the Manufacturing Edition covers.
45 rules across 6 SAP modules. 15 Critical rules targeting the conflicts that appear most often in IFC and SOX audit findings.
| Module | Module name | Risk level | Key process area |
|---|---|---|---|
| FI | Financial Accounting |
Critical — 6 High — 3 Medium — 1
|
Payment processing, GL integrity, accounts payable/receivable |
| MM | Materials Management |
Critical — 4 High — 4 Medium — 2
|
Procure-to-pay, goods receipt, invoice verification, inventory |
| SD | Sales & Distribution |
Critical — 3 High — 3 Medium — 2
|
Order-to-cash, customer master, pricing, billing, credit management |
| PP | Production Planning |
Critical — 2 High — 3 Medium — 2
|
Production order integrity, BOM management, goods confirmation |
| CO | Controlling |
High — 4 Medium — 2
|
Cost center management, internal orders, cost allocation |
| QM | Quality Management |
High — 3 Medium — 1
|
Inspection lots, usage decisions, quality notifications |
| Total | 6 modules • 45 rules | 15 Critical • 20 High • 10 Medium | Manufacturing and distribution environments |
Also available
Financial Services Edition
The Financial Services Edition covers FI, CO, TR (Treasury), FI-AA (Asset Accounting), FI-GL (General Ledger), and HR — 45 rules calibrated to the SoD conflicts that appear most often in banking and financial services audit findings. Both editions can be activated simultaneously and run in a single scan with a single violation report.
45 rules. That's not the whole picture — and that's the point.
The SoD Accelerator Manufacturing Edition covers the six SAP modules that IFC, SOX, and COBIT auditors focus on in manufacturing and distribution environments. It does not cover SAP Basis, HR/Payroll, or Plant Maintenance — because those are separate, purpose-built rule sets, each with the same depth and audit alignment as this edition.
When comparing SoD rule set coverage across vendors, the only meaningful comparison is module-for-module. A vendor listing 200+ rules across all SAP modules combined — Basis, HR, PM, cross-application, and manufacturing core — is not comparable to a manufacturing-focused rule set of 45 rules. The 45 rules in this edition cover the conflicts your manufacturing auditors will test. The other modules are covered separately.
SAP Basis Edition
Technical administration, privileged access, transport management, user & role admin
30 rules
HR / Payroll Edition
Personnel master data, payroll processing, time management, organizational management
35 rules
Plant Maintenance Edition
Work orders, maintenance plans, equipment master data, PM/Finance cross-module conflicts
30 rules
Financial Services Edition
FI, CO, TR, FI-AA, FI-GL, HR — calibrated to banking and financial services audit findings
45 rules
Frequently Asked Questions
How quickly will I see violations after connecting to SAP?
⌄In most environments, the first SoD scan produces results within hours of the initial SAP connector configuration. The time to first value depends primarily on the size of your SAP user and role population — not on a configuration or professional services phase. Because the Manufacturing Edition rule set is pre-loaded, there is no rule-building step between connection and first scan. A typical mid-market environment of 200–500 SAP users completes its first scan within 2–4 hours of connection.
We already have SAP GRC for SoD. Why do we need OpenIAM?
⌄SAP GRC governs SoD within the SAP boundary. OpenIAM does two things GRC cannot: first, it governs SoD across every connected system beyond SAP — Microsoft 365, Salesforce, ServiceNow, and your SaaS applications — in a single platform with a single access certification campaign. Second, OpenIAM’s SoD module is designed to work alongside SAP GRC, not replace it. Many organizations run both: GRC for deep SAP access control, OpenIAM for the governance layer that covers their entire IT landscape. GRC covers SAP. OpenIAM covers everything GRC cannot reach.
We’re running SAP ECC 6.0. Will this work for us?
⌄Yes — fully. SAP ECC 6.0 is one of OpenIAM’s core supported connectors and is treated with the same depth and testing rigour as S/4HANA. The Manufacturing Edition rule set is validated for ECC 6.0 — the version most mid-market SAP customers are running today. The rule set is also compatible with S/4HANA. When you migrate, the rule set migrates with you without requiring a rebuild. OpenIAM does not treat ECC 6.0 as a legacy environment — it is the primary SAP environment for the mid-market customers this edition is built for.
Can we add our own SoD rules on top of the pre-built set?
⌄Yes. The pre-built rule set is the starting point, not the limit. OpenIAM’s rule builder allows your team to create custom SoD rules using the same six-field structure — Rule ID, name, T-codes, risk level, control objective, and remediation guidance. Custom rules are saved to a named custom rule set in the catalog and can be activated alongside the pre-built manufacturing set. Rules from multiple sets run in a single scan and appear in a single violation report. You can also bulk-upload existing rules from SAP GRC or another tool via CSV, Excel, JSON, or XML.
Let’s Connect
Managing identity can be complex. Let OpenIAM simplify how you manage all of your identities from a converged modern platform hosted on-premises or in the cloud.
For 15 years, OpenIAM has been helping mid to large enterprises globally improve security and end user satisfaction while lowering operational costs.