Every T-Code, Table, and Design Technique You Need Before Go-Live
The most expensive SAP S/4HANA audit findings are the ones discovered after go-live. Every one of them.
I have watched organizations spend $200,000 remediating a segregation of duties problem that would have cost $5,000 to configure correctly during the explore phase. I have seen a chart of accounts redesign triggered by a post-implementation audit finding that required a partial reimplementation. And I have seen implementations where the system integrator delivered exactly what was specified, but the specifications never included internal controls, so the organization went live with a perfectly built system that had no preventive controls over vendor payments.
These situations are avoidable. Every single one.
This post walks through the complete methodology for building controls into your SAP S/4HANA implementation from day one. It covers the control-conscious implementation team structure, the control design framework with specific T-codes and table references, the audit involvement model, and the SDLC controls that protect the implementation itself. If your implementation is already underway, skip to the section covering your current phase. If you are planning your next implementation, read everything.
Why Controls During Implementation and Not After
SAP S/4HANA does not ship with authenticated security roles designed for segregation of duties. It does not arrive with a robust set of configurable controls enabled. The delivered roles are designed to perform business functions, not enforce control boundaries. These controls must be identified as functional requirements during the explore phase and configured before go-live.
The cost curve for fixing control gaps is exponential. A missing tolerance check identified during design costs a few hours of configuration. The same gap found during user acceptance testing costs days of rework. Found after go-live, it costs weeks of change management, testing, documentation, and audit response involving at least six people across the organization.
Certain configuration decisions are so foundational that changing them later requires a new implementation. The structure of your general ledger chart of accounts. The setup of your organizational units. The fundamental design of your enterprise structure in the IMG. These decisions, once made and populated with transactional data, become permanent.
Original implementation tip: Before your explore phase begins, require every functional team lead to attend a half-day session covering internal control fundamentals, risk identification for their process area, configurable control options in SAP S/4HANA, and the control documentation template they will use throughout the project. This single investment converts your entire implementation team into a distributed control design workforce and reduces your dependency on dedicated GRC specialists by roughly 60%.
Regulatory and Business Reasons That Make This Non-Optional
Understanding your regulatory landscape before the implementation starts directly affects control design requirements, scope, and documentation standards.
Regulatory Requirements That Apply at Implementation
The Sarbanes-Oxley Act of 2002 in the United States, Bill 198 in Canada, and the Financial Instruments and Exchange Act in Japan all link internal controls to financial reporting reliability. The SEC stated explicitly that "companies are required to prepare reliable financial statements following the implementation of new information systems" and that management cannot exclude new IT systems from the scope of its assessment of internal control over financial reporting.
The Foreign Corrupt Practices Act carries fines up to $2 million per violation for companies and $250,000 plus five years imprisonment for individuals. Recent enforcement actions include Siemens AG at $450 million in 2008, Alstom at $772 million in 2014, Telia Company AB at $1 billion in 2017, Goldman Sachs at $2 billion in 2020, and Airbus at $2.1 billion in 2020. Nearly 50 countries have implemented similar laws.
HIPAA, GDPR, PCI DSS, FDA CGMP guidance, FedRAMP, and the Brazilian Nota Fiscal requirement each impose specific control requirements that must be designed into SAP S/4HANA during implementation. Discovering after go-live that your system cannot support GDPR data subject access requests because the business partner data model was not configured for personal data flagging creates an extraordinarily expensive remediation project.
Business Partner and Contractual Obligations
Loan covenants may establish asset ratios or metrics that require specific SAP reporting controls. Service-level agreements may guarantee operational performance levels that depend on SAP processing integrity. Government contracts contain billing, subcontractor, and disclosure requirements that need system-level enforcement.
If your organization provides services to other organizations and issues SOC 1 or SOC 2 reports, every control in scope for those reports that is affected by SAP S/4HANA must be ready at go-live. There is no grace period.
Original implementation tip: During the prepare phase, compile a regulatory and contractual requirements matrix. List every regulation, contract clause, and SLA that imposes a control requirement. Map each requirement to the SAP S/4HANA process area and functional team responsible for addressing it. Review this matrix with both internal and external auditors before the explore phase begins. I have seen implementations where the procurement team assumed the accounts payable team would handle FCPA third-party payment controls, and the accounts payable team assumed procurement had it covered. Nobody had it covered.
Creating the Control-Conscious Implementation Team
The control-conscious implementation team is a staffing and governance model that distributes control design responsibility across all functional teams while providing expert oversight from a dedicated GRC workstream. It reduces the need for full-time control advisors in every design session without sacrificing control quality.
The Structure
Every functional team member receives training on risk identification, control design fundamentals, and the documentation template. A small dedicated GRC workstream provides advisory support, cross-process validation, and quality assurance. Internal and external auditors participate through defined rules of engagement integrated into the project plan.
The GRC workstream should operate as a separate workstream, not embedded within a single functional team. This gives the workstream visibility across all processes and enables end-to-end control validation that crosses functional team boundaries. Functional team silos are the primary cause of control gaps where one team assumes another team handles a specific risk.
Implementation Team Skills Requirements
Four skill areas must be present or developed: business process risk knowledge, awareness of when and where controls are needed, understanding of SAP S/4HANA configurable control options, and knowledge of how the SAP security model enables or constrains those options.
Risk assessment skills include distinguishing between inherent risk and control risk. Inherent risks exist in every process regardless of organization. The risk of duplicate payment exists in every payables process. Control risks are introduced by the controls themselves. A workflow approval control introduces the risk that the approver is unavailable, that authorization limits are not updated when policies change, or that someone other than the workflow owner gains access to their user ID.
Control design skills include determining the optimal point in the process for a control, assessing the balance between risk mitigation and business impact, identifying control risks introduced by new controls, and evaluating remaining risk after controls are applied.
Original implementation tip: Put your GRC workstream leads through a deep technical walkthrough of SAP S/4HANA configurable controls before the explore phase starts. There are more than 500 configurable controls available in a full-scale SAP implementation. Your GRC leads do not need to know all 500. They need to know the 30 to 50 that matter most for your industry and regulatory environment, and they need to know them well enough to challenge functional team assumptions. I have worked on implementations where the GRC lead did not know that the duplicate invoice check in SAP S/4HANA can be bypassed by a single flag set within vendor-specific business partner data (field XCPDK in table LFB1, now migrated to business partner structures). That is the kind of knowledge gap that creates post-go-live findings.
Audit Involvement and Rules of Engagement
Internal and external auditors should take an active role during the SAP S/4HANA implementation. I say this from direct experience across more than two dozen SAP S/4HANA implementations. The risks of not involving audit far outweigh the independence concerns.
Independence Is Manageable
The standard objection is auditor independence. Here is how to handle it. Auditors participate in an advisory capacity, reviewing control designs, identifying risks, and validating that the GRC workstream is on track. They do not make configuration decisions. They do not approve design documents. They do not own any deliverables on the project plan.
The distinction matters. An auditor who says "this control design does not adequately address the risk of unauthorized journal entries" is providing advisory input. An auditor who says "configure the tolerance group to $10,000" is making a design decision. The first preserves independence. The second does not.
Specific Rules of Engagement
Require auditors to attend all relevant meetings for their full duration. Repeating discussion to someone who was absent wastes implementation team time, and revisiting decisions because audit input was not available derails progress.
Relocate auditors to where the implementation team works. Physical presence creates teamwork and facilitates informal knowledge transfer.
Integrate audit milestones into the project plan. Specific activities such as "risk assessment validation by internal audit" or "control design review by external audit" should appear as tracked tasks with owners and due dates.
Communicate audit concerns through the standard project reporting process, not through separate audit reports. Joint reporting reinforces the message that GRC is an integrated part of the implementation, not a separate compliance exercise running in parallel.
Set the expectation that any potential issue affecting scope or configuration is communicated immediately, even if audit has not fully validated it. This is a behavioral change for most auditors who are trained to complete analysis before reporting. On an implementation, the cost of delayed communication compounds daily.
Original implementation tip: Create a documented SLA between the audit team and the implementation project manager covering meeting attendance expectations, input deadlines for missed meetings, reporting format, risk rating definitions, and escalation protocols. I learned this the hard way on an implementation where the internal auditor raised a concern about the chart of accounts structure during the realize phase, six weeks after the design decision had been made and three weeks after configuration was complete. The concern was valid. The timing made it nearly impossible to address without schedule impact. An SLA with defined review windows during the explore phase would have caught this when it mattered.
Designing Effective Controls: The Complete Framework
Control design during an SAP S/4HANA implementation follows a structured process: define processes and subprocesses, create the risk inventory, map controls to risks, track design progress, and identify additional risks created by control decisions.
Step 1: Define Processes and Subprocesses
Align your control documentation structure with SAP terminology and your business process design documents. For purchase-to-pay, a typical breakdown includes procurement and purchasing, goods and service receipt, payment processing, vendor master maintenance (now business partner maintenance in S/4HANA), and material master maintenance.
Define this structure during the prepare phase before design begins. Every functional team needs an agreed framework before they start documenting risks.
Step 2: Create the Risk Inventory
For each subprocess, list the inherent risks that must be addressed. The procurement subprocess carries risks including unauthorized purchases, purchases from unapproved vendors, purchases exceeding budget authority, duplicate purchase orders, and purchases that violate regulatory requirements such as FCPA restrictions on third-party payments.
Prioritize each risk by likelihood, potential impact, and velocity of effect. Review priorities collaboratively with internal and external auditors. This risk inventory becomes the basis for your control design plan and should follow the same change management process used for other implementation decisions.
Use transaction SPRO to navigate the IMG structure and identify where configurable controls exist for each risk area. For procurement risks, the relevant IMG path is Materials Management, Purchasing, Purchase Order, Release Procedure for Purchase Orders. Document the IMG path alongside each risk so the functional team knows exactly where to look for configuration options.
Step 3: Map Controls to Risks
For each risk, identify the controls that will address it. Walk through the thought process systematically.
Consider the risk of unauthorized purchases. The team evaluates security first. Limiting the number of individuals who can initiate and approve purchases reduces the risk surface. Use transaction PFCG (Role Maintenance) to design roles that enforce procurement authorization boundaries. The authorization object M_BEST_BSA (purchase order document type authorization) with field ACTVT (activity, where 01 is create and 02 is change) and field BSART (purchasing document type) controls who can create specific types of purchase orders.
Security alone is insufficient. Add approval limits configured through the release strategy in the IMG. The configuration tables T16FC (Release Groups, containing fields FRGGR for release group identifier and FRGGT for release group description), T16FD (Release Codes, containing fields FRGGR for release group, FRGCO for release code, and FRGCT for release code description), and T16FS (Release Strategies, containing fields FRGGR for release group, FRGSX for release strategy, and FRGST for release strategy description) define the approval structure.
Supplement with workflow using transaction SWDD (Workflow Builder) or the standard SAP workflow template WS20000075 for purchase order release. Configure the workflow to route approvals based on document value and organizational assignment.
Add a detective control: a custom report or SAP standard report that the controller reviews regularly. Transaction ME2M (Purchase Orders by Material) or ME2N (Purchase Orders by PO Number) with appropriate variant selections can serve as a monitoring tool. For custom report development, use transaction SE38 (ABAP Editor) with proper authorization checks built into the program code.
Each control needs four components documented. When the control fires (trigger point). Who performs it (role or system). What specific action occurs (precise enough to be repeatable). Why it exists (the risk it addresses and the authority that requires it).
Step 4: Track Control Design Progress Through Configuration and Testing
Track four milestones for each control: documentation complete, configuration complete (for automated controls), testing complete (for automated controls), and training complete (for manual and system-dependent controls).
Use the table E070 (Transport Request Header) to verify that control-related configuration changes have been transported through the landscape. Key fields include TRKORR (transport request number), TRFUNCTION (transport category), TRSTATUS (status, where R means released and D means modifiable), AS4USER (owner), AS4DATE (last changed date), and AS4TEXT (short description). Cross-reference with E071 (Object Entries in Transport Requests) which contains TRKORR (transport request), PGMID (program ID), OBJECT (object type), OBJ_NAME (object name), OBJFUNC (object function), and LOCKFLAG (lock indicator).
Filter E070 for transports with descriptions containing control-related keywords. Verify that each control-related transport follows the path from development through quality assurance to production with appropriate testing evidence at each stage.
Original implementation tip: Every planned control should be cross-referenced to the risk inventory with a unique identifier. When a process change occurs after initial control design, this cross-reference lets you immediately identify which controls need re-evaluation. I recommend maintaining this mapping in a purpose-built database rather than spreadsheets. By the time you have 200 risks mapped to 600 controls with cross-references to control risks, spreadsheet maintenance becomes error-prone and version control becomes a nightmare.
Step 5: Identify Control Risks Created by Your Control Decisions
For every planned control, ask: "What could cause this control to fail?"
Security controls fail when initial setup is incorrect or when employee terminations and transfers are not communicated to the security team. Use table USR02 (Logon Data) fields BNAME (user name), TRDAT (last logon date), GLTGB (valid to date), and UFLAG (user lock status) to build a monitoring query that detects dormant accounts. Cross-reference against HR termination data to identify accounts that should have been deactivated.
Approval limit controls fail when limits are not updated as policies change. Document the review cycle for release strategy values and assign ownership to a specific role.
Workflow controls fail when the designated approver is unavailable. Configure substitute and escalation rules in SAP Business Workflow. Use transaction SWIA (Work Item Analysis) to monitor aging workflow items that have not been actioned.
Detective report controls fail when nobody reviews the report or when follow-up actions are not tracked. Document the review frequency, the responsible role, and the expected action for each exception type.
For each identified control risk, determine whether an existing control already addresses it or whether a new control must be designed. The control risk of someone splitting purchases below the approval limit, for example, might be addressed by the same detective report already planned for the unauthorized purchase risk.
T-Codes and Tables for Implementation Audit Evidence
Data Migration Controls
Data migration is one of the highest-risk areas during any SAP S/4HANA implementation. Use transaction LTMC (SAP S/4HANA Migration Cockpit) for standard migration activities. For audit purposes, verify migration completeness by comparing source system record counts against target system counts in the relevant SAP tables.
For business partner migration (replacing the legacy vendor and customer master), query table BUT000 (Business Partner General Data) with fields PARTNER (business partner number), BU_GROUP (business partner grouping), BU_SORT1 (search term 1), TITLE (title key), NAME_ORG1 (organization name 1 for organizations), NAME_FIRST (first name for persons), NAME_LAST (last name for persons), and CRDAT (creation date). Filter on CRDAT matching your migration date to isolate migrated records and compare against source counts.
For vendor bank details migration, query table BUT0BK (Business Partner Bank Details) with fields PARTNER (business partner number), BANKL (bank key), BANKN (bank account number), BKONT (bank control key), and BANKA (bank name). Verify that bank details migrated accurately by sampling and comparing against source system data.
For material master migration, query table MARA (General Material Data) with fields MATNR (material number), MTART (material type), MBRSH (industry sector), MATKL (material group), MEINS (base unit of measure), and ERSDA (creation date). Filter on ERSDA matching migration dates.
Change Management Controls During Implementation
Monitor development activity through transaction SE03 (Transport Organizer Tools). Query E070 joined with E071 to trace every object modified during the implementation. Pay attention to transports owned by users outside the designated development team and transports released directly to production bypassing quality assurance.
The table TPLOG (Transport Log) contains detailed transport execution records. The fields TRKORR (transport request), TRSTEP (transport step, where 6 means import into target system), TRTIME (execution time), and TRRETCODE (return code, where 0 means success and values above 4 indicate warnings or errors) tell you whether transports executed cleanly.
For tracking configuration changes specifically, use table DBTABLOG (Table Change Logging) with fields LOGDATE (date of change), LOGTIME (time of change), USERNAME (user making the change), TABNAME (table changed), and APPSERVER (application server). Enable logging for all configuration tables during the implementation period through transaction SE13 (Maintain Technical Settings) or RZ10 profile parameter rec/client.
Custom ABAP Program Verification
Every SAP S/4HANA upgrade has the potential to affect custom ABAP programs. Query table TSTC (SAP Transaction Codes) filtering field PGMNA (program name) for programs in the customer namespace (Z* or Y*). The field TCODE (transaction code) gives you the custom transaction associated with each program.
For each custom program, verify that it includes proper authorization checks. Query table USOBX (Check Table for Transaction/Authorization Object Assignment) with fields USOBT_EXT (external use, where X means the transaction is assigned to authorization objects), NAME (transaction code), and OBJECT (authorization object). Custom transactions missing from USOBX or with no authorization object assignments represent potential control bypasses.
Use transaction SE38 to review custom program source code for AUTHORITY-CHECK statements. Programs that modify financial data, master data, or security configurations without authorization checks are high-priority findings.
During an upgrade from SAP ERP to SAP S/4HANA, pay particular attention to custom programs that reference tables eliminated or restructured in S/4HANA. SAP provides the Simplification List documenting all table changes. Custom programs referencing eliminated tables will either fail with runtime errors (detectable through transaction ST22, ABAP Dump Analysis) or silently return incomplete data if the table structure changed but the table name persists.
Original implementation tip: On one SAP S/4HANA upgrade, the organization had a custom report monitoring credit limit changes that referenced the legacy credit management tables. When they upgraded and moved to FSCM credit management, the report continued to run without errors but returned zero results because the underlying data was now stored in different tables. Nobody noticed for four months because the report appeared to be working normally. It was showing an empty result set. The credit management team assumed no credit limits were being changed. Meanwhile, 340 credit limit changes had been processed through the new FSCM functionality with no detective monitoring whatsoever. Always test custom reports for functional accuracy after an upgrade, not just for technical execution.
SDLC Controls and Common Implementation Risk Areas
Beyond designing controls for the future-state system, the implementation itself needs controls. These fall into the category of software development lifecycle controls, though SDLC controls alone do not cover all implementation risks.
Project Governance and Schedule Management
The implementation project plan should include control-related activities as explicit tracked tasks, not buried within functional design activities. The GRC workstream should have its own set of milestones visible in project status reporting.
Track control design KPIs and report them through the standard project dashboard. Useful metrics include number of controls per process (more is not necessarily better), ratio of preventive to detective controls, ratio of manual to automated controls, percentage of configurable controls that have been configured, percentage of configured controls that have passed testing, and percentage of manual controls incorporated into user training.
Requirements Traceability
Every functional requirement should trace back to a business need or regulatory requirement. Every control requirement should trace back to an identified risk. This traceability matrix becomes your primary defense during post-go-live audits. When an auditor asks why a specific control was or was not configured, you can point to the documented risk assessment, the control design decision, and the testing evidence.
Store requirements traceability in SAP Solution Manager if deployed, using transaction SOLAR01 (Business Blueprint) and SOLAR02 (Configuration). The structure links business processes to configuration objects to test cases, creating an auditable chain from requirement to implementation.
Data Migration Testing
Data migration failures are among the most common and most damaging implementation issues. Test migration completeness (are all records present), accuracy (are field values correct), and authorization (were migration activities performed by authorized personnel using authorized tools).
Run reconciliation queries comparing source and target record counts for every migrated data object. For financial data, reconcile total balances by company code, account, and period. For master data, reconcile record counts by type and organizational assignment.
Use table BKPF (Accounting Document Header) with fields BUKRS (company code), BELNR (document number), GJAHR (fiscal year), BLART (document type), BUDAT (posting date), USNAM (user who entered the document), and TCODE (transaction code) to verify that migration postings were created through authorized migration transactions and not through manual entry.
User Acceptance Testing for Controls
UAT should include specific test scenarios for every configured control. This means testing not only that the control works when triggered correctly, but also testing that the control cannot be bypassed.
For the purchase order release strategy, test that a purchase order exceeding the approval threshold cannot be saved without appropriate release. Test that a user without release authority cannot execute the release. Test that a released purchase order cannot be modified after release without re-triggering the approval process.
For tolerance checks, test transactions at the boundary values. If the tolerance is $10,000, test at $9,999, $10,000, and $10,001. Boundary value testing catches off-by-one configuration errors that are surprisingly common.
Document test results with screenshots showing the SAP system response. Store these in your project documentation repository. They become evidence during post-go-live audits.
Original implementation tip: Schedule a dedicated "control testing sprint" during the realize phase, separate from functional UAT. In every implementation where I have seen controls tested as part of general UAT, the functional testing consumed all available time and control scenarios were either skipped or rushed. A dedicated sprint with the GRC workstream owning the test cases and the functional team providing testing support produces dramatically better results. Budget two to three days per major process area.
Upgrade-Specific Control Considerations
SAP S/4HANA upgrades introduce three categories of control-relevant changes that most organizations underestimate.
New Functionality That Replaces Existing Controls
SAP S/4HANA provides fuzzy search capabilities for identifying potential duplicate business partners through the Business Partner transaction (BP). This could replace custom duplicate detection routines you previously built outside SAP. Evaluate every new capability against your existing control inventory and determine whether existing controls can be retired or simplified.
Lost Functionality That Eliminates Existing Controls
SAP S/4HANA replaced the credit management functionality within FI with enhanced functionality in the Financial Supply Chain Management (FSCM) component. The legacy credit management had a dedicated report for viewing all credit limit changes. The FSCM credit management component has logging and log reporting but no equivalent out-of-the-box report presenting credit limit changes in the same format.
Query the FSCM tables UKM_HEADER (Credit Management Header Data) and use the Business Partner change documents through table CDHDR (Change Document Header) with OBJECTCLAS set to BUPA_BKK (business partner bank details) or relevant credit management object classes, joined with CDPOS (Change Document Items) filtering on TABNAME and FNAME for credit limit fields, to build a replacement monitoring capability.
Impact on Custom ABAP Programs
Every custom ABAP program must be examined for compatibility with S/4HANA table changes. Additionally, custom programs can inadvertently bypass new functionality introduced by the upgrade.
Query table TADIR (Directory of Repository Objects) with fields PGMID (program ID), OBJECT (object type, where PROG means ABAP program), OBJ_NAME (object name), DEVCLASS (package), and AUTHOR (creator) to inventory all custom objects. Filter for the customer namespace (Z* and Y*). Cross-reference against the SAP S/4HANA Simplification List to identify objects that reference changed or eliminated tables.
For SoD analysis, any upgrade that introduces new transactions or authorization objects requires a reassessment of your SoD ruleset. New transactions are not automatically added to GRC Access Control rulesets during an upgrade. Use transaction SUIM, report "Transactions with Authorization Objects," and compare the complete transaction list in your upgraded system against your GRC ruleset to identify gaps.
Original implementation tip: Role additions and changes related to upgrade enhancements frequently create new SoD conflicts that nobody anticipated. On a recent upgrade engagement, the organization deployed new Fiori apps for purchase requisition approval. These apps used different authorization objects than the classic GUI transactions they replaced. The existing SoD ruleset did not include the new authorization objects, so the SoD monitoring tool reported zero conflicts for users of the new apps even though the same underlying business conflicts existed. Rebuild your SoD ruleset from scratch during any major upgrade rather than trying to incrementally update it.
The Four Phases of an Implementation Audit
Phase 1: Planning
Start with a risk assessment covering both the implementation process itself and the future-state control environment. Review prior audit reports, publicly available audit reports from similar organizations, and the enterprise risk assessment.
Request preliminary information including current SAP systems, supporting application server details, hardware and software versions, client configuration from SCC4 (table T000), contact information for the SAP application owner, security administrator, Basis lead, head of development, and key business process decision-makers.
Use data-driven planning techniques. Analyze transactional data from the current system to establish baseline volumes and patterns. Use process mining tools such as SAP Signavio Process Intelligence to visualize actual transaction flows. Review IT help desk data for recurring SAP-related issues.
During the kickoff meeting, ask stakeholders about planned changes, resource constraints, staff schedules, and any concerns about SAP controls or processing that should influence audit scope.
Phase 2: Fieldwork
Evaluate each layer of the audit pyramid relevant to your scope. For implementation audits, this includes SDLC controls, data migration controls, configuration controls, security design, and early business process validation.
Maintain a running list of potential findings. Review each observation with SAP-knowledgeable personnel before finalizing. This system is complex enough that misunderstanding a configuration setting is a real risk even for experienced auditors.
For tracking configuration changes during fieldwork, query CDHDR joined with CDPOS. Filter CDHDR on UDATE (change date) covering your audit period and TCODE (transaction code) to identify which transaction was used to make each change. In CDPOS, the fields TABNAME (table where the change occurred), FNAME (field name changed), VALUE_NEW (new value), and VALUE_OLD (old value) give you the complete before-and-after picture.
Phase 3: Reporting
Communicate findings as close to identification as feasible. In an implementation context, waiting until after go-live to formally report a design problem is negligent. The traditional five-step reporting process (discussion draft, exit meeting, formal draft, management comments, final report) still applies but should be compressed.
The management response for implementation-related findings should include both the corrective action plan and a timeline that aligns with the implementation schedule. If a finding requires configuration changes, those changes should be included in the implementation plan as tracked tasks, not treated as separate post-go-live remediation.
Phase 4: Follow-Up
For implementation audits, follow-up should occur at two points. First, verify that findings raised during the implementation were addressed before go-live. Second, perform a post-go-live validation (typically 30 to 90 days after cutover) to confirm that controls are operating as designed in the production environment.
Use the same T-codes and tables referenced during fieldwork to verify remediation. If the finding was about missing authorization checks in a custom transaction, query USOBX for the transaction code and confirm that the appropriate authorization objects are now assigned.
Original implementation tip: The post-go-live validation is the step most organizations skip. The argument is always the same: "We just went live, everyone is exhausted, and we need to stabilize before we can handle an audit." I understand the exhaustion. But the first 90 days after go-live are exactly when you need to validate controls, because that is when users are most likely to use workarounds, bypass intended processes, and make mistakes due to unfamiliarity. Schedule the post-go-live review before you go live, with dates and resources committed in the project plan, so it cannot be deferred.
Cross-Cutting Implementation Tips
Original implementation tip on the "technical upgrade" misconception: Every SAP S/4HANA upgrade changes business processes at some level. IT departments frequently describe upgrades as "technical" to limit scope and budget. Do not accept this characterization without independent verification. Pull the SAP S/4HANA Simplification List for your specific upgrade path. Review every functional change and every deprecated function. If any change affects a process with regulatory control requirements, the upgrade is a business change that requires control redesign, not a technical change that can be handled by Basis alone.
Original implementation tip on system integrator accountability: Your system integrator builds what you specify. If your specifications do not include internal controls, you will receive a system without internal controls and a change order bill to add them. Include control requirements in every functional specification document. Require the system integrator to identify configurable control options for every process area during the explore phase and document why each option was or was not enabled. Make control configuration a deliverable with acceptance criteria, not an afterthought.
Original implementation tip on the "we will fix it after go-live" pattern: This is the most dangerous phrase in any SAP implementation. I have tracked the resolution rate for control issues deferred to post-go-live across multiple engagements. The average resolution time is nine months. The resolution rate within the first year is roughly 40%. The remaining 60% either get deprioritized permanently or resurface as audit findings. If a control is important enough to identify during the implementation, it is important enough to configure before go-live.
Original implementation tip on control documentation as audit defense: Every control design decision should be documented with the risk it addresses, the alternatives considered, the reason the chosen approach was selected, and the remaining risk after the control is applied. This documentation becomes your single most valuable asset during post-go-live audits. When an auditor questions why you chose a warning message instead of an error message for a specific tolerance check, you can show the documented analysis demonstrating that the business impact of a hard stop outweighed the risk reduction, and that a compensating detective control was designed to address the remaining risk. Without this documentation, the same conversation becomes adversarial instead of collaborative.
Key References and Standards
ISACA COBIT 2019 Framework for IT governance and management of enterprise IT. 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. SEC FAQ Guide on Sarbanes-Oxley Section 404 implementation, including guidance on system implementations during the assessment period. Sarbanes-Oxley Act of 2002 Sections 302 and 404. Foreign Corrupt Practices Act (FCPA) for anti-bribery and internal control requirements. GDPR (EU Regulation 2016/679) for personal data processing controls. HIPAA Security Rule (45 CFR Part 164) for electronic health information controls. PCI DSS v4.0 for payment card data security. SAP S/4HANA Simplification List (available at help.sap.com) for upgrade impact analysis. SAP Security Guide for SAP S/4HANA. SAP Best Practices for SAP S/4HANA. IIA Global Internal Audit Standards 2024. FDA Guidance on Data Integrity and Compliance with Drug CGMP. NIST SP 800-53 Rev. 5 for security and privacy controls applicable to federal information systems. ISO 27001:2022 for information security management systems.
Making Your Implementation Count
Organizations that treat GRC as a bolt-on workstream, something that runs in parallel without integration into the core project plan, produce implementations that pass functional testing but fail their first audit. The findings accumulate. The remediation costs compound. The credibility of the implementation team suffers. And the organization operates for months or years with control gaps that could have been closed during the explore phase for a fraction of the eventual cost.
Organizations that embed GRC thinking into every design decision, every configuration choice, and every test scenario produce implementations that are audit-ready at go-live. Their control documentation serves as the foundation for ongoing monitoring. Their functional teams understand not just how the system works but why the controls exist. Their post-go-live stabilization period is shorter because the system was designed to enforce process integrity from day one.
The cheapest, fastest, and most effective time to build controls into SAP S/4HANA is during the implementation, and every day you wait after that, the cost of getting it right goes up.
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.