How to Audit IT General Controls, Basis Settings, and SAP S/4HANA Security

 

Audit Guide for SAP S/4HANA IT General Controls, Basis Settings, and Security

A minimum password length of 4 characters. SAP_ALL assigned to 11 dialog users. Table logging disabled in production. The system change option set to modifiable. And the client lock on the production client removed six times during the audit period with no documentation explaining why.

That was a single SAP S/4HANA audit. One client. One system. And every one of those findings existed because nobody checked the foundational layer before testing the business process controls sitting on top of it.

Here is the problem. Organizations spend weeks testing purchase order release strategies, three-way match configurations, and payment approval workflows. They validate that configurable controls are set correctly and that users follow documented procedures. Then an auditor discovers that a developer had debugging access in production, that the system was unlocked for modification three times in the last quarter, and that RFC connections from the development system point directly at production data. Every business process control conclusion becomes unreliable because the foundation was never validated.

ITGCs and Basis security settings are that foundation. If they fail, everything above them in the audit pyramid becomes suspect. This post covers the complete audit approach for IT General Controls, Basis settings, transport controls, logging frameworks, profile parameters, and the SAP authorization concept, with every T-code, table, field, and parameter you need to execute a thorough review.

IT General Controls: The Layer That Supports Everything

ITGCs are internal controls broadly associated with the management, processes, and general operations of the IT function. They are not SAP-specific. They apply to any organization using computers and software to run business processes. But their integrity directly determines whether the SAP S/4HANA controls above them can be trusted.

Think of SAP S/4HANA as a race car. ITGCs are the pit crew, the fuel quality, the track maintenance, and the security preventing someone from tampering with the engine before the race. The best car and driver in the world cannot perform if the fuel is contaminated or the wheels are wrong for the surface.

The common IT services supporting SAP S/4HANA include hardware and database maintenance, data center physical and environmental controls, oversight of third-party hosting providers, help desk management, user authentication processes feeding into SSO, backup and archival management, interface monitoring, system and network performance monitoring, and IT strategic planning.

ITGCs are rarely managed by a single organizational area. They have independent but related layers depending on how the organization manages hardware, databases, and applications. Organization-wide IT policies sit at the top. Below them, IT management areas may differ by geography, business unit, or technology platform. At the bottom, SAP-specific management functions may have their own procedures. Your audit should examine every layer of the stack that supports SAP S/4HANA and ignore stacks that do not.

A general rule: SAP-specific procedures can be more stringent than organization-wide procedures, but the reverse is not acceptable.

Original implementation tip: Before testing any SAP S/4HANA configurable control, verify that your organization has completed an ITGC review within the last 12 months. If ITGCs have not been assessed recently, your conclusions about business process controls carry an implicit assumption that the foundation is sound. That assumption may be wrong. I have seen organizations with perfectly configured three-way match controls operating in an environment where network security was so weak that the check clearing file could be modified before SAP picked it up for processing. The system processed inaccurate data accurately. The ITGC failure made the application control irrelevant.

ITGC Standards and Frameworks You Should Know

Several frameworks provide the authoritative basis for ITGC audits. You do not need to memorize all of them, but you should know which ones apply to your organization and where they overlap.

COBIT 2019, published by ISACA, is the most common IT control framework for audit purposes. It groups control objectives into four domains: Align, Plan, and Organize (APO), Build, Acquire, and Implement (BAI), Deliver, Service, and Support (DSS), and Monitor, Evaluate, and Assess (MEA). Each domain contains 4 to 14 processes leading to several hundred control objectives. Summary documents are available at https://www.isaca.org/resources/cobit.

GAIT (Guide to the Assessment of IT General Controls Scope Based on Risk), published by the IIA, defines a risk-based methodology for prioritizing IT controls. Although the IIA has retired the GAIT series, it remains a valuable reference for those new to ITGCs. GAIT recognizes that not all risks need automated controls and that some IT risks may be mitigated by business monitoring procedures rather than IT controls.

ITIL (Information Technology Infrastructure Library) provides objective guidance for measuring IT service management processes. COBIT tells you what risks IT procedures should address. ITIL tells you how those procedures should work.

CMM (Capability Maturity Model) from the Software Engineering Institute is the standard for systems design and development processes. COBIT 2019 incorporates an IT performance management maturity model recognizing that control processes mature over time.

NIST Cybersecurity Framework (CSF) 2.0 is the gold standard for security in the United States. ISO 27001 and ISO 27002 are international standards for cybersecurity program validation. ISO 27001 defines the standard. ISO 27002 provides controls and implementation guidance, most recently updated in 2022.

ITGC Problem Areas That Matter Most for SAP S/4HANA Audits

Four ITGC areas create the most common and most damaging findings in SAP S/4HANA audits: policies and procedures, security, change control, and interface management.

Policies and Procedures

Before testing SAP-specific settings, verify that documented policies and procedures exist, are complete, and are consistent with industry benchmarks.

The three most common policy-related findings are predictable but persistent.

Out-of-date policies and procedures. Procedures were appropriate when first drafted but no longer reflect current technology or business conditions. The business adapts. The policies do not. Employees stop reading the manual because it is outdated, and the manual stays outdated because employees do not read it. Verify that a periodic review cycle exists for all IT policies.

No process for approving and documenting exceptions. Legacy systems feeding data to SAP S/4HANA may not support current encryption standards. That may be an acceptable exception, but it must be formally approved by management with authority to accept the risk, and the approval must be documented and retained.

Known exceptions not periodically reapproved. I regularly find policy exceptions made more than five years ago still in place without subsequent review. Management turnover, technology advances, and changes in risk appetite all require re-evaluation. A 12-month reapproval cycle is appropriate for most organizations.

Security at the ITGC Level

Three security findings appear in nearly every ITGC review I have conducted.

Ineffective monitoring of privileged access to SAP infrastructure components. IT users with administrator privileges for servers, databases, and network components supporting SAP S/4HANA should be tightly controlled and their activities monitored. The review processes frequently exist. They are frequently inadequate. The logs are so voluminous that detecting unexpected activity is unlikely, and evidence that a review actually occurred is often missing. For organizations running SAP S/4HANA in a hosted or cloud environment, the most common gap is failing to independently monitor the third-party provider rather than simply trusting their controls.

System access not changed upon change in responsibilities. This is one of the easiest findings to detect and one of the most common to discover. Match recent employee terminations and transfers against active system access. Active directory synchronization and SSO theoretically prevent this, but HR notification delays and incomplete communications between HR and IT create gaps regularly.

Some organizations argue that physical access controls and network access controls make stale application access harmless. This argument assumes the only way to access an application is from inside the building, which is false in any organization with remote access. It also assumes only the original user might exploit the access, ignoring shared passwords and discovered credentials. Modify application access when responsibilities change. Period.

Use of generic SoD matrices. Every organization should have an SoD matrix unique to its environment. The default ruleset in SAP Access Control does not account for industry-specific SoD risks, does not see your custom transactions, and does not consider cross-system conflicts. A user who can perform a function in SAP S/4HANA that conflicts with their ability in a separate application creates an SoD risk that no single-system ruleset will detect. Your SoD matrix should be system-independent and periodically validated by management.

Change Control

No matter what type of SAP S/4HANA audit you are performing, some level of change control assessment is recommended. Change control provides assurance that the settings you validate today will be the same tomorrow.

Excessive developer access in production. Developers frequently have development access in production and sometimes even business-type access. Allowing developers to process anything beyond display transactions in production is an SoD issue. The argument that "the system is locked so they cannot make changes" is true only until the system becomes unlocked, at which point all that access becomes usable.

