What to do after detecting an incident?

Why this question arises at all

Most organizations have an incident response procedure, and most of those procedures describe the technical path: who takes the report, how to classify it, when to escalate. The question “what next” comes up at a different moment — once the event is confirmed, part of the systems is down, and several people are waiting for a decision at the same time. The procedure then says who is to do something, but rarely says in what order, and what not to do.

The second source of doubt is regulatory. The same event can trigger obligations under two or three regimes at once, and each of them counts time from something different. An essential or important entity within the meaning of the Act on the National Cybersecurity System (KSC) responds to a significant incident from the moment it is detected. A controller within the meaning of the GDPR responds to a personal data breach from the moment it becomes aware of it, that is, from the moment it has obtained sufficient certainty that an event affecting personal data has occurred. Those two moments rarely fall in the same hour, and for events spread over time they can be days apart.

The third source is the most practical. The first hours decide what the organization will have available later. Traces in systems have limited durability: logs rotate, volatile memory disappears after a restart, virtual machine snapshots are overwritten. A team that instinctively restores the service is acting rationally from a continuity perspective — and is at the same time destroying the material on which the assessment of the event’s scope, the content of the report to the authority and the conversation with the insurer were meant to rest.

What must be determined before the decision

Is the event confirmed and what exactly did it cover

A signal is not yet an incident. Before the organization launches a full response, someone has to confirm that the event actually happened and provisionally establish its scope: which systems, which data, which period, whether access is still ongoing. The verification should be short and documented to the hour, because the rest of the chronology is counted from it.

Scope is established along three dimensions at once: what stopped working, what was changed and what may have been disclosed. The third dimension tends to be examined last, even though it is the one that decides the obligations towards the data protection authority. If, after the first analysis, access to personal data cannot be ruled out, assume for working purposes that access may have occurred and run both tracks in parallel — narrowing the findings is easier than making up lost time.

Who runs the case and who takes which decisions

In an effective response three roles are separated. Someone runs the case and keeps the chronology. Someone decides on technical action — cutting off a network segment, disabling an account, holding back a restore. Someone settles the legal qualification and the reports: the data protection officer on the GDPR side, the person responsible for obligations under the KSC Act on the cybersecurity side.

These roles can be combined in a smaller organization, but they have to be named before the event. Under the KSC Act, responsibility for performing the obligations relating to incident handling and reporting rests with the head of the entity and does not disappear by delegating tasks to someone else — the Act provides for a separate financial penalty for the head of the entity, among other things for failing to perform the obligations relating to incident reporting and reporting duties. A simple organizational conclusion follows: senior management has to learn about a significant incident early enough for reporting decisions to be taken within the deadline, not after it has passed.

Which clocks are already running

Deadlines are stated as fact, not as pressure — but they have to be known in advance, because during the event there is no time to work them out.

• KSC Act — essential and important entities. Early warning of a significant incident: without undue delay, no later than 24 hours from the moment of detection. Report of a significant incident: without undue delay, no later than 72 hours — also from the moment of detection, not from the early warning. This is the most common distortion in secondary sources and the most expensive one in practice, because it creates the illusion of three extra days.
• KSC Act — reporting after the notification. An interim report is submitted only at the request of the competent CSIRT. The final report — no later than one month from the date of the notification. If incident handling has not been completed by then, the entity submits a progress report and files the final report within one month of completion. The channel is the S46 central ICT system.
• GDPR — the controller. A breach is notified to the President of UODO without undue delay and, where feasible, no later than 72 hours after having become aware of it — unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The standard is “without undue delay”; 72 hours is a limit, not an allowance to be used up. A notification made after that point is accompanied by reasons for the delay. Where the full set of information cannot be gathered, the rules allow it to be provided in phases.
• GDPR — the processor. A processor that has become aware of a breach notifies the controller without undue delay. The rules do not state when the controller’s deadline starts running in that arrangement — in practice it is taken to run from the moment the information is received from the processor, which is why the processing agreement should set a specific time and channel for notification.
• Sectoral and contractual commitments. Financial entities have separate deadlines under the DORA Regulation and the technical standards adopted under it, and many customer contracts contain their own information commitments, usually shorter than the statutory ones. These deadlines do not replace one another — they run in parallel.

Two transitional caveats, without which the list above is misleading.

Who the report actually goes to. The Act directs reports to the competent sectoral CSIRT, but the transitional provisions state that, until a communication is issued confirming that this CSIRT has reached operational capability, reports go to the competent CSIRT MON, CSIRT NASK or CSIRT GOV. The competent authorities have eighteen months from the entry into force of the amendment to establish the sectoral CSIRTs. In August 2026, for most sectors the addressee is therefore a national-level CSIRT — check your procedure to see whether the target state has been written into it.

From when the new rules bind former operators of essential services. Entities that held that status before April 3, 2026 report significant incidents under the new rules after six months from the entry into force of the amendment. For them, the change of rules therefore falls at the beginning of October 2026.

Separate rules apply to two groups. A trust service provider reports a significant incident within 24 hours of detection. An important entity that is a public entity is exempt from submitting the early warning and the reports — interim, progress and final.

Which of these clocks apply to an organization at all follows from its qualification, not from the nature of the event. Organizations that do not have this settled in writing usually start by establishing the scope of obligations under NIS2 and KSC before merging the reporting paths into a single procedure.

When an event is a significant incident

Classification is not an intuitive judgement. The thresholds for treating an incident as significant — by type of event in particular sectors and subsectors — are set by the Council of Ministers by regulation, taking into account the number of users affected by the disruption, the duration of the incident’s impact on the service, the geographical reach and other sector-specific factors. Excluded from that delegation are entities for which the European Commission has set thresholds in an implementing regulation — this applies to part of the digital infrastructure and digital services sector, which apply the EU criteria directly.

