Practical Audit Controls for SAP HANA in IT General Controls Reviews

 

Most SAP audits slow down for a simple reason. The team asks good control questions, but they pulls evidence the hard way.

That is expensive. It is also risky. When GRC teams run IT General Controls reviews, Basis reviews, security assessments, and compliance testing without a clear SAP HANA evidence model, they miss population-level issues, they over-rely on screenshots, and they burn weeks reconciling exceptions that should have been identified in hours.

I have seen this firsthand. In one global SAP program, the audit team had strong control design knowledge but no HANA-native audit approach. They extracted data into spreadsheets, sampled manually, and escalated dozens of false positives. The rework took three extra weeks. The actual root cause was not weak audit judgment. It was weak technical evidence strategy.

This post fixes that problem.

You will get a practical framework for using SAP HANA for audits, reviews, and compliance work across IT General Controls, Basis and security settings, and process-level testing. I will stay grounded in SAP guidance and long-standing SAP technical practice. I will also describe relevant transaction codes, key SAP tables, and full technical field names so practitioners can move from theory to execution.

Primary keyword: SAP HANA for audits, reviews and compliance tasks

Secondary keywords: SAP HANA audit queries, SAP ITGC review, SAP Basis audit checklist, SAP security review SAP HANA, SAP compliance evidence, SAP S/4HANA audit controls, SAP HANA tables for audit, SAP transaction codes for audit, SAP GRC audit analytics

Understanding the audit framework for SAP HANA for audits, reviews and compliance tasks

Before you run a single query, you need a mental model.

For SAP audit work, I use a four-layer evidence model. Layer one is IT General Controls. Layer two is Basis and security settings. Layer three is process-specific technical settings. Layer four is the live business process itself. This mirrors how risk actually flows in SAP S/4HANA environments.

Why this matters is simple. HANA can show you what exists in the database and many system views can show you how the platform is behaving. But HANA alone does not prove whether a control is designed correctly, approved correctly, or operated by the right owner. You need to connect technical evidence, application evidence, and governance evidence.

Component 1: IT General Controls as the foundation

ITGCs are the controls that support every system, not just SAP. Think user provisioning, privileged access, change management, interface controls, batch controls, backup and recovery, and operations monitoring.

In SAP S/4HANA audits, weak ITGCs can invalidate confidence in application controls. If file transfers are not controlled, SAP can process bad data perfectly. That still gives you a bad result.

Original implementation tip: Do not start your SAP HANA audit by querying business tables. Start with the ITGC risk map. List every upstream dependency that can change data before SAP processes it, including bank files, middleware queues, directory drops, scheduler jobs, and direct database tools. This prevents a common failure where the audit proves SAP processed data accurately but never proves the data entered SAP completely and accurately.

Component 2: Basis and security settings as SAP-specific control infrastructure

Basis and security settings are the SAP-specific control infrastructure. These include client settings, transport controls, profile parameters, RFC destinations, background jobs, user types, password controls, SSO exceptions, emergency access, and logging configuration.

This is where many less technical audits go wrong. Teams use generic checklists and report issues they do not fully understand. I have done that early in my career. It creates noise, not assurance.

Original implementation tip: Tie every Basis finding to a business risk path. For example, “parameter allows direct changes in production” is not enough. You need the full risk chain. Production change capability can alter posting logic, which can affect automated controls, which can affect financial reporting integrity. If you cannot explain the chain, the finding is not ready.

Component 3: Process-specific technical settings

These are configuration settings inside specific modules such as FI, MM, SD, PP, and HCM. Release strategies, tolerance limits, posting controls, field status groups, duplicate checks, and output controls all sit here.

This layer is where SAP control design becomes business-relevant. The same setting can be low risk in one company and critical in another depending on process design and monitoring.

Original implementation tip: Never test process configuration in isolation. Pair each setting review with one sample of actual usage, one exception report, and one role review. That triangulation cuts false comfort fast.

Component 4: Business process behavior

This is where users either follow the intended process or bypass it.

