What does a significant incident report to a CSIRT contain?

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. Each has its own deadline and its own list of required information. The first two run from detection of the significant incident, the final report runs from the incident notification, and the interim-report deadline is set by the CSIRT. Each is also separately covered by a provision on a financial penalty (Article 73(1)(6)–(9)).

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 for most sectors 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. An entity outside those sectors has no numerical threshold 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)).

Here the first difficulty appears. 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. An entity from a sector not covered by that regulation assesses the event solely against the statutory definition. 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 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 at which the event was recognised as a significant incident. The security team’s event log is evidence here, not a formality.

Who receives the significant incident report

The Act names the competent sectoral CSIRT as the addressee 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. The exception is sectors in which a sectoral team was established before 2025, where the transitional rule does not apply (Article 44(3)).

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 announcement of operational capability is published in that authority’s official journal and on the websites of the national-level CSIRTs.

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)). An organisation without an entry has no account in the system, and without an account it has no channel for reporting. This is the most practical argument for making sure the entry in the register precedes the first incident.

The four submissions — deadline, starting point and content

Submission	Deadline	Counted from	Content required by the Act	Legal basis
Early warning	24 hours	detection of the incident	entity and contact details, 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)
Report	72 hours	detection of the 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 CSIRT’s request	the Act does not specify the content	Article 11(1)(4b)
Final report	one month	the day of the report (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 document is added to the table 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).

Three qualifications to the table. A trust service provider reports a significant incident within 24 hours of detection (Article 11(1a)). An important entity that is a public entity files only the report under Article 11(1)(4a), and the provisions on the early warning and on the reports do not apply to it (Article 12c). All submissions go through S46. Failure to use the system where it is required is separately covered by a penalty provision (Article 73(1)(13)).

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. In practice this means at least two people with access to the system and knowledge of the matter, which matches the duty to designate at least two contact persons (Article 9(1)(1)).

The remaining three items require findings. The moment of occurrence and detection and the duration are discussed above. 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 point in the sequence at which the Act imposes a deadline on the CSIRT rather than on the entity. Organisations rarely use it, because they treat the early warning as an obligation rather than as a channel for obtaining help.

The 72-hour significant incident report — a description of impact, not of the attack

The report 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. The order is not accidental. The CSIRT first needs information that allows it to assess the scale of the disruption, not a technical description of the attack vector.

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 report may also contain other material information on the course of the incident (Article 12(4)).

The most important provision in this section is short. The entity passes on the information known to it at the time of making the report and supplements it while handling the incident (Article 12(5)). Incomplete knowledge after 72 hours is therefore not a reason to delay the report. It is a reason to indicate in the report which information is preliminary. The CSIRT may in any event itself ask for the early warning or the report 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 protecting the information, but it makes it harder for the organisation to show later that it acted with due care.

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 report, 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 three more deadlines run. These are 72 hours for the report, one month for the final report and the deadline in the CSIRT’s request for the interim report.
• Holding the 72-hour report 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.
• Writing the sectoral CSIRT into the procedure as the addressee for today. Until the operational capability announcement, reports go to CSIRT MON, NASK or GOV, unless the sectoral team was operating before 2025.
• No S46 account on the day of the incident. Access to the system follows the entry in the register. Without an entry there is no reporting channel.
• 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 content of every document making up a significant incident report is set by the Act, so the incident handling procedure can contain ready templates for the four documents with fields matching Articles 12, 12a and 12b. Some fields can be filled in before an event. The order of work in putting this area in order looks as follows.

1. Check whether the organisation has an entry in the register and an S46 account for at least two people. Without that, the remaining steps have no channel for delivery.
2. 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.
3. Record in the procedure the criteria for classifying an incident as significant, with reasons for the values adopted. For six sectors these are the thresholds from the 2018 regulation, for the others the statutory definition.
4. Prepare templates for the four submissions with the fields from the Act. Fill in the fixed fields in advance and describe the variable fields with an instruction on who takes the data and from where.
5. Establish how the moment of detection and the moment of completing the handling are recorded, because the deadlines are counted from them.
6. Identify the categories of information treated as legally protected secrets and the way of marking them in the report.
7. 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

Sources

• Act of July 5, 2018 on the National Cybersecurity System, consolidated text (as at July 7, 2026), Article 2(5)–(7), Articles 9, 11–12c, 46 and 73 — ISAP, Chancellery of the Sejm: isap.sejm.gov.pl (in Polish; accessed September 6, 2026)
• Act of January 23, 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252), Articles 32, 35, 42 and 44 — Journal of Laws: dziennikustaw.gov.pl (in Polish; accessed September 6, 2026)
• Regulation of the Council of Ministers of October 31, 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; accessed September 6, 2026)
• Communication of the Minister of Digital Affairs of April 8, 2026 on the schedule for filing applications for entry in the register of essential and important entities (Official Journal of the Minister of Digital Affairs, item 7) — Ministry of Digital Affairs: gov.pl (in Polish; accessed September 6, 2026)
• S46 system, “Self-registration (entry in the KSC register)” — NASK, Ministry of Digital Affairs: gov.pl (in Polish; accessed September 6, 2026)