SAP Security Audit Log Basics: Configure SM19 and Review SM20

The SAP Security Audit Log records selected security-relevant events in an ABAP system. Administrators configure the event scope in SM19 and review collected records in SM20. A useful operating process connects configuration, validation, review, retention, and evidence handling rather than treating the transactions as isolated tasks.

This guide focuses on operational audit logging: deciding what to capture, proving that the configuration works, investigating events, and reducing noise without losing important activity. For the wider control framework, see SAP Security and GRC Overview.

01Understand the audit-log workflow

The workflow has five stages:

1. Define the security events and systems that require monitoring.
2. Configure the audit scope in SM19.
3. Activate or apply the configuration according to the system setup.
4. Generate controlled test activity and verify the result in SM20.
5. Review, export, retain, and escalate relevant records.

The audit log supports accountability, but it does not replace authorization analysis, application logging, change control, or database and operating-system monitoring. Use it as one evidence source in a broader control design.

02Configure SM19

Before changing SM19, document the purpose of the change, the event categories required, the affected clients or systems, the retention expectation, and the approver. Start with events that support a defined control objective, such as authentication failures, successful logons, changes to users or roles, changes to security settings, and other security-relevant administrative activity available in the system.

A practical configuration sequence is:

1. Open transaction SM19 with an account authorized to maintain the audit configuration.
2. Select the relevant audit configuration scope for the system.
3. Choose the event categories required by the control design.
4. Set the appropriate filters for users, clients, or other available dimensions.
5. Save the configuration through the normal change-control process.
6. Record the effective time, administrator, reason, and approval reference.

Keep the selection narrow enough for analysts to review. Broad collection can increase storage and investigation effort, while a narrow selection can leave gaps in an investigation. Maintain a written mapping between each selected event category and the risk or control it supports.

03Validate events in SM20

Validation should use a controlled test account or an approved test procedure. Record the test time, user, client, system, action, and expected event. Generate one test activity for each important category, then open SM20 and search the relevant time window.

Confirm that the result identifies the expected user and event context and that the recorded time aligns with the test. Repeat the search with a narrow time range first, then broaden it only when required. Save the search criteria and evidence reference so another administrator can reproduce the check.

If a test event is absent, check the effective audit configuration, the selected filters, the test account, the system time, and the search interval. Review the relevant system and application processing logs alongside SM20 to determine whether the activity occurred and whether the audit event was expected for that action.

04Review audit records

A repeatable review starts with a defined question. Examples include investigating repeated authentication failures, confirming a privileged-user change, checking activity during a maintenance window, or examining actions linked to an incident.

Use SM20 filters to constrain the search by time, user, client, event, and other available criteria. Preserve the original search scope before narrowing the result for a report. For each significant record, capture the event timestamp, user, client, event description, related object or transaction when shown, review status, and investigation reference.

Separate triage from conclusion. A single failed logon may be routine, while a burst of failures followed by a successful privileged logon deserves correlation with change records and other monitoring data. Record the reason for escalation and the evidence used to close the finding.

For access-governance context, compare audit findings with SAP SoD Segregation of Duties Basics and SAP User Access Review Basics. These controls address different questions: the audit log shows recorded activity, while access reviews assess whether assigned access remains appropriate.

05Build a retention and evidence process

Define retention according to the organization’s policy, regulatory requirements, incident-response needs, and available system controls. Include the audit records, configuration history, review results, approval records, exports, and investigation references in the evidence plan.

Protect exported evidence from unauthorized alteration. Use a controlled repository, record the export time and operator, restrict access, and retain the original search parameters. When an investigation spans several systems, normalize timestamps and identify the system and client for every evidence item.

Review the audit-log configuration after upgrades, security changes, client copies, system copies, and major role changes. A configuration review should confirm that required event categories remain selected and that filters still match the control objective.

06Troubleshoot missing or noisy records

Use this sequence when the audit log does not answer the operational question:

1. Define the exact action, user, system, client, and time of the expected event.
2. Confirm the audit configuration in SM19 and its effective scope.
3. Check whether filters exclude the user, client, or event.
4. Compare the expected action with a controlled reproduction.
5. Search SM20 using a tight time window and the exact test identity.
6. Correlate the result with system, application, change, and access-review evidence.
7. Document the gap, its impact, and the corrective action.

Noise usually comes from an overly broad event scope, service accounts that generate repetitive activity, or searches without a defined control question. Adjust filters through change control and verify that the adjustment does not remove evidence required for security investigations.

07Operational review checklist

Use this checklist for a periodic control review:

• Confirm the owner and approver for the audit configuration.
• Compare selected event categories with current security risks.
• Test representative successful and failed activities.
• Verify that SM20 searches return the expected test records.
• Review privileged-user and security-configuration activity.
• Check retention, access restrictions, and evidence storage.
• Record exceptions, compensating controls, and remediation dates.

The same process can support incident response, internal control testing, and recurring operational monitoring. For related privileged-access controls, see SAP Emergency Access Management Firefighter and SAP GRC Access Control Overview.