NIS-2 — Incident Reporting in Practice. 24h Early Warning, 72h, 1 Month

Three Reporting Phases, One Time Window That Starts at Detection

Art. 23 of Directive 2022/2555 (NIS-2) requires essential and important entities to report significant cybersecurity incidents in three phases — with specific deadlines counted from the moment the entity became aware of the incident. These deadlines are non-negotiable, do not move for weekends, and do not pause during an internal investigation.

For a Polish SME within the scope of NIS-2, this means having an operational playbook — ready to activate within a few hours of the first alert signal. This article breaks down Art. 23 into concrete steps: their content, recipients in the Polish national system, and typical pitfalls that organisations encounter after their first incidents.

The directive entered into force on 16 January 2023 with a national transposition deadline of 17 October 2024. In Poland implementation proceeds through an amendment to the National Cybersecurity System Act (KSC) — at the time of publication the legislation was being processed in the Sejm and had not yet been finally signed, but the directive’s obligations are directly applicable against the Member State.

Art. 23 — Complete Structure of the Obligation

Art. 23(1) imposes on essential and important entities an obligation to notify, without undue delay, the competent CSIRT or competent authority of any significant incident.

Para. 2 adds an obligation to notify service recipients of the incident if it may adversely affect the provision of those services — as well as the measures or actions recipients can take in response.

Para. 3 defines when an incident is “significant”:

it caused or was capable of causing serious operational disruption or financial losses for the entity;
it affected or was capable of affecting other natural or legal persons by causing considerable material or non-material damage.

Para. 4 introduces three reporting phases — early warning within 24 hours, incident notification within 72 hours, and a final report within 1 month.

Phase 1 — Early Warning Within 24 Hours

Art. 23(4)(a) requires an early warning without undue delay — and in any event no later than 24 hours after the entity became aware of the significant incident.

The content of the early warning is deliberately minimal — because at this stage the entity rarely has complete information. It must indicate:

whether there is a suspicion that the incident is the result of unlawful or malicious action;
whether the incident may have a cross-border impact.

The recipient in Poland is the competent CSIRT at the national or sectoral level — in practice CSIRT NASK for most SMEs outside the financial, energy, and healthcare sectors (where dedicated sectoral CSIRTs operate).

Importantly — the time window starts from the moment the entity became aware, not from the moment the incident occurred. Detection two weeks after the actual breach does not extend the window to 14 days and 24 hours — the window starts at the moment of confirmed detection.

Phase 2 — Incident Notification Within 72 Hours

Art. 23(4)(b): within 72 hours of the moment the entity became aware of the incident — a detailed incident notification.

Content of the 72-hour notification includes:

an update of the information from the early warning;
an initial assessment of the significant incident — including its severity and impact;
indicators of compromise (IoCs), where available;
measures taken and planned remediation actions.

Recipient — the same CSIRT to which the early warning was sent. Many national CSIRTs require notification through a dedicated portal (in Poland — the CSIRT NASK portal with a form).

If the incident has not been confirmed as significant by this point — e.g. it turns out the initial diagnosis was a false alarm — the CSIRT must be informed of this update. There is no informal withdrawal.

Phase 3 — Final Report Within 1 Month

Art. 23(4)(c): no later than 1 month after the Phase 2 incident notification — a final report.

Content of the final report:

a detailed description of the incident, including its severity and impact;
the type of threat or cause that likely triggered the incident;
mitigation measures applied and being implemented;
where applicable — the cross-border impact of the incident.

If the incident is still ongoing at the time of the final report, Art. 23(4)(d) requires a progress report and a final report only after full resolution — within one month of that point.

Service Recipient Notification — Art. 23(2)

A separate obligation, independent of reporting to the CSIRT — notification of service recipients. Required when the incident may adversely affect the provision of services to those recipients.

In practice: for B2B SaaS SMEs this means notifying corporate clients by email or through a status page — with a description of the incident, its impact on their service, and measures they themselves can take (e.g. password changes, API key rotation).

The boundary between “may have an impact” and “has no impact” is often unclear in the first hours. The directive’s direction is unambiguous — when in doubt, notify rather than stay silent.

Recipients in the Polish National System

The CSIRT landscape in Poland consists of:

CSIRT NASK — the national CSIRT for most SMEs and non-sectoral public administration;
CSIRT GOV — government administration;
CSIRT MON — the defence sector;
Sectoral CSIRTs — designated by the relevant sectoral authorities (KNF for finance, the Ministry of Health for healthcare, the Ministry of Climate and Environment for energy, the Ministry of Infrastructure for transport).

For SMEs in the ICT sector, e-commerce, and B2B SaaS without sectoral affiliations — the first recipient is CSIRT NASK. Contact numbers and reporting procedures should be in your playbook before an incident happens, not after.

Operational Playbook — Five Steps

Step 1: Detection. An alert from SIEM, EDR, IDS, security log, or a report from an employee or client. Every alert receives a preliminary classification — relevant or irrelevant — with a timestamp recorded in the ticket system.

Step 2: Triage within the first hour. The security team assesses whether this is a significant incident within the meaning of Art. 23(3). Criteria: how many services are affected, how much data may have been exposed, how many users, what is the amount of financial loss, what is the cross-border impact.

Step 3: Classification and reporting decision. Following triage — a formal decision: to report or not. The decision is made by the CISO or the person responsible for security. The decision is documented with reasoning — because in the event of a subsequent supervisory authority inspection, you need to show why something was or was not reported.

Step 4: Notification — early warning within 24h. Sending the early warning to the competent CSIRT — with minimal content. Simultaneously initiating the internal investigation procedure, system isolation, and log preservation for forensic purposes.

Step 5: Post-mortem and final report. After stabilisation — a full post-mortem with root cause analysis, lessons learned, and a map of gaps in the current security stack. From this material, the final report to the CSIRT is produced, along with an internal playbook update.

What to Build Pre-Emptively

Everything that can be built before an incident is cheaper than trying to build it during one. Operational minimum for SMEs:

An incident response team with defined roles. Who is the incident commander, who communicates with clients, who with the CSIRT, who documents. Names, not job titles — because “the CTO” at 2am on a Wednesday may be unreachable.
Playbooks per scenario. Ransomware, data breach with exfiltration, DDoS, supply-chain attack, privileged account compromise. Each with a separate list of first steps, contacts, and communication templates.
CSIRT contacts pre-loaded. CSIRT NASK emergency number, sectoral CSIRT (if applicable), contact for a cyber-specialist lawyer. In paper copy, because your VPN may be blocked by the incident itself.
Logs with proportionate retention. Without logs, the final report cannot be written. Minimum: six months for application logs, twelve months for critical systems, with immutable storage (write-once) for security logs.

QA10 — Where We Test This

In the AiP Audit we verify the client’s playbook readiness under Art. 23 NIS-2 — including a stopwatch test (can the team make the early warning within 24h under a realistic scenario?) and completeness of the logging stack for the final report.