Let’s talk
Wondering how this plays out in your organisation? Get in touch — I answer personally.
Short answer
A significant incident report is not a single document. The Polish KSC Act (Act on the National Cybersecurity System) lists five submissions of increasing detail (Article 11(2)). The early warning is filed without undue delay, within 24 hours of detection of the significant incident at the latest. Among other things it contains the details of the entity, the reporting person and the person giving explanations, as well as the moments of occurrence and detection. The incident notification is filed without undue delay, within 72 hours of detection at the latest. It describes the impact on the service, the causes and course, and the preventive and remedial measures. A trust service provider notifies a significant incident without undue delay, within 24 hours of detection at the latest (Article 11(1a)). An interim report is filed only at the CSIRT’s request. The final report is due within one month of the incident notification and describes the incident, its cause, risk-mitigating measures and cross-border effects. If handling has not ended by that deadline, the entity files a progress report and the final report within one month of completing the handling (Article 12b). An important entity that is a public entity files only the incident notification (Article 12c). The sequence does not apply to the banking and financial market infrastructure sector (Article 8i(1)). All submissions go through the S46 system. The addressee is CSIRT MON, CSIRT NASK or CSIRT GOV until the announcement of the sectoral CSIRT’s operational capability, unless the sectoral team was established before 2025 (Article 44 of the amending act). The entity passes on the information known to it at the time of reporting and supplements it while handling the incident, so the lack of complete data is not a reason to wait.
Why this question arises at all
In organisations’ procedures “reporting to the CSIRT” usually appears as one action with one deadline. The Act describes four separate obligations (Article 11(1)(4)–(4c)). A conditional progress report comes on top of them (Article 12b). Three submissions have a statutory list of required information (Articles 12 and 12a). The first two deadlines run from detection of the significant incident, and the final report deadline runs from the incident notification. The interim report is filed at the CSIRT’s request. Each of the four obligations is also separately covered by a provision on a financial penalty (Article 73(1)(6)–(9)). Financial penalties under Article 73(1) and Article 73a may first be imposed after 3 April 2028 (Article 35 of the amending act). The deferral does not cover the penalty under Article 73(5) for an infringement causing a serious threat. Nor does it change the reporting deadlines.
Remember
An organisation that has sent an early warning and considered the matter closed still has the incident notification and the final report ahead of it. An interim report is added at the CSIRT’s request.
The second source of doubt is the addressee. The Act directs all submissions to the competent sectoral CSIRT. Sectoral teams are only being set up, so outside sectors with a team established before 2025 the addressee today is a national-level CSIRT. The third source is the thresholds. The regulation that determines when an incident is significant dates from 2018 and covers six sectors in the pre-amendment layout. For some digital entities and for trust service providers the thresholds are set by Commission Implementing Regulation (EU) 2024/2690. Other organisations have no threshold in implementing provisions to refer to today.
The sequence of organisational actions in the first 24 hours after detection is described in What to do after detecting an incident?
What has to be established before a decision
Whether the event is a significant incident and from when the clock runs
A significant incident report is required only where the event meets the statutory definition. The Act defines it by its effect (Article 2(7)). It is an incident that causes or may cause a serious deterioration in the quality or an interruption of the continuity of a service, financial losses to the entity or serious harm to other persons. The classification is made by the entity itself on the basis of the thresholds for recognising an incident as significant (Article 11(1)(3)). Entities that met the criteria for an essential or important entity on 3 April 2026 have until 3 April 2027 to implement the obligations under Chapter 3 of the Act (Article 33(1) of the amending act). Those obligations include notification of significant incidents. An entity that meets the criteria later has 12 months from the day it meets them to implement those obligations (Article 16 of the Act). For former operators of essential services, the period for moving to the new rules on notifying significant incidents ended on 3 October 2026 (Article 33(4) of the amending act).
The first difficulty concerns the thresholds. The thresholds are set by the Council of Ministers in a regulation (Article 11(4)). The regulation of 31 October 2018, issued under the previous directive, still applies. It describes thresholds for six sectors and uses the notion of an essential service. Under the transitional provisions of the amendment it remains in force until 3 April 2027 at the latest. Entities for which the European Commission has set thresholds are excluded from the national delegation (Article 11(4)). For the digital entities and trust service providers listed in Article 1 of Commission Implementing Regulation (EU) 2024/2690 the thresholds follow directly from that act. An organisation outside the scope of both the 2018 regulation and Regulation 2024/2690 has no threshold in implementing provisions today. It assesses the event against the statutory definition of a significant incident. In that situation I recommend recording the organisation’s own classification criteria in the procedure, with reasons, because they will be the subject of the authority’s questions after an event.
The second difficulty concerns the start of the deadline. Both initial deadlines are counted from the moment the significant incident is detected, not from its occurrence and not from the end of the analysis. The Act does not define detection. The early warning, however, requires both the moment of occurrence and the moment of detection to be stated (Article 12(1)(4)). The organisation therefore has to be able to name the hour of detection, and the procedure should set out how that hour is recorded. According to the Minister of Digital Affairs, detection is the moment at which the entity can establish that the event is an incident (Q&A 6.5). It is worth counting both deadlines from that moment, not from the later classification of the incident as significant. The security team’s event log is evidence, not a formality.
Who receives the significant incident report
The Act names the competent sectoral CSIRT as the addressee (Article 11(1)(4)–(4c)) and the S46 ICT system as the channel (Article 11(2)). The transitional provisions of the amendment change that picture for a transition period. Until the announcement that a sectoral CSIRT has reached operational capability, entities report significant incidents to the competent CSIRT MON, CSIRT NASK or CSIRT GOV (Article 44(1) of the amending act). Reporting to the sectoral CSIRT starts on the day after the announcement is published (Article 44(2) of the amending act). The transitional rule does not apply to sectors in which a sectoral cybersecurity team was established before 2025 (Article 44(3) of the amending act). Such a team became a sectoral CSIRT on 3 April 2026, and notifications from that sector go to it (Article 46 of the amending act).
The procedure should therefore name the addressee as of today, and the person responsible for contact with the cybersecurity system should follow the announcements of the authority competent for the sector. The authority publishes the announcement of operational capability in its official journal (Article 42(2) of the amending act). The information also appears on the websites of the office serving the Government Plenipotentiary for Cybersecurity and of the national-level CSIRTs, and it is delivered through S46 (Article 42(3) of the amending act). According to the Minister of Digital Affairs, a notification filed in S46 reaches the competent CSIRT, and the teams forward it to one another according to competence (Q&A 6.13 and 7.2).
A separate matter is access to the channel. Use of S46 begins after entry in the register of essential and important entities (Article 9(1)(4)). According to the Minister of Digital Affairs, access to S46 is granted to an entity entered in the register that has completed the full set of data in it, and an account from before 3 April 2026 is retained (Q&A 2.15). Entities that met the criteria on 3 April 2026 have to start using the system by 3 April 2027 at the latest (Article 46(4)). The reporting obligation, however, does not depend on the entry or on an account. Where submission through S46 is not possible, the method of reporting is set by the competent CSIRT (Article 31(1)). For entities that met the criteria on 3 April 2026 the deadline for applying for entry passed on 3 October 2026. An organisation without an entry should apply without delay.
Submissions to the CSIRT — deadline, starting point and content
All submissions go through S46 (Article 11(2)). Failure to use the system where it is required is separately covered by a penalty provision (Article 73(1)(13)). An important entity that is a public entity files only the incident notification under Article 11(1)(4a), without the early warning and the reports (Article 12c). A trust service provider notifies a significant incident within 24 hours of detection (Article 11(1a)). The statutory provisions on notifying significant incidents do not apply to entities in the banking and financial market infrastructure sector, subject to the exceptions in Article 8i(1) and (2). They include the duty to cooperate with the CSIRT (Article 11(1)(5)). According to the Minister of Digital Affairs, the DORA Regulation takes precedence in that sector (Q&A 14.2).
| Submission | Deadline | Content required by the Act | Legal basis |
|---|---|---|---|
| Early warning | 24 hours from detection of the significant incident | details of the entity, the reporting person and the person authorised to give explanations, moment of occurrence and detection and duration, assessment of unlawful action (where possible), impact on other EU Member States | Article 11(1)(4), Article 12(1) |
| Incident notification | 72 hours from detection of the significant incident | impact on the service (service, number of users, geographic reach, impact on other entities), causes and course and probable effects, preventive measures, remedial measures, update of the early warning data | Article 11(1)(4a), Article 12(3) |
| Interim report | at the CSIRT’s request | the Act does not specify the content | Article 11(1)(4b) |
| Final report | one month from the day of the incident notification (72 h) | detailed description of the incident with disruptions and damage, type of threat or probable cause, risk-mitigating measures, cross-border effects | Article 11(1)(4c), Article 12a |
A fifth submission arises in one situation. If the handling of the incident has not been completed by the deadline for the final report, the entity submits a progress report. It then files the final report within one month of completing the handling (Article 12b).
Early warning — what can be prepared before an incident
The list in Article 12(1) has six items. Three of them do not depend on the event. These are the entity’s details with its registration number and address, the details of the person making the report and the details of the person authorised to give explanations. Those fields can be filled in before an incident. The Act distinguishes the person reporting from the person giving explanations. According to the Minister of Digital Affairs, it may be the same person (Q&A 6.11). It is still worth having a stand-in, meaning a second person with access to the system and knowledge of the matter. Designating contact persons for the entities of the national cybersecurity system is a separate obligation. As a rule at least two people are required, and in a micro or small enterprise and in an important entity that is a public entity at least one (Article 9(1)–(3)).
The remaining three items require findings. The moment of occurrence and detection and the duration come from the event log. The assessment of whether the incident was caused by unlawful action or in bad faith is required only where such an assessment is possible, so the Act does not demand guesswork in the first 24 hours. The indication of whether the incident affects other Member States is a field often skipped, yet material for organisations with customers or infrastructure outside Poland.
The early warning may include a request for guidance on measures to limit the effects or for additional technical support (Article 12(2)). The CSIRT then has 24 hours to provide guidance or support. Where the incident bears the marks of a criminal offence, it also provides information on how to notify law enforcement. This is the only deadline in the sequence that the Act sets for the CSIRT towards the reporting entity. It is worth writing this option into the procedure, because the early warning is also a channel for obtaining help.
The 72-hour incident notification — impact first
The incident notification under Article 12(3) is built around the service. The first item is a description of the incident’s impact on the provision of the service, with four elements. It has to state which service, how many users, what geographic reach and what impact on services of other entities. Only the second item concerns the causes, course and probable effects for the systems or services. The description of the course is required as well. According to the Minister of Digital Affairs, it should for example state indicators of compromise (Q&A 6.14).
The third and fourth items are preventive and remedial measures. The Act does not define the difference between them. I adopt a practical distinction. Preventive measures limit the spread of the effects, for example cutting off a network segment or blocking accounts. Remedial measures restore the service, for example recovery from a backup or replacement of a component. The fifth item is an update of the early warning information, if it has changed. The incident notification may also contain other material information on the course of the incident or the actions taken (Article 12(4)).
The entity passes on the information known to it at the time of making the incident notification and supplements it while handling the incident (Article 12(5)). Incomplete knowledge after 72 hours is therefore not a reason to delay the notification. It is a reason to indicate in the notification which information is preliminary. The CSIRT may in any event itself ask for the early warning or the incident notification to be supplemented (Article 12(7)).
Legally protected secrets in the report
A significant incident report often contains information covered by trade secrecy or another legally protected secret. This concerns system architecture, customer data and the terms of supplier contracts. The Act resolves that conflict in favour of the report. The entity passes on such information to the extent necessary, where it is required for the CSIRT to perform its tasks (Article 12(6)). It is, however, obliged to mark in the content which information constitutes legally protected secrets (Article 12(8)).
The consequence for the procedure is practical. The person preparing the report has to know which categories of information the organisation treats as secret. They also need a way of marking them in the system. The absence of marking does not release the CSIRT from its duty of secrecy (Article 40(3)). Marking is nonetheless an obligation of the entity. Failing to mark may lead to a penalty for the head of the entity (Article 73a(1)(10)).
Final report — the document that closes the matter with the authority
The final report (Article 12a) has four elements. These are a detailed description of the incident together with the disruptions and damage caused, the type of threat or probable cause, the risk-mitigating measures applied and being implemented, and cross-border effects. It is the only document in the sequence that describes the event after its end and with full knowledge.
The third element deserves attention. The Act speaks of measures “applied and being implemented”, so also those which, on the day of the report, are still in the course of implementation. The final report is therefore also a declaration of changes in the information security management system. The supervisory authority may later check whether the declared measures were implemented. For that reason I recommend that the final report pass through the person responsible for the security management system before it is sent, and not only through the team handling the incident.
The one-month deadline is counted from the day of the incident notification, not from the end of handling. If handling takes longer, a progress report is submitted within that deadline and the final report within one month of completing the handling (Article 12b). The date of completing the handling is therefore another moment the organisation has to be able to name and document.
Common mistakes
- Treating the early warning as the whole obligation. After 24 hours the incident notification within 72 hours and the final report within one month of it are still due. An interim report is added when the CSIRT requests it.
- Holding the 72-hour incident notification until the findings are complete. The provision requires passing on the information known at the time of reporting and supplementing it later. A delay caused by incomplete knowledge is a breach of the deadline, not diligence.
- An outdated addressee in the procedure. Until the operational capability announcement the addressee is CSIRT MON, NASK or GOV, unless the sectoral team was established before 2025. According to the Minister of Digital Affairs, a notification filed in S46 reaches the competent team (Q&A 6.13 and 7.2).
- No S46 account on the day of the incident. According to the Minister of Digital Affairs, access to the system is granted to an entity entered in the register that has completed the full set of data (Q&A 2.15). Having no account does not suspend the deadlines, and the method of reporting without S46 is set by the competent CSIRT (Article 31(1)).
- Counting deadlines from the occurrence of the incident or from the end of the analysis. Both initial deadlines run from detection. The moment of detection has to be stated in the early warning itself, so it has to be documented.
- Omitting the marking of legally protected secrets. The duty to mark them rests with the reporting entity.
- Preparing the final report by the technical team alone. The document declares measures being implemented in the management system and will be the reference point for supervision.
Conclusions and next steps
The Act sets the content of the early warning, the incident notification and the final report (Articles 12 and 12a). The incident handling procedure can therefore contain ready templates for these three documents. According to the Minister of Digital Affairs, the interim report concerns the actions taken during handling (Q&A 6.23). The organisation designs the templates of the interim report and the progress report itself. Some fields can be filled in before an event. The order of work in putting this area in order looks as follows.
- Check whether the organisation has an entry in the register and an S46 account with access for the reporting person and their stand-in. Establish, from the competent CSIRT’s communication, how to report when S46 is unavailable (Article 31(1) and (3)).
- Establish the addressee of reports as of today for the organisation’s sector and designate a person who follows the announcements on the operational capability of the sectoral CSIRT.
- Record in the procedure the criteria for classifying an incident as significant, with reasons for the values adopted. For the sectors of the 2018 regulation these are its thresholds, and for the entities listed in Article 1 of Regulation 2024/2690 the thresholds of that act. Other organisations assess the event against the statutory definition of a significant incident. This step does not apply to entities in the banking and financial market infrastructure sector (Article 8i(1)).
- Prepare templates for the submissions, and include the statutory fields in those for the early warning, the incident notification and the final report. Fill in the fixed fields in advance and describe the variable fields with an instruction on who takes the data and from where.
- Establish how the moment of detection and the moment of completing the handling are recorded, because the deadlines are counted from them.
- Identify the categories of information treated as legally protected secrets and the way of marking them in the report.
- Test the sequence in an exercise, including the passage of the final report through the person responsible for the security management system.
Related materials
- What to do after detecting an incident? — the sequence of organisational actions in the first 24 hours and the clocks running in parallel under different regimes
- Cybersecurity incident vs personal data breach: what is the difference? — when one event requires two independent notifications
- When and how to apply for entry in the KSC register? — the entry as a condition of access to the S46 system
- How to manage supplier risk under NIS2? — information about an incident received from a supplier and obligations written into supplier contracts
Sources
- Act of 5 July 2018 on the National Cybersecurity System, consolidated text (as at 18 August 2026), Article 2(5)–(7), Articles 8i, 9, 11–12c, 16, 31, 40, 46, 73 and 73a — ISAP, Chancellery of the Sejm: isap.sejm.gov.pl (in Polish)
- Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252), Articles 32, 33, 35, 42, 44 and 46 — Journal of Laws: dziennikustaw.gov.pl (in Polish)
- Regulation of the Council of Ministers of 31 October 2018 on the thresholds for recognising an incident as significant (Journal of Laws 2018, item 2180) — ISAP, Chancellery of the Sejm: isap.sejm.gov.pl (in Polish)
- Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures and further specification of the cases in which an incident is considered to be significant, Articles 1 and 3–14 — EUR-Lex: eur-lex.europa.eu
- Communication of the Minister of Digital Affairs of 8 April 2026 on the schedule for filing applications for entry in the register of essential and important entities and for starting to use the ICT system by essential or important entities (Official Journal of the Minister of Digital Affairs, item 7) — Ministry of Digital Affairs: gov.pl (in Polish)
- S46 system, “Self-registration (entry in the KSC register)” — NASK, Ministry of Digital Affairs: gov.pl (in Polish)
- Questions and answers on the amendment to the Act on the National Cybersecurity System (October 2026 version), Q&A 2.15, 6.5, 6.11, 6.13, 6.14, 6.23, 7.2 and 14.2 — Ministry of Digital Affairs: cyber.gov.pl (in Polish)
Check the procedure before it is needed
If the organisation’s incident handling procedure provides for one significant incident report with one deadline, it is worth comparing it with the sequence in the Act before the first event. Support with incidents and breaches covers a review of the procedure, preparation of report templates and an exercise of the sequence with the team.
This material is general and educational in nature. It is not an individual legal opinion or a recommendation for any specific organisation. The scope of the obligations should be assessed against the situation of the organisation concerned.
Legal status: September 2026.