"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.
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:
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:
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.
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:
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.
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 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.
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.
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.
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.
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.
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.
Related topics: SAP audit, admin, SAP log