Tuesday, 9:12 a.m. Someone logs in to the SAP system on a customer service employee’s account. The password is right first time, so no failed-logon counter moves. The antivirus stays quiet, because there is no malicious file. The firewall stays quiet, because the traffic looks like any other. The SIEM records a successful logon - one of several hundred that morning - and there its role ends. Over the following hours the account browses customer records. First hundreds, as on any other day. Then thousands. By the afternoon the count runs into the hundreds of thousands, and nobody in the company knows.
Onno Coenen of SecurityBridge described this scenario in an article whose title stays with you for a long time: if someone stole two million customer records from your SAP today - would you know? For most organisations the honest answer is no.
The short version:
1/ Attackers rarely break into SAP any more - they log in with stolen, valid credentials and behave like ordinary users,
2/ A SIEM and infrastructure monitoring see the logon, but not what the user does inside the SAP application - the biggest blind spot in SAP security,
3/ GDPR gives you 72 hours to notify the supervisory authority, and Poland’s cybersecurity act (KSC) gives 24 hours for an early warning - both clocks assume you are able to detect and describe the incident in the first place,
4/ The answer is native monitoring inside SAP - detecting unusual data access in real time, plus forensic evidence for the investigation and the regulator.
A logon that passes every control
Over the years companies have built solid protection around their infrastructure: identity management, endpoint protection, network monitoring, a SIEM with a round-the-clock team. Those are good investments and no reasonable person questions them. The problem is that attackers have done the same homework. Instead of forcing the door, they walk in with a key - credentials obtained through phishing, a password leak or a hijacked service account.
From that moment every classic control works in their favour. The logon is valid. The session looks ordinary. Database queries run through standard transactions. From the SIEM’s perspective it is another day of another user’s work, because a SIEM collects events from the network, operating systems and authentication - not from inside the business application. It can tell you that someone entered SAP. It cannot tell you what they are doing there.
And SAP is where the most valuable data lives. Contracts, billing data, payment history, addresses, bank account numbers - in a large organisation, hundreds of thousands or millions of customer records in the tables of a single system. We wrote recently about the Western Digital breach, where the attackers reached exactly that - data held in SAP. The pattern does not age; only the price paid by the victim changes.
Seven questions you will have to answer
A breach rarely comes to light from the inside. More often the customer data turns up for sale on the dark web, the police call, or a business partner asks how fraudsters know their contract numbers. Only then does the investigation start - and the questions sound trivial right up to the moment you have to answer them under pressure from the board, your customers and the regulator all at once:
- When did the activity start?
- Which SAP account was used?
- Which transactions were executed?
- Which customer records exactly were viewed?
- Was the data downloaded or exported?
- How many customers are affected?
- Has the activity actually been stopped?
Knowing that someone logged in to SAP is one thing. Knowing what they did after logging in is a different category altogether - and without an event trail from inside the application, the security team pieces answers together from fragments of logs across systems, for weeks, while running crisis communications in parallel. The organisation is conducting an investigation and fighting the fire at the same time.
The regulator expects facts, not suppositions
Coenen writes from an Asia-Pacific perspective: Singapore’s PDPA requires a breach to be notified to the data protection commission no later than three calendar days after it is assessed as notifiable, with fines of up to 10% of annual turnover in Singapore (for turnover above SGD 10 million) or SGD 1 million; Australia’s Privacy Act provides for penalties of up to AUD 50 million, three times the benefit obtained or 30% of adjusted turnover - whichever is highest. Exotic? Only on the surface, because European rules are built on the same assumption: the organisation is supposed to know what happened before it starts talking about it.
GDPR Article 33 gives you 72 hours to notify the supervisory authority - in Poland that is PUODO - counted from the moment the breach is established, and where the risk to individuals is high, Article 34 adds a duty to inform the affected customers themselves. Breaching the security and notification obligations carries fines of up to EUR 10 million or 2% of worldwide turnover, and breaching the processing principles - up to EUR 20 million or 4%. Poland’s cybersecurity act (KSC), the local NIS2 transposition we covered last week, goes further: an early warning of a significant incident within 24 hours and a notification within 72, both counted from detection. And the calendar is not waiting: the application for entry in the register of essential and important entities is due by 3 October 2026 - two months from now.
Which brings back the trap you know from that article. All these clocks start at detection, or at the establishment of a breach. If you have nothing to detect with, the clock formally never starts - but a supervisory authority will not read that as good luck. It will read it as an absence of technical measures appropriate to the risk. And when the first signal of a breach is a journalist’s phone call, it is too late to start building your answer.
“We believe” versus “we know”
No vendor and no security team can guarantee that a breach will never happen. The difference between a prepared company and an unprepared one shows in the first sentence of its statement.
A company without visibility into SAP says: “We believe customer data may have been compromised. We are still establishing the scale.”
A company with visibility says: “We know which account was used, which transactions were executed, which records were viewed, when it happened and which customers are affected. The activity has been blocked.”
Those are two entirely different conversations with the board, with customers and with the regulator. The first opens a crisis of unknown cost and unknown duration. The second closes an incident with numbers. And customer trust - the one asset you cannot restore from a backup - is far more likely to survive the second version.
Closing the blind spot
If the problem is the lack of visibility inside the application, the solution has to work inside the application. That is exactly what the SecurityBridge platform does - we deploy it as the official partner in Poland:
Threat Detection monitors events inside SAP in real time and raises alerts enriched with business context - not “a user executed a transaction”, but “a customer service account is reading data at a pace and scope that resembles no normal process”.
Data Loss Prevention watches access to sensitive data: it detects unusual browsing and downloading of records as it happens, not after the fact. The security team gets a chance to cut the exfiltration short before millions of records leave the system - and if an incident does occur, the platform delivers the forensic material: which account, which transactions, which data, in what timeframe.
The alerts land in your SIEM, so the investments you have already made are not wasted - they gain the missing layer they cannot see on their own.
Where to start
Not with a purchase. With an honest answer to the question of whether the morning from the beginning of this text would be noticed in your organisation.
The fastest route to that answer is our free assessment, SNOK KSC-CHECK - 25 questions in six steps, 8 to 12 minutes, the result on screen immediately and a PDF report by email. Two of the five areas - Event visibility, and Detection and response - address precisely the blind spot this article is about. It is a self-assessment, not an audit, but it structures the conversation about priorities better than many a status meeting.
The second step we propose is always the same, because it works: book a SecurityBridge demo with us, and then we run a proof of concept in your SAP landscape - on a selected system, on your scenarios, with alerts raised on real events. After such a POC you know exactly what the platform sees in your environment, not on slides. Instead of a discussion about architecture, you get an answer to the question in this article’s title.
We work with sensitive data in SAP every day and at scale - for Medicover we built an HR process platform serving around 45,000 employees in 18 countries and handling roughly 100,000 HR events a year, a project recognised by SAP as an official reference, one of three in Poland. We know what responsibility for personal data in SAP systems looks like long before the word “incident” appears.
If the assessment reveals gaps - or if you would rather go straight to the level of specific systems - write to us. We will show you live what the detection of a mass data read in SAP looks like, before somebody who should not see it does.
Sources
- Onno Coenen, If Someone Stole Two Million Customer Records from SAP Today… Would You Know?, LinkedIn Pulse, 27.07.2026
- GDPR (Regulation 2016/679), Articles 33, 34 and 83 - EUR-Lex
- Act of 23 January 2026 amending Poland’s National Cybersecurity System Act (Journal of Laws 2026, item 252)
- Personal Data Protection Act 2012 (Singapore), PDPC notification requirements; Privacy Act 1988 (Australia) as amended in 2022 - after the source article
- SecurityBridge - platform documentation: Threat Detection, Data Loss Prevention