SAP audit retention for SOC2: what to log and for how long

SAP audit trails come up early in any SOC2 or ISO 27001 audit cycle. The common gap is not access control, which is usually well-managed, but the completeness of the audit data: what is recorded, who can read it, how long it is kept, and whether it can be exported in a form the auditor can work with.

This is a practical view of how to design that audit data for a SAP landscape so the audit cycle goes smoothly.

Why the SAP Security Audit Log alone is rarely enough

The Security Audit Log (SM19, SM20) is the canonical audit surface on the ABAP stack. It is necessary but does not cover everything that auditors look at.

• It records user actions on the ABAP stack. It does not record infrastructure-level actions such as restarting an SAP instance with sapcontrol on the operating system, or direct database access via hdbsql or SQL clients.
• Default SAL retention is configured at the SAP host level. SOC2 typically expects the audit data to be available for at least a year for relevant control families, and ISO 27001 references vary by control.
• SAL files are not in a format auditors usually want to read directly. A 1 GB raw audit file does not demonstrate a control on its own.

SAL stays in scope. It just needs help: a way to add the infrastructure and database actions to the picture, a defined retention policy by event class, and an export workflow.

Configuring the Security Audit Log (SM19 / RSAU_CONFIG)

Before retention matters, the SAL has to be capturing the right events. On older releases the profile lives in SM19 and is read in SM20; on S/4 and recent Basis it is RSAU_CONFIG / RSAU_READ_LOG. Either way it is driven by kernel parameters plus a set of filters (selection slots) per client and user:

# Instance/kernel parameters (RZ11 to inspect, profile to persist)
rsau/enable                = 1     # switch the audit log on
rsau/selection_slots       = 10    # number of filter slots (>= 10 typical)
rsau/user_selection        = 1     # filter by user/client in the slots
rsau/integrity             = 1     # hash-chain the log where supported
# disk budget (release-dependent name):
rsau/max_diskspace/per_day = ...   #   newer
rsau/max_diskspace/local   = ...   #   legacy

# Define the audit filters: SM19 (classic) or RSAU_CONFIG (S/4).
# Per client + user (often * / *), select the event classes:
#   - Dialog logon: successful (AU1) AND failed (AU2)
#   - Transaction / report start
#   - RFC call + RFC logon
#   - User-master and authorization changes
#   - Changes to the audit configuration itself

# Read it back: SM20 (classic) or RSAU_READ_LOG (S/4)

Two filter choices matter for a clean audit: log failed logons and RFC logons (the noisy-but-necessary ones), and always log changes to the audit configuration itself. An audit trail that does not record being switched off has a hole exactly where an attacker would aim. Set rsau/integrity where your release supports it, so the SAL is hash-chained on the host as well.

A retention model that auditors accept

SOC2 does not prescribe specific retention horizons. Auditors look for choices that are documented and consistent with the control they support. A model that has held up well in practice:

The principle is that longer retention applies to events that shape who can do what. Shorter retention is appropriate for transient visibility data. The values above are starting points; you will adjust them to fit the controls your auditor relies on.

What to log by role

The model below is what we use as a baseline when designing audit coverage for an SAP-aware monitoring platform.

Platform owner and admin

• Every login attempt with IP, user agent, MFA outcome.
• Every role and permission change including the target user and the before-and-after state.
• Every API token issued, revealed, revoked.
• Every privileged SAP-side action with the target system, the command and the outcome.
• Every audit query or export, including the period queried and the delivery target.

Customer admin

• The same coverage as above, scoped to the customer's own systems.
• Cross-customer queries are blocked at the API. Any attempt is itself a record.

Technician

• Every SAP-side action linked to a ticket or runbook identifier where possible.
• SSH session activity captured in a form that preserves the command stream rather than the full TTY.
• Privileged database queries recorded with the statement and execution metadata, not the full result set.

Service desk

• Alert acknowledgements and escalations.
• The volume is small but the attribution is still useful in incident timelines.

Making the audit data tamper-evident

An audit record that an operator can quietly edit is not an audit record. There are three patterns we see work in practice.

Append-only collection with chained hashes. The application writes audit records to a database collection it can only insert into, and a separate role can read. A periodic job hashes the previous period's records and chains the hash to the prior period. Any tampering breaks the chain on the next verification pass.

Object storage with object lock. Audit records are batched and written to object storage with a compliance-mode object lock for the retention horizon. The object is immutable until the lock expires. Useful when auditors want a strong tamper-evidence story.

Append-only database with a cold export. Real-time data lives in the database for operator queries; a nightly job exports the period's records to object storage with an object lock. The database carries shorter retention; the object store carries the longer one. This is the pattern Farrenio uses.

Export formats auditors usually accept

CSV is always accepted. Keep the schema wide; one row per event, one column per field. Use UTC ISO 8601 timestamps. Do not omit columns based on event type; leave them empty when not applicable.

JSON Lines is preferred by audit teams used to working with SIEM data. One JSON object per line, nested objects for before-and-after state.

If your auditor is SAP-experienced and asks for AIS-compatible exports of SAL data, confirm before designing the export pipeline. Modern audit partners are usually flexible on format.

A short pre-audit check

Five queries that, if you can answer them quickly, indicate the audit posture is in working order.

1. Every sapcontrol restart of a given system between two dates.
2. Every account that held a privileged role at any point in a given year.
3. The chain hash for a period last year, and a comparison to the value you exported at the time.
4. One audit event drawn from cold storage that is older than the database retention.
5. How long it takes to produce a 12-month CSV export for one role.

How Farrenio handles audit retention

Every privileged platform action, including logins, role changes, token reveals, SAP-side commands, audit queries and configuration edits, is recorded with operator, IP, request identifier and outcome. The security page covers the rest of the model: MFA, role separation, encrypted credentials, and the way audit access itself is gated.

Default retention is one year for security-class events and a shorter horizon for general events. Both are configurable per customer. Exports are available as CSV or JSON Lines and can be scoped by date, system, customer or action class.

If you would like a review of your current SAP audit setup against a SOC2 readiness checklist, write to contact@farrenio.com.