SM19 — Security Audit Log Configuration

SM19 is the maintenance transaction for the Security Audit Log (SAL), the standard SAP mechanism for recording security-relevant events - failed logons, user master changes, RFC and CPIC calls, transaction starts, report starts, and changes to critical authorization objects - per client and per user. The structural fact that explains most confusion: SM19 has two independent activation states, dynamic and static. A filter activated dynamically takes effect immediately in the running kernel but is lost at the next application server restart unless it is also saved into the static instance profile configuration. Consultants who turn on logging dynamically during an incident, watch it work, then find it silently gone after a routine restart or a kernel parameter transport are running into exactly this split, not a bug.

SM19 is reached for whenever what gets logged needs to be established or adjusted before an investigation, or when troubleshooting why an expected security event never appeared in SM20. It gets used ahead of a planned penetration test, before turning on monitoring for a newly built productive system, after an incident to check retroactively whether the relevant event class was even switched on, and periodically by security or GRC teams doing audit log housekeeping across a landscape. It is not used to view the log itself, that is SM20's job. It is not used for authorization design, that belongs to SU24 and PFCG, and it cannot answer who did what after the fact if the filter was never active in the first place - in that case SM19 only answers whether the event was configured to be caught, and frequently the answer is no.

Use RZ11 to display the live value of rsau/enable and rsau/selection_slots on the specific application server instance in question, and compare that against SM19's own status display for the filter believed to be active - a mismatch means the profile change never propagated to that instance or the instance restarted without re-saving. Then go to SM20, filter on the exact client, user and timestamp window of the incident, and check whether any entries exist at all. Entries missing despite SM19 showing 'active' points to the wrong event class being selected, a user wildcard that does not actually match the account involved, or the event happening through RFC rather than dialog logon when only dialog was filtered.

On S/4HANA the underlying audit log mechanism is unchanged in concept: filters still control which event classes get captured, and the dynamic-versus-static split still applies. Storage can be database-backed rather than purely file-based, which changes retention behavior and how quickly entries become visible in SM20. SAP has offered a newer, more structured configuration interface for the audit log alongside SM19 in later releases, but SM19 generally remains available and functional as the classic entry point. There is no Fiori app replacement, since this is a Basis and security-level configuration task rather than an end-user process.

This belongs to Basis and Security/GRC, not to functional consultants. Functional teams typically only need to confirm that a filter covers a specific event for compliance sign-off. A good handover states the filter number in use, whether it is activated dynamically, statically, or both, which instances are covered, the storage target, and the retention window, so the receiving team does not have to reverse-engineer the configuration from scratch.

SM20 is the natural next stop, it is the viewer for whatever SM19 has been configured to capture and the two should always be checked together. SU01 and SU10 matter because filters are frequently scoped by user, and confirming the actual user ID and its naming pattern avoids the wildcard mismatch pitfall. SUIM is useful for broader audit and compliance reporting that goes beyond what the security audit log alone captures. ST01 is worth knowing as an alternative, heavier-weight trace mechanism for cases where the audit log's event classes are too coarse to isolate a specific authorization check.