The Sarbanes-Oxley Act (SOX) is a US federal law enacted in 2002. Section 404 requires publicly traded companies to have management annually assess the effectiveness of their Internal Control over Financial Reporting (ICFR). This assessment must be attested to by an external auditor.
In the SAP context, SOX Section 404 creates specific requirements for IT General Controls (ITGC). These cover all activities affecting SAP systems with a financial impact: FI, CO, AA, GL, MM, and SD. ITGCs encompass four areas: access controls, change management, computer operations, and program development.
The four-eyes principle (two-person rule) is a core change management control. It requires that a critical activity be performed by at least two different people: one who implemented the change and an independent person who provides approval. Combined with Segregation of Duties (SoD), it is the operational translation of the principle of trust: no single person may perform a critical action alone.
SOX controls in the SAP change process fail for structural reasons, not necessarily due to malicious intent:
The SAP Basis administrator problem. SAP Basis administrators often have extensive system privileges that allow them to import transports directly into production systems, assign authorizations directly, and change customizing settings. If the same person who implements a change can also move it into production, the four-eyes principle is technically bypassed, even if the process requires approvals.
The emergency abuse problem. Emergency changes can justify an abbreviated approval process. However, if 30–40 percent of all changes are classified as emergencies, the emergency process has become the standard path. Auditors recognize this pattern as a control failure.
The documentation-instead-of-enforcement problem. The four-eyes principle is in the process manual, but it is not enforced in the authorization concept. Approval is granted, but the same person could technically act without it. For the auditor, what matters is whether the control is technically enforced or merely documented.
The central question in a SOX audit is not, "Did someone document the approval?" but rather, "Could someone have acted without approval?"
What technical enforcement means. Technical enforcement means that the system technically prevents the critical action without prior approval from a second person. For transport imports into production: the import authorization (‘S_CTS_ADMI’ or equivalent) is configured so that only individuals who do not also hold the developer role possess it. The SAP authorization concept enforces the SoD.
What is only documented. If the approval is recorded in the change system, but the developer still technically has the ability to import their own transport, then the four-eyes principle is documented but not enforced. In a SOX audit, this is a control weakness—depending on the severity, either a significant deficiency or a material weakness.
Compensating controls. If technical enforcement is not feasible (e.g., for small teams with limited staff), compensating controls must mitigate the risk: detailed system logs, regular audits of direct imports, and automated anomaly detection. These compensating controls must themselves be documented and audited.
The most common SOX findings in the SAP change process. In practice, three types dominate: direct imports into production without a change record (change management control failure), lack of technical enforcement of SoD between development and production (access control weakness), and an excessively high rate of emergency changes (change management control failure, allowing the bypass of process integrity).
Limitations of compensating controls. Compensating controls can offset technical gaps to a certain extent. However, they are expensive to execute (manual review is labor-intensive), prone to error (humans overlook exceptions), and are viewed by auditors as less robust than technically enforced primary controls. A good compensating control does not solve the root problem; it manages it.
The AI change problem for SOX. When AI coding tools generate ABAP code that is deployed into financial SAP systems, this code must be subject to the same SOX controls as human-generated code. The difference: the developer is now a human who adopts and releases AI-generated code. The question for the auditor: Was the code reviewed by a second, independent person before it went into production?
Technical SoD in the authorization concept. The first step is to review the SAP authorization concept: Which roles allow transport imports into production systems? Can developers hold these roles simultaneously with developer roles? The SoD matrix defines which role combinations are prohibited. This matrix is technically enforced within the authorization concept and reviewed regularly.
Direct import monitoring as compensation. For cases where technical enforcement is not fully possible (small teams, emergencies), direct import monitoring is established: automated detection of imports that bypass the change process, automatic notification and escalation, and regular review cycles by an independent party.
Emergency change rate as a KPI. The ratio of emergency changes to total volume is measured as a KPI and reported to management. A rate above 15-20 percent is a signal that the regular process is perceived as too slow. The problem then lies in the process, not in the emergency mechanism.
AI code review as an explicit control requirement. For changes containing AI-generated code, the change record must explicitly document: Which AI tool was used? Who reviewed the generated code (second person)? What checks were performed (ATC, security check)? This explicit documentation is the technical enforcement of the four-eyes principle for AI-generated code.
By 2026, SOX and the four-eyes principle are no longer theoretical compliance exercises, but operational audit realities with concrete findings. The core question: Is the four-eyes principle technically enforced or merely documented? Technical SoD in the authorization concept, direct import monitoring, emergency change rate as a KPI, and explicit AI code review documentation are the four operational consequences.