Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Security audit log

10 min

Listen to this lesson

0:00 / 5:50

The security audit log is the ABAP system's own record of security-relevant events, built for auditors and security teams. SAP's documentation lists the kinds of events it can record, including successful and failed dialog logons, successful and failed RFC logons, RFC calls to function modules, changes to user master records, successful and failed transaction starts, and changes to the audit configuration itself. It records only what its filters select, so configuring it is a design decision.

How it is switched on and configured

The log is activated by the profile parameter rsau/enable, which defaults to off. Other parameters control where audit files are written and how large they may grow. You define filters that select events by client, user and event class or message. Older documentation describes configuration in SM19 and reading in SM20; current ABAP releases provide newer transactions for the same jobs (RSAU_CONFIG for configuration and RSAU_READ_LOG for reading), so check which your release offers and use the current ones. Audit data is kept until explicitly deleted or archived, so retention and storage are your responsibility.

Events are written by each application server to its own audit files, and only if a filter selects them; the reader brings them together for review.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-303
  1. Activatersau/enable set in the instance or default profile for CMQ and CMP.
  2. Define filtersWhich clients, users and event classes to record.
  3. RecordEvents are written per application server to audit files.
  4. Read and reviewThe audit log reader, filtered for the review question.
  5. Retain and protectArchive per policy; restrict who can delete or change audit data.
The security audit log from activation to retention.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-303

Choosing what to record

Recording everything for everyone produces a log no one can read and storage that fills quickly. Recording nothing useful is worse. A common pattern is two layers: a broad filter for critical events for all users (failed logons, user master changes, changes to the audit configuration), and a detailed filter for privileged users (firefighter IDs, standard users, technical users), recording everything they do.

FilterUsersEventsWhy
Critical eventsAll users, all clientsFailed logons, user master and role changes, audit configuration changesDetect attacks and unauthorized changes to access
Privileged usersSAP*, DDIC, firefighter IDs, Basis administratorsAll eventsEvery action of powerful users is reviewable
Technical usersRFC and system usersLogons, RFC callsDetect misuse of interface credentials, such as a dialog logon attempt
Client 000 and 066All usersAll logonsLogons there are rare and worth seeing

Contoso's starting filter design for CMP, tuned after the first month of review.

A review routine that works

A log nobody reads is not a control. Nadia and Sam agree a routine: a weekly review of failed logons, locks, standard user activity and changes to the audit configuration, and review of firefighter activity through the emergency access process. Each review is recorded (who, when, what was checked, what was followed up), because the record of the review is the evidence auditors ask for. For larger estates, SAP Enterprise Threat Detection is SAP's option to collect logs such as these centrally, correlate them with attack patterns and raise prioritized alerts.

For larger estates, SAP Enterprise Threat Detection collects audit logs centrally and turns patterns into alerts for the security team.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-303
  1. DailyAutomated alertsWhere available: repeated failed logons, SAP* logon attempts, audit configuration changes.
  2. WeeklySecurity reviewFailed logons, locks, standard and technical user activity; findings followed up.
  3. Per sessionFirefighter log reviewController reviews against the incident.
  4. QuarterlyFilter and retention checkFilters still match the privileged user list; storage and archive working.
Contoso's audit log review cadence. Frequencies are Contoso's policy, not SAP defaults.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-303

What would you do?

After two weeks in production, the audit log in CMP is growing so fast that Sam wants to switch it off until after hypercare. Most entries come from a filter recording all events for all users in client 100. What is the best course?

Key points
  • The security audit log records selected security events: logons, RFC logons and calls, user changes, transaction starts, configuration changes.
  • rsau/enable activates it; filters choose clients, users and events; data stays until deleted or archived.
  • Use current configuration and reader transactions for your release (RSAU_CONFIG, RSAU_READ_LOG where available).
  • Design two layers: critical events for all, everything for privileged users.
  • Review on a fixed routine, record each review, and protect the log's configuration.

Check your understanding · not graded

Lesson check

  1. 1. Which profile parameter activates the security audit log?

  2. 2. Why not record all events for all users?

  3. 3. What makes an audit log review count as evidence?

  4. 4. Why should changes to the audit log configuration be restricted and logged?