SDLC Controls, Data Migration Verification, and Every T-Code You Need
I once watched an organization go live with SAP S/4HANA after 14 months of implementation effort, a $22 million investment, and exactly zero documented control design decisions. The system worked. Transactions processed. Reports generated. And the first post-go-live audit produced 47 findings, 11 of which required configuration changes that cost more than $1.8 million in rework.
The implementation team had built exactly what was specified. The specifications never included controls.
Auditing an SAP S/4HANA implementation is fundamentally different from auditing a production system. You are evaluating a moving target. Design decisions change weekly during agile sprints. Data migration scripts run and rerun across environments. Security roles evolve as functional teams discover new requirements. The controls you need to test are not just the future-state business process controls. They include the SDLC controls governing the implementation itself, the program governance structures supporting decision-making, the data migration procedures protecting data integrity during transition, and the security controls safeguarding non-production environments that contain real organizational data.
This post covers the complete audit approach for SAP S/4HANA implementations and upgrades, with specific T-codes, tables, fields, and testing procedures for each control category. Whether you are performing a concurrent audit during the implementation or a retrospective review shortly after go-live, every technique here applies.
The Five Control Categories for Implementation Audits
An SAP S/4HANA implementation audit covers five distinct control categories that operate simultaneously throughout the project lifecycle. Missing any one of them creates gaps that compound as the implementation progresses.
Program governance and risk management controls support the management of the implementation itself. Business requirement traceability and change controls ensure that what gets built matches what was designed and approved. Organizational change management controls address the human side of adoption and training. Data migration controls protect the integrity of information moving from legacy systems into SAP S/4HANA. Security controls govern access to non-production environments and the design of production security roles.
These categories mirror the ITGCs discussed for production environments but apply to the pre-production environment during the development process. The stakes are different. A misconfigured control in production can be corrected through the standard change management process. A misconfigured control baked into the implementation design becomes the baseline that everything else builds upon.
Original implementation tip: When scoping your implementation audit, map each planned test procedure to one of these five categories. If your audit plan is heavily weighted toward program governance with minimal coverage of data migration and security, rebalance immediately. Data migration failures and security design gaps are the two areas that produce the most damaging post-go-live findings, and they are the two areas most frequently underaudited during implementations.
Program Governance and Risk Management Controls
Program governance controls are the foundation of the implementation audit. They determine whether the right people are making the right decisions at the right time with the right information. Without effective program governance, every other control category becomes unreliable.
What to Test
The project plan should exist as a detailed, actively maintained artifact with control-related activities included as explicit tracked tasks. Verify that the plan includes milestones for risk identification, control design, control configuration, control testing, and control training. Each milestone should have an assigned owner, a due date, and status tracking.
Review the steering committee charter and meeting minutes. The steering committee should include representation from business process owners, IT leadership, the system integrator, and internal audit. Meeting minutes should document decisions made, risks discussed, and open issues tracked. Look for evidence that control-related topics appear on steering committee agendas. If GRC topics never surface in steering committee discussions, the governance structure is treating controls as a subordinate concern.
Examine the issue and risk tracking process. Every implementation generates issues. The question is whether those issues are documented, assigned to owners, tracked to resolution, and escalated when deadlines slip. Request access to the issue log and verify that entries include severity ratings, assigned owners, target resolution dates, actual resolution dates, and escalation history.
Go-Live Readiness Decision Controls
The go-live decision is the single highest-stakes governance checkpoint in any SAP S/4HANA implementation. Test the following elements of the go-live readiness process.
Who participates in the go-live decision? This should include business process owners for every major process area, IT leadership, the system integrator project lead, internal audit, and executive sponsorship. If the go-live decision is made solely by IT or solely by the system integrator, the governance structure has a fundamental problem.
What criteria must be met before go-live is approved? Documented go-live criteria should include completion percentages for functional testing, user acceptance testing, integration testing, data migration validation, security role assignment, control configuration, and training delivery. Each criterion should have a defined threshold. "Testing complete" is not a criterion. "95% of critical test scenarios passed with zero severity-1 defects open" is a criterion.
How are unresolved issues handled? Not every issue can be resolved before go-live. The governance process should require explicit documentation of any open issues carried into production, the risk assessment for each, compensating controls or workarounds in place, and formal acceptance by a business process owner with authority to accept the risk.
Use SAP Solution Manager transaction SOLAR01 (Business Blueprint) and SOLAR02 (Configuration) to verify traceability between business process documentation and configured objects. In SOLAR01, the business scenario structure should map to functional specifications. In SOLAR02, each configuration object should link to a test case. Gaps in this mapping indicate either incomplete documentation or untested configuration.
Original implementation tip: I have audited implementations where the go-live readiness checklist existed as a single spreadsheet maintained by the project manager, with no independent verification of any line item. The project manager checked boxes based on verbal confirmation from functional team leads. When I tested three of the "completed" items, two had open defects that the functional team had decided were acceptable but never formally documented as accepted risks. Your audit should independently verify at least a sample of go-live readiness criteria rather than relying on the project manager's attestation.
Budget and Scope Change Monitoring
Request the original project budget and compare it to actual spending at regular intervals throughout the implementation. Significant budget overruns, particularly in specific functional areas, often indicate scope changes, rework, or design problems that may affect control design.
Review the scope change management process. Every scope change should be documented with a description of the change, the business justification, the impact on timeline and budget, the impact on control design (if any), and formal approval by the steering committee or designated authority.
Query the project management tool for all approved scope changes and verify that each change was assessed for control impact. A scope change that adds a new payment method, for example, requires assessment of whether existing payment controls cover the new method or whether additional controls are needed.
For SAP Solution Manager based implementations, use transaction SMSY (System Landscape Directory) to verify the system landscape configuration. Confirm that the landscape follows the standard three-system architecture: development (DEV), quality assurance (QAS), and production (PRD). Verify that transport routes enforce the expected path. Any deviation from the standard landscape introduces risk that changes can reach production without proper testing.
Query table TCETRAL (Transport Control System) and TMSCSYS (TMS System Configuration) to verify transport route definitions. In TMSCSYS, the fields SYSNAM (system name), SYSTYPE (system type, where VIRTUAL indicates a virtual system), and DOMNAM (transport domain name) confirm the landscape structure. Cross-reference with transaction STMS (Transport Management System) to verify that transport routes match the documented landscape design.
Business Requirement Traceability and Change Controls
Requirements traceability is the audit trail connecting business needs to functional specifications to configuration to testing to training. In SAP S/4HANA implementations, this trail is complicated by the one-to-many and many-to-one relationships between artifacts. A single business requirement may generate multiple functional specifications. Multiple requirements may be addressed by a single configuration object. A requirement may be tested across several test scenarios and test scripts.
What to Test
Select a sample of business requirements from the requirements document. For each requirement, trace forward through the following chain: business requirement to functional specification to technical specification (if applicable) to configuration object or custom development to test scenario to test script to test results to training material.
Gaps in any link of this chain indicate a traceability failure. A requirement without a corresponding test scenario means something was built but never verified. A test scenario without a link back to a requirement means testing effort was spent on something that may not have been requested. A requirement without training material means users were not prepared for a feature they will need to use.
For agile implementations, traceability becomes more challenging because requirements evolve across sprints. Verify that the agile backlog maintains version history for user stories and that acceptance criteria for each story include control-related considerations where relevant.
Transport and Change Control During Implementation
Even during the implementation, changes to configuration and custom development should follow a controlled process. Query table E070 (Transport Request Header) for all transports created during the implementation period. Key fields include TRKORR (transport request number), TRFUNCTION (transport category, where K is workbench request and W is customizing request), TRSTATUS (status, where R is released, D is modifiable, and L is modifiable and protected), AS4USER (owner of the transport), AS4DATE (last changed date), and AS4TEXT (short description of the transport).
Join with table E071 (Object Entries in Transport Requests) to see the specific objects within each transport. Fields include TRKORR (transport request), PGMID (program ID, where R3TR indicates a main object), OBJECT (object type, where CDAT is view cluster data, TABU is table contents, PROG is program, and FUNC is function group), OBJ_NAME (object name), and LOCKFLAG (lock indicator).
Look for the following red flags in transport data:
Transports released directly to production bypassing quality assurance. Filter E070 for TRSTATUS equal to R and cross-reference with TPLOG (Transport Log) to verify the import path. The TPLOG fields TRKORR (transport request), TRSYSNAM (target system name), TRSTEP (transport step, where 6 is import), TRTIME (execution timestamp), and TRRETCODE (return code, where 0 is success) show exactly where each transport was imported and whether it succeeded.
Transports owned by users who are not part of the authorized development team. Compare AS4USER values against the documented list of authorized developers.
Transports released outside of normal working hours. Filter on AS4DATE and the timestamp in TPLOG for weekend or late-night releases that may indicate unauthorized changes.
Transports with return codes above 4 in TPLOG, indicating warnings or errors during import. A return code of 8 or higher means the transport had errors that may have left objects in an inconsistent state.
Configuration Documentation and Audit Trail
Every configuration decision should be documented with the business rationale, the specific IMG path, the configuration values selected, the alternatives considered, and the approver. This documentation serves as both implementation governance and future audit defense.
Use transaction SCDO (Display Change Documents for Object) or query tables CDHDR (Change Document Header) and CDPOS (Change Document Items) to build a complete configuration change history for the implementation period.
In CDHDR, the key fields are OBJECTCLAS (object class, such as ADRESSE for address data, KRED for vendor master, DEBI for customer master, MATERIAL for material master, or various configuration object classes), OBJECTID (specific object identifier), CHANGENR (change document number), USERNAME (user who made the change), UDATE (date of the change), UTIME (time of the change), and TCODE (transaction code used to make the change).
In CDPOS, the key fields are OBJECTCLAS (same as CDHDR), CHANGENR (change document number linking to CDHDR), TABNAME (database table where the change occurred), TABKEY (table key identifying the specific record), FNAME (field name that was changed), CHNGIND (change indicator, where U is update, I is insert, E is delete, and J is initial insert), VALUE_NEW (new field value), and VALUE_OLD (previous field value).
Filter CDHDR on UDATE covering the implementation period and sort by TCODE and USERNAME. Configuration changes made through transaction SPRO (Customizing) or direct table maintenance through SM30 (Call View Maintenance) should be traceable to documented design decisions. Changes made through unexpected transactions or by unauthorized users require investigation.
Original implementation tip: On one implementation, I found 340 configuration changes made directly through SM30 by the system integrator's technical lead, none of which appeared in the configuration documentation. When I asked about them, the explanation was "those were just technical settings that don't affect business processes." Fourteen of those changes modified tolerance groups, payment terms defaults, and document type assignments. All of them affected business processes. All of them should have been documented. Your audit should reconcile the total population of configuration changes in CDHDR against the documented configuration decisions in the implementation documentation. The gap between these two numbers tells you how much undocumented configuration exists in your system.
Organizational Change Management Controls
Organizational change management during an SAP S/4HANA implementation determines whether users can actually operate the system correctly after go-live. Since the COVID-19 pandemic shifted many implementations to hybrid remote environments, the approach to training delivery and adoption tracking has changed significantly.
What to Test
Verify that a formal training plan exists covering every role that will interact with SAP S/4HANA. The training plan should map SAP transactions and processes to specific user roles and include both classroom (or virtual) instruction and hands-on practice in a training environment.
For each major process area, verify that training materials exist, were reviewed for accuracy by the functional team, include control-related procedures (not just transaction execution steps), and were delivered to all users assigned to the relevant roles.
Request training attendance records. Cross-reference attendance against the user list in SAP. Users who were assigned SAP access but did not complete training represent a risk. They will interact with the system without understanding the intended process, increasing the likelihood of control bypasses and data entry errors.
Verify that training covers not just how to execute transactions but why specific controls exist. Users who understand that the three-way match process prevents unauthorized payments are less likely to bypass it by entering invoices through the invoice-only process. Users who only learned the mechanical steps of entering a purchase order but never understood the release strategy will find workarounds when the system blocks their transaction.
Test whether the training environment configuration matches the production environment configuration. Discrepancies between training and production create user confusion and increase error rates during the initial go-live period. Use transaction SCC4 (Client Administration) to verify client configurations across environments. In table T000 (Clients), compare the fields CCCATEGORY (client category), CCCORACTIV (changes and transports for client-specific objects), and CCNOCLIIND (cross-client object changes restriction) between the training client and the production client.
Original implementation tip: The most overlooked aspect of organizational change management is control performer training. Your implementation probably has hundreds of configured controls. Each control has a human performer, a system performer, or both. For every manual and system-dependent control, somebody needs to know that the control exists, understand what they are supposed to do, and know what to do when the control identifies an exception. I have seen implementations where the accounts payable supervisor was designated as the reviewer of the blocked invoice report (transaction MIR6) but was never told this was their responsibility. The report existed. The control was designed. Nobody performed it for six months after go-live because the person who was supposed to do it did not know they were supposed to do it. Include control performer responsibilities in role-specific training materials and verify that each control performer acknowledges their responsibilities before go-live.
Data Migration Controls: The Highest-Risk Area Most Audits Undercover
Data migration is where implementations fail most visibly. Incorrect balances, duplicate records, missing master data, and corrupted transactional history create problems that surface for months after go-live. The data migration process includes mapping (defining how source data translates to target data structures), cleansing (correcting data quality issues before migration), and loading (executing the actual migration into SAP S/4HANA).
Accountability and Ownership
The first thing to test is who owns the data migration process. Accountability between the organization and the system integrator is frequently unclear. The system integrator typically builds the migration tools and scripts. The organization owns the data and is responsible for its accuracy. The handoff between these responsibilities is where errors occur.
Verify that a documented data migration plan exists specifying which data objects are being migrated, the source system for each object, the mapping rules from source to target, the cleansing rules and who approves them, the migration sequence (dependencies between objects), the reconciliation procedures after each load, and the rollback plan if migration fails.
Data Mapping and Transformation Verification
Select a sample of critical data objects. For each, review the mapping specification that defines how source fields translate to SAP S/4HANA target fields.
For business partner migration (replacing legacy vendor and customer masters), the target table BUT000 (Business Partner General Data) contains fields PARTNER (business partner number), BU_GROUP (business partner grouping, which determines the number range and field configuration), TYPE (business partner category, where 1 is person and 2 is organization), BU_SORT1 (search term 1), NAME_ORG1 (name of organization for category 2), NAME_FIRST (first name for category 1), NAME_LAST (last name for category 1), CRDAT (creation date), and CRUSR (created by user).
For vendor-specific data, table LFA1 (Vendor General Data) migrates to BUT000 with role assignment through table BUT100 (Business Partner Roles), which contains fields PARTNER (business partner number), RLTYP (role category), and VALID_FROM and VALID_TO (validity period). The field RLTYP value FLVN01 indicates a vendor role.
For financial data migration, table BKPF (Accounting Document Header) contains BUKRS (company code), BELNR (document number), GJAHR (fiscal year), BLART (document type), BLDAT (document date), BUDAT (posting date), MONAT (fiscal period), WAERS (document currency), USNAM (user who entered the document), TCODE (transaction code used), BSTAT (document status, where blank means normal document and S means noted item), and CPUDT (entry date). Migration postings should have a distinct document type or reference identifying them as migration entries.
Table BSEG (Accounting Document Segment) contains the line item detail with fields BUKRS (company code), BELNR (document number), GJAHR (fiscal year), BUZEI (line item number), BSCHL (posting key), KOART (account type, where S is GL, D is customer, K is vendor), HKONT (GL account number), WRBTR (amount in document currency), DMBTR (amount in local currency), and ZUONR (assignment number).
Migration Reconciliation Testing
For each migrated data object, perform three reconciliation checks.
Completeness: Compare record counts between source and target. For vendor masters, count records in the legacy vendor table and compare against count in BUT000 filtered by CRDAT matching the migration date and BUT100 where RLTYP equals FLVN01. Any difference requires explanation and documentation.
Accuracy: Select a sample of migrated records and compare field values between source and target. For financial balances, reconcile total debits and credits by company code, GL account, and fiscal period between legacy trial balance reports and SAP S/4HANA trial balance (transaction S_ALR_87012277 or FAGLB03 for the new GL). Discrepancies at the account level indicate mapping errors or transformation problems.
Authorization: Verify that migration activities were performed by authorized users using authorized tools. Query BKPF for migration document types and examine the USNAM and TCODE fields. Migration postings should come from designated migration user IDs using SAP S/4HANA Migration Cockpit (transaction LTMC or LTMOM) or approved migration programs. Postings made through FB01 (Post Document) or other manual entry transactions during the migration window indicate potential unauthorized data manipulation.
Use transaction LTMOM (SAP S/4HANA Migration Object Modeler) to review the migration objects configured for your implementation. This transaction shows which standard migration objects were used, any custom migration objects created, and the status of each migration run.
Data Cleansing Controls
Data cleansing is necessary but introduces its own risks. When the organization edits source data before migration to improve quality, the potential exists for intentional or accidental alteration of meaningful information.
Test the following controls over the cleansing process. Access to cleansing tools and staging areas should be restricted to authorized personnel. All cleansing changes should be logged with before and after values. Cleansing rules should be documented and approved by data owners. A reconciliation should confirm that cleansing activities did not change total financial balances (unless a documented and approved adjustment was intended).
If cleansing occurs in a staging database or file system before data enters SAP, verify that network access controls protect the staging area from unauthorized access. This is an ITGC that applies during the implementation, not just after go-live.
For personally identifiable information, verify that data privacy regulations are enforced throughout the migration process. GDPR, HIPAA, and similar regulations apply to data in transit, not just data at rest. If real production data containing PII is used in non-production environments during the implementation, access controls must restrict that data to authorized users, and the organization should have documented justification for using real data rather than anonymized test data.
Original implementation tip: On a recent implementation, the data migration team cleansed vendor bank details by removing duplicates and correcting formatting errors. Reasonable work. The problem was that the cleansing process was performed by a contractor using a personal laptop with no access logging. When the first post-go-live payment run sent $340,000 to an incorrect bank account, the investigation could not determine whether the bank detail was wrong in the legacy system or was changed during cleansing, because there was no audit trail for the cleansing activity. The payment was eventually recovered, but the incident triggered a full re-validation of all migrated bank details at a cost far exceeding what proper cleansing controls would have required. Log every cleansing change with before and after values, the user who made the change, and the timestamp. Store those logs permanently.
Security Controls During Implementation
Security during an SAP S/4HANA implementation operates at two levels: access control for the non-production environment during the implementation itself, and the design and testing of security roles for the future production environment.
Non-Production Environment Security
Development and quality assurance environments during an SAP S/4HANA implementation frequently contain real organizational data. This data arrives through client copies, data migration testing, and integration testing with real transactions. The increasing number of data privacy regulations means that non-production environments require access controls proportional to the sensitivity of the data they contain.
Verify client configuration for each non-production client through transaction SCC4 and table T000. The development client should have CCCORACTIV (changes and transports for client-specific objects) set to 1 (changes allowed) to enable configuration work. The quality assurance client should have CCCORACTIV set to 0 (no changes allowed) to ensure that only transported changes reach this environment. If the QAS client allows direct changes, you cannot rely on QAS testing as evidence that production will behave the same way.
Query table USR02 (Logon Data) in each non-production client to identify all active users. The fields BNAME (user name), USTYP (user type, where A is dialog user), UFLAG (user lock status), TRDAT (last logon date), and CLASS (user group) reveal who has access and whether that access is current. Compare the user list against the documented project team roster. Users who are not part of the implementation team but have access to non-production environments represent a potential data privacy violation.
For SAP HANA database level access in non-production environments, connect through transaction DBACOCKPIT or HANA Studio and query SYS.USERS. The columns USER_NAME (database user name), CREATOR (user who created the account), CREATE_TIME (account creation timestamp), LAST_SUCCESSFUL_CONNECT (last login timestamp), and USER_DEACTIVATED (whether the account is deactivated) identify all database-level accounts. Cross-reference against the authorized project team list.
Review RFC connections from non-production to production environments through transaction SM59 (RFC Destinations). Table RFCDES (RFC Destination Description) contains RFCDEST (destination name), RFCTYPE (connection type), RFCOPTIONS (connection options including target host), and RFCHOST (target host name). RFC connections from development or quality assurance environments pointing to the production system can allow unauthorized data access or, worse, unauthorized changes to production data.
Production Security Role Design
The security roles designed during the implementation become the access control foundation for the production system. Testing these roles before go-live is critical because changing role designs after users are assigned and transacting is significantly more complex.
Use transaction PFCG (Role Maintenance) to review role design in the development environment. For each role, examine the authorization profile and the specific authorization objects assigned. Table AGR_1251 (Authorization Data for Activity Group) contains AGR_NAME (role name), OBJECT (authorization object), AUTH (authorization name), FIELD (authorization field), LOW (from value), and HIGH (to value). These entries define exactly what each role can do.
Test segregation of duties by cross-referencing role assignments. Table AGR_USERS (Assignment of Roles to Users) contains AGR_NAME (role name), UNAME (user name), FROM_DAT (valid from date), and TO_DAT (valid to date). Join AGR_USERS with AGR_1251 to identify users who hold conflicting authorization objects through different role assignments.
For a procurement SoD test, look for users who hold both authorization object M_BEST_BSA (purchase order document type authorization) with activity 01 (create) and authorization object F_BKPF_BUK (accounting document company code authorization) with activity 01 (create). This combination allows a single user to create purchase orders and post invoices.
For a payment SoD test, look for users holding authorization object F_BKPF_BUK with activity 01 (create, allowing invoice posting) and authorization object F_REGU_BUK (payment program authorization) with activity 16 (execute, allowing payment run execution). This allows a single user to post an invoice and execute the payment for that invoice.
Verify that SAP standard default users have been secured. Run report RSUSR003 (Check Passwords of Standard Users) to confirm that users SAP*, DDIC, and EARLYWATCH have had their passwords changed from defaults in every client. Check table USR02 for user TMSADM (Transport Management System administration user) and verify it is not using a default password.
Review the security audit log configuration through transaction SM19 or RSAU_CONFIG (Security Audit Log Configuration). Even during the implementation, critical security events should be logged. Verify that the following event categories are enabled: dialog logon (successful and unsuccessful), RFC and CPIC logon (successful and unsuccessful), transaction starts, and changes to user master records.
Analyze the security audit log through transaction SM20 or RSAU_READ_LOG for the implementation period. Look for patterns indicating unauthorized access attempts, successful logons by default users, and privilege escalation through role or profile changes.
For SAP HANA database security, query SYS.GRANTED_PRIVILEGES to identify users with administrative privileges. The columns GRANTEE (user or role receiving the privilege), GRANTOR (user who granted the privilege), PRIVILEGE (privilege name), OBJECT_TYPE (type of object), and IS_GRANTABLE (whether the grantee can further grant the privilege) reveal the complete privilege landscape. Focus on users holding DATA ADMIN, USER ADMIN, SYSTEM ADMIN, or CATALOG READ privileges. These provide database-level access that bypasses all SAP application security.
Query SYS.AUDIT_POLICIES to verify that HANA-level audit policies are active during the implementation. The columns AUDIT_POLICY_NAME (policy name), EVENT_STATUS (whether the policy fires on successful events, unsuccessful events, or both), EVENT_ACTION_TYPE (type of action being audited), and IS_AUDIT_POLICY_ACTIVE (whether the policy is currently enabled) show whether the database layer is generating audit evidence.
Original implementation tip: During one implementation audit, I discovered that the system integrator's entire team of 23 consultants had SAP_ALL (full authorization profile) assigned in the development client. The justification was "they need it for development efficiency." When I checked the QAS client, 19 of those 23 consultants also had SAP_ALL there. The system integrator argued this was necessary for integration testing. The problem was that the QAS client contained a full copy of production data including employee payroll information, customer credit card numbers, and vendor bank details. Twenty-three external consultants had unrestricted access to all of it with no logging of what they accessed. Apply least-privilege principles in non-production environments. Developers need development access. Testers need testing access. Nobody needs SAP_ALL in a client containing real data.
Testing SDLC Controls During the Implementation, Not After
SDLC controls should be tested as each phase or task completes, with recommendations for improvement communicated immediately. Waiting until after go-live to audit SDLC controls defeats their purpose entirely. By then, the decisions have been made, the configuration is locked, and the only option is expensive rework.
Phase-Specific Testing Approach
During the prepare phase, test whether the project governance structure is established, the risk and control framework is defined, the GRC workstream is staffed and integrated into the project plan, and the steering committee charter includes GRC oversight responsibilities.
During the explore phase, test whether risk inventories have been completed for each process area, control designs have been documented and mapped to risks, the requirements traceability matrix links business requirements to control requirements, and audit has reviewed and validated risk priorities.
During the realize phase, test whether configuration matches documented design decisions (compare CDHDR and CDPOS against design documentation), custom ABAP programs include appropriate authorization checks (query USOBX for custom transactions), unit testing includes control scenarios (not just functional scenarios), and integration testing validates end-to-end control operation across modules.
During the deploy phase, test whether user acceptance testing includes specific control test cases, data migration reconciliation is complete and documented, security roles have been tested for SoD conflicts, go-live readiness criteria have been independently verified, and training has been delivered to all users including control performers.
Custom ABAP Program Authorization Verification
Every custom program created during the implementation should include proper authorization checks. Query table TSTC (SAP Transaction Codes) with field TCODE (transaction code) and PGMNA (program name) filtered for the customer namespace (Z* or Y*). This gives you the complete list of custom transactions.
For each custom transaction, query table USOBX (Check Table for Transaction/Authorization Object Assignment) with field NAME (transaction code) and OBJECT (authorization object). If a custom transaction does not appear in USOBX, or appears with no authorization object assignments, it means users executing that transaction face no authorization restrictions beyond basic logon authority.
To verify that authorization checks are actually coded into the program, use transaction SE38 (ABAP Editor) to review the source code. Search for the AUTHORITY-CHECK statement. Programs that modify financial data, master data, or security configurations without AUTHORITY-CHECK statements represent a high-priority finding.
Query table TADIR (Directory of Repository Objects) to inventory all custom objects. The fields PGMID (program ID), OBJECT (object type, where PROG is program, FUGR is function group, CLAS is class, and TABL is table), OBJ_NAME (object name), DEVCLASS (package assignment), AUTHOR (creator), and CREATED_ON (creation date) provide the complete catalog of custom development. Filter for CREATED_ON during the implementation period to identify everything built for this project.
Cross-reference custom programs against the SAP S/4HANA Simplification List if your implementation is an upgrade. Custom programs referencing tables eliminated in S/4HANA will either fail at runtime (visible through transaction ST22, ABAP Dump Analysis, table SNAP with fields DATUM for dump date, UZEIT for dump time, AESSION for session ID, and MESSION for error program) or return incorrect results if the table structure changed but the table name persists.
Original implementation tip: I recommend building a custom program audit matrix during the realize phase. For every custom transaction, document the program name, the business purpose, the authorization objects assigned in USOBX, whether AUTHORITY-CHECK statements exist in the source code, the developer who built it, the functional owner who approved it, and the test cases that validated it. This matrix becomes a permanent reference for future audits. Without it, the next auditor who encounters your custom transactions will have to reverse-engineer their purpose and authorization design from scratch, which increases audit duration and the likelihood of misinterpretation.
Implementation Audit Tips
Original implementation tip on late-stage design changes: Late-stage process changes during SAP S/4HANA implementations are common and dangerous. A business process owner who realizes during UAT that the approval workflow does not match their actual process will request a change. That change may affect the release strategy configuration, the security role design, the SoD assessment, and the training materials. Your audit should verify that a formal process exists for evaluating the control impact of late-stage changes. Every change request submitted after the explore phase should include a mandatory field for "impact on internal controls" assessed by the GRC workstream before the change is approved. Without this, late-stage changes routinely introduce control gaps that nobody evaluates.
Original implementation tip on system integrator control knowledge: Your system integrator builds what you specify. Most system integrators have strong functional and technical skills. Fewer have deep expertise in SAP S/4HANA configurable controls. Do not assume your integrator will proactively identify control configuration opportunities. During the explore phase, ask the integrator to present the configurable control options available for each process area, including tolerance groups, release strategies, validation rules, substitution rules, and workflow templates. If the integrator cannot articulate these options, supplement the team with an SAP controls specialist who can.
Original implementation tip on dual-purpose testing: Many implementation audit procedures can serve dual purposes. Your test of data migration completeness validates both the SDLC control over migration and the accuracy of opening balances for the future-state financial audit. Your test of security role design validates both the implementation governance over role development and the adequacy of access controls for the production environment. Structure your working papers to capture evidence for both purposes. This reduces total audit effort and creates continuity between the implementation audit and the first production audit.
Original implementation tip on agile implementation risks: Agile methodology for SAP S/4HANA implementations introduces specific risks to control design. In a traditional waterfall approach, the explore phase produces a complete design before configuration begins. In agile, design and configuration happen concurrently across sprints. A control designed in sprint 3 may be invalidated by a process change in sprint 7. Your audit should verify that the agile backlog includes control-related user stories, that each sprint retrospective includes an assessment of control impact from changes made during the sprint, and that the GRC workstream reviews completed sprint deliverables for control completeness before the next sprint begins.
Key References and Standards
ISACA COBIT 2019 Framework for IT governance and management, specifically the Build, Acquire, and Implement domain (BAI). ISACA IT Audit and Assurance Standards (ITAF) for audit methodology. COSO Internal Control Integrated Framework 2013 for control design principles. PCAOB Auditing Standard No. 5 for integrated audits of internal control over financial reporting, particularly guidance on evaluating controls during system implementations. SEC FAQ Guide on Sarbanes-Oxley Section 404, including the statement that companies cannot exclude new IT systems from the scope of their assessment. Sarbanes-Oxley Act of 2002 Sections 302 and 404. Foreign Corrupt Practices Act for anti-bribery and internal control requirements, including enforcement actions against Siemens, Alstom, Telia, Goldman Sachs, and Airbus. GDPR (EU Regulation 2016/679) for personal data processing controls during data migration. HIPAA Security Rule (45 CFR Part 164) for electronic health information controls in non-production environments. PCI DSS v4.0 for payment card data security during system implementations. SAP S/4HANA Simplification List (available at help.sap.com) for upgrade compatibility assessment. SAP Security Guide for SAP S/4HANA for production and non-production security configuration. SAP Solution Manager documentation for SOLAR01 and SOLAR02 usage in requirements traceability. IIA Global Internal Audit Standards 2024 for internal audit involvement during system implementations. NIST SP 800-53 Rev. 5 for security and privacy controls, specifically the SA (System and Services Acquisition) control family. ISO 27001:2022 Annex A controls A.8.25 (Secure development life cycle), A.8.31 (Separation of development, test, and production environments), and A.8.33 (Test information).
What Happens When You Skip This
Organizations that skip the implementation audit or defer it to post-go-live produce systems that work technically but fail operationally. Configuration decisions made without control assessment become embedded in the production baseline. Data migration errors compound as transactions post against incorrect opening balances. Security roles designed without SoD analysis create access conflicts that are expensive to untangle once users are transacting in production. The first post-go-live audit becomes an adversarial exercise rather than a validation of decisions already made and documented.
Organizations that audit the implementation concurrently produce systems where every configuration decision is traceable to a business requirement and a risk assessment. Data migration is reconciled and documented. Security roles are tested for conflicts before a single user logs in. The first production audit validates what was already verified during the implementation, reducing audit duration and eliminating the surprise findings that damage credibility and consume executive attention.
The time to find control gaps in an SAP S/4HANA implementation is when they can be fixed for the cost of a configuration change, not when they require a change order, a transport cycle, and six months of remediation.
What is the most expensive post-go-live control gap your organization has encountered, and could it have been caught during the implementation with the right audit procedures in place?
About the Author
The SAP frameworks, tools, taxonomies, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own SAP management and audit programs. If you find them valuable, the only ask is proper attribution.
Prof. Huwyler serves as AI GRC ERP Consultancy Director, AI Risk Manager, SAP GRC Specialist, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.
As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe.
Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance landscapes.
His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at https://hwyler.github.io/hwyler/. His ongoing writing on AI Governance and AI Risk Management appears on his blogger website at https://hernanhuwyler.wordpress.com/
Connect with Prof. Huwyler on LinkedIn at linkedin.com/in/hernanwyler to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.
If you are building an AI or SAP governance program, standing up a risk function, preparing for compliance obligations, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.