The IT director of a manufacturing company signs off on a SIEM deployment. Collectors pull logs from domain controllers, firewalls and application servers, correlation rules are live, the dashboard is green. A week later the board asks: “so are we NIS2 compliant now?”. The answer is: partly — and not in the part the supervisory authority will ask about first.
This text is not a guide to choosing a SIEM, nor a vendor list. One boundary interests us: where what the tool delivers on its own ends, and what only a staffed process delivers begins. That boundary is not a matter of opinion — it runs where Polish law shifts from describing a technical measure to naming a deadline, a recipient, and a person with a first name, a surname and a work phone number.
Is a SIEM alone enough to meet NIS2 requirements?
It is not enough, and deployment maturity is not the reason. A SIEM covers requirements describing the state of the information system — data collection, correlation, continuous monitoring. The Polish National Cybersecurity System Act places alongside them requirements describing how the organisation behaves over time: what must happen within 24 hours of detection, who must do it, and to whom it must be sent.
The difference is not academic. A company with a mature SIEM and no incident handling process satisfies one group of provisions and breaches another — the one hedged with deadlines in hours and a penalty on the head of the entity personally. Deploying a SIEM does count towards compliance, and below we show which provision it closes; it simply closes less than sales conversations suggest.
Which requirement of the Polish NSC Act does a SIEM actually cover?
A SIEM delivers the requirement to place the information system under continuous monitoring. The provision reads literally: an essential or important entity implements measures covering “the coverage of the information system used to provide the service by a continuous monitoring system” — Article 8(1)(2)(g) of the National Cybersecurity System Act as amended by the Act of 23 January 2026 (Journal of Laws 2026 item 252, in force since 3 April 2026).
That is not the only anchor point. The same article, in point 3, requires “the collection of information on cyber threats and vulnerabilities to incidents of the information system used to provide the service”, while Article 11(1)(2) requires the entity to give the competent CSIRT access to information on recorded incidents. Neither can be performed without a central event repository. A less obvious requirement follows: Article 8(1)(2)(h) mandates “policies and procedures for assessing the effectiveness of technical and organisational measures”, and SIEM data is the evidentiary material here — without it, the assessment rests on declarations.
Key takeaway: a SIEM closes three requirements of the Polish NSC Act — continuous monitoring, collection of threat information, and CSIRT access to recorded incidents. All three concern data. None concerns the decision made on that data.
What does a SIEM fail to cover, even though it looks as if it does?
A SIEM does not cover the incident management obligation. In the Act it takes a single line — Article 8(1)(4) lists “incident management” alongside the other elements of an information security management system — but unpacking that line takes four articles: 11, 12, 12a and 12b.
NIST states the crux of the problem: “Additional analysis is often needed to determine whether adverse cybersecurity events indicate that a cybersecurity incident has occurred” — NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025, Section 1.
That analysis does not come with the licence. A SIEM produces events and alerts; deciding whether an alert amounts to an incident, whether the incident is significant in the legal sense, and whether the reporting clock has started are three separate decisions, each requiring a person authorised to make it. We develop the staffing thread itself in our article on why a SOC is essential for KSC and NIS2 compliance.
Why is the 24-hour deadline a staffing requirement rather than a tooling one?
Because the clock starts at the moment of detection, not when somebody looks at the console. Article 11(1)(4) requires an early warning about a significant incident to be submitted “without undue delay, no later than within 24 hours from the moment of its detection, to the competent sectoral CSIRT”. Point 4a allows a further 48 hours for the full notification — 72 hours from detection in total.
The consequence is easy to overlook. An alert raised on Friday at 19:00 starts a deadline expiring on Saturday at 19:00. If console coverage runs eight hours a day, Monday to Friday, the deadline passes before anyone opens a case. The tool worked correctly, and the obligation was breached.
For some entities the mesh is tighter: within 24 hours of detection a trust service provider submits not an early warning but the full notification (Article 11(1a)). The final report reaches the sectoral CSIRT no later than one month from the day of notification (Article 11(1)(4c)), and where incident handling has not concluded by then, the entity submits a progress report (Article 12b(1)).
Where round-the-clock in-house staffing is out of reach, this part of the obligation can shift to a provider — that is what a 24/7 SOC service is for. It does not relieve the head of the entity of liability, but it closes the gap between detection and decision.
What must a notification contain that a SIEM will not generate?
The notification must contain data that is not in the logs. Under Article 12(1), an early warning includes “the first name and surname, work phone number and work email address of the person submitting the notification” and the same details for the person authorised to provide explanations. That is a requirement about a person on duty, not about a system.
The full notification goes further. Article 12(3) requires a description of the incident’s impact on service provision: the specific service, the number of users affected, the geographic scope of the area concerned, and the impact on services provided by other entities. A SIEM knows IP addresses, accounts and host names; translating those into a customer count and a geographic area takes a service register and a customer database — data that is not in the SIEM and should not be.
The final report adds the elements listed in Article 12a: a detailed description of the incident with the disruption and damage caused, the type of threat or the probable root cause, the risk-mitigation measures applied, and cross-border effects. Everything travels through the ICT system referred to in Article 46(1) (Article 11(2)) — a channel that needs an account and designated people set up in advance.
Practical card: before your first incident, check three things that will cost hours during the event: whether you have an account in the Article 46(1) system, which sectoral CSIRT is competent for you, and whether you can state within 24 hours how many users a specific service outage affected.
Who sets the threshold above which an incident is “significant”?
Neither the organisation nor the SIEM vendor sets the threshold. Under Article 11(4), thresholds for treating an incident as significant are set by the Council of Ministers by regulation, by type of event across the sectors and subsectors listed in Annexes 1 and 2 to the Act, referring them to the number of users affected, the duration of the incident’s impact, the geographic scope, or other factors specific to the sector.
There is an exception of wide practical reach. The provision excludes entities for which the European Commission has already set thresholds in an act adopted under Article 23(11) of Directive 2022/2555 — among others cloud computing providers, data centre providers, content delivery networks and managed service providers. For them the source of thresholds is Commission Implementing Regulation (EU) 2024/2690, to which Article 8b(1) of the Act refers.
The consequence for configuration is direct. The severity fields in a SIEM — critical, high, medium — come from the vendor’s risk model and bear no relation to the statutory threshold. Until you write the values from the act applicable to your sector into your procedure, you classify incidents in a technically correct and practically useless way as far as the reporting obligation goes. We described the same mechanism for a different instrument in our article on whether ISO 27001 is enough for NIS2.
What does NIST say about the place of SIEM in incident handling?
NIST places SIEM in a narrow slice of incident handling, and this can be counted. Publication SP 800-61r3 of April 2025 takes the form of a CSF 2.0 Community Profile and lists 106 framework elements — subcategories assigned to six Functions: Govern, Identify, Protect, Detect, Respond and Recover. SIEM appears in the recommendations for three of them: DE.AE-02, DE.AE-03 and DE.AE-04.
All three sit in one category — adverse event analysis within the Detect Function. There NIST recommends SIEM or SOAR for continuous log monitoring (DE.AE-02), for correlating information from multiple sources (DE.AE-03), and for estimating the impact and scope of an event (DE.AE-04). Beyond those three points, a SIEM-class tool does not appear in the profile at all.
You can check the numbers in five minutes: download the document from the NIST site and count the occurrences.
Key takeaway: in the NIST model, SIEM accounts for three subcategories out of one hundred and six, all within the Detect Function. The remaining one hundred and three describe decisions, roles, procedures and communication — and NIS2 compliance is settled mainly in the Govern and Respond Functions, where no SIEM-class tool is named.
Who is liable when the notification does not go out on time?
The head of the entity is liable, personally. Article 8c(1) assigns the head of an essential or important entity responsibility for obligations including those in Article 8 and Articles 9 to 12b — covering both the information security management system and the entire reporting block. Paragraph 3 adds that liability persists even where the obligations have been entrusted to another person with their consent.
The sanction is set out separately. Article 73a(1)(9) provides for a financial penalty on a head who fails to perform at least one obligation under Article 11, while point 11 separately penalises a final report submitted without the elements required by Article 12a. The penalty may not exceed 300% of the head’s remuneration, calculated on the basis used for holiday pay equivalent (Article 73a(4)).
The penalty on the entity runs in parallel: for an essential entity, up to EUR 10,000,000 or 2% of turnover for the preceding financial year, whichever is higher, and no less than PLN 20,000 (Article 73(3)). For an important entity — EUR 7,000,000 or 1.4% of turnover, no less than PLN 15,000 (Article 73(4)). A contract with a SIEM vendor transfers none of these.
How do you check whether your SIEM is wired into the obligation or only into the network?
Five questions will tell you, and answering them takes one afternoon. Each concerns the junction between the tool and the legal obligation — which is why the console holds no answers.
First: is there a correlation rule whose firing means “probable significant incident within the meaning of the Act”, rather than merely high technical priority? Second: does anyone have a duty to respond to it in under 24 hours, at night and on Saturdays included, and is that duty written into a contract or a job description? Third: is there a procedure turning an alert into a notification that carries a user count and a geographic scope?
Fourth: have the people performing tasks under Articles 8 and 11 produced the National Criminal Register certificate of no convictions for offences against the protection of information, required by Article 8f(1) before admission to those tasks? Fifth: does log retention let you reconstruct the course of the incident for the final report? Three answers of “no” mean your SIEM works correctly as a monitoring system and is not yet wired into the statutory obligation.
What exactly remains to be added after a SIEM is deployed?
Everything that happens after the alert remains. The table sets the requirement of the National Cybersecurity System Act against what a typical SIEM deployment delivers without extra work, and against what has to be added separately.
| NSC Act requirement | What SIEM delivers out of the box | What remains to be added |
|---|---|---|
| Continuous monitoring (Art. 8(1)(2)(g)) | Collection and correlation of events from covered sources | Monitoring coverage of every system in the service process |
| Cyber threat information (Art. 8(1)(3)) | Enrichment of events with threat data | Feed subscriptions and review of their fit to the sector |
| Incident management (Art. 8(1)(4)) | Alert queue and statuses | Runbooks, decision roles, escalation, out-of-hours duty |
| Incident qualification (Art. 11(4)) | Vendor priorities (critical/high) | Thresholds from the sector’s regulation, written into the procedure |
| Early warning in 24 h (Art. 11(1)(4)) | Detection timestamp | Staff able to respond in time, an Art. 46(1) account, the competent CSIRT |
| Early warning content (Art. 12(1)) | Technical event data | Named details of the person notifying and the one giving explanations |
| Notification content in 72 h (Art. 12(3)) | Technical course and remedial actions | Number of users affected, geographic scope, impact on other entities |
| Final report (Art. 12a) | Evidentiary material from logs | Root cause analysis, damage description, cross-border effects |
| Informing users (Art. 11(2b)) | — | Decision criterion and ready-made messages in the crisis plan |
| Clean record of task performers (Art. 8f(1)) | — | Procedure for obtaining the register certificate before admission |
The middle column runs out everywhere the provision stops describing a system and starts describing somebody’s action within a set time.
Where should you start if you have a SIEM and no certainty about NIS2?
Start by establishing your own status, not by reviewing the configuration. Check whether you are an essential or an important entity and which annex to the Act covers you — that determines whether you take thresholds from the Council of Ministers regulation or from Commission Implementing Regulation (EU) 2024/2690.
The second step is the clock: establish who responds to an alert qualifying as a probable significant incident, and in what mode, then compare that against the 24-hour deadline counted from detection. The third is the channel — an account in the Article 46(1) system, an identified sectoral CSIRT, and a notification template with the fields from Article 12.
To see the whole gap at once, rather than discovering it incident by incident, set the obligations of the NSC Act against the actual state of play — that is what support with National Cybersecurity System Act compliance covers. We described the amendment’s context in our article on the amendment to the NSC Act and NIS2 requirements, and the difference between a tool and a team in our comparison of SOC, SIEM and SOAR.
Key takeaway: a SIEM is a necessary condition and genuinely shortens the road, but NIS2 compliance is settled where no console reaches — at the statutory threshold, the clock counted from detection, the name of the person on duty, and the signature of the head of the entity.
Sources:
- Act of 5 July 2018 on the National Cybersecurity System, as amended by the Act of 23 January 2026 (Journal of Laws 2026 item 252, in force since 3 April 2026) — Articles 8, 8b, 8c, 8f, 11, 12, 12a, 12b, 46(1), 73 and 73a.
- Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2), OJ L 333, 27.12.2022, p. 80 — Article 21(5), Article 23(11).
- Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, OJ L 2024/2690, 18.10.2024.
- NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, April 2025.