Debugging access in production is particularly dangerous. Debugging is granted through the DEBUG object type in the S_DEVELOP authorization object. A user with debugging access can bypass every control in SAP S/4HANA, including security controls. Rather than granting debugging as part of a developer's standard role, use SAP Access Control's Emergency Access Management (EAM) functionality to grant enhanced privileges only when needed, with logging, monitoring, and automatic expiration.

Failure to include security and control requirements in change requests. In organizations with immature governance, security requirements get designed into a change only if the requestor specifically asks for them. Place security and control requirement fields on the standardized change request form so they are consistently considered.

Failing to maintain supporting documentation in an accessible location. The change control process generates evidence at every stage: request, requirements, approvals, testing, QA, and production transport authorization. All of this must be gathered, signed, and stored in a way that associates it with the specific transport.

Failing to complete skipped steps after implementing emergency changes. Emergency changes bypass normal controls for speed. Following up after the emergency to ensure the change meets production standards is non-negotiable.

Failure to check code for vulnerabilities. ABAP code is susceptible to SQL injection, cross-site scripting, and other common attacks. SAP provides development guides for writing secure code, but many developers are unaware of them. Code scanning should be part of every change process.

Interface Management and Monitoring

Interface procedures should ensure that information is received and processed completely, that data is processed only once with reprocessing procedures preventing duplication, that data in transit between systems is protected from modification and encrypted if sensitive, and that monitoring procedures detect and resolve file completeness and integrity issues.

The most common interface problem is role confusion. SAP personnel monitor batch jobs through SAP transactions. Other IT personnel review interface status through other tools. When IT communicates an interface issue to business management but considers their job done until they receive further instructions, and the business area misses or forgets the message, the problem never gets resolved. Verify that interface issue communications have a defined resolution tracking process.

Original implementation tip: When auditing interfaces, use transaction SM37 (Background Job Overview) to review scheduled interface jobs. Query table TBTCO (Job Status Overview) with fields JOBNAME (job name), SDLUNAME (scheduled by user), STRTDATE (actual start date), ENDDATE (actual end date), STATUS (job status, where F is finished, A is aborted, and Y is ready), and SDLSTRTDT (planned start date). Filter on STATUS equal to A for aborted jobs during the audit period. Cross-reference aborted interface jobs against the issue tracking system to verify that each failure was detected, communicated, and resolved. The gap between aborted jobs in TBTCO and documented incidents in the issue tracker tells you whether the monitoring process is actually working.

Basis Settings and Transport Controls: Where SAP-Specific Assurance Begins

Basis settings and transport controls are the SAP-specific extension of ITGCs. They determine how the system is locked from unauthorized changes, how development follows the intended lifecycle, and how configuration changes are controlled. This section covers the specific settings, parameters, and audit procedures for each.

Logging Options: What SAP S/4HANA Records and What It Does Not

SAP S/4HANA offers multiple logging frameworks. Some are enabled by default. Some are not. Some can be disabled. Understanding what is being logged and what is not is essential before you test any controls.

Change documents record master data and accounting-relevant transaction data changes. They are enabled by default and can be modified. Three requirements must be met for a field change to be recorded: the field must be associated with a data element marked for change documents, the table must be associated with a change document object, and the program must call one of the CHANGEDOCU functions. Change documents are not intended for high-volume changes, which is why they primarily cover master data and accounting-relevant transactional data.

The change document tables are CDHDR (Change Document Header) and CDPOS (Change Document Items). In CDHDR, key fields include OBJECTCLAS (object class such as KRED for vendor, DEBI for customer, MATERIAL for material), OBJECTID (specific object identifier), CHANGENR (change document number), USERNAME (user who made the change), UDATE (change date), UTIME (change time), and TCODE (transaction code used). In CDPOS, key fields include OBJECTCLAS (same as header), CHANGENR (linking to header), TABNAME (table where change occurred), FNAME (field name changed), CHNGIND (change type where U is update, I is insert, E is delete), VALUE_NEW (new value), and VALUE_OLD (previous value).

Most auditors do not realize that change document configuration can be modified. An administrator with excessive access could disable change documents for a specific field like vendor bank account, make the change, and re-enable logging. The risk is low because you would eventually notice the field never appearing on change reports, or you would detect the configuration change through transport or emergency access reviews. But be aware the possibility exists.

SAP Gateway logging records configuration changes and activity for SAP Gateway, which is the front door into SAP S/4HANA for other applications. It is turned off by default. It can be dynamically enabled through transaction SMGW following menu path Goto, Expert Functions, Logging. The parameter gw/logging controls what events are logged at server startup. Gateway log reviews are typically part of advanced technical or cybersecurity audits.

The security audit log records security-related events. In SAP S/4HANA, it is enabled by default for critical events, a significant improvement over SAP ERP where it was disabled by default. SAP S/4HANA allows more than 170 detailed events to be configured for logging, ranging from critical system events like deletion of audit log data to low-risk events like user logoff.

Use transaction SM19_DISP (introduced in SAP S/4HANA 2022) to display the security audit log configuration without modification risk. This read-only transaction shows static configuration profiles defining what events are logged for which users and clients. The default configuration logs all activity by the SAP* user across all clients and all activity by any user in client 066 (SAP EarlyWatch).

Use transaction SM20N to view security audit log data for specific risk investigations.

My recommendation: log all possible events. Disk space is cheap. Security audit log files are stored as text files on the file system and are easily archived to WORM storage. Log everything. Monitor critical and high-risk events proactively. Having low-risk event data available means you can narrow investigation windows when an incident occurs. If someone reports that your CFO's password is being used in the evenings, being able to identify logon and logoff times across all sessions is invaluable.

The system log captures technical system events and is monitored by the Basis team through transaction SM21. It is enabled by default and cannot be disabled. Each entry receives an automatic priority. Historically it was the only way to see debugging activity, but that capability now exists in the security audit log, which is easier to correlate with surrounding activity. Most auditors have limited use for the system log.

Table logging is one of the most critical yet underutilized logging options in SAP S/4HANA. Certain audit-relevant questions cannot be answered without it. Was the production client opened for editing? How long was a previously closed posting period open? Was a key configuration changed temporarily and then reverted?

Confusion persists from the early SAP R/3 days when high-volume tables were incorrectly set to be logged by default, causing performance issues. SAP Note 608835 confirms this was fixed. SAP Note 1653464 explicitly recommends that table logging be enabled in production systems. In more than a decade of recommending table logging across my client base, I have encountered exactly two performance issues, both caused by incorrect custom development that would have been identified earlier if SAP Note guidance had been followed.

Table logging differs from change documents. Change documents cover only one scenario: changes made through standard SAP transactions that call CHANGEDOCU functions. Table logging covers five of six scenarios, failing only to log changes made directly in the SAP HANA database outside of SAP S/4HANA.

Enabling table logging requires two steps. The profile parameter rec/client must be set to your production client number or to ALL. And each table to be logged must have the Log Changes flag selected in transaction SE13 under the Data Changes section of General Properties.

View table log entries through transaction SCU3.

Do not forget custom tables. Many organizations have custom tables driving allocations, authorization limits, and rates that get changed through parameter transactions editing table values directly in production. Enable table logging for these tables.

Workload analysis, accessed through transaction ST03N, provides short-term log files designed for performance monitoring, not long-term audit trails. However, it can serve audit purposes for security exposure testing when the security audit log has not been enabled for transaction starts. You can determine whether specific transactions were executed during the period covered by the log retention.