A three-way match can be perfectly configured, but if users route invoices through non-PO processing, control effectiveness drops immediately. HANA is very useful here because it lets you test whole populations, spot path deviations, and compare expected versus actual transaction patterns.

Original implementation tip: For every key control, define one “behavioral anomaly query” in HANA. Examples include sudden growth in invoice-only postings, high after-hours master data changes, or repeated changes to payment terms before payment runs. These queries often find more real issues than static configuration checks.

Stage 1: Build the SAP HANA audit evidence architecture

A high-performance audit starts with a clean evidence architecture.

The goal is not to query everything. The goal is to define where each control question will be answered. Some answers live in SAP GUI transactions. Some live in SAP tables. Some live in HANA system views. Some live in GRC access control logs. Some still require policy documents and approvals outside SAP.

The best audit teams create a control-to-evidence matrix before fieldwork begins. In one large manufacturing client, this reduced evidence requests by about 40 percent because the team stopped asking the business for artifacts already available in SAP.

What to implement

Build a matrix with these columns:

1. Control objective
2. Risk statement
3. SAP transaction code for review
4. SAP table or HANA view
5. Full technical field names
6. Evidence owner
7. Test method
8. Frequency
9. Population logic
10. Exception threshold

For ITGC and Basis reviews, common SAP transaction codes include:

• SU01. User Maintenance. Used to display and maintain user master records.
• SUIM. User Information System. Used to report on users, roles, profiles, authorizations, and change data.
• PFCG. Role Maintenance. Used to create, change, and analyze roles and authorization data.
• SM19. Security Audit Log Configuration. Used to configure the Security Audit Log.
• SM20. Security Audit Log Analysis. Used to review logged security-relevant events.
• RZ10. Maintain Profile Parameters. Used to maintain instance and default profiles.
• RZ11. Display Profile Parameters. Used to display active profile parameter values.
• SCC4. Client Administration. Used to maintain client-specific settings, including change options.
• SE06. Set Up Change and Transport System. Used to review system change options and transport controls.
• STMS. Transport Management System. Used to manage SAP transports across the system landscape.
• SM37. Job Monitoring. Used to review background jobs and statuses.
• SM59. RFC Destinations. Used to maintain and test RFC connections.
• DBACOCKPIT. Database Administration Cockpit. Used for database monitoring and administration, including SAP HANA views depending on release and authorization.
• HANA Studio or SAP HANA Cockpit. Used to query SAP HANA catalog views, monitoring views, and security configuration.

Core SAP tables for audit work

Here are some common tables every SAP auditor should know.

• USR02. Logon data for users in client.

  • BNAME. User Name in User Master Record.
  • USTYP. User Type. Typical values include A for Dialog, B for System, C for Communication, S for Service, L for Reference.
  • CLASS. User Group.
  • GLTGV. Valid From Date.
  • GLTGB. Valid To Date.
  • TRDAT. Last Logon Date.
  • LTIME. Last Logon Time.
  • LOCNT. Number of Incorrect Logon Attempts.
  • UFLAG. User Lock Status.
  • CODVN. Code Version for Password Hash Procedure.

• AGR_USERS. Assignment of Users to Roles.

  • AGR_NAME. Role Name.
  • UNAME. User Name.
  • FROM_DAT. Valid From Date.
  • TO_DAT. Valid To Date.
  • EXCLUDE. Assignment Excluded Indicator.

• AGR_DEFINE. Role Definition.

  • AGR_NAME. Role Name.
  • PARENT_AGR. Parent Role.
  • AGR_TEXT. Role Description.
  • UNAME. Last Changed By User.
  • CHANGE_DAT. Date of Last Change.

• AGR_1251. Authorization Data for the Activity Group.

  • AGR_NAME. Role Name.
  • OBJECT. Authorization Object.
  • AUTH. Authorization Name.
  • FIELD. Authorization Field.
  • LOW. Lower Limit Value.
  • HIGH. Upper Limit Value.
  • MODIFIED. Manually Changed Authorization Indicator.

