The five SAP Notes below cover the lifecycle of SAL end to end · from initial configuration through archiving, privacy-compliant review, and gap analysis. A security consultant who has not read all five is working from an incomplete picture.
2191612 · FAQ - Use of Security Audit Log as of NetWeaver 7.50
This is the anchor note for any system on SAP_BASIS 7.50 or higher. It documents the transaction shift away from the legacy SM19/SM20 pair toward RSAU_CONFIG, RSAU_CONFIG_SHOW, RSAU_READ_LOG, and RSAU_ADMIN, and it explains the usage scenarios behind that redesign: local file-based auditing, database-based auditing for SIEM integration, and the hybrid model that writes to both destinations.
Two details matter most for a security review. First, the filter ceiling changed release over release · 10 slots on older kernels, 15 as of SAP_BASIS 7.40 SP08, and 90 as of SAP_BASIS 7.50 SP02. A landscape still configured for 10 or 15 filters after an upgrade is very likely under-logging, not because anyone decided to under-log, but because nobody revisited the ceiling once headroom became available. Second, the note describes the integrity protection format, which allows an HMAC-based tamper check on file-based logs. Once switched on, audit files can no longer be opened by third-party tools at the file-system level, which has downstream implications for any SIEM or log-forwarding integration that was built assuming raw file access.
For engagements running versions below 7.50, the equivalent reference is the older FAQ note 539404. Both should be checked against the actual SAP_BASIS release before any recommendation is written into a report.
3094328 · RSAU_ARCHIVE_RELOAD - Reloading Archives of Security Audit Log
Archiving strategy for SAL is a genuine design decision, not an afterthought. Database-resident logs give SIEM tools fast query performance but grow the RSAU_LOG table quickly, particularly on HANA where table growth carries a direct cost implication. The standard pattern is to keep recent activity in the database for real-time correlation and move history to archive files for cheaper, longer-term retention.
This note governs the reverse operation: pulling archived data back into the live table when an investigation needs to query historical events using RSAU_READ_LOG rather than the more limited RSAU_ARCHIVE_READ interface. SAP is explicit that this program should be handled with care, since reloading can produce inconsistencies if run against a table that has changed structure or partitioning since the archive was written. For a consultant supporting forensic or e-discovery requests, this is the note to check before promising a client that “we can pull anything from three years ago in a few minutes.” The honest answer usually involves a reload step, a time window, and a caveat.
2883981 · RSAU_READ* - Anonymized Display of Security Audit Log Data
This note sits at the intersection of security and data protection, which is exactly where it belongs. It introduces the pseudonymized view of SAL data, made available through RSAU_READ_LOG_ADM (and SM20_ADM on the older transaction naming), where user IDs and terminal identifiers are replaced with generated hash values rather than shown in clear text.
The relevance for GDPR- and DPDPA-aligned engagements is direct. The Security Audit Log records who did what and from where, which makes it personal data under most privacy frameworks the moment a natural person can be identified from it. A blanket “everyone with SAL access sees full user and terminal detail” design is difficult to defend in a privacy impact assessment. This note gives security teams a supportable middle ground: broad analytical access to event patterns through the pseudonymized transaction, with re-identification reserved for a narrower group under a documented process. Any SoD matrix or access model built for SAL review roles should reference this distinction explicitly, not leave it implicit.
3026042 · Missing Overview of Settings for Security Audit Log
Configuration drift is the single most common finding in SAL reviews, and this note addresses the tooling gap that allows drift to go unnoticed. RSAU_CONFIG_SHOW is meant to give administrators and auditors a consolidated view of what is actually active across application servers, as distinct from what the static profile says should be active. When that overview is incomplete or fails to reflect dynamic changes made outside the static profile, filters can appear active in documentation while being silently inactive at runtime, or vice versa.
For a consultant running a control walkthrough, this is a reminder that the audit trail supporting a SAL control test needs to include evidence from the overview transaction itself, not just a screenshot of the filter configuration screen. A profile that looks correct on paper is not evidence that the correct events were captured during the period under review.
2676384 · Best Practice Configuration of the Security Audit Log
This is SAP's own baseline for what a reasonably configured SAL should look like, and it is referenced directly inside the S/4HANA Security Guide as the primary source for audit logging configuration. It complements the FAQ notes by moving from “how the feature works” to “what SAP recommends you turn on,” covering recommended filter design for critical user activity, superuser monitoring using the SAP#* selection pattern to exclude the SAPSYS background user, and the baseline event classes that should be active by default on new installations.
Two practical points are worth calling out for client work. First, “secure by default” behavior in newer releases activates a baseline SAL configuration automatically on installation, but only where no customer-defined configuration already exists · a system migrated or copied from an older landscape will typically not benefit from this default and needs the baseline applied deliberately. Second, the note's filter guidance is the natural reference point for building a client-specific SAL design document, since it gives a defensible, SAP-sourced starting position rather than a consultant's personal preference.
Closing Perspective
None of these five notes stands alone. 2191612 sets the architectural context, 2676384 supplies the configuration baseline, 3026042 protects the integrity of the evidence that configuration produces, 2883981 governs who can see what once that evidence exists, and 3094328 determines whether historical evidence can still be retrieved when it is needed most. A SAL control that has been designed against only one or two of these notes will hold up during a routine review and fail during an actual investigation, which is precisely the scenario in which it matters most. Reviewing all five together, against the specific SAP_BASIS release in scope, should be a standard step in any SAP security or GRC engagement that touches logging, monitoring, or forensic readiness.