Poland’s amendment to the National Cybersecurity System Act has been in force since 3 April 2026. The application for entry into the register of essential and important entities must be filed by 3 October 2026 - roughly ten weeks from now. Registration is the easy part, because it is a form in a government system. The hard part never shows up on that form: the ability to detect an incident, and to prove later that detection actually happened.
In SAP, that ability usually does not exist.
The short version:
1/ Entry in the KSC register - deadline 3 October 2026, applications accepted since 7 May via wykaz-ksc.gov.pl,
2/ Reporting a significant incident - early warning within 24 hours and full notification within 72 hours, both counted from detection, plus a final report within one month of the notification,
3/ First audit of essential entities - by 3 April 2028, based on evidence collected from 2026 onwards,
4/ Multi-factor authentication - required explicitly by Article 21(2)(j) of NIS2, and rarely implemented inside SAP.
The clock is already running
The Act of 23 January 2026 amending the National Cybersecurity System Act was published on 2 March 2026 (Journal of Laws 2026, item 252) and entered into force on 3 April 2026. This is how Poland transposes the NIS2 Directive.
| Date | What happens |
|---|---|
| 3.04.2026 | The act applies. Incident handling and reporting duties are live from day one |
| 7.05.2026 | The Ministry of Digital Affairs opens self-registration in the register |
| 3.10.2026 | Deadline for filing the application for entry in the register of essential and important entities |
| 3.04.2028 | Deadline for the first security audit of essential entities |
Two numbers usually end the boardroom discussion. An essential entity faces fines of up to EUR 10 million or 2% of turnover, an important entity up to EUR 7 million or 1.4% - in both cases whichever amount is higher. Where a breach threatens state security, public order or human health, or risks serious financial damage, the act provides for an extraordinary penalty of up to PLN 100 million, and the head of a private entity is personally liable for an amount of up to 300% of their remuneration.
There is also an amendment that quietly lowers the guard: the imposition of ordinary administrative fines has been deferred by roughly two years from entry into force. The deferral does not cover everything - the extraordinary penalty and some supervisory measures remain available from the start. It sounds like breathing room. In practice it is the worse scenario, because the 2028 audit will not ask about the state of affairs in 2028. It will ask for evidence from the period that is running now.
A morning that appears in no procedure
Picture a Basis administrator on a Wednesday at 7:40. Three production systems, yesterday’s transport waiting to be imported, forty unread messages. None of them says that overnight somebody tried to log in to a technical account twenty times from an external address until one password worked. Nobody sends that message, because nothing generates it.
The Security Audit Log is switched on - that is how it looks in most of the projects we run. Nobody reads it, no thresholds are set, and entries roll over after a few days. The SIEM holds firewall, endpoint and Active Directory logs, while SAP monitoring stops at availability: the system responds, so all is well.
That is where the regulatory trap closes. The 24-hour clock for the early warning starts when the incident is detected. If nothing can detect it, the clock formally never starts - except that in proceedings a supervisory authority will most likely read that not as an absence of incidents, but as an absence of technical measures appropriate to the risk. In such proceedings, the difference between “we had no incident” and “we do not know whether we had an incident” is the whole case.
Six steps that show where you stand
Not about compliance in general. About SAP specifically. These are the same six steps you walk through in our free assessment, SNOK KSC-CHECK - five areas of five questions each, plus the step where you say where to send the report.
Step 1. Event visibility. Whether the Security Audit Log, table change logs and RFC logs are recorded at all, how long you keep them, and whether any of it reaches the SIEM. With no record there is nothing to detect an incident with, and the clock starts at detection.
Step 2. Detection and response. Who receives an alert from SAP and after how many minutes, who is on call outside working hours, who signs the 72-hour notification, and whether the procedure has ever been exercised.
Step 3. Vulnerabilities and patching. How many days pass between SAP Security Patch Day and HotNews notes going live in production. If nobody knows the number, that is the answer.
Step 4. Identity and access. Whether production access requires a second factor, when service account passwords were last changed, and how many users hold near-full authorisations. NIS2 names multi-factor authentication explicitly in Article 21(2)(j), and in Polish SAP landscapes a second factor is still rare.
Step 5. Compliance and evidence. Whether your entity status is formally established, whether the register application was filed, what belongs to SAP and what to you under RISE with SAP, and what exactly you will show an auditor in 2028 as evidence of detection during 2026 and 2027. A screenshot is not evidence.
Step 6. Result and report. A score across the five areas on screen immediately, and a PDF report by email with the three largest gaps plus a 30-day and a 12-month plan.
That is 25 questions and 8 to 12 minutes in total. The questions are written for an IT director rather than a Basis administrator, and “I don’t know” is a permitted answer scored at zero - not knowing your own system is itself a result. It is a self-assessment, not an audit or a confirmation of compliance, but it shows where to look for gaps.
How the gap gets closed
Compliance is not a product, so no tool will “take care of it”. You need procedures, a process owner, on-call rotation and exercises. What a tool does own is the part you cannot do by hand: watching the system continuously and recording what it sees.
The SecurityBridge platform runs as a certified add-on inside ABAP, with no external servers and no additional operating-system agents. Four areas matter for KSC duties:
Real-time detection. Event monitoring and anomaly detection in the SAP application layer, where firewalls and antivirus see nothing. The platform understands SAP specifics that generic tooling misses: the Security Audit Log, bulk table reads through SE16, changes to ABAP objects outside the authorised path, privilege escalation through SU01 and PFCG, unusual RFC traffic between systems. Those events are what make a 24-hour early warning possible, because they describe user and system behaviour rather than the mere fact that the system responds.
SIEM and SOAR integration. SAP events land in the same place where the SOC watches the rest of the estate - in practice most often Microsoft Sentinel, Splunk, IBM QRadar or ArcSight. Without it SAP stays an island and incidents surface with a delay measured in weeks. The SOAR layer lets part of the response belong to a scenario rather than to whoever is on duty: locking an account, escalating to the SOC, collecting the change trail. For the 24-hour deadline that counts twice over, because no time goes into working out who is supposed to act.
Vulnerability and note management. An inventory of what is missing after each Patch Day, with an assessment of what actually applies to your configuration - not every note with a high CVSS matters in a system where the component in question is not active. Alongside notes, configuration and custom code are checked too, the two sources of exposure the vendor will never patch for you. This connects directly to the monthly SAP patch cycle, and its by-product answers the question from step three: how many days actually pass between a note being published and reaching production.
Compliance reporting. Controls mapped to ISO 27000, CIS and NIS2 - orderly material to put in front of an auditor, instead of reconstructing history a week before the inspection. Mapping alone is not yet proof of compliance; the proof is the records showing the controls actually worked. The value of this area grows the closer 2028 gets: an auditor will not ask whether you have monitoring today, but whether you can show what you saw during 2026 and 2027 and what you did about it. A report generated on a schedule is far stronger evidence than a screenshot of a console, whose date and completeness say nothing.
Then there is the identity layer. TrustBroker joined the SecurityBridge portfolio with the acquisition of the UK company CyberSafe, announced in July 2025. It provides secure single sign-on and multi-factor authentication enforced conditionally: at logon, or only when a user attempts a high-risk operation (step-up). It works with what companies already run - Microsoft Entra MFA, Okta, PingID, Duo, RSA SecurID, TOTP and HOTP apps. Following integration with the platform, the decision to demand a second factor can take threat signals into account, such as anomalous logon behaviour or an unrecognised device.
That answers the second-factor question from step four, in a form you can deploy without replacing your whole identity architecture. Conditional enforcement matters in practice: a second factor on every logon to a system that warehouse staff enter a dozen times a day ends in workarounds or open revolt, whereas a second factor before changing a supplier’s bank details draws no objection from anyone.
It is worth saying what this layer is not. The platform does not replace authorisation management or segregation of duties - it shows that somebody used broad privileges, but it does not decide whether they should hold them. Nor does it replace a SOC: it delivers events, not the person who looks at them at two in the morning. The sensible order is therefore to name the process owner and the alert recipient first, and switch the tooling on afterwards - the reverse order produces a console nobody opens.
What such a deployment will not do
Three things worth knowing in advance, because otherwise disappointment arrives after the contract is signed.
First, the platform will not write your incident reporting procedure or nominate the person on call. If nobody answers the phone at 2 a.m., the alert stays in the console and the 24-hour deadline passes exactly as it would without any monitoring.
Second, the first weeks after enabling anomaly detection mean false positives. Thresholds have to be tuned to your processes, and that is human work, not automation. Usually counted in weeks rather than days.
Third, for a small landscape with no essential-entity status, the full platform can be more than the situation requires. It is then more sensible to tidy up what you already have: enable the right event classes, push logs to the SIEM, review service accounts. We say this to clients who arrive ready to buy a licence too - sequence matters, and hardening SAP is a process, not a project.
“The biggest problem is not the vulnerabilities we learn about on Patch Day. The biggest problem is systems where nobody has checked for two years who actually logs in and what they do. The act will not change that, but the 2028 audit will expose it.”
Jarosław Zdanowski, Partner responsible for SAP cybersecurity and SAP Basis at SNOK
A ten-week plan
Three things can realistically be done before 3 October, and they are enough to move out of the “we do not know” position.
Start by establishing status: essential entity, important entity, or neither. It depends on the sector listed in the annexes to the act and on size, and for managed service providers the thresholds are far lower than for other entities. Without that answer, every following step is guesswork.
Next, take stock of what is visible in SAP today: which event classes are recorded, for how long, who reads them, what reaches the SOC. The output is a list of gaps, not a presentation.
Finally, decide on the technical layer and on a process owner with a name, not a team label. The application to the register is filed in a government system and takes hours. Detection capability takes months to build, which makes registration the last step, not the first.
How we help
SNOK holds SecurityBridge Poland Premier Partner status and works in SAP across Basis, security and compliance at once. In practice that means the readiness review runs on your landscape rather than on slides: the six steps from this article walked through on real systems, the evidence collected, and a prioritised list of gaps with estimated effort.
The simplest starting point is the SNOK KSC-CHECK assessment - you get the result immediately, without talking to anyone. If you then want to walk it through on real systems, get in touch. The conversation commits you to nothing.
Frequently asked questions
When is the KSC register application due? By 3 October 2026 for entities that met the criteria on the day the act entered into force. Applications have been accepted since 7 May 2026 in the wykaz-ksc.gov.pl system. Entities that meet the criteria later have six months from that point.
How long is there to report a significant incident? Early warning within 24 hours of detection, full notification within 72 hours, final report within one month. Where a sectoral CSIRT exists, the entity reports to it and that CSIRT forwards the case to the national CSIRT within 8 hours.
Does the KSC Act require MFA? The NIS2 Directive lists multi-factor or continuous authentication among risk management measures (Article 21(2)(j)), and the Polish act obliges entities to apply measures appropriate to the risk. For access to production SAP systems holding financial and personal data, a second factor is hard to argue away.
Does RISE with SAP fall under our obligations? As a rule yes, provided the duties apply to your organisation as a key or important entity. Responsibility is shared and does not transfer wholesale to the provider. The scope of SAP-side monitoring follows the contract and typically excludes the application layer and authorisation abuse - precisely what an audit asks about.
Fines are deferred by two years, so why the hurry? The deferral covers ordinary administrative fines, not obligations, and it does not cover the extraordinary penalty or some supervisory measures. Incident reporting has applied since 3 April 2026, and the first audit of essential entities is due by 3 April 2028, assessing evidence from the whole transition period.
Is the register entry itself enough? No. The entry identifies the entity in a government system. The substantive duties - risk management, incident handling, supply chain review, management oversight and training - apply regardless of the entry.
Sources
- Act of 23 January 2026 amending the National Cybersecurity System Act, Journal of Laws 2026 item 252 - ISAP
- Register of essential and important entities - wykaz-ksc.gov.pl, Ministry of Digital Affairs announcement
- Directive (EU) 2022/2555 (NIS2), Article 21(2) - EUR-Lex
- Registration procedure, deadlines and sanctions - Traple Konarski Podrecki & Partners
- CyberSafe acquisition and TrustBroker products - SecurityBridge