SAP Segregation of Duties (SoD) refers to the practice of ensuring no single user has access to perform two or more conflicting functions in SAP, such as creating a vendor record and also processing payment to that vendor, or initiating a purchase order and also approving goods receipt. The control exists because when one person can execute both sides of a financially material transaction without independent oversight, the conditions for undetected fraud or error are present by design.
For manufacturing companies operating under SOX, IFC, or COBIT frameworks, SAP SoD is where the conversation about compliance typically starts. It is not where the audit ends.
This distinction matters because the audit scope has expanded significantly while most manufacturing governance programs have not. The systems auditors test, the evidence they require, and the questions they ask after a conflict is found have all changed. An SoD program confined to SAP can pass an access review and still produce an audit finding. Understanding why, and what a complete program looks like, is the argument this post makes.
Manufacturing audits test access control, identity lifecycle, and access certification across every system that processes financially material transactions, not only within SAP.
Manufacturing audits do not start and stop at the SAP boundary. The three control areas that consistently appear in SOX ITGC reviews, IFC assessments, and COBIT-aligned audits are access control, identity lifecycle, and access certification, and each of these extends well beyond SAP.
On access control, auditors are testing whether high-risk role combinations exist across the systems that process financially material transactions. In a manufacturing environment, that means SAP Financial Accounting, Materials Management, and HR/Payroll, but it also means Active Directory and Entra ID, where privileged access to production systems lives. It means ServiceNow, where change approvals happen. It means HR systems, where the source of truth for role assignments originates. It means contractor management platforms and, in some environments, plant-level operational technology systems.
The specific conflict between vendor master creation and payment run execution is the most commonly cited SAP-internal example. Auditors in manufacturing environments also test purchase order creation combined with goods receipt confirmation, production order release combined with goods issue, and payroll creation combined with payroll posting. These are SAP-internal conflicts that a well-configured SoD program should detect. The broader access control risk, however, does not stop at SAP. Auditors are increasingly testing whether the same users hold combinations of access across SAP and connected systems that together create a conflict no single-system SoD tool can surface.
On identity lifecycle, auditors are asking whether access changes when employment status changes, and whether the evidence of that change is timestamped and retrievable. A leaver whose SAP access was revoked but whose Active Directory account remained active for sixty days is a finding, not because the SAP control failed, but because the lifecycle governance stopped at the SAP boundary.
On access certification, auditors are asking whether reviewers had the information they needed to make a real decision, not just whether the campaign completed. A certification that shows role names without business-process context, or that shows SAP access without the SoD risk associated with it, is technically complete and evidentially weak.
The audit is testing all three areas, across all systems in scope. SAP SoD addresses one area, in one system.
SAP SoD detects conflicting role combinations within SAP but does not cover cross-system conflicts, directory access, or contractor and temporary identities that fall outside the configured governance perimeter.
SAP SoD detection identifies conflicting role combinations within the SAP environment. A properly configured SoD program for a manufacturing SAP estate will surface the most dangerous cross-functional conflicts: the combinations that allow a single user to initiate and complete a financially material transaction without independent oversight.
This is genuinely valuable. The conflicts that appear most often in IFC and SOX audit findings, including vendor creation combined with payment execution and purchase order creation combined with goods receipt, are SAP-internal conflicts that a well-configured SoD program detects and surfaces for remediation.
What SAP SoD does not cover falls into three categories.
The first is cross-system conflicts. A user who holds a standard SAP Accounts Payable role and also holds administrative access to the HR system that feeds salary data into payroll holds a conflict that no SAP-internal SoD rule can detect. The two functions exist in different systems, and the risk is real even though the detection gap is structural.
The second is directory and infrastructure access. Active Directory and Entra ID group memberships determine what users can access across the enterprise. A user whose AD group membership grants them access to financial reporting systems, combined with their SAP role access, may hold a conflict that only becomes visible when both systems are analyzed together, because SAP GRC does not analyze Active Directory and the conflict accumulates undetected.
The third is contractor and temporary access. Manufacturing environments routinely involve contractors, seasonal workers, plant transfer employees, and third-party service accounts. These identities often exist outside the primary HR system that feeds the SAP role model. They acquire access through ad hoc requests, project-specific assignments, and emergency provisioning, and they are frequently absent from formal SoD analysis because they fall outside the governance perimeter the SoD tool was configured to cover.
The practical result is an SoD program that surfaces the conflicts it was configured to find, in the systems it was connected to, for the identities it was told to analyse. In a manufacturing environment with dozens of connected systems, a distributed contractor workforce, and a complex intersection of operational and enterprise IT, the configured scope and the actual risk scope are rarely the same.
Manufacturing does not have an access-data problem. It has an access-evidence problem. Data exists in many places across SAP, HR, Active Directory, and plant systems, but audit-ready evidence requires that data to be connected to decisions, workflows, remediation, and accountability in a single retrievable record.
Finding a conflict satisfies only the first of five questions auditors ask. The remaining four require evidence of what happened after the conflict was identified.
There is a version of the SAP SoD conversation that treats detection as the destination: find the conflict, remediate it, close the finding. This framing is understandable and incomplete.
Auditors testing manufacturing SOX ITGC and IFC controls are not only asking whether conflicts were found. They are asking five sequential questions, and a manufacturing compliance program needs to be able to answer all five.
First, what access did this user hold, and when? The answer requires a complete access inventory at a specific point in time, across all systems in scope and not just SAP.
Second, was this access flagged as a risk? The SoD analysis must show that the conflict was identified at the T-code level, mapped to a specific control objective, and assigned a risk level.
Third, who reviewed it, and when? The access review record must show a named reviewer, a documented decision, and a timestamp. A completed certification campaign without reviewer-level evidence does not satisfy this question.
Fourth, what was decided? The outcome is either remediation, meaning access was removed, or accepted risk, meaning the conflict was retained with a documented compensating control and a business justification. Both are acceptable outcomes, but neither is acceptable without documentation.
Fifth, what happened after the decision? For remediation, the access change must be timestamped and retrievable. For accepted risk, the compensating control must be operating and evidenced. The audit finding is most often generated not by the existence of a conflict but by the inability to answer questions four and five.
A manufacturing SoD program that detects conflicts but does not produce this evidence chain leaves an audit gap that the reviewer's certification record cannot close.
For a complete treatment of the evidence requirements across each control area, the manufacturing identity governance white paper covers the full model in detail. Download it free at The Audit Was Never Just SAP.
A complete manufacturing governance program operates across three disciplines simultaneously: preventive controls, detective controls, and evidence.
Preventive controls stop conflicting access from being assigned in the first place. When a new role request is evaluated, the governance platform checks whether the requested role, combined with the user's existing access, would create a conflict, and if it does, the request is flagged before assignment occurs. This is the most effective form of SoD governance because it eliminates the remediation burden after the fact.
Detective controls identify conflicts that already exist in the environment, arising from legacy assignments, ad hoc provisioning, role copies, and access that survived organizational changes. These require continuous scanning across all connected systems and not just periodic campaigns within SAP. A detective control that runs quarterly misses the conflict that was created in the second month of the quarter and remediated before the scan ran, while a detective control that runs continuously maintains a current picture of the risk environment.
Evidence is the discipline that determines whether the first two capabilities produce audit value. Every preventive decision, whether blocked, approved with justification, or escalated, must be timestamped and retrievable. Every detective finding, whether surfaced, reviewed, remediated, or accepted, must be documented with the reviewer, the decision, and the action. Every access certification must show not just completion but the business-context information the reviewer saw when making the decision.
The governance model that connects these three disciplines across SAP and every connected system is what the manufacturing identity governance white paper documents in full. The seven-step model it describes moves from running the first SAP SoD scan through prioritizing high-risk violations, documenting remediation, expanding access reviews beyond SAP, connecting HR-driven lifecycle workflows, adding contractor and privileged access governance, and establishing service account governance foundations. It is structured specifically for manufacturing environments and built around the evidence requirements that regulators and auditors apply. Download it at this link.
For the full platform treatment of manufacturing identity governance, including what auditors test and how the controls map to SAP and connected systems, see Manufacturing compliance that covers every system your auditor will test.
What is SAP Segregation of Duties?
SAP Segregation of Duties (SoD) ensures no single user can perform two conflicting functions in SAP, such as creating a vendor record and also processing payment to that vendor. The control exists because when one person can execute both sides of a financially material transaction without oversight, the conditions for undetected fraud are present by design.
Why is SAP SoD important for manufacturing companies?
Manufacturing processes high volumes of financially material transactions across procurement, production, and payroll, which are the areas where SoD conflicts create the most direct fraud and error risk. Auditors test these functions under SOX ITGC, IFC, and COBIT frameworks, and a single user who can execute both sides of any transaction without oversight is a finding.
Does SAP GRC cover all manufacturing SoD risks?
SAP GRC covers SoD conflicts within SAP and does so well when rule sets are properly configured. It does not govern access in Active Directory, Entra ID, ServiceNow, or HR systems outside SAP, and cross-system conflicts that span SAP and a connected system are outside its detection scope by design.
What systems do manufacturing auditors test for SoD?
Auditors typically cover SAP (FI, MM, HR/Payroll, Basis), Active Directory and Entra ID, HR and payroll systems, ServiceNow, contractor management systems, and in some environments plant-level operational technology applications. The scope is determined by which systems process financially material transactions, not by the SAP boundary.
What evidence do auditors require for SoD compliance?
Auditors need five things: a complete access inventory at a specific point in time, an SoD analysis showing the conflict at T-code level, a review record showing who decided and when, documentation of the outcome whether remediation or accepted risk, and a timestamped record of when each step occurred.