SAP Table Access Logging Configuration

Why table logging matters

SAP table logging is the technical control that captures every change to a configured customizing or master data table. The change document includes the user, the timestamp, the field, the old value, and the new value. The change document is the audit evidence that survives external auditor walkthrough and SoX testing. Without disciplined table logging the customer cannot reconstruct who changed which configuration when and cannot answer the audit question of who approved the change.

This article documents the activation framework, the read access logging extension, the storage and retention design, and the audit defensible logging posture. Reference the SAP security audit pillar, the audit trail analysis, and the SoX compliance expertise.

Activation framework

Table logging activation rests on two layers. First, the table itself carries the technical setting log data changes in the table definition. Second, the system profile parameter rec/client controls the client level activation. Both layers must be on for changes to be logged. The customer position is to activate logging globally through rec/client and to confirm each customizing table carries the log data changes flag during quarterly review of the configuration landscape.

Reference the audit trail analysis, the change management analysis, and the SoX ITGC analysis.

Read access logging extension

Read access logging extends the change logging framework to read events on sensitive data. The framework names the channel, the field, and the purpose of the read access logging. The framework supports GDPR article 30 record of processing requirements and the SoX requirement to evidence privileged read on financial data. The customer position is to enable read access logging on the master data fields that hold personal data and on the financial data tables that drive SoX testing.

Reference the GDPR compliance analysis, the privileged access analysis, and the critical authorizations analysis.

Read access logging closes the most common audit finding in privileged access reviews. The framework produces evidence of who read the sensitive data and links the evidence to the purpose declared in the configuration.

Storage and retention design

Table logging and read access logging both produce volume. The volume drives the storage and retention design. The customer position is to define retention by data category. SoX in scope tables retain change logs for at least 7 years. GDPR data category retention follows the controller obligation. Operating tables retain change logs for the rolling 2 years. The retention design includes the archive process and the legal hold framework for tables under litigation hold.

The detail is in our license audit pillar (cross cluster reference for the named user implication of log retention), the change management analysis, and the SoX ITGC analysis.

Audit defensible logging posture

The audit defensible logging posture has four components. First, the documented table inventory with logging activation status confirmed. Second, the rec/client parameter at the recommended value across every client in the landscape. Third, the read access logging on GDPR and SoX in scope data with documented purpose. Fourth, the retention design with archive and legal hold processes evidenced. The four components together survive external auditor walkthrough and SoX testing.

The implementation detail is in our security baseline analysis, the audit trail analysis, the GDPR compliance analysis, and the compliance framework pillar. The SoX compliance expertise documents the full senior advisor methodology.