SM20 — Security Audit Log Analysis

SM20 reads and displays entries from the Security Audit Log, a kernel-level log of security-relevant events: successful and failed logons, transaction and report starts, RFC and CPIC calls, changes to user master records, and other flagged actions. SM20 itself writes nothing and configures nothing. The single fact that explains most confusion is that the log only contains what the active filters, defined and activated separately in SM19 (or RSAU_CONFIG on later releases), told the kernel to record for a given client, user, and event class, on a given application server, during a given time window. If the filter did not cover the event, the event is not in the log, and SM20 will show an empty list even though the underlying action genuinely occurred.

SM20 is reached for during security incident investigation, audit trail review for compliance (SOX, internal audit, external audit requests), and tracing suspicious logon or privilege activity such as repeated failed logons, use of a dormant service user, or a dialog logon into a background-only user. It is distinct from change document review: SM20 shows who logged on and which transaction or report was started, not what data was changed inside that transaction. For data change history, change documents or table logging is the correct tool. For read access to sensitive fields specifically, a dedicated read access logging configuration is used instead. Consultants reach for SM20 when the question is 'who accessed the system and how', not 'what did they change once inside'.

There is usually no direct SE16 path for the raw log because it lives in OS-level files rather than a standard transparent table; the supported way to prove content is running SM20 or the equivalent read report with the exact date, server, and client used during the incident, and cross-checking the filter scope in SM19/RSAU_CONFIG for that same window to confirm the event class in question was actually being captured at the time. If database persistence has been configured for the audit log on the system in question, the underlying table can be queried directly for timestamp, user, and event code, but the table name is release and configuration dependent and should be confirmed with Basis rather than assumed.

On S/4HANA, SM19 and SM20 are formally superseded by RSAU_CONFIG for configuration and a corresponding read report for analysis, though SM19 and SM20 remain usable as compatibility transactions on many releases, pointing at the same underlying log. There is no widely adopted dedicated Fiori app replacing this analysis; it stays a SAP GUI activity in most landscapes. The core structural point is unchanged: the log only contains what filters permitted, regardless of which transaction is used to read it.

Basis and security administration own SM19/RSAU_CONFIG filter setup, log retention, and storage sizing. Functional or GRC consultants typically only read SM20 output during an investigation. A clean handover states the exact date/time window, the client and server in question, and the filter scope that was active at the time, so Basis can confirm whether the data could ever have existed.

SM19 is the direct counterpart, controlling what the log will ever contain, and should be checked before any SM20 investigation begins. SU01 is used to resolve the user IDs found in the log against actual master data and lock status. SUIM provides broader authorization and role reporting that often needs to be cross-referenced when a logged event points to a privilege question. SU56 gives the buffered authorization trace for a user, which is a useful companion when SM20 shows repeated authorization failures and the specific missing object needs to be identified.