• E070. Change and Transport System, Header of Requests.

  • TRKORR. Transport Request Number.
  • AS4USER. User Who Created the Request.
  • AS4DATE. Date of Last Change.
  • TRFUNCTION. Request Type.
  • STRKORR. Parent Request.
  • KORRDEV. Development Class or Package Context depending on usage.

• E071. Change and Transport System, Object Entries of Requests.

  • TRKORR. Transport Request Number.
  • PGMID. Program ID.
  • OBJECT. Object Type.
  • OBJ_NAME. Object Name.
  • AS4POS. Position in Request.

• T000. Clients.

  • MANDT. Client.
  • MTEXT. Client Name.
  • CCCATEGORY. Client Role.
  • CCNOCLIIND. Cross-Client Object Changes Indicator.
  • CCORACTIV. Changes and Transports for Client-Specific Objects.
  • CCIMAILDIS. Distribution of CUA Data Indicator depending on release.

Original implementation tip: Build one audit data dictionary for your team and lock the naming standard. The same field gets described differently across teams, and that causes rework during QA. If one workpaper says UFLAG means “inactive” and another says “lock status,” the reviewer loses trust. Standardize field definitions before testing starts.

Stage 2: Use SAP HANA system views for technical control testing

This is where SAP HANA changes the speed of the audit.

For technical reviews, HANA gives you direct access to monitoring views, security metadata, audit trail options, and database object metadata. In SAP HANA 2.0, key catalog and monitoring views such as USERS, GRANTED_ROLES, GRANTED_PRIVILEGES, M_AUDIT_ACTIONS, M_AUDIT_POLICIES, M_CONNECTIONS, M_DATABASE, M_INIFILE_CONTENTS, and M_BACKUP_CATALOG can support audit evidence if access is appropriately governed.

Be careful though. Accessing HANA directly does not mean bypassing SAP governance. Read-only audited access is the right pattern.

What to implement

For HANA database security and operations reviews, build tests around these areas:

User and privilege review

Relevant HANA views include:

• USERS. Database users.

  • USER_NAME. Database User Name.
  • USER_ID. Internal User Identifier.
  • USER_DEACTIVATED. User Deactivation Status.
  • LAST_SUCCESSFUL_CONNECT. Timestamp of Last Successful Connection.
  • PASSWORD_CHANGE_TIME. Timestamp of Last Password Change.
  • USER_MODE. Authentication or operational mode depending on release.

• GRANTED_ROLES. Roles granted to users or roles.

  • GRANTEE. User or Role Receiving the Grant.
  • ROLE_NAME. Granted Role Name.
  • GRANTOR. User Who Granted the Role.
  • ADMIN_OPTION. Whether Further Granting is Allowed.

• GRANTED_PRIVILEGES. System, object, analytic, package, or application privileges granted.

  • GRANTEE. User or Role Receiving the Privilege.
  • PRIVILEGE. Privilege Name.
  • OBJECT_TYPE. Type of Secured Object.
  • OBJECT_NAME. Name of Secured Object.
  • GRANTABLE. Grant Option Indicator.

Use SAP HANA Cockpit or SQL console with read-only rights to identify inactive users with active privileges, technical users with broad rights, and direct grants that bypass role-based design.

Audit logging review

Relevant HANA views include:

• M_AUDIT_POLICIES. Configured audit policies.

  • POLICY_NAME. Audit Policy Name.
  • ENABLED_STATUS. Whether the Policy is Enabled.
  • AUDIT_ACTION. Audited Action Type.
  • CONDITION. Policy Condition Expression.
  • RETENTION_DAYS. Retention Period in Days, depending on release.

• M_AUDIT_ACTIONS. Available auditable actions.

  • ACTION_NAME. Audit Action Name.
  • CLASS_NAME. Audit Class Name.
  • DESCRIPTION. Description of the Action.

Confirm whether audit policies cover privileged changes, user administration, failed logons, and critical configuration changes.

Backup and recovery review

Relevant HANA views include:

• M_BACKUP_CATALOG. Backup catalog entries.

  • ENTRY_ID. Backup Entry Identifier.
  • SYS_START_TIME. Backup Start Time.
  • SYS_END_TIME. Backup End Time.
  • STATE_NAME. Backup State.
  • ENTRY_TYPE_NAME. Backup Type.
  • BACKUP_SIZE. Backup Size in Bytes.

• M_DATABASE. Database status.

  • DATABASE_NAME. Database Name.
  • ACTIVE_STATUS. Current Active Status.
  • RESTART_MODE. Restart Mode.
  • VERSION. HANA Version String.

Validate successful backup patterns, failed backup frequency, and whether retention aligns to policy.

Configuration review

Relevant HANA views include:

• M_INIFILE_CONTENTS. Effective ini parameter values.
  • FILE_NAME. Configuration File Name.
  • SECTION. Configuration Section.
  • KEY. Parameter Name.
  • VALUE. Effective Parameter Value.
  • LAYER_NAME. Configuration Layer.
  • HOST. Host Name.

This helps validate settings that affect auditing, password policy, persistence, and trace behavior.

Original implementation tip: Separate “database security exceptions” from “application security exceptions.” I have seen audits report HANA direct privileges as if they automatically create SAP transaction risk. Sometimes they do. Sometimes they do not. Map the HANA privilege to the actual attack path or administrative path. That distinction matters.

Stage 3: Test IT General Controls with SAP transactions and tables

ITGC testing in SAP S/4HANA should blend process walkthroughs, transaction-level review, and population analytics.

The common domains remain stable across industries. User access management. Privileged access. Change management. Computer operations. Interface and batch controls. Backup and recovery. Incident handling. Logging and monitoring.

User access management

Start in SU01 and SUIM. These are still core transactions for application-level access evidence.

Use SUIM to report on:

• Users by logon date
• Users by user type
• Users with critical authorizations
• Roles by complex selection criteria
• Change documents for users and roles

Key tables:

• USR02. Logon data for users in client.
• USR21. Assignment of User Name to Person Name.
  • BNAME. User Name.
  • PERSNUMBER. Person Number.
• ADRP. Persons, Central Address Management.
  • PERSNUMBER. Person Number.
  • NAME_FIRST. First Name.
  • NAME_LAST. Last Name.

This allows tests for dormant users, generic users, shared IDs, and orphaned access.

Original implementation tip: Always reconcile user populations across HR source, identity source, and SAP user master. A dormant SAP user is not just “no recent logon.” It can also be a terminated employee with an active account, a contractor with expired contract dates, or a communication user no one owns anymore.

Privileged access and emergency access

Review powerful access through PFCG, SUIM, and if deployed, SAP GRC Access Control.

Look for authorizations related to:

• S_USER_GRP. User Master Maintenance by User Groups.
• S_USER_AGR. Assignment of Activity Groups.
• S_USER_PRO. Profile Maintenance.
• S_TABU_DIS. Table Maintenance by Authorization Group.
• S_TABU_NAM. Table Access by Table Name.
• S_TRANSPRT. Transport Authorization.
• S_DEVELOP. ABAP Workbench Access.
• S_RFC. Authorization Check for RFC Access.
• S_DATASET. File Access on Application Server.

In AGR_1251, inspect:

• OBJECT. Authorization Object.
• FIELD. Authorization Field.
• LOW. Low Value.
• HIGH. High Value.

For emergency access, inspect firefighter or elevated access logs if SAP GRC is used. Evidence typically sits in GRC repository tables and workflow logs, not just ECC or S/4HANA tables.

Original implementation tip: Do not rely on role names like SAP_ALL, FI_ADMIN, or BASIS_SUPER as your only criteria. Role names lie. Authorization values do not. Test the object-field-value combination, especially for table access, development, transport, and user administration.

Change management

Use SE06, SCC4, STMS, and transport tables E070 and E071.

You want to answer:

• Is production protected from direct changes
• Are transports moved through the correct path
• Are developers restricted from production
• Are emergency changes approved and reviewed

In SCC4, review client settings in T000:

• CCNOCLIIND. Cross-Client Object Changes Indicator.
• CCORACTIV. Changes and Transports for Client-Specific Objects.

In SE06, review system change options. In STMS, review transport path and import history. In E070 and E071, sample changes by request type, creator, importer, and object class.

Original implementation tip: Build one query that flags transport requests created and imported within unusually short windows. Many real problems hide here. The speed itself is not proof of failure, but it is a strong signal for emergency change review.

Stage 4: Review Basis and security settings that directly affect audit reliance

This stage is where the technical quality of the audit becomes visible.

A Basis and security review should not be a random checklist. It should focus on settings that can change the reliability of business processing, the integrity of reports, or the recoverability of the platform.

Critical transactions and what they tell you

• RZ11. Display active profile parameters. Use this to review active values for login controls, session controls, RFC controls, and other security-relevant parameters.
• RZ10. Maintain profile parameters. Use this to identify controlled versus ad hoc parameter management.
• SM19 and SM20. Security Audit Log setup and review. Use this to validate what security events are captured and whether logs are actually monitored.
• SM59. RFC destination review. Use this to identify trusted RFCs, stored credentials, external connections, and obsolete destinations.
• SM37. Background jobs. Use this to review failed jobs, critical interfaces, and scheduling integrity.
• SCC4. Client settings. Use this to confirm whether production client changes are restricted.
• DBACOCKPIT. Database admin views. Use this to review DB health, growth, alerts, and in some landscapes HANA-related operational details.

Parameters and settings to review

A few examples matter often in audits:

• login/min_password_lng. Minimum Password Length.
• login/fails_to_user_lock. Number of Failed Logon Attempts Before User Lock.
• login/no_automatic_user_sapstar. Prevents Automatic Activation of SAP* in Certain Conditions.
• rec/client. Client-Specific Table Logging Activation.
• rsau/enable. Security Audit Log Enablement, depending on release and setup.

Validate the active value in RZ11 and the maintained value in RZ10 where relevant. Differences between intended and active values can happen during incomplete change cycles.

Original implementation tip: Do not report a parameter issue before checking business context, release guidance, and compensating controls. I once saw a review raise a password parameter finding that was functionally mitigated by enterprise SSO, MFA at the identity tier, and restricted direct SAP logon paths. The parameter still mattered, but the risk statement was overstated. Precision improves credibility.

Stage 5: Use HANA to test compliance outcomes, not just settings

This is where good audits become valuable audits.

Many teams stop at configuration testing. That proves a setting exists. It does not prove the control outcome is happening. HANA makes outcome testing practical because you can scan full populations, compare trends over time, and isolate behavioral anomalies.

What to implement

Build a small compliance analytics library around your top risks.

Examples:

• Dormant privileged users with valid accounts and no review evidence
• Posting activity by generic or technical users in inappropriate transaction paths
• Changes to vendor bank data close to payment execution dates
• Manual journal entries posted outside standard hours
• High rates of invoice postings without purchase order references
• Repeated failed interfaces followed by manual correction postings

For FI-related examples, useful tables can include:

• BKPF. Accounting Document Header.

  • BUKRS. Company Code.
  • BELNR. Accounting Document Number.
  • GJAHR. Fiscal Year.
  • BLART. Document Type.
  • USNAM. User Name.
  • TCODE. Transaction Code.
  • CPUDT. Entry Date.
  • CPUTM. Entry Time.

• BSEG. Accounting Document Segment.

  • BUKRS. Company Code.
  • BELNR. Accounting Document Number.
  • GJAHR. Fiscal Year.
  • KOART. Account Type.
  • HKONT. General Ledger Account.
  • LIFNR. Vendor Account Number.
  • KUNNR. Customer Number.
  • WRBTR. Amount in Document Currency.

For vendor master changes in classic and S/4 contexts, exact tables vary by design and business partner model. In S/4HANA, vendor data is tied to Business Partner structures, so validate your landscape before designing queries.

