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.

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.