View retention settings in transaction ST03N by navigating to Collector and Performance DB, Performance Database, Workload Collector Database, Reorganization, Control. The User, Transaction Profile settings capture transaction execution by user ID. The retention fields DAggRetPer (daily aggregates), WeekRetPer (weekly aggregates), and MonRetPer (monthly aggregates) control how long data is available.

Within the retention period, access user transaction execution under Detailed Analysis, Business Transaction Analysis, or through transaction STATS.

Version management is enabled by default and cannot be disabled. It is part of the transport organizer and active for all ABAP Workbench object categories. It provides a complete history of changes to SAP repository objects with the ability to compare versions, such as current ABAP code versus a prior version.

Access version management through transaction SE80 (Object Navigator) by selecting the object and choosing Utilities, Versions, Version Management. Or from transaction SE38 (ABAP Editor) while displaying code, choose Utilities, Versions, Version Management.

Versions exist in the system where they were created. If a change was made in development and transported to production, production shows the new version number, but seeing the full version list and doing comparisons requires either being in the development system or using the Fetch Remote Versions option.

Original implementation tip: During your audit planning, verify the status of every logging framework before you start fieldwork. Run transaction RSPFPAR and check the rec/client parameter. If it is blank or set to 000, table logging is not active for your production client. Run transaction SM19_DISP to verify security audit log configuration. Check whether SAP Gateway logging is enabled through the gw/logging parameter. Document the status of each log. If critical logs are disabled, your ability to answer certain audit questions is fundamentally limited, and that limitation should be documented in your working papers and communicated to audit management before you scope fieldwork procedures that depend on log data.

System Development Controls and SAP S/4HANA Locking Mechanisms

SAP S/4HANA provides three primary mechanisms for preventing unauthorized changes: the system change option, the client lock, and transport route enforcement. Testing all three is required for any Basis audit.

The System Change Option

Transaction SE06 provides the system change option under Post-Installation Actions for Transport Organizer. This lock prevents modification globally across all clients. It can be set at the global level and granularly by software component or namespace.

To test: Run transaction SE06 and click System Change Option. The Global Setting field should be set to Not Modifiable. Each software component and namespace in the lists below should also be Not Modifiable. If set to Modifiable, a developer with appropriate authorization can create or change objects including ABAP code.

To verify whether this setting changed during the audit period: From the same screen, click the log icon. Click the plus icon to the left of the top-most entries to expand the detail showing date, time, and user for each change. When using the global change option, each software component records a separate log entry, so you may need to scroll through many pages.

The Client Lock

Transaction SCC4 controls the client lock. This protects a specific client from client-dependent changes (configuration in the IMG), client-independent changes (ABAP code), and erroneous client copies.

To test: Run transaction SCC4 and double-click your production client. Verify the following settings. Changes and Transports for Client-Specific Objects should be No changes allowed. Cross-Client Object Changes should be No changes to repository and cross-client customizing objects. Client Copy and Comparison Tool Protection should be Protection level 2 with no overwriting and no external availability. CATT and eCATT Restrictions should be eCATT and CATT Not Allowed.

One potential exception: Some add-on products use CATT or eCATT functionality for data loading in production, such as batch journal entry uploads. In these cases, allowing CATT and eCATT only for trusted RFCs is acceptable.

To verify whether the client lock changed during the audit period: This requires table logging to be active. Run transaction SCU3 and enter table T000 with Evaluation set to Tables. The log shows each field change with the date, time, and user. In the table, the fields CCCORACTIV (changes and transports for client-specific objects), CCNOCLIIND (cross-client object changes), and CCCOPYLOCK (client copy protection) correspond to the first three settings in SCC4.

The 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, 1 means changes allowed, and 2 means changes without automatic recording), CCNOCLIIND (cross-client object changes restriction), and CCCOPYLOCK (protection level for client copy).

When opening production for an emergency change, enable automatic recording of client-specific objects. In the SCU3 table log for T000, this appears as a value of 1 in the Corr. Sys. field, meaning client-specific changes are associated with a local transport request. The transport request number will start with the three-character SID of your production system, an inherent control in SAP S/4HANA that distinguishes local changes from transported changes.

Important procedural note: The check for the system lock and client lock occurs early in the code, specifically after the user runs a development transaction but before they save their work. If a user is editing a program in SE38 when the lock is set, they can still save their changes. Always terminate all user sessions before locking or unlocking the system or client.

Transport Route Controls

Transport routes ensure that all changes follow the designated SDLC path: development to test to production, with no direct route from development to production.

Review transport routes by running transaction STMS and clicking the Transport Route icon. Have the head of development walk you through the configured routes.

To verify whether transport routes changed during the audit period: From the transport route display, select Configuration, Get Other Version. The version history shows every change to transport paths with date and version number. Double-clicking a version number shows the transport route as it existed at that point.

To review transports imported into production: Select the Import Overview option from transaction STMS, double-click your production SID, and double-click specific transport requests to see contents. Press Ctrl+Shift+F2 for additional transport date and status information.

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 and D is modifiable), AS4USER (owner), AS4DATE (last changed date), and AS4TEXT (short description). Table E071 (Object Entries in Transport Requests) contains TRKORR (transport request), PGMID (program ID), OBJECT (object type where PROG is program, TABU is table contents, CDAT is view cluster data), OBJ_NAME (object name), and LOCKFLAG (lock indicator).

Security enforcement completes the development control framework. Developers should not be able to unlock the system or client, and they should not be able to import their own transports into production. Both restrictions are enforced through SAP authorization objects.

Original implementation tip: Developer keys (SSCR keys) are no longer required in SAP S/4HANA as of version 1511. SAP Note 2309060 documents this change. If you are auditing SAP S/4HANA and still checking table DEVACCESS for developer key registrations, you are testing an obsolete control. The system now relies solely on authorization objects assigned through the security model to control development access. Update your audit program accordingly.

Profile Parameters: The Settings That Control System Behavior

SAP S/4HANA profile parameters are read at system startup and control system behavior for security, encryption, communication protocols, and more. Many have no audit relevance. Some are critical.

Determining and Testing Parameter Values

Parameters can be set at three levels. The kernel default is the value hard-coded into SAP S/4HANA and cannot be changed. The default profile applies to all application server instances. The instance-specific profile applies to a single instance only. Instance-specific values override default profile values, which override kernel defaults.

Use transaction RSPFPAR to view parameter settings. This transaction is superior to the legacy RSPARAM program because it allows selection of specific parameters and creation of variants for repeatability. In the report output, if the User Value column (also titled User-Defined Value) contains a value, that is the active setting. If blank, the SysDefault column (System Default Value) is active.

Critical audit point: Parameter reports display values for the application server instance you are currently logged into. If parameters are set in instance-specific profiles, they may differ across instances. To verify consistency, review each instance-specific profile in transaction RZ10, or examine the text files in the directory indicated by the DIR_PROFILE parameter.

Profile parameters are case sensitive. They must be entered exactly. SAP S/4HANA does not validate entries. I encountered a situation where an administrator pasted parameter values from Microsoft Excel, which automatically capitalized the first letter of each parameter. The parameters were invalid. The report showed a Login/password_expiration_time suggesting passwords expired monthly, but the system did not recognize the entry and used the kernel default, which required no expiration at all.

Even when the kernel default value is your desired setting, enter it explicitly in the default profile. If SAP changes the kernel default during a future upgrade, your chosen values remain in place unless you consciously accept the new value.

Parameters Most Common in SAP S/4HANA Audits

For typical audits: rdisp/gui_auto_logout (automatic session timeout in seconds, kernel default 0 meaning no timeout), rec/client (table logging client, no default meaning disabled), and all parameters starting with login/ covering password policies and authentication behavior.

