The second Tuesday of May 2026 - the 12th - was a week ago. Your Basis team received another list of SAP Security Notes to review, assess and implement. In a typical Polish SAP landscape, the average time from note publication to patch deployment in the production environment is 45 to 90 days. The window ransomware actors currently need to build a working exploit is now measured in hours. A week ago, when the May notes were published, a vulnerability disclosed a year earlier - CVE-2025-31324, with the highest possible CVSS score of 10.0 - was still being actively exploited in the wild.
This is not an article about “patching faster”. This is an article about the fact that since the transposition of the NIS2 directive into Polish law, failing to patch quickly means risking a fine of up to EUR 10 million and personal liability for board members.
1. The details: what is actually happening with CVE ≥ 9.5 in SAP
Critical SAP vulnerabilities are no longer a theoretical, academic risk. Three concrete cases from the past twelve months illustrate the scale of the problem:
CVE-2025-31324 - SAP NetWeaver Visual Composer, CVSS 10.0 (the highest possible score). An unauthenticated deserialisation vulnerability in the /developmentserver/metadatauploader endpoint. An attacker sends a crafted HTTP packet and obtains remote code execution with the privileges of the SAP service user. SAP published the note in April 2025; a working exploit appeared in the wild within 72 hours. CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalogue in May 2025. The BianLian and RansomEXX ransomware groups have been confirmed as active exploiters.
CVE-2025-42999 - an exploitation chain building on CVE-2025-31324, CVSS 9.1. Enables privilege escalation once initial access has been obtained. Together, the two CVEs form a ready-made initial access → full compromise chain at the SAP application layer.
Context for the Polish market. Visual Composer is a component present in SAP NetWeaver 7.0-7.5 - that is, in landscapes that have not yet moved to S/4HANA. This describes the majority of the Polish ERP market outside the top twenty largest implementations. In other words: if your organisation is still running classic ECC, the probability that this component is present in your environment is high. The probability of being aware that it is installed is considerably lower.
This is precisely the crux of the problem. The classic SAP vulnerability response cycle looks as follows:
- SAP publishes a note (the second Tuesday of the month)
- Basis reads the note, assesses its impact from memory or via a manual component review
- A required service window is scheduled (typically 4-6 weeks ahead)
- Testing in QA
- Production deployment
Average time: 45-90 days. Actual exploitation window: 24-72 hours.
2. NIS2 + the KSC Act - the hard regulatory truth
The second dimension of this problem - and the reason this article is titled “Patch Day vs NIS2” - is regulatory.
The NIS2 directive (2022/2555) was adopted at EU level and is subject to mandatory transposition into national law. In Poland, this is being carried out through an amendment to the National Cybersecurity System Act (UoKSC) - draft UD68. The transposition deadline expired on 17 October 2024; Poland is still finalising the legislative process, but the substantive obligations and fines will apply from the moment the amended act enters into force.
Who is subject to NIS2/KSC in sectors using SAP:
- energy (electricity, gas, oil, district heating, hydrogen)
- transport (air, rail, road, water)
- banking and financial market infrastructure
- healthcare
- drinking water and wastewater
- digital infrastructure
- public administration
- critical manufacturing (chemicals, medical devices, automotive, electrical equipment)
- food (processing, distribution)
- postal and courier services
Most enterprises in these sectors run their core processes on SAP. In other words: SAP is not “just an ERP application” - it is a system whose compromise can constitute grounds for classifying an incident as significant under Article 23 of NIS2.
Specific obligations that touch day-to-day SAP work:
| NIS2 requirement | What this means in practice for SAP |
|---|---|
| Art. 21 - technical and organisational measures (10 areas) | Vulnerability handling, access control, MFA, cryptography, supply chain - all measured across the SAP landscape |
| Art. 23 - incident notification | Early warning within 24 hours, incident notification within 72 hours, final report within 30 days to CSIRT NASK / CSIRT GOV |
| Art. 20 - management liability | Board members are personally liable for oversight of cybersecurity risk management |
| Art. 34 - administrative fines | Essential entities: up to EUR 10 million or 2% of annual turnover. Important entities: up to EUR 7 million or 1.4% of turnover |
What a regulator is likely to ask during an inspection sounds roughly like this:
“Your SAP ECC system contained the Visual Composer component with vulnerability CVE-2025-31324, CVSS score 10.0. The SAP note was published on 24 April 2025. A public exploit appeared on 28 April 2025. CISA added the vulnerability to KEV on 8 May 2025. Please provide documentation confirming when your organisation became aware of this vulnerability, what compensating controls were implemented before the patch was installed, and when the patch was deployed to the production environment.”
Without an audit trail - a log of decisions, alerts, action items and timestamps - there is no answer to that question. And no answer means a potential finding of a breach of obligations under Article 21 and - more importantly - personal liability for board members under Article 20.
It is worth highlighting one further aspect of the supply chain (Article 21(2)(d) NIS2). If SAP is serviced by an external provider, the regulator will expect that you - as an essential or important entity - have verified that provider’s maturity in vulnerability management. An SLA on uptime is not enough. What is needed is an SLA on response time to a CVE with a defined CVSS score.
3. How we approach this at SNOK - SecurityBridge plus a decision log for NIS2
SecurityBridge is a native SAP platform - the only one that simultaneously covers four areas relevant under NIS2:
Vulnerability management. The platform maps a specific SAP note to the specific SIDs in your landscape - and answers the question “does this patch even affect us”. Without SecurityBridge, that answer takes one Basis specialist 4-8 hours per month. With the platform: 5 minutes, an automatic timestamped report - in other words, a ready-made element of the audit trail documentation.
Threat detection. A SIEM operating at the SAP application layer - precisely where classic cybersecurity tools do not reach. It detects exploitation attempts in real time (including attempts to exploit CVE-2025-31324). It generates alerts that feed into the incident log - and serve as evidence of response for the purposes of Article 23 NIS2.
Virtual patching. The most important element from a real-world business perspective. When a vulnerability is critical but production must keep running and the service window is six weeks away, SecurityBridge can block the attack vector at the monitoring and gateway layer without waiting for the actual kernel patch. That is the difference between “we were vulnerable for six weeks” and “we were vulnerable for six hours, then closed off by a compensating control, then patched”.
Code security and patch management automation. Static analysis of in-house ABAP/Java code for vulnerabilities introduced by internal developers. This is relevant in the context of Article 21 NIS2 on software development security.
SNOK’s role as a SecurityBridge partner in Poland:
- platform implementation in the client’s landscape (typically 6-10 weeks)
- 24/7 monitoring through our Security Operations Centre
- monthly post-Patch Day analysis, with recommended actions within 24h of publication
- maintenance of a full audit trail in a format compatible with Article 23 NIS2 requirements
- a ready-made set of documents for the regulator in the event of an inspection
What we deliver in practice is a reduction of the response cycle from 45-90 days to 24-72 hours - fitting within the window enforced by NIS2.
What next
If your organisation is subject to NIS2 (or will be once the amended KSC Act enters into force) and runs critical processes on SAP, the recommended minimum is two actions over the next 30 days:
- Inventory the vulnerabilities in your current SAP landscape - in other words, answer the question “how many CVEs with a CVSS score of ≥ 9.0 do we currently have open in production”. Without that answer, it is impossible to determine whether the current posture complies with Article 21 NIS2.
- Assess audit trail readiness - whether, in the event of a regulatory inspection, you are able to document the response to a specific SAP note from a specific date.
At SNOK we offer a free SAP Security Health Check - one day of our consultant’s work in your environment, with a report ready within a week. The result is a map of vulnerabilities in the landscape, a risk assessment against NIS2, and a recommendation for next steps - with or without SecurityBridge, depending on scale.
This article does not replace a binding legal interpretation of the NIS2 directive or the amended KSC Act. The specific obligations applicable to your organisation as an essential or important entity require individual legal assessment.
Would you like to see this in practice or discuss implementation for your organisation? Get in touch - we will reply within 48 hours.