AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor
What SOX Auditors Test In SAP
A Comprehensive Guide For IT And Process Owners
Why IT And Process Owners Must Understand SOX Audit Expectations
The IT department is typically well-versed in the IT general controls that fall within its direct responsibility under SOX compliance. However, the IT function's role in SOX extends well beyond managing its own control domain. IT and SAP process owners are frequently called upon to provide data extractions, system configuration documentation, user access reports, and transaction evidence that auditors require to test controls across the organization's business cycles. When auditors lack the system access privileges or the technical expertise to extract this information independently, they depend on IT to produce it accurately, completely, and in a format that supports their testing procedures.
This dependency creates a practical requirement for IT and SAP teams to understand what SOX auditors are testing, why they are testing it, and what evidence they need. When IT teams understand the audit objectives behind each data request, they can provide more useful information, anticipate recurring requests, identify opportunities to automate evidence collection, and engage constructively in the audit process rather than treating each request as an interruption to operational priorities.
Under SOX Section 404(a), management is required to assess and report on the effectiveness of the organization's internal controls over financial reporting. Under SOX Section 404(b), the external auditor must attest to management's assessment for accelerated filers and large accelerated filers. Both assessments depend on the reliability of the IT systems that process, store, and report financial data. PCAOB Auditing Standard AS 2201 directs the auditor to evaluate IT general controls as part of the top-down, risk-based approach to the audit of internal control, because weaknesses in IT general controls can undermine the reliability of every application control and every business process control that depends on the IT environment.
The COSO Internal Control Integrated Framework of 2013, which is the framework most commonly used by management to structure the SOX compliance program, identifies information technology as a critical component of the control environment that enables and supports the other components of internal control. The ISACA COBIT 2019 framework provides additional detailed guidance on IT governance and management objectives that support SOX compliance, including specific practices for access management, change management, operations management, and application control.
This guide describes the IT general controls and IT application controls that SOX auditors evaluate in SAP environments, organized by control domain, with the specific SAP transactions, tables, and audit procedures that IT and process owners should expect.
IT General Controls: The Foundation Of System Reliability
IT general controls are the foundational controls that ensure the reliability, integrity, and security of the IT environment within which financial applications operate. If IT general controls are ineffective, the auditor cannot rely on the application controls that depend on them, regardless of how well those application controls are designed. This cascading dependency is why ITGC testing is typically the first phase of the SOX IT audit and why ITGC deficiencies can have enterprise-wide implications for the SOX assessment.
SOX auditors evaluate IT general controls across five primary domains.
Access Controls And User Security
Access controls ensure that only authorized individuals have access to financial systems and data, that access is appropriately segregated to prevent conflicts of interest, and that access rights are reviewed and updated in response to personnel changes.
User access provisioning and deprovisioning is the control that ensures access is granted based on documented business requirements, approved by appropriate management, and promptly removed when an employee transfers, changes roles, or leaves the organization. In SAP, user master records are maintained through transaction SU01 (or SU01D for display), and the user information is stored in table USR02, which contains user logon data including validity dates, user type, and lock status. Auditors will request a listing of all active users, compare it against the current employee roster from HR, and test a sample of terminated or transferred employees to verify that their access was revoked or modified within the timeframe required by the organization's access management policy. The SUIM User Information System provides the most efficient reporting capability for this analysis.
Role and profile assignments determine what each user can do within the system. SAP's role-based access model assigns authorization profiles to users through roles, which are maintained in transaction PFCG. The relationship between roles and users is recorded in table AGR_USERS, and the authorization values assigned to each role are stored in table AGR_1251. Auditors will review whether roles are designed according to the principle of least privilege, whether role assignments are consistent with users' job responsibilities, and whether any users have been assigned overly broad profiles such as SAP_ALL or SAP_ALL_ACCESS that bypass normal authorization restrictions. Users with these profiles effectively have unrestricted access to all functions in the system and represent the highest-priority access risk.
Segregation of duties analysis evaluates whether any individual user has been assigned combinations of access that create unacceptable fraud or error risk. The earlier post on the 100 most critical segregation of duties conflicts in SAP provided a detailed reference for the transaction code combinations that auditors evaluate. In practice, auditors use the SUIM reports or dedicated GRC tools such as SAP GRC Access Control (transaction GRAC_SPM or Fiori-based equivalents) to run automated SoD conflict analysis across the entire user population. The analysis identifies users with conflicting access and evaluates whether mitigating controls are documented and effective for each conflict that cannot be resolved through access restriction.
Periodic access reviews and certification verify that management reviews user access at defined intervals, typically quarterly or semi-annually, to confirm that access assignments remain appropriate. Auditors will request evidence that these reviews were performed, that the reviewers had sufficient knowledge to evaluate the appropriateness of access, and that identified issues were remediated within the required timeframe.
Privileged and emergency access management addresses the controls over highly privileged accounts, including system administrators, basis administrators, and emergency access users (commonly referred to as firefighter access in SAP GRC terminology). In SAP GRC Access Control, emergency access sessions are logged and must be reviewed by a designated controller after each use. Auditors will review the emergency access logs to verify that each session was authorized, that the activities performed during the session were consistent with the stated purpose, and that the controller review was completed within the required timeframe. The security audit log, accessible through SM20 or RSAU_READ_LOG, provides the detailed event-level data needed to evaluate what specific transactions and data were accessed during privileged sessions.
Change Management
Change management controls ensure that modifications to the SAP system, including program changes, configuration changes, and data corrections, are properly authorized, tested, and implemented without compromising the integrity of the production environment.
Transport management is the primary mechanism through which changes move through the SAP landscape. In a standard three-system landscape consisting of development, quality assurance, and production environments, all changes should originate in the development system, be tested in the quality assurance system, and be transported to production only after testing is complete and the transport is approved. Transaction SE10 and STMS (Transport Management System) provide the interface for managing transport requests, and the transport history is recorded in tables E070 (transport header data) and TPLOG (transport log). Auditors will trace a sample of transports from origination through testing to production implementation, verifying that each transport was properly approved, that testing evidence exists, and that no changes were made directly in the production environment without following the standard transport path.
Client settings in transaction SCC4 control whether the production client is open or closed for changes. In a properly configured SOX-compliant environment, the production client should be locked against direct changes, meaning that all modifications must arrive through the transport system from the development environment. Auditors will verify the SCC4 settings and investigate any periods during which the production client was opened for direct modification.
Emergency change procedures address the controls over changes that must be implemented in production outside the normal transport process due to urgent business or technical requirements. These changes carry elevated risk because they bypass the standard testing and approval workflow. Auditors will review the population of emergency changes, verify that each was authorized by appropriate management, that the change was subsequently tested and formally transported through the standard process, and that the emergency change procedure is used infrequently and only for genuinely urgent situations.
Development standards and code review address the controls over custom ABAP programs, enhancements, and modifications. Custom programs, which in SAP convention use the Z or Y namespace, are reviewed for compliance with the organization's development standards, secure coding practices, and authorization against the program catalog in table TADIR. Transactions SE38 (ABAP Editor) and SE80 (Object Navigator) are used for program development and review.
Computer Operations And Job Scheduling
Computer operations controls ensure that the IT environment operates reliably, that scheduled processes execute successfully, and that data is protected through adequate backup and recovery procedures.
Background job monitoring is critical in SAP because many financial processes, including payment runs, posting runs, dunning runs, and interface processing, are executed as scheduled background jobs rather than through interactive user transactions. Transaction SM37 provides the job overview, and the job execution history is stored in tables TBTCO (job status records) and TBTCP (job step information). Auditors will review job execution logs over a defined period to verify that critical financial processing jobs completed successfully, that failures were detected and resolved in a timely manner, and that the job scheduling configuration in SM36 reflects the organization's processing requirements.
Backup and recovery procedures ensure that SAP data can be restored in the event of system failure, data corruption, or disaster. Transaction DB13 provides the database administration calendar, including backup scheduling and execution logs. Auditors will review backup logs to verify that backups are performed according to the defined schedule, that backup success is monitored, and that recovery testing is performed periodically to confirm that backups can be restored within the required timeframes.
Interface monitoring ensures that data transfers between SAP and external systems are complete, accurate, and processed in a timely manner. Transactions WE02 and WE05 display IDoc (Intermediate Document) processing logs, which record the status of each data exchange. Transaction SM58 displays transactional RFC (tRFC) logs, and SMQ1 and SMQ2 display queued RFC (qRFC) status. Auditors will review interface processing logs, test reconciliation procedures that verify the completeness and accuracy of data transfers, and evaluate the error handling procedures for failed transmissions.
Spool management controls ensure that sensitive financial reports and data outputs are directed to authorized output devices and that spool data is retained and deleted in accordance with the organization's data security policies. Transaction SP01 displays spool requests, and SPAD provides spool administration. Auditors will verify that access to spool administration is restricted and that sensitive financial reports are not accessible to unauthorized users through the spool system.
Program Development
Program development controls, sometimes evaluated as a subset of change management, ensure that custom programs and system modifications are developed according to defined standards, properly tested, and authorized before implementation.
Source code and version control ensure that changes to custom programs are tracked, that prior versions can be recovered, and that unauthorized modifications are detectable. The version management capability within the ABAP Workbench provides change history for custom objects. Auditors will review a sample of custom program changes to verify that the changes were authorized, tested, and transported through the standard change management process.
Table maintenance controls restrict the ability to modify data directly in SAP database tables, which bypasses application-level controls and creates significant data integrity risk. Transaction SM30 provides the table maintenance interface, and transaction SE16N provides direct table display access. Auditors will verify that access to table maintenance and direct table modification transactions is restricted to authorized administrators and that changes made through these transactions are logged and reviewed.
Physical And Environmental Controls
Physical and environmental controls ensure that the hardware infrastructure supporting the SAP environment is physically secure and protected against environmental threats.
Data center access is controlled through physical security measures including badge access systems, visitor logging, and surveillance. Auditors will review data center access logs, verify that only authorized personnel have physical access to server infrastructure, and assess whether environmental safeguards including power protection, cooling systems, and fire suppression are adequate and tested.
Operating system and database security ensure that access to the SAP servers and the underlying database, including SAP HANA for S/4HANA environments, is restricted to authorized administrators and that administrative activities are logged. Transaction SM51 displays the application server overview, and AL11 provides access to the server file system directories. Auditors will review operating system and database administrative access, verify that default passwords have been changed, and assess whether administrative activities are monitored and logged.
IT Application Controls: Ensuring Data Integrity Within SAP Financial Modules
IT application controls are the automated and configurable controls embedded within the SAP financial modules that ensure the completeness, accuracy, validity, and authorization of financial transactions as they are processed through the system. Unlike IT general controls, which provide the foundation for system-wide reliability, application controls operate at the transaction, process, or module level and directly affect the quality of financial data that flows into the organization's financial statements.
Auditors evaluate IT application controls across five categories.
Input Controls
Input controls ensure that data entered into the SAP financial modules is valid, complete, authorized, and accurately recorded. These controls prevent erroneous or unauthorized data from entering the system at the point of origination.
Posting validations in the general ledger ensure that financial transactions comply with defined rules before they are posted. SAP provides validation and substitution rules, configured through transactions GGB0 and GGB1 (or through SPRO in the IMG customizing path), that can enforce conditions on posting data including account assignments, cost center assignments, document types, and posting keys. Auditors will test these rules by attempting to post transactions that violate the defined conditions and verifying that the system rejects or corrects them.
Master data validation ensures that customer and vendor master records contain complete and accurate information. In SAP ECC, customer master data is maintained through transactions in the XD, VD, and FD families, and vendor master data through transactions in the XK, MK, and FK families. In S/4HANA, all master data maintenance is consolidated under the Business Partner transaction BP, as discussed in the earlier post on SAP transaction codes for auditing. Auditors will review master data for completeness of required fields, duplicate detection, and consistency of critical data elements such as bank details, payment terms, tax identification numbers, and reconciliation account assignments.
Tolerance limits control the maximum amount that can be posted, the acceptable variance in invoice verification, and other quantitative thresholds that prevent unauthorized or erroneous transactions from being processed. Tolerance groups for general ledger postings are configured in transaction OBA4, and tolerance limits for invoice verification are configured in OMR6. Auditors will review the configured tolerance values, verify that they are consistent with the organization's policies, and test whether the system enforces the limits when transactions exceed them.
Posting period controls determine which accounting periods are open for posting and which are closed. Transaction OB52 maintains the posting period variants, and this configuration is one of the most critical application controls for the financial close process. Auditors will verify that posting periods are opened and closed in accordance with the organization's close calendar, that access to OB52 is restricted to authorized financial controllers, and that no postings were made to periods that should have been closed. This control was identified in the earlier post on segregation of duties conflicts as a high-priority SoD risk when combined with mass reversal capabilities.
Processing Controls
Processing controls ensure that transactions are processed completely and accurately after they enter the system.
Automated account determination rules govern how SAP assigns general ledger accounts to transactions based on transaction type, material valuation class, movement type, and other configuration parameters. These rules are configured through the IMG (transaction SPRO) and stored in configuration tables specific to each module. Transaction OB40 maintains the automatic posting configuration for materials management. Auditors will verify that automatic account determination rules are consistent with the organization's chart of accounts and accounting policies, and will test a sample of transactions to confirm that the correct accounts were assigned.
Three-way matching in the procure-to-pay cycle verifies that the purchase order, the goods receipt, and the vendor invoice agree in terms of quantity, price, and total amount before the invoice is approved for payment. This automated matching control is a foundational application control for preventing overpayment, duplicate payment, and payment for goods or services not received. The three-way match configuration is established in the purchasing organization settings and the vendor master record. Auditors will verify that the three-way match is activated for the relevant purchasing organizations and vendor categories, and will test a sample of invoices to confirm that the matching process functioned as intended. Invoice documents can be reviewed through transaction MIR4, and blocked invoices pending resolution can be reviewed through MRBR and MIR6.
Batch processing controls ensure that mass processing runs, such as payment runs, dunning runs, and automatic clearing runs, produce complete and accurate results. Auditors will review batch input sessions through SM35 to verify that mass data uploads were authorized and processed correctly, and will reconcile the input and output totals of critical batch processes.
Intercompany processing controls ensure that transactions between company codes within the same corporate group are properly recorded and capable of being eliminated in consolidation. Intercompany documents can be displayed through FBU3, and auditors will verify that intercompany balances reconcile and that the posting rules produce offsetting entries in both company codes.
Output Controls
Output controls ensure that financial reports and data outputs are complete, accurate, restricted to authorized recipients, and protected against unauthorized modification.
Financial statement and report access must be restricted to individuals who have a legitimate business need for the information. General ledger line item reports (FAGLL03 or FBL3N), trial balance reports (S_ALR_87012332 or equivalent), and financial statement reports (F.01 using the financial statement version) should be accessible only to authorized finance and audit personnel. Auditors will review the authorization assignments for financial reporting transactions and verify that access is consistent with the organization's data classification and need-to-know policies.
Report parameter restrictions ensure that users cannot modify report parameters or selection criteria in ways that produce misleading or incomplete output. Auditors will verify that standard financial reports include appropriate parameter controls and that critical reports generate audit trails through the spool system (SP01) that document the parameters used for each execution.
Interface Controls
Interface controls ensure that data exchanged between SAP and external systems is transferred completely, accurately, and securely.
IDoc monitoring and reconciliation is the primary control for data exchanges using SAP's IDoc interface technology. Transactions WE02 and WE05 provide IDoc status monitoring, and auditors will review processing statistics, error rates, and the procedures for investigating and resolving failed transmissions. End-to-end reconciliation procedures that compare record counts and financial totals between the sending and receiving systems are essential for ensuring transfer completeness.
External application interfaces, particularly those related to electronic banking, electronic commerce, and third-party data feeds, require specific audit attention because they involve the transfer of financial data across system boundaries where the organization's internal controls may be less effective. Auditors will walk through each critical interface, evaluate the data validation and error handling procedures, test the reconciliation controls, and assess the security of the data transmission channel including encryption, authentication, and access controls.
Configuration Controls
Configuration controls ensure that changes to SAP's financial configuration, which determines how the system processes transactions, are properly authorized, tested, and documented.
Financial configuration management encompasses all customizing settings that affect financial processing, including document types (maintained in OB57 and OBA7), number ranges (SNRO or module-specific transactions), tolerance groups, tax determination rules, currency settings, and substitution and validation rules. These settings are maintained through the IMG (SPRO) and transported through the standard change management process. Auditors will compare production configuration settings against the organization's documented policies and approved baselines, review the transport history for configuration changes, and verify that each change was authorized and tested before implementation.
Exchange rate maintenance is a specific configuration control that affects the valuation of foreign currency transactions and balances. Exchange rates are stored in table TCURR and maintained through transaction OB08 or through automated feeds from external rate providers. Auditors will verify that exchange rates are updated at the required frequency, that the rates used are consistent with approved external sources, and that the exchange rate type configuration produces the correct valuation results for different transaction categories.
SAP-Specific Business Process Testing
Beyond ITGCs and ITACs, SOX auditors test business process controls that operate within SAP to ensure the reliability of financial reporting. IT and process owners should expect data requests and system demonstrations in several areas.
Segregation of duties within business processes requires IT to produce access reports for the specific transaction combinations relevant to each business cycle. As detailed in the earlier post on SoD conflicts, these analyses focus on whether individual users have access to incompatible functions such as creating vendors and processing payments, creating sales orders and maintaining customer master data, or modifying configuration and posting financial transactions. Custom transactions using the Z or Y namespace are included in this analysis when they perform functions equivalent to standard transactions involving high-risk approvals or financial postings.
Master data integrity testing involves extracting master file data for auditor review. Auditors examine customer and vendor master records for inconsistencies including duplicate entries, incomplete required fields, mismatched bank details, non-standard payment terms, and inactive or blocked records that may indicate data quality issues. These extractions are typically performed through SE16N queries against the relevant master data tables or through dedicated reports within the SUIM User Information System.
System parameter and configuration review involves verifying that the SAP system configuration enforces the organization's financial control policies. Auditors will examine whether three-way matching is enabled, whether posting periods are restricted appropriately, whether approval workflows for parked financial documents (FBV3 for display) are configured with appropriate authorization levels, and whether delegation of approval authority is controlled and documented. Configuration settings in the IMG (SPRO) and the related configuration tables provide the evidence base for these tests.
Manual controls supported by SAP data include controls that are performed by individuals using information produced by the SAP system, such as the manual reconciliation of account balances, the manual review and signing of payment documents, and the manual approval of adjusting journal entries. Auditors will test both the integrity of the system-produced information and the evidence that the manual control activity was performed as designed.
SAP GRC Tools For SOX Compliance
Organizations that have implemented SAP GRC Access Control, SAP GRC Process Control, or equivalent third-party tools from providers such as Pathlock, Soterion, or SecurityBridge have access to automated capabilities that significantly improve the efficiency and effectiveness of SOX compliance testing.
SAP GRC Access Control automates segregation of duties analysis, access risk monitoring, emergency access management, and the user access certification process. It provides continuous monitoring of access risks rather than point-in-time testing, and its workflow capabilities automate the access request, approval, and provisioning process with embedded SoD checks. The access risk analysis identifies SoD conflicts at the point of role assignment, preventing new conflicts from being introduced, and the emergency access management (firefighter) module logs all activities performed under elevated access for subsequent review.
SAP GRC Process Control automates the SOX control testing workflow, including the scheduling of control tests, the collection and storage of evidence, the documentation of test results, and the tracking of deficiency remediation. It provides a centralized repository for the SOX compliance program and enables real-time status reporting to the SOX program manager, the external auditor, and the audit committee.
Continuous control monitoring through these platforms enables organizations to move beyond the periodic testing model, in which controls are tested at specific points during the year, toward a continuous monitoring model that identifies control failures in near real time. This transition reduces the time between a control failure and its detection, enables faster remediation, and provides the auditor with more comprehensive evidence of control effectiveness over the full reporting period.
IT teams should recognize that the implementation of GRC automation tools does not eliminate the need for manual audit procedures. The tools automate the execution of predefined tests, but the design of the test program, the interpretation of results, the evaluation of exceptions, and the assessment of deficiency severity remain professional judgment activities that require human expertise.
Preparing For SOX Audits: Practical Guidance For IT And Process Owners
IT and SAP teams that are prepared for SOX audit requests can reduce the disruption to their operational responsibilities and contribute to a more efficient and constructive audit process.
Anticipate recurring requests. Most SOX audit requests follow predictable patterns that repeat each year. User access listings, terminated employee access reports, transport logs, job execution summaries, configuration comparisons, and master data extractions are requested in every audit cycle. IT teams should develop standardized extraction procedures that produce these reports in the format the auditors require, with the selection parameters documented for consistency and reproducibility.
Understand the audit timeline. SOX audits follow a defined timeline with interim testing, typically conducted during the second and third quarters, and year-end testing conducted in the fourth quarter and early first quarter. IT teams should understand when audit requests will arrive and plan their resources accordingly rather than treating each request as an unexpected interruption.
Maintain a centralized evidence repository. Rather than responding to individual audit requests by extracting data ad hoc, IT teams should maintain a centralized repository of SOX-relevant evidence, including access management documentation, change management records, job monitoring logs, backup verification records, and configuration baselines. This repository reduces the effort required to respond to audit requests and provides a consistent evidentiary foundation across audit cycles.
Know what auditors are looking for and why. When IT teams understand the control objectives behind each audit request, they can provide more useful information and identify potential issues before the auditor discovers them. An IT team that proactively identifies and reports a control deficiency demonstrates control environment maturity and builds credibility with the audit team. An IT team that provides data without understanding its significance may inadvertently withhold information that the auditor needs or provide information that creates questions the team is not prepared to answer.
Coordinate with the SOX program manager. The SOX program manager is responsible for the overall compliance program and serves as the primary interface between the business, IT, internal audit, and the external auditor. IT teams should coordinate their audit preparation and response activities through the SOX program manager to ensure consistency in communication, avoid duplication of effort, and escalate issues through the established governance structure.
From Audit Support To Control Ownership
The IT function's role in SOX compliance is not limited to responding to audit requests and extracting data. IT is a control owner responsible for the design, implementation, operation, and monitoring of the IT general controls and application controls that underpin the organization's financial reporting reliability. The external auditor evaluates these controls. Management assesses them under Section 404(a). But IT operates them, and the quality of that operation determines whether the controls are effective.
IT and SAP teams that understand their controls deeply, that maintain their control evidence proactively, that monitor their own control effectiveness continuously, and that engage with the audit process as partners rather than as subjects of examination contribute directly to the organization's SOX compliance posture and to the reliability of its financial reporting. This is not an administrative burden imposed by the compliance function. It is a governance responsibility that reflects the IT function's critical role in the organization's financial reporting infrastructure.
Examples of SAP Transactions Commonly Relevant in SOX Work
In access and security reviews, the most commonly referenced transactions often include SU01, SUIM, PFCG, SM20, ST01, and where implemented, GRC transactions and firefighter logs.
In change management reviews, SE09, SE10, STMS, SCC4, and transport related tables such as E070 are common points of evidence.
In operations and interface reviews, SM37, DB13, WE02, WE05, SM58, SP01, SM21, and related monitoring transactions are often relevant.
In finance and business process reviews, auditors frequently request transactions such as FB03, FBV3, FBL1N, FBL3N, FBL5N, FS10N, OB52, OBA7, OBB8, GGB0, GGB1, and process specific master data display transactions. Depending on the control design, they may also need access to invoice verification, purchasing, billing, and inventory movement transactions that support business process walkthroughs.
The exact list will always depend on the company’s SAP landscape, modules, workflow design, and control architecture. That is why report logic and table extract quality matter as much as the transaction names themselves.
Why Report Completeness And Accuracy Is Often The Real Audit Issue
A recurring issue in SAP based SOX testing is the assumption that a system generated report is automatically reliable because it comes from SAP. That is not enough.
When a control relies on a report or data extract, management needs to demonstrate that the report is complete and accurate for the purpose used. This may require review of report logic, parameter settings, reconciliation to source populations, validation of custom report design, or evidence that access to the report and underlying configuration is controlled.
This is one of the most important reasons auditors often need IT and SAP support even for business cycle testing. The issue is not only extraction. It is evidencing report reliability.
How IT, SAP, And Audit Teams Can Work Better Together
The most effective SOX programs are collaborative without compromising independence. IT, SAP functional teams, and process owners should understand the control objectives and evidence requirements early, not only when a request arrives during testing. Auditors should communicate why they need a given extract, report, or configuration review and what completeness and accuracy requirements apply. Management should ensure that report ownership, extraction procedures, role responsibilities, and evidence retention are clear.
This reduces rework, improves the quality of testing, and helps prevent late stage disputes over whether evidence is sufficient.
Final Perspective
SOX auditing in SAP environments is not limited to classic ITGC testing, nor is it only a business process exercise handled outside IT. In reality, reliable SOX assurance depends on the interaction between SAP security, configuration, report integrity, interface reliability, and business process execution.
That is why IT and SAP owners should understand what auditors typically request and why. The stronger the coordination among IT, SAP functional teams, process owners, and audit, the more defensible and efficient the SOX program becomes.
In SAP based financial environments, that coordination is not optional. It is part of what makes internal control over financial reporting reliable in practice.
References
Public Company Accounting Oversight Board. Auditing Standard 2201 An Audit Of Internal Control Over Financial Reporting That Is Integrated With An Audit Of Financial Statements
Committee of Sponsoring Organizations of the Treadway Commission. Internal Control Integrated Framework
COBIT guidance relevant to IT general controls, application controls, and IT governance
Leading market practice in SAP SOX testing, SAP security reviews, and report completeness and accuracy validation
SAP standard transactions, tables, and administrative controls commonly used in audit and compliance reviews
SAP Audit Program for SOX IT Compliance
This audit plan is based on professional standards including PCAOB AS 2201, COSO Internal Control Framework, and industry best practices for SAP control environments. It should be tailored to specific organizational risks, system configurations, and regulatory requirements.
This audit plan provides a comprehensive framework for evaluating the design and operating effectiveness of SAP controls within the scope of SOX compliance and internal control over financial reporting (ICFR). The plan aligns with PCAOB Auditing Standard No. 2201, which governs audits of internal control over financial reporting integrated with financial statement audits -10. It incorporates industry best practices for continuous monitoring, automated control benchmarking, and risk-based testing strategies.
Audit Objective: To assess whether SAP IT General Controls (ITGCs) and IT Application Controls (ITACs) are properly designed, implemented, and operating effectively to support the accuracy and integrity of financial reporting.
Scope: SAP ECC/S/4HANA environments supporting financial processes, including FI, CO, MM, and SD modules.
Audit Period: [Insert Period]
Audit Approach: Risk-based sampling, walkthroughs, configuration reviews, and data analytics leveraging SAP tables and transaction codes. Where applicable, the audit will assess opportunities for automated control benchmarking as permitted under PCAOB AS 2201, Appendix B -10.
Part I: SAP IT General Controls (ITGCs)
ITGCs represent the foundation of the SAP control environment. They ensure the proper development, implementation, and operation of applications, as well as the integrity of programs and data -10. Under the PCAOB framework, ITGCs are typically organized into four domains: Access to Programs and Data, Program Changes, Program Development, and Computer Operations -7.
1. Access to Programs and Data
| Control Domain | SAP Controls to Test | SAP Transactions/Tables | Auditor Testing Approach | Enriched Testing Guidance |
|---|---|---|---|---|
| User Access Administration | - User master record creation, modification, and deletion - Role/profile assignments aligned to job functions - Password policy enforcement (complexity, length, aging) - Authentication mechanisms providing individual accountability | Transactions: SU01 (user maintenance), PFCG (role maintenance), SUIM (information system), SU53 (authorization check) Tables: USR02 (user master), AGR_USERS (role assignments), AGR_1251 (authorization values), USR41 (logged-in users) | - Run SUIM SoD conflict reports (e.g., report /SAPQUERY/SUIM_RISK_COMP) - Sample new hires, terminations, and transfers to verify timely access changes - Test terminated users in SU01 (check deletion/disablement) - Review password parameters via SECPOL or RSPARAM | PCAOB Alignment: Addresses I.B (authentication mechanisms) and I.C (timely access revocation) per AS 2201 -7. Pro Tip: Review termination reports from HR interfaces and verify access removal occurred within 24 hours of termination date -7. |
| Privileged Access | - SAP_ALL / SAP_NEW profile assignments - Emergency access (firefighter IDs) - Superuser privilege monitoring | Transactions: SUIM (user by profile), GRAC_SPACCESSLOG (firefighter logs), SM04/SM50 (active users) Tables: USR04 (user master by profile), AGR_USERS (role assignments) | - Identify users with SAP_ALL/SAP_NEW via SUIM - Review firefighter logs for inappropriate activities - Sample emergency access events and verify business justification | Key Insight: Firefighter tools (e.g., GRC Access Control) provide centralized logging of emergency access. Auditors should verify that logs are reviewed by management and that access is temporary -7. |
| Segregation of Duties (SoD) | - Toxic combination identification - Mitigating controls for unavoidable conflicts - Role-level SoD analysis | Transactions: GRAC (GRC Access Control), SUIM SoD reports Tables: AGR_1251 (authorization field values), USR02 (users) | - Run SUIM SoD conflict reports or use GRC Access Control risk analysis - Sample high-risk users and validate mitigating controls - Review role design for conflicting authorizations | Automation Opportunity:
SAP GRC Access Control can automate SoD monitoring, reducing manual
testing time by up to 70% while identifying 95% of access risks -1. Critical T-Codes: PFCG, SU01, SU21, SUIM are essential for roles and authorizations audits -1. |
| Periodic Access Reviews | - Manager attestation of user access - Review of orphaned/deactivated accounts - Removal of inappropriate access | Transactions: SUIM (user analysis reports) Tables: USR02 (user status), AGR_USERS (role assignments) | - Obtain access certification evidence - Sample users and compare access to job descriptions - Identify generic or shared accounts | Control Objective I.D: Requires periodic review of active users and access rights to identify and remove inappropriate access -7. |
2. Program Changes (Change Management)
| Control Domain | SAP Controls to Test | SAP Transactions/Tables | Auditor Testing Approach | Enriched Testing Guidance |
|---|---|---|---|---|
| Transport Management | - Segregation of development, testing, and production systems - Transport request creation, approval, and promotion - Emergency transport handling | Transactions: SE10 (transport organizer), STMS (transport management), SE09 (workbench requests) Tables: E070 (transport header), TPLOG (transport log), CTS_REQUEST | - Trace 25 transports from DEV → QAS → PRD using SE10/STMS - Verify approval documentation exists - Test that emergency transports follow separate approval workflow | Unauthorized Changes Risk: Unauthorized code transports pose risks of bypassing testing protocols and compromising production systems. Control Measure: Limit access to BASIS teams and implement stringent approval processes -1. |
| Client Administration | - Client settings (SCC4) - Client copy and deletion controls | Transactions: SCC4 (client administration), SCCL (client copy) Tables: T000 (client master) | - Review SCC4 settings (protection level, changes without automatic recording) - Test that client deletion is restricted and logged | Critical Control: Deleting clients can result in the loss of critical data. Restrict access to emergencies only and actively monitor system logs -1. |
| Change Approval Documentation | - Evidence of user acceptance testing - Authorization for production moves - Test results retention | Transactions: SE10 (transport display) Tables: E070 (header table) | - Sample transports and verify test evidence exists - Confirm approvals align with authorization matrix | Benchmarking Relevance: If key ITGCs over change management operate effectively, organizations may rely on benchmarked automated controls for subsequent years -10. |
3. Program Development
| Control Domain | SAP Controls to Test | SAP Transactions/Tables | Auditor Testing Approach | Enriched Testing Guidance |
|---|---|---|---|---|
| Custom ABAP Development | - Development standards and methodology - Code review and approval - Segregation of development and production access | Transactions: SE38 (ABAP editor), SE80 (workbench), SE84 (repository info system) Tables: TADIR (repository objects), REPOSRC (source code) | - Review custom program inventory via SE80 - Sample programs and verify development followed standards - Ensure developers lack production access | Best Practice: Prohibit SE38/SE16 access to sensitive tables in production and restrict development T-codes to non-production environments -1. |
| Table Maintenance Restrictions | - Access to table maintenance (SM30) - Critical table change logging | Transactions: SM30 (table maintenance), SE11 (data dictionary) Tables: TDDAT (table logging settings) | - Review users authorized to SM30 - Verify logging is enabled for critical tables - Test table change logs via SE11 logging display | Data Integrity Risk: Unauthorized table access can jeopardize data integrity -1. |
4. Computer Operations
| Control Domain | SAP Controls to Test | SAP Transactions/Tables | Auditor Testing Approach | Enriched Testing Guidance |
|---|---|---|---|---|
| Background Job Monitoring | - Job scheduling and execution - Failed job identification and resolution - Job authorization controls | Transactions: SM37 (job overview), SM36 (job scheduling), SM69 (external commands) Tables: TBTCO (job header), TBTCP (job steps) | - Review SM37 job logs for failures over 90 days - Verify 95%+ job success rate - Sample job definitions and confirm appropriate scheduling | Performance Benchmark: Target 95% job success rate over 90 days for critical financial jobs -2. |
| Backup and Recovery | - Database backup procedures - Backup success monitoring - Disaster recovery testing | Transactions: DB13 (database administration), BRBACKUP/BRRESTORE Tables: DBSTATC (backup history) | - Review DB13 backup logs - Test backup success verification process - Obtain evidence of periodic recovery testing | Automated Controls: SAP HANA and database tools provide automated backup monitoring capabilities -3. |
| Interface Monitoring | - tRFC/qRFC error handling - IDoc monitoring - Interface reconciliation | Transactions: SM58 (tRFC errors), SMQ1/SMQ2 (qRFC queues), WE02 (IDoc display) Tables: EDIDC (IDoc control records) | - Sample interface error logs (SM58) - Verify error resolution within SLA - Trace IDoc end-to-end (WE02 → WE19) | Continuous Monitoring: Organizations should establish automated interface reconciliation procedures to detect failures promptly -6. |
| Spool Management | - Spool access controls - Output management - Print server security | Transactions: SP01 (spool request), SPAD (spool administration) Tables: TSP01 (spool requests) | - Review spool access authorizations (SPAD) - Verify confidential output handling - Test that users cannot view others' spool output | Control Consideration: Spool output containing financial data should be protected from unauthorized viewing -1. |
5. Physical/Environmental (Technical Infrastructure)
| Control Domain | SAP Controls to Test | SAP Transactions/Tables | Auditor Testing Approach | Enriched Testing Guidance |
|---|---|---|---|---|
| Server Access | - Data center physical access controls - Server room entry logs - Video surveillance | Transactions: SM51 (SAP servers), AL11 (directory access) External: Data center access systems | - Review badge access logs for server rooms - Verify visitor logs and escorts - Test that unauthorized personnel cannot access | Cloud Consideration: Under the Shared Responsibility Model, the cloud provider secures infrastructure, but the customer remains responsible for application-level controls -6. |
| HANA Database Security | - HANA user administration - Database audit logging - System replication security | External: HDBSQL, HANA Studio Tables: SYS.USERS (HANA catalog) | - Review HANA admin access via HDBSQL - Verify audit logging enabled (HANA audit) - Test that only authorized users have database access | High-Risk Access: Database-level access bypasses application controls and should be strictly limited -6. |
| OS-Level Security | - OS user accounts (Windows/Linux) - File system permissions - SAP <sid>adm access | Transactions: AL11 (directory listing) External: OS commands | - Review OS users with SAP privileges - Verify OS patch levels - Test file system permissions for SAP directories | Compliance Note: OS and database access represent critical components of the ITGC environment and must be evaluated for segregation of duties -7. |
Part II: SAP IT Application Controls (ITACs)
IT Application Controls are automated controls embedded within SAP financial modules (FI/CO/MM/SD) that ensure the completeness, accuracy, authorization, and validity of financial transactions -10. A well-designed internal control framework should include a balance of manual, automated, and semi-automated controls, with a significant component being automated -10.
Key ITAC Testing Principles
When testing ITACs, auditors should focus on five critical areas -4:
Control Configuration: Verify the control logic (e.g., three-way match tolerances, posting restrictions) is configured as per policy.
Execution Evidence: Review system-generated evidence (logs, workflow approvals) showing the control operated.
Change Management: Validate that only authorized users can modify control configurations (linked to ITGC).
Access Management: Ensure users cannot bypass controls through excessive system rights.
Exception Handling: Review if overrides or tolerance breaches are tracked, approved, and reported.
ITAC Testing by Domain
| Domain | SAP Controls to Test | SAP Transactions | Testing Approach | Enriched Testing Guidance |
|---|---|---|---|---|
| Input Controls | - G/L posting validation - Vendor/customer master validation - Tolerance limits (e.g., three-way match) - Posting period locks | Transactions: FB01/F-02 (postings), XK01/XD01 (master data), OBB8 (tolerances), OB52 (posting periods) Tables: T030 (account determination), T007V (tolerance groups) | - Test invalid G/L postings (FB01) with incorrect account combinations - Verify vendor duplicate checks via XK01 - Attempt to bypass tolerances (OBB8) and confirm system blocks - Test posting period lock (OB52) by posting to closed period | Three-Way Match Example: Back-end testing reviews tolerance values; front-end testing emulates a user attempting to trigger the tolerance -10. Pro Tip: Use T-codes like ME23N, FB03, OB52 to capture evidence rather than relying on screenshots -4. |
| Processing Controls | - Automatic account assignments - Tax calculation accuracy - Intercompany eliminations - Foreign currency valuation | Transactions: FAGL_FC_VAL (foreign currency valuation), FB05 (post with clearing), OB40 (automatic account determination) Tables: BSEG (document segments), BSIS (G/L indices), FAGLFLEXA (General Ledger) | - Recalculate tax postings (FB01) and compare to system calculation - Verify batch input totals (SM35) reconcile to source - Test clearing logic (FBL1N/FBL5N) for proper open item management - Validate foreign currency revaluation (FAGL_FC_VAL) | Automated Control Opportunity: Many processing controls can be benchmarked. If ITGCs are effective, organizations may rely on prior testing for up to three years -10. |
| Output Controls | - Financial statement access restrictions - Report parameter enforcement - Digital signature validation | Transactions: FAGLL03 (line items), S_ALR_87012284 (trial balance), F.01 (financial statement) Tables: TSTC (transaction codes), USR12 (user authorizations) | - Test unauthorized report access by users without required roles - Verify report completeness (sample documents match report output) - Review output logs (SP01) for sensitive report distribution | Control Consideration: Access to financial statements should be restricted based on job function and reviewed periodically -4. |
| Interface Controls | - IDoc monitoring/reconciliation - PI/PO interface validation - File import controls | Transactions: WE02/WE05 (IDoc display), SM58 (tRFC errors), SMQ1/SMQ2 (qRFC queues), WE19 (IDoc testing) Tables: EDIDC (IDoc control), EDIDS (IDoc status) | - Trace IDoc end-to-end (WE02) from inbound to posted document - Reconcile interface totals between source system and SAP - Test error handling (WE19) by simulating failures - Verify file import logs confirm completeness | Continuous Monitoring: Implement automated reconciliation tools to detect interface failures quickly -5. Pro Tip: Use SM58 to identify failed tRFC calls that could impact financial data completeness. |
| Configuration Controls | - Financial configuration changes - Document type / number ranges - Validation/substitution rules - Tolerance groups | Transactions: SPRO (IMG), OB57 (document types), OBA7 (document types), GGB1 (validations) Tables: T001 (company codes), T003 (document types), NRIV (number ranges) | - Review config change transports (SE10) for authorization - Test validation rule bypass (GGB0) to confirm enforcement - Perform number range gap analysis (SNRO) for critical docs - Compare PRD configuration to baseline transports | Benchmarking Strategy: Configuration can be benchmarked in year one and monitored in subsequent years if no changes occur -10. Critical T-Codes: SPRO (IMG), OB52 (posting periods), OBB8 (tolerances) are essential for config audits -4. |
Part III: SAP GRC Solutions for SOX Automation
SAP provides dedicated Governance, Risk, and Compliance modules that automate SOX testing and monitoring activities. These tools significantly reduce manual effort while improving control effectiveness -2.
| GRC Module | SOX Coverage | Key Transactions | Auditor Considerations |
|---|---|---|---|
| GRC Access Control | SoD monitoring, access risk analysis, emergency access management (Firefighter), role management | GRAC_INIT, GRAC_SPM, GRAC_FIREFIGHTER | - Run risk analysis reports to identify SoD conflicts - Review Firefighter log (GRAC_SPACCESSLOG) for emergency access - Test role provisioning workflows |
| GRC Process Control | Control testing workflows, evidence collection, issue management, continuous monitoring | GRPC_WF_BC, GRPC_TEST, GRPC_ISSUE | - Review automated control testing results - Verify evidence collection automation - Test issue management workflows -2 |
| GRC Audit Management | SOX audit planning, execution, reporting, workpaper management | GRWAUDITOR | - Evaluate audit workflow automation - Review workpaper documentation - Test report generation capabilities |
Automation Benefits: SAP GRC Process Controls (PC) is widely used to automate controls and break down silos across enterprises. By carefully using data sources, organizations can eliminate the first level of testing for configuration, master data, and transaction data -2. SAP Risk and Assurance Management (RAM) provides a SaaS-based approach with comprehensive automated control procedures aligned with most business requirements -2.
Part IV: Automated Control Benchmarking Strategy
What is Automated Control Benchmarking?
Benchmarking, as outlined in PCAOB AS 2201, Appendix B, allows organizations to reduce internal and external audit efforts while maintaining compliance with internal control requirements -10. A benchmarked automated control, once tested thoroughly, can be relied upon in subsequent periods without retesting, provided that key ITGCs remain effective.
The Three-Year Benchmarking Cycle
| Year | Activities | Audit Effort |
|---|---|---|
| Year 1 (Benchmark Year) | - Back-end testing: Assess, define, and document configuration values stored in SAP tables - Front-end testing: Perform "test of one" positive/negative tests to validate control operation | Highest effort (establish baseline) |
| Year 2 (Reliance Year) | - Verify no unauthorized configuration changes occurred - Re-run back-end configuration review only - No front-end testing required if ITGCs effective | Reduced effort |
| Year 3 (Reliance Year) | - Same as Year 2 - Monitor for significant changes | Reduced effort |
| Year 4 (Re-benchmark) | - Repeat Year 1 activities - Required every three years or after significant changes | Highest effort again |
When to Re-Baseline
Every three years as standard practice
After significant configuration changes
Following major system upgrades (e.g., ECC to S/4HANA)
When control logic is modified
Exception: High-risk areas (e.g., revenue recognition controls) may not be eligible for benchmarking and require annual testing -10.
Example: Three-Way Match Benchmarking
| Activity | Description | SAP Transactions/Tables |
|---|---|---|
| Back-End Testing | Review tolerance values for quantity and amount variances between purchase order, goods receipt, and invoice | OMB2 (tolerance keys), OMRM (invoice verification), Tables: T169G (tolerance limits) |
| Front-End Testing | Create test invoice exceeding tolerance; verify system blocks payment | MIRO (invoice entry), MIR4 (invoice display) |
| Change Monitoring | Quarterly review of configuration tables; verify no unauthorized changes | SE16 (table display), SE14 (table editor) |
Part V: Sampling Methodology and Testing Approach
Sample Size Guidelines (Based on Risk Assessment)
| Control Frequency | Low Risk | Moderate Risk | High Risk | Notes |
|---|---|---|---|---|
| Daily / Continuous | 25-30 | 40-50 | 60+ | Use data analytics for continuous controls |
| Weekly | 10-15 | 20-25 | 30-40 | Consider population size |
| Monthly | 5-8 | 8-12 | 15-20 | Test across months |
| Quarterly | 3-4 | 4-5 | 5-6 | Cover all quarters if possible |
| Annually | 1 | 1-2 | 2-3 | Test design and operating effectiveness |
SAP Transaction Testing Approach
| Audit Procedure | SAP Transactions | Evidence Documentation |
|---|---|---|
| User Access Review | SU01, SUIM, PFCG | Screenshots of user profiles, role assignments |
| Transport Review | SE10, STMS | Transport logs, approval emails, test evidence |
| Job Monitoring | SM37 | Job log screenshots, failure reports, resolution documentation |
| Posting Validation | FB03, FBL1N, FBL5N | Document headers, line items, reversal logs |
| Configuration Review | SPRO, OB52, OBB8 | Configuration screenshots, transport numbers |
Leveraging SAP Tables for Evidence
| Control Area | Key SAP Tables | Sample Query Purpose |
|---|---|---|
| Access Controls | USR02, AGR_USERS, UST10, AGR_1251 | Identify user authorizations and roles |
| Change Management | E070, TPLOG, CTSREQUEST | Track transport history and approvals |
| Background Jobs | TBTCO, TBTCP, TBTCM | Monitor job execution and failures |
| Financial Postings | BSEG, BKPF, BSIS, BSIK, BSAK | Analyze transaction details |
| Audit Logs | SM20_LOG, BALLOG, CDHDR/CDPOS | Review change documents and audit trails |
Part VI: Evidence Collection and Documentation
Evidence Requirements
For each control tested, auditors should document -5:
Control Description: What the control does and why it matters
Test Procedure: Steps performed to evaluate the control
Population: Complete set of items from which samples were drawn
Sample Selection: How samples were chosen (random, judgmental, stratified)
Results: Pass/Fail with supporting documentation
Exceptions: Any deviations and their impact
Remediation: Actions taken to address deficiencies
Evidence Collection Best Practices
Use System-Generated Reports: Run reports directly from SAP rather than accepting screenshots from process owners -4
Timestamp Documentation: Include system timestamps in evidence
Parameters Visible: Ensure date ranges, company codes, and selection criteria are visible
Audit Trail: Document the complete path to evidence (transactions used, tables queried)
Exception Tracking: Log all exceptions, even those subsequently resolved
Automated Evidence Collection
Modern tools enable automated evidence collection, dramatically reducing manual effort -5:
| Step | Description | SAP Implementation |
|---|---|---|
| Control Evidence Definition | Define controls and required evidence (reports, logs, screenshots) | GRC Process Control evidence requirements |
| System Access & Data Retrieval | Automatically access SAP and run reports/queries | Scripted via SAP GUI scripting or APIs |
| Evidence Validation | Perform basic checks (date ranges, completeness, signatures) | GRC Process Control validation rules |
| Evidence Organization | Store by control ID, period, owner | GRC Audit Management repositories |
| Exception Flagging | Identify missing/invalid evidence automatically | GRC workflow notifications |
Part VII: Common Findings and Remediation Guidance
| Finding Area | Typical Deficiency | Remediation Recommendation |
|---|---|---|
| Segregation of Duties | Users with conflicting access (e.g., vendor master and payment approval) | - Re-design roles to eliminate conflicts - Implement mitigating controls - Use GRC Access Control for automated monitoring |
| Emergency Access | Firefighter logs not reviewed; generic IDs used | - Establish monthly review process - Require business justification for all emergency access - Disable generic accounts |
| Transport Approvals | Missing approval documentation for production moves | - Enforce workflow approvals in Transport Management - Retain all approval emails/test evidence |
| Failed Background Jobs | Critical financial jobs failing without detection | - Implement automated job monitoring (CCMS) - Establish alerting for job failures - Define SLAs for resolution |
| Configuration Drift | Production configuration differs from approved baseline | - Lock production configuration access - Require transports for all config changes - Conduct quarterly configuration comparisons |
| Interface Errors | tRFC errors unresolved for extended periods | - Monitor SM58 daily - Establish error resolution SLA - Automate reconciliation processes |
Part VIII: Key SAP Tables Reference for Auditors
| Table Name | Description | Common Audit Use |
|---|---|---|
| USR02 | User master (logon data, account status) | Identify active/inactive users, locked accounts |
| AGR_USERS | Role assignments by user | Understand user entitlements |
| AGR_1251 | Authorization field values | Analyze detailed authorizations within roles |
| UST10 | Authorizations per profile | Cross-reference authorizations |
| E070 | Transport request header | Track transport creation and status |
| TPLOG | Transport log | Verify transport execution history |
| TBTCO | Background job header | Monitor job schedules and status |
| TBTCP | Background job steps | Analyze individual job steps |
| BSEG | Accounting document segments | Line-item details for financial transactions |
| BKPF | Accounting document header | Document-level financial data |
| CDHDR / CDPOS | Change document header/items | Track changes to master data and configurations |
| EDIDC | IDoc control records | Interface monitoring and reconciliation |
| T001 | Company codes | Financial entity configuration |
| NRIV | Number ranges | Gap analysis for critical documents |
Part IX: Conclusion and Auditor Recommendations
Key Success Factors for SAP SOX Audits
Shift from Manual to Continuous Monitoring: Traditional periodic audits create gaps between testing cycles. Organizations should adopt continuous control monitoring to maintain real-time visibility into their compliance posture -6.
Leverage Automated Control Benchmarking: Implement the three-year benchmarking cycle permitted under PCAOB AS 2201 to significantly reduce testing effort while maintaining compliance -10.
Integrate GRC Solutions: SAP GRC Access Control and Process Control automate SoD monitoring, control testing, and evidence collection, reducing manual effort by up to 70% -1-2.
Maintain Audit-Ready Documentation: Establish centralized repositories for control evidence, configuration baselines, and change documentation to streamline audit preparation -5.
Collaborate Across Functions: Ensure IT, security, compliance, and audit teams work from a single source of truth regarding control design and operating effectiveness -6.
Recommended Next Steps
Conduct a baseline assessment of current SAP control environment
Identify opportunities for automated control benchmarking
Implement GRC tools for continuous monitoring where feasible
Establish quarterly configuration reviews to maintain benchmark status
Document control rationalization to eliminate redundant testing
Appendices
Appendix A: Critical T-Codes by Audit Domain
| Domain | T-Codes |
|---|---|
| User Administration | SU01, SU01D, SU10, PFCG, SUIM, SU53 |
| Authorization Analysis | SUIM, SU24, SU25, SU56 |
| Change Management | SE09, SE10, STMS, SCC4, SE14 |
| Background Jobs | SM36, SM37, SM69, SM49 |
| System Monitoring | SM50, SM51, SM66, AL08 |
| Database/OS | DB13, DB02, AL11, OS01 |
| Financial Postings | FB01, FB03, FB50, F-02, FBL1N, FBL5N |
| Configuration | SPRO, OB52, OBB8, OB40, OVA8 |
| Interfaces/IDocs | WE02, WE05, WE19, SM58, SMQ1 |
| Audit/Logs | SM19, SM20, SM18, SE30 |
Appendix B: Automated Control Benchmarking Eligibility
| Control Type | Benchmarking Eligible? | Notes |
|---|---|---|
| Configuration controls (tolerances, limits) | Yes | Re-baseline every three years |
| Automated calculations (tax, currency) | Yes | Provided logic unchanged |
| System-generated reports | Yes | Validate report logic year one, monitor changes |
| User access controls | No | Must test annually (high risk) |
| Interface controls | Conditional | Depends on complexity and risk |
| Revenue-related automated controls | No | PCAOB high-risk area -10 |
Appendix C: Sample Evidence Documentation Template
| Field | Example |
|---|---|
| Control ID | ITAC-FI-012 |
| Control Description | Three-way match tolerance enforced for vendor invoices |
| Test Procedure | 1. Review OMB2 configuration for tolerance keys 2. Create test invoice exceeding quantity tolerance (MIRO) 3. Verify system blocks payment and generates error |
| Population | All vendor invoices processed in [period] |
| Sample Size | 25 invoices (5 per company code) |
| Transactions Used | MIRO, MIR4, OMB2, SE16 (table T169G) |
| Results | Pass - All test invoices correctly blocked |
| Exceptions | None |
| Evidence Location | \Audit\FY2025\ITAC\FI-012_Evidence.pdf |
Appendix D: Regulatory and Standards Mapping
| Requirement | SAP Control Area | Audit Procedure Reference |
|---|---|---|
| PCAOB AS 2201 | Automated control benchmarking | Part IV |
| COSO 2013 | Control environment, monitoring | Part I-II |
| ISO 27001:2022 | Access control, change management | Part I |
| SOX Section 404 | ICFR assessment | All sections |
| EU AI Act (Article 10) | Data governance for AI systems | N/A (future) |
Get the latest in corporate governance, risk, and compliance on Twitter