For advanced technical audits: DIR_AUDIT (security audit log file directory), DIR_PROFILE (profile file directory), parameters starting with auth/ (authorization-related), rsau/ (security audit log configuration), gw/ (SAP Gateway), and rfc/ (RFC communication).

Key login parameters include login/min_password_lng (minimum password length, default 8 in recent releases), login/password_expiration_time (days until password expires, default 0 meaning no expiration), login/fails_to_session_end (failed attempts before session termination, default 3), login/fails_to_user_lock (failed attempts before user lock, default 12), login/no_automatic_user_sapstar (controls SAP* default superuser behavior, must be 1 to prevent automatic SAP* logon when the user master record is deleted), login/disable_multi_gui_login (controls concurrent logon behavior, where 1 allows with logging), and login/multi_login_users (exclusion list for the multi-login restriction).

Use transaction RZ11 for detailed parameter documentation. Enter the parameter name and click Display Documentation. The documentation includes dependencies on other parameters that are not always found through online searches. For example, the login/disable_multi_gui_login parameter documentation reveals that login/multi_login_users can provide an exclusion list, so your analysis is incomplete without evaluating both parameters.

Detecting Parameter Changes During the Audit Period

Transaction TU02 shows the history of parameter value changes. Click on the application server instance, select the Select Period button, and enter the start date of your audit period. The report displays only parameters with new values since that date.

Note: The System ID column in TU02 actually displays the instance number, not the SID. SIDs are three-character codes. Instance identifiers combine a hostname with a two-digit instance number. This is a labeling error SAP has carried forward from older versions.

Critical limitation: Transaction TU02 cannot be granted in read-only mode because it includes a Delete Server Names function that can delete all profile parameters for an application server instance. I recommend creating a custom copy of the underlying program with that function removed, assigned to a custom transaction code like ZTU02, to enable safe audit access.

Original implementation tip: On every SAP S/4HANA audit, I run transaction RSPFPAR for the login parameters and rec/client as my first test procedure. If login/min_password_lng is below 8, login/password_expiration_time is 0, or rec/client is blank, I know the organization has not addressed basic security hygiene, and I adjust my risk assessment and testing scope accordingly. If the basics are wrong, the complex controls will also have problems. This simple test takes five minutes and sets the trajectory for the entire Basis review.

SAP User Security and the Authorization Concept

SAP S/4HANA uses a default-deny security model. A newly created user ID can log in but can do nothing except view the main menu and access help. Every permission must be explicitly granted through authorization objects assigned via roles. This is fundamentally different from most other security models and requires specific audit techniques.

User Master Records

Every user ID has a user master record managed through transaction SU01 (maintenance) or SU01D (display). The minimum fields required to create a user are the User ID, Last Name, User Type, and an initial password.

Table USR02 (Logon Data) stores core user master data. Key fields include BNAME (user name), USTYP (user type where A is dialog, B is system, C is communication, L is reference, S is service), UFLAG (user lock status where 0 is unlocked), TRDAT (last logon date), LTIME (last logon time), GLTGV (valid from date), GLTGB (valid to date), ERDAT (creation date), CLASS (user group), and CODVN (password hash code version indicating the hashing algorithm).

If a user ID should be associated with a security policy (allowing different password rules for different user categories), the Security Policy field in the Logon Data tab must be completed. If the user should be restricted to specific administrators, the User Group field must be populated, and only administrators authorized through the S_USER_GRP authorization object for that group can maintain or display the user.

User IDs can be effective-dated with starting and ending validity dates. Expiration dates serve two purposes: deactivating users who are no longer needed and periodically expiring contractor or temporary accounts for reconfirmation.

A layered defense strategy for expired user IDs includes four steps. Invalidate the ID by setting an ending validity date in the past. Reset the password so that even if someone convinces an administrator to reset the validity date, the old password no longer works. Assign the ID to a user group restricted to a small number of administrators, making it harder to reactivate. Remove all roles and profiles so that even if someone bypasses the first three layers, the ID is useless.

Do not delete user IDs. Deletion destroys the audit trail.

User Types and Their Risk Profiles

SAP S/4HANA has five user types, each with different capabilities and risk characteristics.

Dialog users (type A) are the most common. They log in interactively through SAP GUI. Passwords expire based on the login/password_expiration_time parameter. Users can change their own passwords. Concurrent logons are logged if allowed. This is the standard user type for individual employees.

Service accounts (type S) are the highest-risk user type. They allow anonymous access through SAP GUI for large groups of users, such as web service consumers viewing product prices. Passwords do not force changes. They are the most dangerous type because they combine interactive logon capability with no password expiration and anonymous usage.

System users (type B) are used for background processing, workflows, interfaces, and transports. They cannot log into SAP GUI. Historically considered lower risk, the proliferation of freely downloadable tools that communicate with SAP through system accounts has increased their risk profile significantly over the last decade.

Communication users (type C) are used for dialog-free communication between systems, typically through RFC connections. Password expiration is enforced similar to dialog users, but the password is actually changed in the calling system.

Reference users (type L) cannot log in through any method. They exist to extend the user buffer size for user IDs with many authorizations. When assigned as a reference user to another ID, the target ID inherits the reference user's authorizations, effectively doubling the buffer capacity.

In SAP S/4HANA, authorizations inherited through reference user association are included in transaction SUIM reports. In SAP ERP, they are not. I have demonstrated in audit training courses a user ID that appears to have no authorizations whatsoever, but because it is associated with a reference user holding SAP_ALL, it can do everything in the system. On SAP ERP, this does not appear in any standard security report.

The Authorization Concept

The SAP authorization concept determines what a user ID is authorized to do. It operates through authorization objects, which are security constructs referenced in ABAP code that tell SAP S/4HANA what authorizations a user needs to perform a specific function.

An authorization object acts as a filter applied to data. The F_BKPF_BUK authorization object tells SAP S/4HANA to check which company codes a user is authorized to access when working with accounting documents. If the code also references F_BKPF_BLA, an additional filter restricts the user to specific document types. The combination of authorization objects creates layered access restrictions.

Critical point: The ABAP code must reference the authorization object through an AUTHORITY-CHECK statement. If a developer writes code that updates accounting entries without referencing any authorization objects, any user who can run that code has unrestricted access to whatever the code allows. This is why QA processes must verify that developers call relevant authorization objects in custom code, whether or not the user requesting the customization specified security requirements.

Authorization objects have fields that define the scope of access. The ACTVT field, present in most business-oriented authorization objects, defines the activity type. The four most common audit-relevant ACTVT values are 01 (create), 02 (change), 03 (display), and 06 (delete). Not all authorization objects have an ACTVT field, which means it is not always possible to restrict a user to display-only access for certain functions.

Roles, Profiles, and Access Assignment

Security administrators create roles through transaction PFCG (Profile Generator). The administrator enters the transactions to include in the role. The profile generator proposes authorization objects typically associated with those transactions. The administrator fills in desired values for each authorization object field, such as company codes, plant numbers, or activity types.

After values are assigned, the administrator generates the related profile, which is a container storing the authorizations. The profile is contained within the role. The key difference: roles can be effective-dated when assigned to users. Profiles alone cannot.

Table AGR_1251 (Authorization Data for Activity Group) stores the authorization details for each role. Fields include AGR_NAME (role name), OBJECT (authorization object), AUTH (authorization name), FIELD (authorization field), LOW (from value), and HIGH (to value).

Table AGR_USERS (Assignment of Roles to Users) maps users to roles. Fields include AGR_NAME (role name), UNAME (user name), FROM_DAT (valid from date), and TO_DAT (valid to date).