The practical conclusion is that the thresholds have to be written into the procedure before the event, stating which source applies to the organization. Working this out during the first day eats up time that is not there.

What to secure before restoration begins

Limiting the effects and gathering evidence are not mutually exclusive, but they require an order. Before the environment is restored it is worth securing images of the affected systems and volatile memory, exporting logs from systems with short retention and saving the configuration in its pre-change state. Isolating a network segment is safer than switching a machine off, because it stops the attacker without erasing the state of the system.

In parallel, a single chronology of the event is kept. The record of who established or changed what, and when, later forms the basis of the report, the settlement with the insurer and the answers to the authority’s questions. Reconstructing that timeline a week after the event, from the memory of several people, produces a result that cannot be defended.

Who else has to be told

Beyond the authorities, the circle of those informed is set by the rules, by contractual relationships and by the actual impact of the event — in that order, because the first element tends to be overlooked.

The KSC Act imposes two information obligations on essential and important entities towards the users of their services. In the case of a significant cyber threat, the entity informs the users who may be affected about the preventive measures available to them; it informs them about the threat itself where doing so will not increase the level of risk to the security of the systems. In the case of a significant incident that has an adverse effect on the provision of services — it informs users about the incident. These are obligations, not communication decisions; the question is “how and when”, not “whether”.

Next come the contractual relationships. Where the organization is a processor, its first addressees are the controllers for whom it processes data — and it is they, not it, who decide whether to notify the authority. Notifying the data subjects is a separate decision: it arises only where there is a high risk to their rights and freedoms and is governed by its own rules, described in Does every data breach need to be reported?.

Internal communication requires the same discipline as external. A single source of information, one approved message and a clear statement of what is not yet known reduce the number of versions circulating around the organization — and it is those versions that most often end up outside it in a form nobody approved.

The first day — a checklist

The list organizes the sequence, but it does not replace a procedure tailored to the organization. Its value only shows once a specific role — not a department — has been assigned to each point before the event.

Most common mistakes

• Restoring the service before securing the evidence. The most common mistake and the hardest to repair. After a restore from backup it is usually no longer possible to establish how long access lasted or what was taken.
• Adding 72 hours to the early warning. Both KSC deadlines run from detection of the incident. A procedure under which the report is to be made “within 72 hours of the early warning” plans to miss the deadline.
• Counting every deadline from a single moment. The KSC deadline runs from detection of the incident, the GDPR one from becoming aware of the breach. A single shared date in the documentation means one of them was calculated wrongly.
• Writing the target addressee of reports into the procedure. Sectoral CSIRTs are only being set up; until the communication on their operational capability, reports go to CSIRT MON, NASK or GOV.
• Assuming that a report to the CSIRT exhausts the obligations. Reports under different regimes have different addressees, different scope and different deadlines. None of them replaces the others. Nor do they replace the duty to inform the users of the services.
• Treating loss of availability as a purely technical matter. Lack of access to data is a personal data breach just as much as its disclosure, even if the backup worked.
• Scattered communication. Parallel messages from IT, customer service and the board, differing in content, create a bigger problem later than the event itself.
• Closing the case once the service is back. Without the final report, the conclusions and changes to safeguards, the organization returns to exactly the state in which the incident was possible.

Conclusions and next steps

After detecting an incident an organization takes not one decision but a sequence of decisions with different owners and different deadlines. Speed only helps where the order is right: confirmation, securing the evidence, limiting the effects, qualification, reports, information for users, restoration, conclusions.

Five things are worth settling before the next event. Who has the right to declare an incident confirmed, and where that moment is recorded. What the minimum set of evidence secured every time looks like, regardless of the type of event. Which classification thresholds apply to the organization and where they come from. Which regimes apply to it, who prepares the report under each of them and to whom it is addressed. Who approves messages going outside.

An organization that has these elements settled spends the first hours on substantive work. An organization that does not spends them working out who is responsible for what — and it is usually that, rather than the scale of the event itself, that decides how the matter looks later in the documents.

Related materials

• Does every data breach need to be reported? — the notification threshold and the assessment of risk to the rights and freedoms of individuals, that is, the decision to which the sequence described here leads.
• Does every organization fall under NIS2? — the entity qualification that decides whether, alongside the GDPR obligations, deadlines towards the CSIRT are also running.
• Where should the board begin preparing for NIS2? — the order of senior management actions once the entity’s status is established, including assigning responsibility for incident handling.
• What should a personal data breach register contain? — what of the first 24 hours ends up in the documentation.
• Who else needs NIS2 training besides the management board? — the circle of people beyond the head of the entity and how to derive it from Articles 8 and 11.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), Articles 33 and 34, consolidated text — EUR-Lex: eur-lex.europa.eu (accessed: August 18, 2026)
• Act of July 5, 2018 on the National Cybersecurity System, Articles 11–12c, consolidated text — Chancellery of the Sejm, ISAP: isap.sejm.gov.pl (accessed: August 18, 2026) (in Polish)
• Act of January 23, 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252) — transitional provisions on incident reporting, Journal of Laws: dziennikustaw.gov.pl (accessed: August 18, 2026) (in Polish)
• Reporting a personal data breach — Personal Data Protection Office (UODO): uodo.gov.pl (accessed: August 18, 2026) (in Polish)
• What is the deadline for notifying a breach to the President of UODO? — Personal Data Protection Office (UODO): uodo.gov.pl (accessed: August 18, 2026) (in Polish)
• Questions and answers on the amendment to the Act on the National Cybersecurity System — Ministry of Digitization: cyber.gov.pl (accessed: August 18, 2026) (in Polish)