Original implementation tip: Pair every configuration test with one outcome test. If you test duplicate invoice controls, also test the invoice population for duplicate patterns. If you test bank change approval, also test bank changes occurring within a short period before payment. This closes the assurance gap that causes audit findings to look theoretical.

Cross-cutting implementation tips for SAP HANA for audits, reviews and compliance tasks

These apply across every stage.

1. Keep read access truly read-only

Audit access to HANA and SAP should be traceable, approved, and non-invasive. Use dedicated audit roles with display access only. Log direct database access where possible.

Original implementation tip: Create a named audit role catalog for recurring reviews. When every audit creates a one-off access model, approvals become slow and risk teams lose visibility. Standardized read-only audit roles improve both speed and control.

2. Document field logic before documenting exceptions

Teams often write exceptions before they lock their extraction logic. That creates avoidable disputes.

Original implementation tip: For every query, document source object, join logic, key filters, client logic, date logic, and excluded populations first. Then freeze it. Only after that should the team assess exceptions. This cuts re-performance issues dramatically.

3. Distinguish configuration evidence from operating evidence

A parameter value is design evidence. A monitored log is operating evidence. A signed review with follow-up is governance evidence.

Original implementation tip: Force every workpaper to label each evidence item as design, operating, or governance. You will quickly spot where your “strong control” has no operating proof behind it.

4. Treat false positives as a design flaw in the audit, not a nuisance

If half your exceptions disappear after business explanation, your logic is weak.

Original implementation tip: Track exception attrition by test. If a test produces more than 25 percent invalid exceptions after the first two cycles, redesign the logic. Better audit analytics is part of control quality.

The best SAP audits do not ask for more evidence. They ask sharper questions of the evidence already in the system.

Key references for SAP HANA and SAP S/4HANA audit work

Use authoritative sources and align your review method to them.

SAP sources

• SAP Help Portal for SAP HANA Platform and SAP HANA Security Guide
• SAP Help Portal for SAP S/4HANA and SAP S/4HANA Security
• SAP Notes relevant to SAP HANA security, audit logging, and Basis parameters
• SAP HANA Administration Guide
• SAP HANA SQL and System Views Reference
• SAP S/4HANA System Administration documentation
• SAP GRC Access Control documentation
• SAP Basis administration guidance and Security Audit Log documentation

Audit and control frameworks

• COBIT for governance and management objectives
• ISACA IT Audit Framework guidance
• NIST Cybersecurity Framework and selected SP 800 series guidance
• ISO/IEC 27001 and ISO/IEC 27002
• COSO Internal Control Framework
• PCAOB guidance and SOX-related interpretive practice where relevant
• Local financial reporting and data protection requirements by jurisdiction

Practical audit references

• Long-form SAP security and Basis technical books from recognized SAP publishers
• SAP Press technical references on SAP security, SAP HANA administration, and SAP GRC
• Internal architecture standards, transport standards, and privileged access standards maintained by the client

If you treat SAP HANA audit work as a screenshot collection exercise, you will produce a compliance artifact that looks busy and says very little. The team will spend time chasing samples, the business will push back on weak findings, and management will still not know which risks are real.

If you treat SAP HANA as a controlled evidence engine, the audit changes shape. You move from sample-heavy testing to population-level insight. You connect ITGCs to Basis, Basis to process settings, and process settings to actual user behavior. That is where assurance becomes useful.

The core idea is simple. High-performance SAP audit work happens when technical evidence, control logic, and business risk are tied together in one disciplined method.

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 governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic risk theory and the operational controls organizations actually need in production.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, SAP control design, and 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 regulation is active and organizations face complex compliance demands.

His code repositories, risk model templates, and Python-based tools for governance are publicly available at https://hwyler.github.io/hwyler/. His ongoing writing on governance and 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 risk assessment frameworks, compliance automation, model validation practices, SAP controls, and the evolving regulatory landscape.

If you’re building an 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.