Table USOBT_C (Relation Transaction to Authorization Object) is used by the profile generator to propose authorization objects for transactions. This table can be maintained by administrators and is not 100% reliable, but it provides a useful starting point for understanding which authorization objects relate to which transactions.

For precise determination of required authorization objects, use transaction ST01 (Authorization Trace). An administrator enables the trace for a specific user, the user performs the activity of interest, and the administrator disables the trace. The resulting log shows every authorization object checked, in order, with the required field values.

Multiple Pathways to Data

SAP S/4HANA data can be accessed through multiple pathways, each of which must be secured. Standard transactions go through the normal authorization check sequence: table TSTC verification, S_TCODE authorization check, transaction-assigned authorization object check, and AUTHORITY-CHECK statements in the ABAP code.

But users can also access data by running programs directly through transaction SA38 or SE38, editing tables through table maintenance transactions, communicating through RFC connections, accessing SAP Fiori apps, or connecting directly to the SAP HANA database through ODBC. Each pathway has its own authorization objects and security requirements.

For the HANA database pathway, query SYS.GRANTED_PRIVILEGES to identify users with DATA ADMIN, CATALOG READ, or other administrative privileges that bypass SAP application security entirely.

Auditing User Security: Practical Procedures

Start with transaction SU01D for individual user reviews and transaction SUIM for population-level analysis. In SUIM, navigate to User, Users by Complex Selection Criteria, Users by Complex Selection Criteria (the executable option).

Common audit questions for user master records include whether user IDs follow naming conventions, whether each ID is assigned to the correct security policy, whether each ID is in the correct user group, whether any users can bypass SSO and log in through SAP GUI directly, whether any users communicate with SAP using unencrypted connections, whether each user is associated with the correct roles, whether any user has directly assigned profiles, and whether expired users have been properly deactivated with validity dates, group reassignment, and role removal.

I follow a progressive audit approach, testing basics first. If an organization cannot get the basics right, more complex issues are guaranteed.

First query: Users with SAP_ALL profile. In SUIM Users by Complex Selection Criteria, go to the Role/Profiles tab and enter SAP_ALL in the Profile Name field. This profile grants wildcard values to every field in every authorization object. Any dialog user with SAP_ALL can do everything in SAP S/4HANA.

Second query: Users with SAP_NEW profile. This grants full access to newer authorization objects released by SAP in recent versions.

Third query: Users with directly assigned profiles. Run the Users by Complex Selection Criteria report with no selection criteria, click the Profiles button in the results, and filter the Profile Type column to exclude generated profiles. Generated profiles cannot be directly assigned without role assignment, an inherent SAP control. Any remaining profiles were directly assigned outside the role framework.

Fourth query: Users assigned to sensitive roles. Talk to security administrators to identify roles granting access to unlock the production client, open posting periods, make inventory adjustments, or perform other high-risk functions. In SUIM, enter the role name in the Role field to see all assigned users.

Fifth query: Users with high-risk authorizations. To find users who can unlock the production client through SCC4, search for users with S_TCODE authorization for transaction SCC4 combined with S_TABU_NAM authorization for table T000. Also search separately with S_TABU_DIS using authorization group SS, as this provides an alternative path to the same table.

Sixth query: Users with wildcard values in sensitive authorization objects. To find users granted the asterisk wildcard (representing all possible values) in a specific authorization object field, enclose the asterisk in double quotation marks in the SUIM search field. Without quotes, the asterisk acts as a search wildcard. With quotes, it searches for users who were actually granted the asterisk value.

Original implementation tip: When I find SAP_ALL assigned to dialog users in production, I stop the security review and escalate immediately. SAP_ALL on a dialog user means that user can unlock the system, modify ABAP code, change configuration, delete audit logs, create other users with SAP_ALL, and reverse any control in the system. There is no combination of compensating controls that adequately mitigates this. On one audit, the security administrator told me "those are just our support team, they need it for troubleshooting." Seven of the eleven users with SAP_ALL had never logged in during the audit period. Three of the remaining four had used their access solely for running standard reports. The eleventh had used it to modify a custom program directly in production without a transport, without a change request, and without QA. That single user represented the entire risk I was concerned about, and the organization had granted ten other users the same capability for no operational reason.

SAP S/4HANA Audit Program

IT General Controls, Basis Settings, and Security

Introduction and Audit Objectives

This audit program provides a structured approach for evaluating IT General Controls (ITGCs), Basis settings, and security configurations in an SAP S/4HANA environment. The program is designed for auditors, compliance professionals, and security specialists who need to assess the reliability, integrity, and security of SAP systems. The objectives of this audit program are to:

• Evaluate the design and operating effectiveness of ITGCs that support the SAP S/4HANA environment

• Assess Basis configuration settings that impact system security and control

• Review user security and authorization concepts to ensure appropriate access controls

• Validate change management processes that protect production system integrity

• Identify control weaknesses and provide recommendations for remediation

This program follows a top-down, risk-based approach consistent with frameworks including COBIT 2019, ISO 27001/27002, and NIST Cybersecurity Framework guidance -8. The procedures outlined herein should be tailored to your organization's specific risk profile, system landscape, and regulatory requirements.

---

Section 1: IT General Controls Audit Procedures

ITGCs establish the foundation for all other controls within SAP S/4HANA. If these foundational controls are weak, controls within business processes cannot be relied upon. This section addresses the management, processes, and general operations of the IT function that supports SAP S/4HANA.

1.1 Policies and Procedures Review

Audit Objective: Determine whether formal policies and procedures exist, are complete, current, and consistently followed for IT operations supporting SAP S/4HANA.

Risk: Without documented and approved policies, IT operations may be inconsistent, non-compliant with regulations, and unable to demonstrate due care. Outdated policies may be ignored by staff, creating a cycle of non-compliance -1.

Audit Procedures:

• Obtain and review the IT policy manual and related procedures documentation

• Verify that policies exist for key areas including:

  • Access management and password standards

  • Change management

  • Backup and recovery

  • Incident response

  • Third-party service provider oversight

• Assess whether policies have been reviewed and approved within the last 12 months

• Examine evidence of policy distribution and acknowledgement by IT staff

• Review the process for approving and documenting exceptions to policies

• Select a sample of policy exceptions and verify they were approved by appropriate management

• Confirm that exceptions are periodically reapproved (typically annually) to ensure continued appropriateness

Common Findings:

• Policies are outdated and no longer reflect current technology or business practices

• No formal exception process exists

• Exceptions were approved years ago and never re-evaluated

• Employees are unaware of policy requirements

1.2 Security Management Review

Audit Objective: Evaluate the effectiveness of security management practices, including privileged access, user access administration, and segregation of duties.

Risk: Weak security management can lead to unauthorized access, data breaches, fraudulent activities, and inability to hold individuals accountable for their actions. Developers with access to production systems pose particular risks -1.

Audit Procedures:

Privileged System Access:

• Obtain a listing of users with privileged access to SAP infrastructure components including:

  • Operating system access to SAP application servers

  • Database administration access (SAP HANA)

  • Network device administration

  • SAP Basis administrator authorizations

• Verify that privileged access is restricted to authorized personnel

• Review monitoring procedures for privileged user activities

• Assess whether logs of privileged activities are reviewed regularly by someone independent of the administrators

• Examine evidence of log reviews to confirm they occurred

• For cloud or hosted environments, review oversight procedures for third-party provider monitoring

User Access Administration:

• Review procedures for granting, changing, and removing user access

• Select a sample of new user access requests and verify they were properly authorized

