Why SAP SoD Programs Stall Before They Start — and the Cold-Start Problem Nobody Talks About
The audit finding arrives and the narrative is always the same. A user in accounts payable had the ability to both create a vendor master record and execute the automatic payment run. No individual role assignment was wrong. No one deliberately built the conflict. It accumulated quietly over two years of normal business operations — a role copied for convenience, temporary access from a previous position that was never revoked, an organizational change that nobody mapped back to the access model.
The conflict sat undetected. The auditor found it.
This is not an unusual scenario. It is the standard pattern for how SoD violations surface in mid-market SAP environments. And the reason it happens is not that organizations are negligent about access control. It is that most SoD programs never actually get started, for a reason that is almost never named directly in the conversation about why the finding occurred.
The Cold-Start Problem
Ask any IT Audit Manager who has tried to implement SoD detection in SAP without a GRC consulting engagement and the description of the experience is consistent. They understand what SoD means and why it matters. They can point to the specific control objective the violation is tied to. What they cannot easily produce is a practical, implementable set of rules that maps SAP transaction codes to audit control objectives — structured in a way that can be loaded into a detection tool and run against actual role assignments without months of internal build work.
Building a SAP SoD rule set from scratch in a mid-size 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 for every conflict. The realistic estimate for a team with genuine SAP authorization expertise is three to four months. Most mid-market IT audit teams do not have that expertise in-house, and most do not have three to four months of capacity to allocate to a rule-building project before the next audit cycle begins.
The result is that the SoD program gets deferred. Not cancelled — deferred. The intention to implement it remains. The tool that will eventually run it may even be selected. But because the rule set does not exist, the first scan cannot run, and because the first scan cannot run, the violations that already exist in the environment continue to accumulate undetected. By the time the program is actually implemented, the remediation effort is significantly larger than it would have been eighteen months earlier.
This is the cold-start problem. It is the primary reason most mid-market SAP SoD programs fail before they produce a single violation report. The conversation about the audit finding rarely mentions it because by the time the finding occurs, the question of why the program was never implemented has been replaced by the more immediate question of what to do about the finding.
Why SAP Alone Cannot Solve This
Understanding why SoD violations accumulate in SAP environments requires understanding what SAP's authorization framework was and was not designed to do.
SAP's authorization model is built around individual role assignments. When a user is assigned a role, SAP validates that the role exists and that the assignment follows the defined process. What SAP does not evaluate 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 independent oversight.
This is not a flaw in SAP. It is a design boundary. SAP is an enterprise resource planning system. Segregation of duties enforcement is a governance control that sits above the ERP layer. SAP manages what users can do individually. SoD detection determines what users can do in combination across their full role portfolio — a different and analytically more complex question that requires a rule set, cross-role analysis, and audit-ready output. None of these three elements ships with SAP.
SAP GRC Access Control can provide SoD enforcement within the SAP boundary, but only after a rule set has been built. It also stops at the SAP boundary — it does not detect conflicts created by the combination of SAP access and access to Microsoft 365, Salesforce, or other connected systems. For organizations where the same users who hold SAP financial roles also hold administrative access in connected systems, the SoD picture that SAP GRC produces is incomplete by design.
What the T-Code Level Actually Means for Audit Evidence
There is a specificity question in SoD detection that is worth understanding before evaluating any detection tool. SOX audit findings are documented at the transaction code level. IFC management assertions reference T-codes. PCAOB audit workpapers reference T-codes. When an auditor finds an SoD conflict, the finding names the specific SAP transaction codes that created it, the control objective at risk, and the remediation required.
A detection tool that works above the T-code level produces output that needs to be translated before an auditor can use it. That translation step is where audit cycles are lost and where the conversation between the IT audit team and the external auditor becomes unnecessarily complex.
Detection at the T-code level means the output of a scan is directly usable by an auditor without transformation. The violation names the specific T-codes in conflict. The control objective is mapped. The remediation guidance is included. The auditor receives a document that matches the format and specificity of the finding they would write themselves.
For mid-market organizations without dedicated audit support teams, the difference between output that requires transformation and output that does not is frequently the difference between a SoD program that produces audit value and one that produces reports nobody fully acts on.
What a Rule Set That Ships Pre-Built Actually Changes
The cold-start problem is structural, which means the solution is structural. The most direct way to eliminate a three-to-four month rule-building phase is to not require one.
A pre-built SoD rule set for a specific industry and SAP module coverage — curated from ISACA, PCAOB, and SAP authorization documentation, mapped to control objectives across SOX, IFC, and COBIT, validated against the conflict patterns that appear most consistently in actual audit findings — eliminates the cold-start delay entirely. The first scan runs on the day the tool connects to SAP. The violation report is formatted for audit review from the moment it is generated.
This changes the SoD program timeline in a way that is practically significant. An IT Audit Manager who connects a pre-built rule set to a SAP ECC environment on a Monday can have a violation report on that environment by Wednesday — not three months later. The violations that have been accumulating undetected can be surfaced and remediated before the next audit cycle rather than discovered by the auditor during it.
The audit finding that opened this piece — the accounts payable lead with vendor creation and payment execution access — would have been detected within hours of the tool being connected. The 26-month accumulation window that made the finding possible exists because the detection program was never implemented. The detection program was never implemented because the rule set was never built.
That is the problem the cold-start solution solves.
For pre-built SoD rule sets for SAP manufacturing and financial services environments, including T-code level detection mapped to SOX, IFC, and COBIT control objectives, visit
https://www.openiam.com/soluti....ons/sap-compliance/s