SAP Security Audit Log: Configuration, Analysis & Best Practices

The SAP Security Audit Log (SAL) is one of the most important tools for monitoring security-relevant activities in SAP systems. Yet in many organisations it is either not activated at all or configured in a way that provides little value when an incident occurs. This article shows how to set up the SAL systematically, analyse its data and integrate it into your security strategy.

What Is the Security Audit Log?

The Security Audit Log records security-relevant events in the SAP system – from successful and failed logon attempts through transaction calls to changes to user master records. Unlike the system log (SM21), the SAL focuses specifically on security-relevant activities and provides the data basis for forensic analysis and compliance evidence.

Since SAP NetWeaver 7.50, SAP recommends the new configuration transaction RSAU_CONFIG as the successor to the classic SM19. RSAU_CONFIG offers more granular filter options and improved management of audit policies.

Configuration with SM19 and RSAU_CONFIG

Basic configuration involves two steps: First, activate the Security Audit Log via the profile parameter rsau/enable = 1. Then define filters that determine which events are recorded for which users.

In RSAU_CONFIG you can create static and dynamic filters. Static filters take effect after a system restart, while dynamic filters can be activated at runtime – ideal for time-limited intensive monitoring when suspicious activity is suspected.

Key profile parameters: rsau/max_diskspace/local determines the maximum file size, rsau/selection_slots the number of available filter slots. Plan for at least 500 MB of storage space for production systems.

Which Events Should Be Logged?

A sensible minimum configuration covers the following event categories:

• Dialog logons: Successful and failed logins, particularly with privileged users (SAP*, DDIC, emergency users)
• RFC/API access: Logons via RFC interfaces, which are frequently used as attack vectors
• Transaction starts: Calls to critical transactions such as SE16, SM59, SU01, STMS, SE38
• User master record changes: Creation, modification, locking and unlocking of users
• Authorisation checks: Failed authorisation checks as indicators of access attempts

For SAP_ALL users and emergency users, we recommend complete logging of all activities. For standard users, logging of logons and critical transactions is generally sufficient.

Filter Strategies and Performance Impact

A common mistake is excessive logging: recording everything for all users not only generates huge volumes of data but also impacts system performance. Use a risk-based approach: define user groups by risk profile and adjust logging depth accordingly.

In practice, a three-tier model has proved effective: Tier 1 for all users (logons only), Tier 2 for privileged users (logons plus critical transactions), Tier 3 for emergency users (complete logging). This model keeps the performance impact below 2% while still delivering meaningful data.

Analysis with SM20 and RSAU_READ_LOG

Transaction SM20 provides interactive analysis of the audit log. For systematic analysis, however, RSAU_READ_LOG is recommended as it offers extended filter functions and an ALV grid export, allowing you to process the data in Excel or other tools.

Regular analysis routines should cover the following scenarios: multiple failed logon attempts (brute-force indicator), logons outside business hours, use of critical transactions by unauthorised users and unusual RFC activity.

SIEM Integration

For real-time analysis and correlation with other security events, integration with a SIEM system (Security Information and Event Management) is recommended. SAP offers SAP Enterprise Threat Detection (ETD) as a native solution. Alternatively, SAL data can be transferred to external SIEM systems such as Splunk, QRadar or Microsoft Sentinel via the XAL/XAL2 interface, the SAP Audit Log Connector or direct database queries.

Important: define use cases and correlation rules upfront. A SIEM without meaningful rules produces noise rather than actionable alerts.

Compliance Requirements

The Security Audit Log is a central requirement in virtually all relevant compliance frameworks: SOX requires monitoring of privileged access, ISO 27001 demands logging of security-relevant events (Control A.12.4), and GDPR requires traceability of access to personal data. Document your configuration and analysis processes – auditors assess not only whether the SAL is active but also how systematically it is analysed.

Conclusion

A properly configured Security Audit Log is not a nice-to-have but a fundamental security measure. The effort required for setup is manageable, while the value in an incident is enormous. Start with a risk-based configuration, establish regular analysis routines and integrate the SAL into your overarching security monitoring strategy.

Get in touch →

Related Articles

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles