SAP Security Audit Log: SM19/SM20, Event Selection and Retention
Configure and review the ABAP Security Audit Log as a targeted evidence source for security-relevant logon, user, authorization and system events, with governed retention and monitoring.
Explanation
📌 KEY POINTS
✅ SM19/SM20 are the classic transactions; RSAU_CONFIG/RSAU_READ_LOG are the current NetWeaver (including S/4HANA) equivalents — expect either or both depending on release.
⚠️ The people whose privileged actions are monitored should never have unrestricted ability to disable logging.
💡 Logs show an event occurred — correlate with change documents, transport records, and EAM evidence for the full picture.
━━━━━━━━━━━━━━━━━━━━
▶ 1. THE TOOLS, ACROSS RELEASES
- SM19 (configuration) + SM20 (analysis) — classic
- RSAU_CONFIG (configuration) + RSAU_READ_LOG (analysis) — current, alongside or replacing the classic pair depending on release
━━━━━━━━━━━━━━━━━━━━
▶ 2. SCOPING THE LOG
- Reflect security policy: successful/failed logons, user administration, security changes, RFC or other critical events as supported
- Recording everything without capacity planning creates excessive volume; recording too little misses incidents
━━━━━━━━━━━━━━━━━━━━
⚠️ 3. PROTECT THE EVIDENCE
- Restrict access to audit configuration and log access
- Monitored privileged users should not be able to disable logging or erase evidence
━━━━━━━━━━━━━━━━━━━━
▶ 4. RETENTION AND CORRELATION
- Align retention with investigation/compliance requirements
- SIEM forwarding supports correlation and longer retention, but source configuration still needs health checks
- Correlate with change documents, transport records, Firefighter/EAM evidence and business context — the log alone doesn't prove intent
✅ CHECKPOINT: name the current NetWeaver-release equivalents of SM19 and SM20.
Real project scenario
An incident investigation needed failed privileged logons from six weeks earlier, but local audit retention was only seven days and no SIEM forwarding existed. The security baseline was updated with risk-based retention and log-health monitoring.
Common mistakes
- Enabling every event without sizing.
- Giving monitored admins unrestricted audit configuration.
- Having retention shorter than investigation needs.
- Assuming no log means no action without checking log health.
- Treating audit event as proof of intent.
Best practices
- Protect audit configuration.
- Monitor log health/storage.
- Retain based on policy.
- Forward critical events centrally.
- Correlate with other evidence.
Interview angle
Explain SM19/SM20 purpose, selective event logging, retention and separation of duties.
Practice this lesson
Quick check
1. Scenario — An incident investigation needed failed privileged logons from six weeks earlier, but local audit retention was only seven days and no SIEM forwarding existed. For the lesson "SAP Security Audit Log: SM19/SM20, Event Selection and Retention", which response shows the strongest architecture and production judgment?
2. Which of the following is NOT one of the standard event categories (audit classes) that can be selected when defining a Security Audit Log filter?
3. Which practice best supports effective long-term management of Security Audit Log data growth on application servers?
Interview questions
1. You are the senior consultant/architect responsible for SAP Security Audit Log: SM19/SM20, Event Selection and Retention. The project situation is: An incident investigation needed failed privileged logons from six weeks earlier, but local audit retention was only seven days and no SIEM forwarding existed. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?
Answer it in your own words first, then compare.
2. Using this SAP project situation — Configure logging for failed privileged logons, then review events and correlate them with a known test account to understand what the log can and cannot prove — explain Security Audit Log Fundamentals. What should happen, which concepts or process steps matter, and what common mistake would you avoid?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.