• Select a sample of terminated employees and verify access was removed timely

• Match recent employee terminations and transfers from HR records to system access listings

• If user access was not removed, investigate reasons and compensating controls

• Review process for periodic recertification of user access

• Examine evidence of access recertification reviews

Segregation of Duties:

• Obtain the organization's SoD matrix

• Assess whether the matrix is tailored to the organization or a generic ruleset

• Verify that the matrix considers:

  • Industry-specific risks

  • SAP S/4HANA customizations

  • Cross-system risks

  • Critical transaction combinations

• Review how the SoD matrix is maintained and updated

• Select high-risk SoD combinations and identify users with conflicting access

• For users with SoD conflicts, determine whether mitigating controls exist

• Assess the effectiveness of mitigating controls

Common Findings:

• Ineffective monitoring of privileged access due to log volume or insufficient review evidence

• System access not changed upon employee termination or transfer

• Generic SoD matrices that fail to address organization-specific risks

• No process for cross-system SoD analysis

1.3 Change Management Review

Audit Objective: Assess controls over changes to SAP S/4HANA applications and infrastructure to ensure changes are authorized, tested, and properly migrated to production.

Risk: Unauthorized or inadequately tested changes can introduce errors, security vulnerabilities, or control weaknesses into the production environment. Developers with excessive access can bypass controls -5.

Audit Procedures:

Change Control Process:

• Obtain and review change management policies and procedures

• Document the software development lifecycle including:

  • Change request initiation and approval

  • Development and unit testing

  • Quality assurance testing

  • User acceptance testing

  • Transport to production

• Verify that security and control requirements are included in change request forms

• Assess whether changes require appropriate approvals before migration

Developer Access:

• Obtain a listing of users with developer access in production

• Review authorizations for developers, specifically:

  • Access to change production objects directly

  • Debugging access (S_DEBUG authorization)

  • Access to critical transactions

• Assess whether developer access is appropriately restricted

• If developers have emergency access processes, review:

  • How access is granted

  • Whether access is temporary

  • Monitoring of emergency access usage

• Review emergency access logs for unusual activity

Transport Management:

• Review transport routes in Transaction STMS

• Verify that transport paths follow: Development → Test → Production

• Confirm no direct development-to-production routes exist

• Assess whether production client and system are locked (see Section 2)

• Select a sample of transports to production

• For each transport, trace back to:

  • Change request documentation

  • Testing evidence

  • Approval records

• Verify that supporting documentation is complete and retained

Emergency Changes:

• Review procedures for emergency changes

• Select a sample of emergency changes

• Verify that emergency changes were:

  • Properly authorized

  • Documented

  • Followed up with standard change process completion

Code Security:

• Inquire about code scanning processes for vulnerabilities

• Determine whether ABAP code is scanned for issues such as:

  • SQL injection

  • Cross-site scripting

  • Other common vulnerabilities

• Review results of code scans and remediation efforts

Common Findings:

• Excessive developer access in production

• Debugging access granted in production

• Security requirements not included in change requests

• Missing supporting documentation for changes

• Emergency changes not followed up

• No code vulnerability scanning

1.4 Interface Management and Monitoring

Audit Objective: Evaluate controls over interfaces to and from SAP S/4HANA to ensure complete, accurate, and timely processing.

Risk: Interface failures can result in incomplete or inaccurate data processing, financial misstatements, and operational disruptions. Without proper monitoring, issues may go undetected -1.

Audit Procedures:

• Obtain an inventory of all interfaces to and from SAP S/4HANA

• For significant interfaces, review:

  • How data is transmitted

  • Whether data is encrypted for sensitive information

  • How data completeness is ensured

  • How data is protected in holding areas

• Review monitoring procedures for interfaces

• Determine who is responsible for monitoring

• Examine evidence of interface monitoring

• If issues occurred during the audit period, review:

  • How they were detected

  • How they were resolved

  • Whether root cause analysis was performed

• Assess communication protocols between IT and business teams for interface issues

• Verify that there is clear accountability for resolution

Common Findings:

• Unclear responsibility for interface monitoring

• No process to ensure interface issues are resolved

• Lack of encryption for sensitive data in transit

• No completeness checks for incoming/outgoing data

---

Section 2: Basis Settings and Transport Controls Audit Procedures

This section addresses specific technical Basis settings within SAP S/4HANA that support ITGCs and provide assurance that the system operates as intended.

2.1 Logging Framework Review

Audit Objective: Verify that appropriate logging is enabled to provide an audit trail of relevant system activities and changes.

Risk: Without adequate logging, unauthorized or inappropriate activities cannot be detected or investigated. Loss of audit trail impairs ability to demonstrate compliance -2-9.

Audit Procedures:

General Logging Assessment:

• Review which logging frameworks are enabled (see Table 5.1 in source material)

• Assess whether logging configuration aligns with organizational policy and regulatory requirements

• Verify that logs are protected from unauthorized modification or deletion

• Review log retention policies and procedures

Security Audit Log:

• Verify security audit log is enabled using Transaction SM19_DISP or SM19

• Confirm critical events are logged across all clients

• Review static configuration profiles

• Assess whether the following are logged:

  • Critical system events

  • High-risk events (incorrect password attempts)

  • Privileged user activities

• Verify that audit log files are stored in a protected location (parameter DIR_AUDIT) -2-6

• Review access controls to audit log data

• Using Transaction SM20N or RSAU_READ_LOG, review audit log data for unusual activities

• Test that logging cannot be disabled by unauthorized users -9

Table Logging:

• Verify table logging is enabled by checking parameter rec/client in Transaction RSPFPAR -6

• Confirm parameter is set to production client number or ALL

• Using Transaction SE13, verify that critical configuration tables have the "Log Changes" flag selected

• Review table T000 (client table) logging to track client lock changes

• Using Transaction SCU3, review table log entries for:

  • Changes to production client settings

  • Changes to critical configuration

  • Unusual or unauthorized modifications

• Document any periods when production client was unlocked -1

Change Documents:

• Verify change documents are enabled for critical fields

• Review configuration to ensure master data and accounting-relevant changes are captured

• Test change document functionality by making a test change to a vendor or customer master record

• Verify change is recorded with user ID, timestamp, old value, and new value

Other Logs:

• Review SAP Gateway logging configuration (parameter gw/logging)

• Assess whether workload analysis logs (Transaction ST03N) are retained appropriately

• Verify version management (Transaction SE80, SE38) is active (cannot be disabled)

Common Findings:

• Security audit log not enabled or misconfigured

• Table logging not activated despite SAP recommendations -1

• Logs not regularly reviewed

• Insufficient log retention

• Audit log files not protected from modification

2.2 System Development and Transport Controls

Audit Objective: Verify that system development controls, including naming conventions, system locks, and transport management, are properly configured to protect production integrity.

Risk: Without proper locks and transport controls, unauthorized or untested changes can be made directly in production, bypassing controls and potentially corrupting data or introducing vulnerabilities -5.

Audit Procedures:

Naming Conventions:

• Verify that all custom-developed objects follow SAP naming conventions

• Custom objects should begin with Y, Z, or /namespace/ -1

• Using Transaction SE80 or SE38, review a sample of objects to verify naming compliance

• Identify any objects that do not follow conventions and investigate

System Change Option:

• Using Transaction SE06, review system change option settings

• Verify Global Setting is set to "Not modifiable"

• Confirm software components and namespaces are set to not modifiable

• Review change log (click log icon in SE06) for any changes during audit period

• Document date, time, and user for any changes to system lock

Client Lock:

• Using Transaction SCC4, review production client settings

