SAP Table Change Logging: Configuration, Security Risks, and Auditing
Last Updated: 12/31/2025
Table Change Logging is a critical security control that provides real-time visibility into data modifications within your SAP environment. It acts as a watchdog, recording modifications made via tools like SM30 or custom programs that might otherwise slip under the radar.
While standard SAP reports often have blind spots, enabling this feature ensures you have a clear audit trail. This is a foundational element of a robust SAP security strategy because it protects the system integrity required for compliance and automated compliance auditing.
Why Table Change Logging is Important for SAP Security
Configuring SAP to log data changes is essential for maintaining a defensible security posture. It provides:
- Transparency: Creates a clear, immutable audit trail of who changed what and when.
- Security: Identifies unauthorized or risky changes that could indicate an insider threat or compromise.
- Troubleshooting: Pinpoints the source of data inconsistencies quickly.
- Compliance: Supports regulatory requirements (SOX, GDPR) for data change tracking.
By implementing Table Change Logging, organizations can maintain the integrity of their SAP systems, even when faced with necessary direct table edits in production or customizing environments.
How Table Change Logging Works in SAP
Table Change Logging functions by targeting specific tables that impact your system’s structure. It documents all modifications, regardless of the method used (e.g., direct table edits), to catch unauthorized changes before they cause outages.
Rather than just monitoring user logins, Table Change Logging functions by targeting specific data structures. It operates on three core principles:
- Comprehensive Recording: It documents the “who, what, and when” of every modification, regardless of the method used to change the data.
- Targeted Tracking: It focuses on specific SAP tables (defined by
rec/client) that impact your system’s configuration and integrity. - Risk Mitigation: It captures unauthorized or incorrect changes (e.g., direct table edits via SM30) before they cause system outages.
To maximize its effectiveness, security teams must:
- Regular Reviews: Establish a process to analyze logged changes periodically using threat detection tools.
- Identify Key SAP Tables: Create a list of tables whose alterations could significantly affect your system.
- Set Up Alerts: Configure notifications for changes to these crucial tables.
What Should You Track? (Relevant SAP Notes)
Deciding which tables to log is a balance between visibility and performance. Refer to the following SAP Notes for guidance:
- SAP Note 1916: Refers to older releases and is generally considered obsolete.
- SAP Note 112388: Provides the most up-to-date definition of relevant logging tables.
Prerequisites for Table Change Logging
From a technical perspective, it is easy to activate Table Change Logging. For table changes to be logged, the system profile parameter rec/client needs to be enabled. This parameter is used to activate and deactivate client-dependent Table Change Logging. Depending on the setting of this parameter, certain change options are either not logged at all, are logged only in certain clients or are logged in all clients.
In order to check the value of the rec/client parameter, execute transaction code RZ11, fulfill the Parametername field and click on Display.
This is a very important step because if the parameter is disabled, even though you have activated Table Change Logging in the technical settings for any table, it won’t log the data changes to that table. Also make sure that the values for rec/client are the same on all instances of a system. Only then will logging work correctly.
These are the possible values that the parameter can adopt:
|
|
|
|
|
|
|
|
|
|
|
|
*WARNING: From a security perspective it is important to audit all the clients in the system. Setting the rec/client parameter to ‘ALL’ can seriously impair R/3 system performance. SAP recommends you do not use the value ‘ALL’.
** <client1>,<client2>,…,<client10>. Caution: Make sure there are no space characters before or after the separator ‘,’.
Incorrect definition:
rec/client=001, 002 , 003
Correct definition:
rec/client=001,002,003
The default setting is OFF (no changes are logged). This setting is only normal in the installation and test phase.
Changing the value of rec/client
In order enable Table Change Logging, set the profile parameter rec/client to ALL or at least specify your production and customizing clients according to SAP recommendations. You can query the SAP table T000 in order to confirm which clients (MANDT column) are production clients (CCATEGORY column equal to ‘P’) and which are customizing clients (CCATEGORY column equal to ‘C’) as shown below:
Finally, the change can be applied through the following steps:
- Open an SAP GUI connection to the SAP server.
- Log in using an administrative account.
- Execute transaction RZ10.
- Select the appropriate profile.
- Select ‘Extended Maintenance’ and click ‘Change’.
- Modify the value of the affected parameter to the recommended setting and click ‘Copy’.
- Go back and select ‘Profile’ > ‘Save’.
- Restart your SAP instance.
Table Change Logging must be activated for each table individually with transaction SE13 (Maintain Technical Settings (Tables)) by enabling the Log Data Changes checkbox. In many SAP standard tables this logging flag is already set. As a result of that, tables will show up as enabled in SAP table DD09L.
Extending Table Change Logging with ABAP Development
While standard tools are robust, custom secure ABAP development can extend logging capabilities to meet specific business needs.
Common ABAP Enhancements for Table Change Logging:
- Custom Reports: Create reports that extract detailed information from logged tables, providing insights not easily accessible via standard transactions like SCU3.
- Automated Log Analysis: Develop programs to analyze change logs for anomalies, such as unexpected changes to critical fields.
- Enhanced Filtering: Enable granular filtering by creating custom selection screens to isolate relevant log entries quickly.
- Example: A simple ABAP program can loop through the contents of
CDHDRandCDPOStables to extract user-specific changes to critical tables, and then email the results to administrators.
Integrating SAP Table Change Logs with External Auditing Tools
For robust security, integrating SAP logs with SIEM systems (like Splunk, Sentinel or QRadar) offers centralized monitoring. This facilitates real-time anomaly detection and automated incident response.
Step-by-Step: Extracting Logs for SIEM Integration:
- Access SAP table change logs via transaction code SCU3 or the relevant logging program (RSTBHIST or RSVTPROT).
- Export logs in a format compatible with your SIEM tool, such as CSV or through a direct API connection (if supported).
- Utilize third-party tools to facilitate log ingestion into systems like Splunk, ArcSight, or IBM QRadar.
Once integrated, your SIEM system can track critical changes and raise alerts when suspicious activity is detected, ensuring faster response times to potential threats.
Automating Alerts and Reports for Critical Table Changes
To further strengthen your SAP security posture, it’s possible to automate alerts and reporting for critical table changes. By leveraging SAP’s alerting mechanisms or integrating with third-party tools, you can set up real-time notifications whenever key tables are modified. This is particularly useful for tables that contain sensitive business or personal data.
How to Automate Alerts:
• Set up email or system alerts by configuring SAP Business Workflow, which triggers notifications when specific table changes occur.
• Use SAP Solution Manager to monitor changes in real-time and send out automated alerts when deviations from standard processes are detected.
• Create scheduled reports in SAP that pull daily or weekly logs of table changes and automatically send them to key stakeholders for review.
If the standard SAP tools for generating alerts don’t meet your organization’s specific needs, previously mentioned ABAP development can provide a more tailored solution. ABAP programs can be written to trigger alerts or workflows whenever specific conditions are met in change logs.
Example ABAP Automation Use Case:
A custom ABAP program that monitors changes to sensitive tables (e.g., customer data) and sends a notification to security administrators whenever certain fields are modified outside of business hours. This allows real-time, context-aware monitoring that standard logs or alerts may not offer.
How Onapsis Helps with SAP Table Change Logging
Onapsis SAP cybersecurity products can help you with two different modules to detect which relevant tables you must configure to activate Table Change Logging: active logging for critical technical tables and active logging for critical business tables.
Below we show you the step-by-step instruction for activating logging for each table.
- Go to transaction code SE13 and complete the Table/view name field with the table for which you want to enable Table Change Logging (e.g. BNKA)
- Click the Change button and enable the Log Data Changes option in the bottom of the window
- Click Save
In order to confirm the change, a new entry will appear in SAP table DD09L.
As shown in the image above, the second line contains a character ‘X’ for the column PROTOKOLL. By double clicking on it, we can see the details.
If these prerequisites are fulfilled, use program RSTBHIST (table change analysis) or RSVTPROT to evaluate the changes made in the tables (alternatively, use transaction code SCU3).
- Run transaction code SA38
- Complete the program name RSTBHIST and press F8
- Click on list of the logged tables to list all the tables whose checkbox Log Data Changes is enabled
- Finally, choose Evaluate Logs to select the corresponding period of time and table to analyze
The system generates a log entry in the log table for every change to logged tables. This is an example of the information that appears in that table:
Conclusion
It’s important to understand the risks of not enabling the Table Change Logging. There is a risk that no alerts will exist for potential unauthorized table data modifications. All changes to the critical SAP ERP tables should be logged by the system and the periodic review of these logs should form a part of the security procedures for the organization.
Perform regular checks to your clients to eliminate the risk of illicit access. OSP can help protect you against this and other attacks. Our tool is able to detect not only if the Table Change Logging status is enabled, but also to determine which critical tables should be activated to log changes.
Learn more about how The Onapsis Platform can protect your business-critical applications.
Frequently Asked Questions (FAQ)
How do I enable Table Change Logging in SAP?
To enable Table Change Logging, you must set the system profile parameter rec/client. Setting this parameter to ALL logs changes in every client, while setting it to a specific client number (e.g., 000, 100) restricts logging to that specific client.
What SAP transaction code is used to view table logs?
The primary transaction code for viewing table change logs is SCU3. This transaction allows administrators to evaluate the logs of customized tables and track specific modifications over time.
Does Table Change Logging affect SAP system performance?
Yes, enabling logging for all tables can significantly impact performance and increase database size. Best practice dictates enabling logging only for critical customizing and configuration tables, rather than high-volume transaction tables.
Which SAP tables should be logged?
You should log tables that are critical to system integrity and security, such as those defined in SAP Note 112388. Generally, this includes client-independent system tables and business-critical configuration tables where unauthorized changes could pose a risk.