Most SAP S/4HANA audits fail before fieldwork even begins. The planning is shallow, the scope misses entire control layers, and the team lacks the technical depth to distinguish a real finding from a false positive. I have seen audit reports with 40 findings that missed the three issues that actually mattered. That is expensive failure.
Getting the SAP S/4HANA audit right matters because the system sits at the center of financial reporting, procurement, inventory management, and dozens of other processes that carry real organizational risk. A weak audit gives false assurance. A strong audit identifies quantifiable business impact and drives measurable control improvement.
This post walks through the complete SAP S/4HANA audit framework, from IT General Controls through business process validation, with every T-code, table, and configuration parameter you need to execute at a high level. Each section includes implementation tips drawn from field experience across financial services, manufacturing, and public sector engagements.
The SAP Audit Pyramid: Why Layered Assurance Matters
The SAP S/4HANA audit is not a flat checklist. It is a pyramid of interdependent control categories where each layer depends on the integrity of the layer beneath it. Skip a foundational layer, and your conclusions about the layers above become unreliable.
The pyramid, from bottom to top, consists of five categories: project governance controls, IT General Controls, Basis and security settings, SAP process-specific technical settings, and business processes enabled by SAP S/4HANA.
Project governance applies during implementation. ITGCs apply to every organization running SAP in production. Basis and security settings are the first truly SAP-specific layer. Process-specific settings address configurations within individual modules like FI, MM, or SD. Business process controls validate how employees actually use the system day to day.
Original implementation tip: When scoping your SAP S/4HANA audit, map each planned test procedure to a specific layer of the pyramid. If you find that 80% of your procedures target Basis and security settings with nothing covering actual business process behavior, your scope is inverted. The most significant and quantifiable findings almost always emerge at the business process layer, where real transactions reveal real problems.
IT General Controls: The Foundation You Cannot Overlook
ITGCs are not SAP-specific. They apply to any organization using computers and software to run core business processes. But they directly affect the reliability of SAP S/4HANA processing, and ignoring them during an SAP audit creates a dangerous gap in assurance.
Consider a simple example. Your bank provides a check clearing file that gets placed on a network share before SAP S/4HANA picks it up for automatic bank reconciliation. If network security is weak, someone could modify that file before the system processes it. SAP S/4HANA would then accurately process inaccurate data. The system did its job perfectly. The controls around the system failed.
During an ITGC review supporting an SAP S/4HANA audit, you should be asking eight core questions:
Does the IT department have sufficient skills and resources to accomplish their duties? How is access to systems granted, controlled, and monitored? Where systems pass information to each other, how does the organization ensure complete and accurate transfer of data? How are processing problems and system errors detected and resolved? Who can update information directly within databases, and how are these capabilities controlled? What processes ensure that users are effectively authenticated? What prevents unauthorized changes to applications? If processing is interrupted, can the organization recover in a reasonable timeframe?
T-Codes and Tables for ITGC Evidence Collection
For interface monitoring, use transaction SM37 (Background Job Overview) to review scheduled jobs that handle data transfers between systems. The table TBTCO (Job Status Overview) contains the fields JOBNAME (job name), SDLUNAME (scheduled by user), STRTDATE (actual start date), ENDDATE (actual end date), and STATUS (job status, where F means finished and A means aborted). Aborted jobs on interface processes represent potential data integrity gaps.
For direct database access controls on SAP HANA, query the system view SYS.EFFECTIVE_PRIVILEGES to identify users with the HANA system privilege DATA ADMIN or CATALOG READ. These privileges allow direct manipulation of database content outside the SAP application layer. The columns GRANTEE (user or role receiving the privilege), PRIVILEGE (the specific privilege granted), OBJECT_TYPE (type of database object), and IS_VALID (whether the privilege is currently active) tell you exactly who can bypass application controls entirely.
Use transaction SE16N (General Table Display) with logging enabled to verify who has accessed sensitive tables directly. The table DBTABLOG (Table Change Logging) records direct table changes with the fields LOGDATE (date of change), LOGTIME (time of change), USERNAME (user who made the change), DATAAGING (data aging date), APPSERVER (application server), and TABNAME (table that was changed).
Original implementation tip: A single ITGC weakness in isolation is rarely catastrophic. But when you combine a weak access provisioning process with poor change management and no interface monitoring, the aggregate risk becomes material. Document the interactions between ITGC weaknesses, not just individual findings. Regulators and audit committees increasingly look at aggregated deficiencies, particularly under Sarbanes-Oxley guidance from the PCAOB.
Basis and Security Settings: Where Technical Depth Separates Good Audits from Bad Ones
This is the first audit layer that is truly SAP S/4HANA specific. Basis and security settings affect the entire system regardless of which modules are deployed. They are component-independent. And they require more technical knowledge to audit properly than any other ERP application on the market.
If you are new to SAP auditing, get expert help for this section. I mean that sincerely. I have been working with SAP systems for years, and I still learn something new about Basis and security settings several times per year. The breadth is extraordinary.
The questions driving this portion of the review include: How are changes to SAP S/4HANA configuration and ABAP code managed? What clients are enabled and how is each used? Is the production client locked for editing? How are Remote Function Calls managed? Who can bypass single sign-on to log on directly? Is security managed through least privilege? How does the organization stay current with SAP Notes and security patches?
Client Configuration and Transport Controls
Start with transaction SCC4 (Client Administration). This shows you every client configured in the system. The underlying table T000 (Clients) contains the fields MANDT (client number), MTEXT (client description), ORT01 (city), CCCATEGORY (client category such as production, test, or customizing), CCCORACTIV (changes and transports for client-specific objects, where 0 means no changes allowed), CCNOCLIIND (cross-client object changes restriction), and CCCOPYLOCK (protection level for client copy).
For a production client, the field CCCORACTIV should be set to 0 (no changes allowed) or at minimum 2 (no changes allowed, only from automatic corrections). If this field shows value 1 (changes allowed), anyone with the right authorization can modify configuration directly in production without going through the transport landscape. This is one of the most critical Basis findings you can report.
Verify the transport landscape with transaction STMS (Transport Management System). Check that the transport route enforces the expected path from development through quality assurance to production. The table E070 (Transport Request Header) contains TRKORR (transport request number), TRFUNCTION (transport category, where K is workbench and W is customizing), TRSTATUS (status, where R is released), AS4USER (owner), and AS4DATE (last changed date). Review released transports to production for unusual timing, such as weekend or holiday releases, or transports owned by users who should not have transport authority.
Password and Authentication Parameters
Use transaction RZ10 (Profile Parameter Maintenance) or report RSPFPAR to review security-relevant profile parameters. The critical parameters for audit include:
login/min_password_lng (minimum password length, recommended 8 or higher), login/password_expiration_time (days until password expires, recommended 90 or fewer), login/fails_to_session_end (failed attempts before session termination, recommended 3), login/fails_to_user_lock (failed attempts before user lock, recommended 5), login/no_automatic_user_sapstar (controls SAP* default superuser behavior, must be set to 1), and rdisp/gui_auto_logout (automatic session timeout in seconds, recommended 3600 or less).
For SAP HANA database-level password policies, query the system view SYS.M_PASSWORD_POLICY. The columns PROPERTY (policy parameter name) and VALUE (current setting) show you the HANA-specific authentication controls including minimal_password_length, password_lock_time, maximum_invalid_connect_attempts, and password_expire_warning_time.
Security Audit Log Configuration
Transaction SM19 (Security Audit Log Configuration) or the newer RSAU_CONFIG (Security Audit Log Configuration) controls what security events are being logged. Transaction SM20 (Security Audit Log Analysis) or RSAU_READ_LOG lets you analyze those events.
On the HANA database layer, query SYS.AUDIT_POLICIES to see which audit policies are active. The columns AUDIT_POLICY_NAME (name of the policy), EVENT_STATUS (whether the policy triggers on successful actions, unsuccessful actions, or both), and IS_AUDIT_POLICY_ACTIVE (whether the policy is currently enabled) reveal whether the organization is actually monitoring critical database-level events.
Original implementation tip: The abundance of existing audit guidance for Basis and security settings is a double-edged sword. It reduces ambiguity about expectations, but it increases the risk that auditors applying standard checklists generate a pile of false positives while missing the findings that actually matter. I have seen auditors report a finding because login/min_password_lng was set to 8 instead of 12, while completely ignoring that three SAP* default accounts still had their original passwords. Focus on what creates exploitable risk, not what deviates from a template.
User Administration and Authorization Analysis
Transaction SU01 (User Maintenance) is where individual user accounts are managed. For bulk analysis, use SUIM (User Information System), which provides dozens of reports covering users by role, by profile, by authorization object, and by last login date.
The table USR02 (Logon Data) is essential. Key fields include BNAME (user name), USTYP (user type, where A is dialog, B is system, C is communication, L is reference, and S is service), UFLAG (user lock status, where 0 is unlocked and various other values indicate different lock states), TRDAT (last logon date), LTIME (last logon time), GLTGV (user valid from date), GLTGB (user valid to date), and ERDAT (creation date). Run a query against USR02 where USTYP equals A and TRDAT is more than 90 days old. Those are dialog users who have not logged in for three months and should be reviewed for deactivation.
The table AGR_USERS (Assignment of Roles to Users) maps users to their assigned roles with the fields AGR_NAME (role name), UNAME (user name), FROM_DAT (valid from date), and TO_DAT (valid to date). Cross-reference this with AGR_1251 (Authorization Data for Activity Group), which contains AGR_NAME (role name), OBJECT (authorization object), AUTH (authorization name), FIELD (authorization field), LOW (from value), and HIGH (to value). This is how you trace from a user through their role assignments down to the specific authorization values they hold.
For identifying users with critical authorizations, run report RSUSR003 (Check Passwords of Standard Users) to verify that default user accounts SAP*, DDIC, and EARLYWATCH have had their passwords changed from defaults. Run RSUSR006 (Users with Critical Authorizations) to find users holding sensitive authorization objects like S_DEVELOP (development access) with activity 02 (change) or S_ADMI_FCD (system administration functions).
SAP Process-Specific Technical Settings and Segregation of Duties
Moving up the audit pyramid, process-specific technical settings address configurations within individual SAP S/4HANA modules. The specifics vary between modules, but a consistent set of audit concerns applies across all of them: master data integrity, tolerance levels, authorization restrictions, custom transactions, and segregation of duties.
Why Segregation of Duties Belongs at the Module Level
Different auditors place SoD testing in different parts of the review. I place it here, at the process-specific level, because SoD violations are most meaningful in the context of a specific business process. The Basis and security review should evaluate how the organization considers SoD when assigning roles. The actual identification and assessment of SoD conflicts belongs at the module level.
The principle is straightforward. No single individual should be able to authorize a transaction, record or report on it, maintain custody of related assets, and reconcile or verify the results. In accounts payable, the person recording payments in SAP S/4HANA should not approve those payments, distribute checks, or reconcile bank statements containing those payments.
To identify potential SoD conflicts, query the table AGR_1251 joined with AGR_USERS. Look for users assigned to roles that contain conflicting authorization objects. For procurement, a conflict exists when one user holds both authorization object M_BEST_BSA (purchase order document type authorization) with activity 01 (create) and authorization object F_BKPF_BUK (accounting document posting authorization) with activity 01 (create) for the same company code. This combination allows a single user to create a purchase order and post the corresponding invoice.
Transaction S_BCE_68001426 (Users with Critical Authorizations and SoD Conflicts) provides a pre-built report, and SAP GRC Access Control (if deployed) automates ongoing SoD analysis through its Access Risk Analysis component.
Purchasing Release Strategy Audit
For procurement audits, examine the release strategy configured through transaction SPRO (Customizing) under Materials Management, Purchasing, Purchase Order, Release Procedure. The configuration tables include T16FC (Release Groups), T16FD (Release Codes), and T16FS (Release Strategies). Review whether the release strategy enforces appropriate approval thresholds and whether the authorization object M_EINK_FRG (release authorization for purchasing documents) restricts release codes to the correct approvers.
Use transaction ME2M (Purchase Orders by Material) or ME2N (Purchase Orders by PO Number) with variant selections to identify purchase orders that were created and released by the same user. This is a direct test of whether the configured release strategy is being followed in practice.
Original implementation tip: The most dangerous SoD conflicts are not the obvious ones between creating vendors and posting payments. They are the conflicts involving custom transactions that the organization built after go-live. Custom T-codes often bypass standard authorization checks if the developer did not include proper authority-check statements in the ABAP code. During your process-specific review, always ask for a list of custom transactions using table TSTC (SAP Transaction Codes), filtering on field PGMNA (program name) for programs in the customer namespace (Z* or Y*). Then verify that each custom transaction has appropriate authorization object checks by reviewing the entries in table USOBX (Check Table for Transaction/Authorization Object Assignment).
Business Process Controls: Where the Real Findings Live
Here is the part that matters most. Everything below this layer in the audit pyramid is foundational. Everything in this layer is where you find actual business impact, quantifiable losses, and the kind of findings that get discussed at the board level.
An SAP S/4HANA system can be configured perfectly and still produce bad outcomes. This happens when employees misuse functionality due to poor training, unclear procedures, insufficient management monitoring, or intentional circumvention. The system cannot prevent every one of these situations. Management monitoring and audit are required to detect them.
The Three-Way Match Bypass Problem
Consider vendor payments. SAP S/4HANA has excellent three-way match controls where the system compares purchase order, goods receipt, and vendor invoice before allowing payment. But not every payment goes through three-way match. Utilities, taxes, and similar payments use invoice-only processing (historically called sundry invoices), which lacks the preventive controls of the standard process.
I have seen multiple organizations where accounts payable staff routinely entered invoices through the invoice-only process that should have gone through three-way match. The reasons varied. Sometimes it was faster. Sometimes the purchase order had errors they did not want to fix. Sometimes there was no good reason at all.
To detect this, use transaction FBL1N (Vendor Line Items) and filter for documents posted with transaction code FB60 (Enter Incoming Invoices) or MR8M (Reverse Invoice Document) where a corresponding purchase order exists but was not referenced. Compare the volume of invoices posted through MIRO (Enter Incoming Invoice with PO Reference) versus FB60 over the audit period. A ratio shift toward FB60 is a red flag.
The table BKPF (Accounting Document Header) contains the fields BUKRS (company code), BELNR (document number), GJAHR (fiscal year), BLART (document type), BUDAT (posting date), USNAM (user name who entered the document), TCODE (transaction code used), and CPUDT (entry date). Filter on TCODE to distinguish between documents entered through the standard MM process versus manual FI postings.
Management Monitoring of Exception Reports
At the business process level, you should be testing whether management actually reviews the exception reports SAP S/4HANA provides. This includes blocked invoice reports (transaction MIR6), GR/IR clearing account analysis (transaction MB5S), open purchase order reports (transaction ME2M with appropriate selections), and aged trial balance reports (transaction FBL1N or S_ALR_87012082).
The finding here is rarely about the report being wrong. It is about whether anyone looks at it, and whether they do anything about the exceptions they find.
Original implementation tip: When you are reviewing business process controls, do not just validate that the process works correctly at the time of your review. Ask yourself what would happen if a Basis setting changed between audit periods. If someone enabled changes to the production client for a weekend, custom report logic could be modified, document types could be added or removed, and the completeness of the management reports you just tested could be compromised. The business process layer depends on the integrity of every layer below it. Your conclusions should explicitly reference the dependencies you validated.
The SAP S/4HANA Internal Control Maturity Model
Many organizations have implemented sufficient controls in SAP S/4HANA, but not optimal controls. The maturity model provides a framework for assessing where the organization currently sits and where it should aspire to be.
The model considers 12 attributes: extent of automation, general nature of controls, design determination, purpose, technical understanding, governance, nature of testing, ongoing monitoring process, ongoing monitoring actions, control failures, control reporting, and return on investment.
At maturity level 1, controls are largely manual or inherent to the system. Fewer than 10% of key controls are automated. Testing is entirely manual. Monitoring occurs only at the minimum level required by regulation.
At maturity level 3, roughly 25% of key controls are performed by SAP S/4HANA. There is a balance between preventive and detective controls. Automated mechanisms identify potential control failures for high-risk configurable controls, running at least quarterly.
At maturity level 5, more than half of key controls are automated. Every preventive control is monitored by an automated detective control for early warning of failure. Continuous automated monitoring extends to manual controls through self-certification and semi-intelligent analysis. Potential control failures trigger notifications within 72 hours.
Monitoring processes are part of the maturity model, not separate from it. Organizations with mature SAP S/4HANA controls by definition have mature monitoring processes. The settings alone are not enough.
Original implementation tip: Use the maturity model during audit planning to set scope boundaries. If an organization self-assesses at level 2 but aspires to level 4, your audit should test current-state controls at level 2 and explicitly identify the gaps to reaching level 4. This turns your audit report from a compliance artifact into a roadmap. The maturity model also gives you defensible language for explaining to management why additional controls should be enabled. "Your current maturity level is 2 out of 5" is a more productive conversation than "you have 17 medium-risk findings."
Audit Execution: From Planning Through Follow-Up
Every SAP S/4HANA audit follows four phases: planning, fieldwork, reporting, and follow-up. Each phase has specific objectives and deliverables that affect the quality of the final product.
Planning: Get the Scope Right or Nothing Else Matters
Audit planning starts with a risk assessment. Review prior audit reports, including evaluations performed by other auditors or consultants. Review publicly available audit reports from similar organizations (public sector entities are required to post theirs online). Cross-reference against the enterprise risk assessment. If any new developments have occurred since the last risk assessment, update your understanding through targeted interviews.
Request preliminary information before the audit begins. This includes details on current SAP systems, application server instances, hardware and software versions, and SAP clients in use. Get contact information for the SAP application owner, security administrator, Basis lead, head of development, and key decision-makers for processes in scope. Request process-specific policies, procedures, flowcharts, and recent committee meeting minutes.
Data-driven audit planning improves scope quality significantly. Analyze transactional data from tables like BKPF, BSEG (Accounting Document Segment), and EKKO (Purchasing Document Header) to understand who is doing what, when, and how volumes are trending. If the organization uses SAP Signavio Process Intelligence, request process mining output to visualize actual transaction flows and identify control point bypasses. Review IT help desk tickets related to SAP S/4HANA for recurring problems or leading indicators.
Original implementation tip: During the kickoff meeting, explicitly ask stakeholders to voice concerns about SAP S/4HANA controls, processing, or support processes. Ask about planned changes to the system during the audit period. Ask about resource constraints and vacation schedules. I learned the hard way that starting fieldwork the same week as a major support pack upgrade creates chaos for everyone. Also ask about any planned SAP S/4HANA changes scheduled for shortly after the audit. If a major change is imminent, you may want to adjust scope or timing to capture both current state and transition risks.
Fieldwork: Validate Findings Before You Write Them Up
During fieldwork, you evaluate how well the risks identified in planning are being managed and whether controls are reliable. The duration varies from one week to several months depending on scope and organizational maturity.
Throughout fieldwork, maintain a running list of potential observations. Here is the critical part: review your observations with SAP-knowledgeable personnel in the organization well before finalizing anything. This system is extraordinarily complex. The risk you are concerned about may be addressed in a way you did not initially recognize. You may have misunderstood a configuration setting and its impact.
I once reported a finding about an open RFC destination that I believed created an unmonitored pathway into production. The Basis administrator showed me a compensating control through a custom monitoring program that logged and alerted on every call through that RFC. Had I not validated before reporting, that finding would have been a false positive in the final report, and my credibility with that client would have taken a hit.
Use transaction SM59 (RFC Destinations) to review configured connections. The table RFCDES (RFC Destination Description) contains the fields RFCDEST (RFC destination name), RFCTYPE (connection type, where 3 means ABAP connection and G means HTTP connection), and RFCOPTIONS (connection options including target host and system number). Look for RFC destinations pointing to production from development or test systems.
Reporting: Speed Matters More Than Formality
The audit report communicates findings, observations, and recommendations. The traditional reporting cycle involves discussion drafts, exit meetings, formal drafts, management comments, and final reports. This process exists for good reasons, but in an SAP S/4HANA environment where problems can affect entire categories of transactions until corrected, a prolonged cycle is unacceptable.
Progressive audit teams distribute reports close to the end of fieldwork and communicate potential problems informally as close to identification as feasible. If you find that someone can modify ABAP code directly in production, waiting three months to formally report that finding is negligent.
During the exit meeting, present findings collaboratively. If auditees disagree with you, listen and ask them to support their position with specific facts. Minor issues should be captured in a separate letter and may not need tracking. Major findings require management responses that detail corrective action plans, time estimates for completion, and responsible individuals.
Original implementation tip: The management response to SAP S/4HANA audit findings sometimes requires system changes that take months to implement properly. In these cases, capture both the desired end state and a short-term compensating control that closes the gap immediately. "We will redesign the role structure within six months" is acceptable as a long-term plan. It is not acceptable as a response to a critical SoD violation that exists today. Insist on interim controls, such as enhanced monitoring through transaction SUIM or a custom report on table CDHDR (Change Document Header), with fields OBJECTCLAS (object class), OBJECTID (object value such as document number), CHANGENR (change document number), USERNAME (user who made the change), UDATE (change date), UTIME (change time), and TCODE (transaction code used).
Follow-Up: Close the Loop
After the final report, most audit functions track remediation. For SAP S/4HANA findings, do not accept management's word that an issue is resolved. Verify it. If the finding was about an unlocked production client, log into SCC4 and confirm the CCCORACTIV field is now set correctly. If the finding was about excessive authorizations, run the SUIM reports again and compare results.
Cross-Cutting Implementation Tips for SAP S/4HANA Audits
These apply regardless of which audit layer or phase you are working in.
Original implementation tip on HANA database security: SAP HANA introduces a database-level security model that is separate from the SAP application security model. Many audit teams focus exclusively on SU01 and role assignments while ignoring HANA database users entirely. Query SYS.GRANTED_PRIVILEGES and SYS.GRANTED_ROLES through HANA Studio or DBACOCKPIT to identify database users with administrative privileges. A database user with the HANA system privilege SYSTEM ADMIN or USER ADMIN can create new database users and grant privileges outside the SAP application entirely. This is a control gap that exists in many S/4HANA environments because the Basis team and the database team operate in silos.
Original implementation tip on change document analysis: Table CDHDR combined with CDPOS (Change Document Items) provides a complete audit trail for master data and configuration changes. CDPOS contains the fields OBJECTCLAS (object class), OBJECTID (object value), CHANGENR (change document number), TABNAME (table name where the change occurred), FNAME (field name that was changed), CHNGIND (change type, where U is update, I is insert, and D is delete), VALUE_NEW (new value), and VALUE_OLD (old value). Build a standard extraction for these two tables covering the full audit period. Sort by USERNAME and TCODE from CDHDR. Changes made through unexpected transaction codes or by users who should not have access to the changed objects are your highest-priority investigation items.
Original implementation tip on SAP Notes and security patches: Use transaction SNOTE (SAP Note Assistant) to review which SAP Notes have been applied to the system. Cross-reference against the SAP Security Patch Day advisories published monthly at support.sap.com. The gap between published security notes and applied notes represents your unpatched vulnerability exposure. Many organizations are months or years behind on critical security patches for SAP HANA and S/4HANA kernel components. This is a legitimate ITGC finding with direct cybersecurity implications.
Original implementation tip on audit evidence preservation: Export all key evidence to PDF or spreadsheet format during fieldwork. SAP S/4HANA data changes constantly. If you identify an issue in week two of fieldwork and management fixes it in week three, you need the original evidence to support your finding. Screenshots from transactions SM19, SCC4, RZ10, and SUIM should be timestamped and stored in your working papers immediately upon capture.
Key References and Standards
The following standards and frameworks provide the authoritative foundation for SAP S/4HANA audit activities described in this post:
ISACA COBIT 2019 Framework for IT governance and management. ISACA IT Audit and Assurance Standards (ITAF). AICPA SOC 1 and SOC 2 reporting frameworks for service organizations. PCAOB Auditing Standard No. 5 for integrated audits of internal control over financial reporting. NIST SP 800-53 Rev. 5 for security and privacy controls. ISO 27001:2022 for information security management systems. SAP Security Guide for SAP S/4HANA (available at help.sap.com). SAP HANA Security Guide and SAP HANA Administration Guide. Sarbanes-Oxley Act Section 404 and related SEC guidance. IIA Global Internal Audit Standards 2024. COSO Internal Control Integrated Framework 2013. SAP Note 2960795 and related notes on SAP HANA security recommendations.
Making Your Audit Count
Treating the SAP S/4HANA audit framework as a compliance checkbox produces reports that nobody reads and findings that nobody fixes. The organization gains nothing. Risk accumulates silently until something breaks publicly.
Treating it as an operational tool produces a maturity roadmap that management can act on, a prioritized list of control improvements with measurable business impact, and an ongoing dialogue between audit and operations that strengthens the entire control environment. The audit report becomes the starting point for improvement rather than the end of the conversation.
The quality of your SAP S/4HANA audit is determined not by how many findings you report, but by whether those findings accurately identify the risks that affect the business and provide a clear path to resolution.
What is your organization's current maturity level for SAP S/4HANA internal controls, and what would it take to move up one level in the next 12 months?
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.