• Verify the following settings:

  • Changes and Transports for Client-Specific Objects: "No changes allowed"

  • Cross-Client Object Changes: "No changes to repository/cross-client customizing objects"

  • Client Copy and Comparison Tool Protection: "Protection level 2"

  • CATT and eCATT Restrictions: "eCATT and CATT Not Allowed" (or appropriate exception)

• If table logging is enabled, review table T000 changes in Transaction SCU3

• Document any periods when production client was unlocked

• For periods when unlocked, review activities performed

Transport Routes:

• Using Transaction STMS, review transport routes

• Verify transport paths follow Development → Test → Production

• Confirm no direct development-to-production routes exist

• Review transport route version history for changes during audit period

• For any route changes, verify proper authorization

Transport Review:

• Using Transaction STMS, access Import Overview

• Select a sample of transports to production (consider high-risk objects, period-end, etc.)

• For each transport request:

  • Review objects included

  • Verify existence of change request documentation

  • Examine testing evidence

  • Confirm proper approvals

  • Verify transport date and status

• Using Transaction /SDF/TRCHECK or similar, assess whether transport checks are performed -5

Common Findings:

• Production client not locked

• System change option modifiable

• Direct development-to-production transport routes

• Missing transport documentation

• Emergency changes not properly documented

2.3 Profile Parameters Review

Audit Objective: Verify that critical profile parameters are configured appropriately to support security and control objectives.

Risk: Misconfigured profile parameters can weaken security controls, disable logging, or create vulnerabilities that bypass application-level controls -6.

Audit Procedures:

• Using Transaction RSPFPAR, review current profile parameter settings -1

• For critical parameters, compare user-defined values to system defaults

• Review the following key parameters at minimum:

Parameter	Significance	Audit Focus
login/password_expiration_time	Password aging	Should be > 0 (typical 30-90 days)
login/min_password_lng	Minimum password length	Should align with policy (min 6-8)
login/disable_multi_gui_login	Concurrent logons	Verify setting aligns with policy
rec/client	Table logging activation	Should be production client or ALL
rdisp/gui_auto_logout	Inactivity timeout	Verify appropriate value
rsau/enable	Security audit log	Should be 1 to enable -6
rsau/local/file	Audit log location	Verify secure location -6
login/no_automatic_user_sapstar	SAP* automatic logon	Should be 1 (disabled)

• Document any parameters where user-defined values deviate from policy

• Review parameters starting with "auth/" for security-relevant settings

• Review parameters starting with "rfc/" for RFC security

• Using Transaction TU02, review parameter change history during audit period -1

• Document date, time, user, and value for any parameter changes

• For cloud environments, verify parameters are managed appropriately

Important Consideration:

• Parameter reports are instance-specific; verify settings across all application server instances -1

• Parameters are case-sensitive; invalid entries are ignored without warning

Common Findings:

• Password parameters below security standards

• Table logging not activated

• Security audit log not enabled

• Concurrent logons allowed without monitoring

• Parameter changes not tracked or approved

---

Section 3: SAP User Security Audit Procedures

This section addresses user administration, authorization concepts, and access controls within SAP S/4HANA.

3.1 User Master Records Review

Audit Objective: Verify that user master records are properly maintained, follow naming conventions, and reflect current user populations.

Risk: Inactive or improperly configured user IDs can be exploited for unauthorized access. Users with inappropriate user types may have excessive privileges -1.

Audit Procedures:

• Using Transaction SUIM, navigate to User → Users by Complex Selection Criteria

• Obtain a complete listing of all active user IDs

• Review user naming conventions for compliance with policy (e.g., contractor identifiers)

• Using Transaction SU01D, review a sample of user master records for:

  • Appropriate user type (Dialog, Service, System, Communication, Reference) -1

  • User group assignment

  • Validity dates (if applicable)

  • Security policy assignment

• For service accounts (user type Service), verify:

  • Business justification

  • Enhanced monitoring

  • Password controls

• For terminated employees, verify:

  • Ending validity date in past

  • Password reset

  • User group changed (if applicable)

  • All roles and profiles removed

• Review process for handling user access upon change in responsibilities

User Type Analysis:

User Type	Risk Level	Audit Focus
Dialog	Medium	Normal users; verify active/inactive status
Service	High	Anonymous access; verify justification and monitoring
System	Low	Background processing; cannot GUI logon
Communication	Medium	RFC communication; verify purpose
Reference	Low	Authorization inheritance; verify usage is appropriate

Common Findings:

• Terminated users still active

• Service accounts without business justification

• Users with incorrect user types

• No process for updating access upon role change

3.2 Authorization and Role Review

Audit Objective: Assess whether user authorizations are appropriate and follow the principle of least privilege.

Risk: Excessive authorizations can lead to fraud, errors, or data breaches. Without proper role design, SoD conflicts cannot be effectively managed -1-10.

Audit Procedures:

High-Risk Access Review:

• Using Transaction SUIM, identify users with SAP_ALL profile

• Document users with SAP_ALL access and verify business justification

• Using Transaction SUIM, identify users with SAP_NEW profile

• Review SAP_NEW assignments and assess whether appropriate

• Using Transaction SUIM, identify users with directly assigned profiles (not through roles)

• Filter on Profile Type to exclude generated profiles -1

• For users with directly assigned profiles, verify justification

Critical Role Review:

• Work with management to identify high-risk roles, such as:

  • Roles allowing production client unlock

  • Roles allowing posting period changes

  • Roles allowing inventory adjustments

  • Roles with sensitive transaction access (FB01, SE38, SU01, etc.) -4

• Using Transaction SUIM, identify users assigned to these roles

• Verify that only authorized personnel have access

• For users with access, assess whether duties are compatible

Critical Authorization Review:

• Using Transaction SUIM, identify users with access to sensitive authorizations

• Example: Ability to change client lock (Transaction SCC4):

  • Authorization object S_TCODE with value "SCC4"

  • Authorization object S_TABU_NAM with table T000 access

  • Authorization object S_TABU_DIS with authorization group SS -1

• For sensitive authorizations identified, review user listings and assess appropriateness

Wildcard Access Review:

• Using Transaction SUIM, identify users with wildcard (*) access to critical authorization fields

• Use double-quotes around * in queries (e.g., "*") -1

• For users with wildcard access, verify business justification

• Document any inappropriate wildcard access

SoD Analysis:

• Using organization's SoD matrix, identify high-risk conflict combinations

• For each combination, identify users with conflicting access

• For users with SoD conflicts, assess:

  • Compensating controls

  • Risk acceptance documentation

  • Monitoring procedures

• Review if SoD analysis includes cross-system risks

Common Findings:

• Excessive users with SAP_ALL or SAP_NEW

• Direct profile assignments bypassing role concept

• Users with sensitive role access without justification

• Wildcard access not properly controlled

• SoD conflicts without compensating controls

3.3 Authorization Trace and Testing

Audit Objective: Validate that authorization objects are properly configured and that users have only the access needed for their job functions.

Risk: Theoretical access may not reflect actual capabilities. Developers may fail to call required authorization objects in custom code -3.

Audit Procedures:

Authorization Trace:

• For sensitive transactions or activities, consider performing an authorization trace

• Using Transaction ST01, work with Basis team to:

  • Activate trace for a specific user

  • Have user perform the activity

  • Deactivate trace

• Analyze trace results to identify required authorization objects and field values -3

• Compare trace results to assigned authorizations

Custom Code Review:

• Identify critical custom programs and transactions

• Review ABAP code for proper AUTHORITY-CHECK calls

• Verify that relevant authorization objects are checked

• For custom code lacking authority checks, assess risk

