How to Effectively Implement SAP Security Monitoring and SIEM Integration: A Practical Approach 

Share
  • Security, SAP

First, let’s take a moment to address the question of how secure SAP environments are.
In May 2025, SAPinsider published a report indicating that 23% of respondents had experienced an attack on their SAP environments in the past 12 months.

There was also a year-on-year increase in threats related to unauthorized access to data and attacks directly on the supply chain.  

SAP environments often act as silos for security monitoring. Even when data is monitored, it is often incomplete. In this post, we will describe how to elevate security to a level that allows for the identification of all security challenges.  

Implementing SAP security monitoring is not just about connecting the system to a SIEM.
It is a process that begins with properly defining the scope and ends with daily maintenance and improvement of incident detection. In this article, I show how to approach this topic in a practical way—based on real-world project experience.

First – scope

The scope of implementation and integration are the foundation of any solution. We need to clearly answer the question: What exactly do we want to do? What do we want to monitor, and why? Monitoring changes in parameters and configurations is one thing, but monitoring access to transactions or changes to master data is quite another. 

In addition, we need to decide how and where we want to monitor. This presents another challenge: 

  • What systems are part of our ecosystem? 
  • Which environments (DEV/TEST/PROD)? 
  • What is the business significance of the above? 


The key point here is to distinguish between environments—production and test systems differ not only in terms of importance but also in terms of the types of risks they face. Additionally, there is the question of data quality on non-production systems (i.e., if it is a copy, do we have control over access to the data copied from production? 

The example of the division is quite intuitive: 

  • PROD refers to critical events (such as changes in roles or access), 
  • TEST poses a potential risk associated with copies of production data. 


Therefore, the same monitoring rules cannot be applied to all environments.

Centralized or distributed deployment? 

The next fundamental question concerns the architecture of the monitoring stack (each decision has its pros and cons, as well as implications regarding how much time we need to devote to monitoring and how we should approach it): 

  • Centralized monitoring—meaning everything in one place—means easier management and standardization, 
  • distributed monitoring—managing each system individually—provides greater local control but makes maintenance more complex. 


The decision on whether to decentralize or centralize directly affects, among other things: 

  • the method of event processing, 
  • their aggregation, 
  • integration with SIEM.


Now, regarding events—monitoring every single one may not make sense. This is especially true when considering where such events occur. Here are some examples of events that may not necessarily be relevant in non-production environments: 

  • Assigning roles  
  • Administrative actions 
  • Configuration changes 
  • Access to sensitive data (if we do not have a copy of the production system or the data is encrypted at the database level). 

 

The very scope of what we want to monitor depends directly on the risks that the activity may pose to the business, the customer's pain points, or simply the specific characteristics of the systems we are monitoring. 

Second – SIEM

SIEM offers additional capabilities rather than being an end in itself; integration with it is just one piece of the puzzle. Not every event is an incident. The fundamental principle is that SIEM is not designed to collect everything—only to identify incidents. 

We can view SIEM as a monitoring tool that helps us address several key questions: how to filter data, how to correlate SAP activities with other events in our infrastructure, and how we want to analyze identified issues. 

And since we can integrate activities in SIEM, it is possible to support the process with elements such as: 

  • linking SAP events with other sources (e.g., Active Directory), 
  • detection of anomalies (e.g., activity outside of working hours), 
  • developing attack scenarios (i.e., following the trail to the source—where it comes from and who is doing what). 

 

This is particularly important because SAP is just one of the data sources—SIEM aggregates the complete security picture.

Third - competencies

In practice, Security Operations Center (SOC) teams do not have specialized SAP expertise. SOC teams are security specialists, but because SAP generates very specific events, we may have trouble properly addressing a particular finding.  

Why is this a problem? Without the right knowledge, events can be misinterpreted. Alerts themselves can either be ignored (we don’t know what’s going on) or overinterpreted (information overload). The latter can lead to an increasing number of false positives, which in turn reduces the quality of monitoring.  

So what is needed to effectively address the issue of competence? We have several options (and as always, every choice has consequences): 

  • SOC training on SAP basics – this certainly won’t fill the gaps in your knowledge 
  • Support from the SAP (BASIS) team or directly from SAP Security 
  • Manage the external SAP Security team  

Fourth – definitions of events

A key element of monitoring is the proper definition of events and their structure. This essentially comes down to proper data standardization. If the fields are clearly labeled and the event structure is consistent, it is easier to build detection rules, and event analysis by the SOC becomes simpler. 

In practice, SIEM systems often help automatically detect anomalies, but validation and expert consultation are still necessary. This is where SAP expertise comes into play.

Lukardi delivers:

  • SAP security solution implementations in Europe,
  • NIS2 checklists prepared by experts,
  • Benchmarks confirming a 70-80% reduction in audit time,
  • Full PoC support in SAP environments.

Fifth - simply connecting SAP and SIEM isn't enough

Connecting SAP directly to a SIEM can prove problematic. We’ve already discussed the issue of expertise. The very act of connecting to all log sources (and there are several of them) generates a massive volume of data. This leads to two main drawbacks: 

  • Information overload (who is capable of processing such a large number of events and identifying the critical ones?) 
  • High processing costs (modern SIEM tools are typically licensed based on the volume of data processed)  


Therefore, it is important to introduce an intermediary layer to facilitate and standardize the transfer of relevant information from SAP to SIEM. Such a layer: 

  • aggregates data from various SAP sources (SAL, change logs, system logs), 
  • normalizes them into events, 
  • filters them at the SAP application level. 


The benefits include: data reduction—less than 1% of logs contain information critical from a security perspective; improved information quality—the event database directly corresponds to real-world scenarios; lower SIEM costs—only relevant information is sent to the SIEM. 

And how does this work in practice? A typical flow of information from SAP to SIEM is as follows: 

  1. SAP generates events, 
  2. writing to filesat the OS level,
  3. forwarding (e.g., by an agent) to the SIEM, 
  4. correlation and analysis. 

 

Sixth - daily activities

And this is where the actual monitoring begins. The ultimate goal is not to collect data, but rather: 

Identification of real incidents with minimal noise. 

The security team's daily tasks include, among other things: 

  • Analysis of alerts 
  • reduction of false positives 
  • filters optymalization 
  • monitoring trends and anomalies, 
  • adding new data sources. 

 

SAP monitoring is an ongoing process. Initial efforts must focus on selecting the right data sources to cut through the noise and identify what is critical to the organization.  

As this natural evolution unfolds, we reach a point where we can identify which events are unnecessary, and as we refine the rules, we focus on what really matters. 

From there, it’s a straightforward process to identify anomalies and trends. For example, sudden spikes in events, unusual patterns, or simply activities that don’t appear to be standard. Often, these are things that, when occurring in isolation, don’t raise any suspicion. 

 

Summary

We are seeing challenges related to the lack of a clear and transparent vision for SAP security. Organizational challenges include defining responsibilities and coordinating efforts to assess specific security incidents.  

Technically speaking, the challenge lies in integrating the data sources provided by SAP systems. After all, it’s not just the Security Audit Log that contains specific information. OS logs, databases, interfaces, and change tables/documents—that’s where the real meat of the data often lies.  

And if this is a challenge, addressing it by filtering events at the SAP application layer will lead to cost savings for SAP and increased transparency in the SAP security layer.  

In terms of expertise, we need to acknowledge the obvious gaps in SAP analysis knowledge at the SOC level. However, we can address this by providing targeted support in specific workflows—whether it’s day-to-day support or configuring alerts and event types.  

Effective SAP monitoring is not a technology project—it is an operational process.

Key factors for success: 

  • a clearly defined scope, 
  • seamless integration with SIEM, 
  • skills (or additional skills), 
  • continuous optimization. 

The most important metric isn’t the number of logs collected—it’s the number of actual incidents detected.

Joanna Komsa

Digital Transformation & Business Development |Marketing Manager at Lukardi.
She has been involved in online marketing, strategy building and communications for 15 years. She is passionate about new technologies, AI and neuropsychology. She supports organizations in digital transformation and generating new business opportunities, combining experience in dordzdz, sales and marketing.