"SAP logs everything" — it's a statement heard frequently. But is it actually true? Can you always trace who did what in the system? And are there ways to bypass or delete those logs? This article addresses all of these questions.
What Are SAP Logs and Why Do They Matter?
Logs are the digital equivalent of fingerprints: traces of actions performed by users within the system. In an ERP context like SAP, this means purchase orders, invoices, accounting documents, configuration changes, and so on.
SAP has strong logging capabilities — but that does not mean it logs everything. The statement is colloquially understandable, but technically inaccurate. There are deliberate reasons why not everything is traced:
- Not every action warrants a trace. Does it matter if a user changes their default printer? Probably not. Does it matter if they modify an accounting document? Absolutely. Even within documents, not every field change may be relevant.
- Logging has a performance cost. Every log entry consumes system resources. Tracing everything would degrade performance.
- Logging has a storage cost. Comprehensive logging requires managing large volumes of archived data over time.
SAP Log Families: What Exists and What Is Active by Default
SAP systems are organized around environment separation — development, test, and production — to ensure that changes are tested before reaching production (via the Transport Management System). This creates two distinct categories of logs:
Logs of Actions in the Production System
- SAP Security Audit Log — must be explicitly activated
- SAP Change Log — active by default on certain standard tables
- Table Change Log — must be explicitly activated
- Application Log — active in some areas; requires explicit activation in others
- System Log — active by default
Logs of Changes Transported from Development to Production
- Transport Management System (TMS) — tracks changes moved through the system landscape
SAP Security by Default: Where Things Stand
SAP is progressively adopting a Security by Default approach — shipping software pre-configured with security settings already enabled, including logging and tracing. This is the right direction, but the journey is long.
Many logging functions — including some of the most important ones — were not active by default in the past, and in some systems still are not today. This means that during system installation or ongoing management, a conscious decision needs to be made about which logs to activate.
A provider can recommend activating specific logs, but the organization needs both the willingness and the operational capacity to manage those logs correctly once they are running. Activating a log that no one monitors creates a false sense of security.
Does Activating All Logs Make You Secure?
Not on its own. SAP Security is a specialized discipline with many layers, and the logging layer is just one of them. Even with comprehensive application-level logging in place, several areas remain:
- The database layer. What happens at the database level, beneath the SAP application layer, requires separate controls and monitoring.
- System communications. Data in transit between SAP components and external systems needs its own protection mechanisms.
- Custom developments. Functionality developed specifically for the organization — outside SAP standard — does not automatically inherit SAP's standard logging mechanisms. Unless logging is explicitly built into the custom code, actions performed through custom transactions leave no trace in the standard logs.
What About Administrators? Can They Delete Logs?
Yes. Users with administrative access to SAP have access to tools designed for log retention management — tools that are entirely legitimate when used for their intended purpose (deleting logs that have reached their retention period). The same tools can be misused to delete traces of unauthorized activity.
This is one reason why Segregation of Duties among administrators matters — not just between business users. And it is a direct argument for forwarding critical logs to an external SIEM.
As covered in the article on SE16, some administrative functions can also be used to modify log tables directly. The implication is the same: an administrator determined to cover their tracks can do so within the SAP system alone, if no external controls are in place.
SIEM Integration as a Mitigation
Forwarding selected SAP logs — typically the most critical ones — to an external SIEM system significantly raises the bar for log tampering. If logs exist only in SAP, an administrator with the right access can delete them in one place. If those same logs have already been forwarded to an independent system, covering tracks requires acting on multiple systems simultaneously — substantially more complex.
This does not eliminate the risk entirely, but it makes unauthorized log deletion meaningfully harder. It also requires investment: not just in technology, but in the processes and organizational structures needed to monitor and act on what the SIEM surfaces. The right level of investment should be determined through a risk assessment.
Shared User Accounts: A Subtle but Serious Problem
Shared SAP user accounts — where a single account is used by multiple people — are fortunately not widespread, but they do exist. When they do, the technical integrity of the logs is not compromised: entries are still recorded. But their evidentiary value is.
If an account registered under one person's name is used by others, actions logged against that account may not have been performed by the named user at all. The log exists — it just no longer tells you who actually did what.
This is fundamentally an organizational and accountability issue. Technology can help detect patterns that suggest shared usage, but it cannot fully compensate for an organizational model that tolerates shared accounts. Training and clear accountability policies are as important here as any technical control.
Frequently Asked Questions
Does SAP log everything?
Not automatically. SAP has strong logging capabilities, but not all log types are active by default, and not all actions are logged by design. What gets traced depends on which mechanisms are activated and how the system is configured.
What are the main SAP log types?
The main families are: Security Audit Log (must be activated), Change Log (active by default on certain tables), Table Change Log (must be activated), Application Log (active in some cases), System Log (active by default), and the Transport Management System log for transported changes.
Can SAP administrators delete audit logs?
Yes. Legitimate tools exist for log retention management that can also be misused to delete evidence. This is why administrator-level Segregation of Duties and SIEM integration are important mitigations.
Does activating all logs mean the system is secure?
No. Application-level logging is one layer of a broader security picture that also includes the database layer, system communications, and custom developments — none of which automatically inherit standard SAP logging.
What is the risk of shared SAP user accounts for audit trails?
Logs remain technically intact but lose evidentiary value: actions are recorded under one username but may have been performed by someone else. This requires an organizational response — clear accountability policies and user awareness — not just a technical one.