Transaction SU24 Review:

• Review Transaction SU24 (Assignment of Authorization Objects to Transactions)

• Verify that SAP-delivered default values are appropriate

• Assess whether any modifications could impact security

Common Findings:

• Authorization traces not used to validate access

• Custom code without proper authority checks

• SU24 modifications without proper approval

3.4 SAP HANA Database Auditing

Audit Objective: Verify that SAP HANA database auditing is properly configured to capture database-level activities.

Risk: Direct database access bypasses application-level controls. Without database auditing, such activities cannot be detected or investigated -7.

Audit Procedures:

• Verify HANA auditing is activated by checking parameter 'global_auditing_state' is set to 'true' -7

• Confirm for both SYSTEM and TENANT databases

• Review audit policies configured:

  • Verify 'MandatoryAuditPolicy' is active

  • Review additional policies for capturing:

    • Privileged user activities

    • Database configuration changes

    • Data access for sensitive tables

• Assess audit trail target settings (CSTABLE recommended) -7

• Review audit log retention policies

• If using CSTABLE, verify parameter 'minimal_retention_period' is set appropriately

• Test that audit logs are protected from unauthorized modification

• Review a sample of audit log data for unusual activities

Common Findings:

• HANA auditing not activated (disabled by default)

• Insufficient audit policies configured

• Audit logs not regularly reviewed

• Inadequate retention periods

---

Section 4: Audit Reporting and Remediation

Audit Objective: Document findings, communicate with management, and track remediation efforts.

Audit Procedures:

Finding Documentation:

• For each identified issue, document:

  • Condition (what was found)

  • Criteria (standard or benchmark)

  • Cause (root cause)

  • Effect (risk or impact)

  • Recommendation

• Prioritize findings based on risk

Management Communication:

• Discuss findings with process owners during audit

• Validate facts and obtain management responses

• Present preliminary findings at exit conference

Final Report:

• Prepare audit report including:

  • Executive summary

  • Scope and methodology

  • Detailed findings and recommendations

  • Management action plans

• Obtain management responses for each finding

• Include target dates for remediation

Remediation Tracking:

• Establish process for tracking remediation

• Follow up on management action plans

• Perform validation testing on remediated issues

• Report on remediation status to appropriate committees

---

Summary of Key Transaction Codes

This table summarizes key transaction codes referenced throughout the audit program -1-4:

Transaction	Purpose
SE06	System change option settings
SE09/SE10	Transport organizer
SE13	Table technical settings (logging)
SE38	ABAP editor
SE80	Object navigator
SE93	Maintain transactions
SM19/SM19_DISP	Security audit log configuration
SM20/SM20N	Security audit log analysis
SM21	System log
SMGW	Gateway monitoring
ST01	Authorization trace
ST03N	Workload analysis
STMS	Transport management system
SU01/SU01D	User master maintenance/display
SU10	User mass maintenance
SUIM	User information system
SCU3	Table logging display
SCC4	Client administration
PFCG	Profile generator (role maintenance)
RZ10	Profile maintenance
RZ11	Profile parameter documentation
RSPFPAR	Profile parameter display
TU02	Parameter change history

---

Tips for Basis and Security Audits

Original implementation tip on security policies: SAP S/4HANA security policies allow different password rules for different user categories. A service account used for web access might have a 256-character password that never expires, while dialog users have 12-character passwords expiring every 90 days. If your organization has not implemented security policies, all users are governed by the same login parameters regardless of their type and risk profile. Check whether the Security Policy field is populated in user master records by querying USR02 and reviewing the SECPOL field (Security Policy). If blank for all users, the organization is not using this capability, and you should evaluate whether differentiated policies would improve the security posture.

Original implementation tip on table TSTC and transaction locking: Table TSTC (SAP Transaction Codes) contains a field called CINFO that controls whether a transaction is locked (disabled). Locking a transaction through transaction SM01_CUS or SM01 prevents all users from executing it. This is useful for disabling dangerous transactions like SE16N (which allows editing mode access to table data with the right debug settings) or SA38 (which allows direct program execution). Query TSTC for your critical transaction list and verify that transactions your organization has decided to disable are actually locked. I have found organizations where the security team believed certain transactions were disabled because they were removed from role menus, but the transactions were not locked in TSTC and could still be executed by typing the transaction code directly in the command field.

Original implementation tip on RFC security: Transaction SM59 shows configured RFC destinations. Table RFCDES (RFC Destination Description) contains RFCDEST (destination name), RFCTYPE (connection type where 3 is ABAP connection and G is HTTP), RFCOPTIONS (connection options), and RFCHOST (target hostname). RFC destinations from development or test systems pointing to production are high-risk findings because they can enable unauthorized data access or changes. RFC destinations using stored credentials (visible in the connection details) where the stored user has broad authorizations in the target system are equally dangerous. Verify that RFC users in production have restricted authorizations appropriate for their specific interface function, not broad access granted for convenience during the implementation.

Original implementation tip on the SAP* default user: The SAP* user is the most dangerous user ID in SAP S/4HANA. If the login/no_automatic_user_sapstar parameter is set to 0 (or not set and the kernel default is 0 in older versions), and someone deletes the SAP* user master record from a client, SAP S/4HANA automatically creates a temporary SAP* user with a known default password and SAP_ALL authorization. This means that deleting SAP* actually makes it more dangerous. The correct approach is to keep the SAP* user master record, change its password from the default, lock it, and set login/no_automatic_user_sapstar to 1. Run report RSUSR003 to verify that default passwords for SAP*, DDIC, and EARLYWATCH have been changed in every client.

References and Standards

ISACA COBIT 2019 Framework for IT governance and management, available at https://www.isaca.org/resources/cobit. ISACA IT Audit and Assurance Standards (ITAF) for audit methodology. IIA GAIT Framework for risk-based ITGC scoping (retired but valuable reference). ITIL v4 for IT service management best practices. SEI Capability Maturity Model for systems development processes. NIST Cybersecurity Framework (CSF) 2.0 for security controls. ISO 27001:2022 for information security management system certification. ISO 27002:2022 for security controls and implementation guidance. SAP Security Guide for SAP S/4HANA 2022 (970 pages, available at help.sap.com). SAP Note 608835 regarding table logging performance. SAP Note 1653464 recommending table logging in production. SAP Note 16466 for customer name ranges. SAP Note 2309060 regarding elimination of developer keys. PCAOB Auditing Standard No. 5 for integrated audits of internal control. COSO Internal Control Integrated Framework 2013. Sarbanes-Oxley Act Sections 302 and 404. IIA Global Internal Audit Standards 2024.

The Foundation Determines Everything Above It

Organizations that treat ITGCs and Basis security as a perfunctory checklist produce audits where business process control conclusions rest on unverified assumptions. The release strategy configuration may be perfect. The three-way match controls may be flawless. But if the production client was unlocked for modification, if table logging is disabled, if developers have debugging access, and if transport routes allow direct imports from development to production, none of those business process conclusions are reliable. The foundation was never tested.

Organizations that validate the foundation first produce audits where every conclusion at the business process layer is backed by verified evidence that the underlying system environment is controlled. Configuration settings can be trusted because the system was locked. Change history is available because logging was enabled. Unauthorized access can be detected because the security model was tested. The audit pyramid holds because every layer was built on solid ground.

The strength of your SAP S/4HANA controls is exactly equal to the strength of the weakest layer supporting them, and that layer is almost always the one nobody checked.

What is the current status of table logging in your SAP S/4HANA production system, and when was the last time someone verified that the production client lock has remained set throughout the entire audit period?

---

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.