Incident management
A security incident is any event capable of threatening the confidentiality, integrity or availability of information systems. In business reality incidents are inevitable — the question is not "will one reach us", but "when", and "will we be ready". An organisation with no incident management procedure will meet the crisis with chaos, panic and uncoordinated actions that can make the situation considerably worse. Article 33 GDPR requires Poland's data protection authority (UODO) to be notified of a personal data breach within seventy-two hours of discovering it, and Article 34 requires the data subjects to be notified where the risk is high. NIS2 imposes even stricter reporting requirements on operators of critical services. ISO 27001, in Annex controls A.5.24 to A.5.28, sets out procedures for the detection, analysis of and response to security incidents.
The scale of the phenomenon in Poland
For context, it is worth setting procedures against the data. In 2025 CERT Polska received 658,320 reports and registered 260,783 incidents — an increase of 152 per cent year on year. There were 179 ransomware cases, against 163 the year before. CSIRT NASK handled 27 significant incidents within the meaning of the KSC Act.
Among the events described in the report for 2025 is an attack on a water treatment station in which pump settings were altered — the result was an interruption of around six hours in the water supply to nearly 2,500 residents. It is a good illustration that an incident in a control system does not stop at data.
On the data protection side the picture is similar: in 2025 UODO received 22,435 breach notifications, and the authority imposed 32 fines totalling approximately PLN 64.4 million.
Two practical conclusions follow. First, the probability that an organisation will handle an incident within a given year is high — a procedure is not an investment in an unlikely scenario. Second, events that begin with a person and their credentials dominate, so detection based solely on malware signatures will catch only a minority of cases.
Phases of management
The incident management process is conventionally divided into six phases: preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Each phase has clearly defined objectives, responsible people and procedures.
Article 33 GDPR requires notification of the President of UODO within 72 hours.
The preparation phase is the most important and often the most neglected. It is in peacetime that we have to build the infrastructure, procedures and teams that will operate under pressure when an incident occurs. Preparation covers a number of elements. The first is deploying a threat detection system — this may be a SIEM (Security Information and Event Management) solution such as Splunk or IBM QRadar, which aggregates logs from across the infrastructure and identifies suspicious activity. The second is establishing an Incident Response Team (IRT) comprising staff from IT, security, management, legal and PR. The third is drawing up an incident management procedure document describing the stages, roles and communication. The fourth is implementing backup and disaster recovery systems — without a working backup, an organisation is completely defenceless in the face of ransomware. The fifth is regular training for the IRT, so that everyone knows their roles and procedures.
Detection and analysis
The detection and analysis phase begins when a system or an employee notices something suspicious. It may be an alert from a SIEM system, an employee noticing a strange process on their computer, or the discovery of traces of an attack in the logs. At that moment someone from the security or IT team should trigger the incident procedure. The first step is to confirm that an incident is genuinely taking place — alerts are sometimes false. Once an incident is confirmed, the team starts gathering information: what exactly happened, which systems are infected, when it started, how much data may have been at risk. This analysis should be conducted under the supervision of technical staff, but it must at the same time be alive to legal requirements — if the incident involves personal data, it qualifies as a data breach within the meaning of the GDPR and must be reported.
Containing the incident
The containment phase is aimed at limiting the damage and preventing the incident from spreading. If an attacker has access to a system, containment means immediately restricting what they can do. In concrete terms, this may mean disconnecting the infected server from the network, resetting passwords for users whose accounts may have been compromised, blocking suspicious IP addresses on the firewall, or temporarily switching off VPN access. In the case of ransomware, containment is critical — the faster the infected systems are taken off the network, the smaller the chance that the ransomware will spread to other machines.
Eradication and recovery
The eradication phase consists in removing the attacker from the infrastructure. This is not as simple as it might be assumed to be. If the attacker has installed a backdoor (a hidden way into the system), installing a security patch will not be enough — the backdoor has to be found and removed. In the case of ransomware, eradication means identifying and removing the malware from all infected systems. This phase should be carried out very carefully, because if the threat is not fully eliminated the attacker may return and resume the attack. Many organisations wrongly assume that once a security patch has been applied the problem is solved, and are then surprised when the attacker comes back days or weeks later.
The recovery phase consists in restoring systems to normal operation. For infected servers, this may mean a clean installation of the operating system and restoring data from a clean backup. In the case of ransomware, if the organisation has access to backups it can restore its files without paying the ransom (which is also the recommended course, because paying is often ineffective and supports criminal activity). This phase must, however, be handled carefully — if we restore files from a backup that was already infected, we will simply reinfect the systems.
Reporting deadlines — three clocks running in parallel
The costliest mistakes in incident management are not technical but procedural. The team is putting out the fire while, in the background, deadlines nobody remembers are running.
GDPR — 72 hours. A personal data breach is reported to the President of UODO within 72 hours of becoming aware of it (Article 33). If the breach may result in a high risk to the rights and freedoms of individuals, those individuals must also be notified without undue delay (Article 34). A late notification is permissible, but requires an explanation of the delay, and UODO does penalise its absence in practice: in April 2026 a housing community paid PLN 5,000 for precisely this failure.
The KSC Act — 24 hours, 72 hours, one month. Essential and important entities submit an early warning within 24 hours of detecting a significant incident, a full notification within 72 hours, and a final report within one month. An early warning does not require a full analysis — it requires a signal.
Audit and internal reporting. An essential entity that has received a security audit report passes a copy of it to the competent authority within 3 working days.
These clocks do not replace one another. An incident that leaks personal data at an entity covered by the KSC Act sets both tracks running at once — before two different authorities, in two different formats, with different moments at which the deadline starts to run.
That is why the first step in a response procedure should not be a technical action but classification: is this an event, an incident, a significant incident, a personal data breach — or several of these at once? Which clocks start running depends on that decision.
Roles and decisions — who actually runs the incident
In small organisations the incident is handled by whoever noticed it first. That works right up to the moment when a costly decision has to be made — take a production system offline, notify customers, pay or refuse to pay a ransom.
The minimum division of roles worth establishing before an incident:
Incident coordinator — one person who runs the event, maintains the timeline and keeps track of deadlines. They need not be the best technician on the team; they must have a mandate to give instructions.
Business decision-maker — someone who can authorise downtime. In practice this means a board member with a deputy, because incidents do not wait for people to come back from holiday.
Compliance owner — the data protection officer (DPO) or information security officer, who assesses the reporting obligations and prepares the content of the notifications.
Communications owner — a single voice to the outside world, towards customers, the media and business partners. Scattered communication during an incident does more damage than the incident itself.
External contact — technical support provider, law firm, insurer. Telephone numbers recorded outside company systems, because in the event of an attack email and the intranet may be unavailable.
What not to do in the first few hours
Do not power down infected machines without preserving evidence. Cutting the power wipes the memory, which often holds keys, processes and network connections essential to establishing how the attack unfolded. Network isolation is usually better than shutting down.
Do not delete logs "to free up space". That sounds absurd until it happens on a server that runs out of disk space in the middle of an incident.
Do not communicate over channels that may have been compromised. If we suspect that company email has been compromised, coordinating the team over that same email tells the attacker about every move the defenders make.
Do not announce that "everything is under control" before you know it is. Walking back that kind of message costs more than a cautious note about an ongoing analysis.
Do not negotiate a ransom without a board decision and legal advice. Payment may carry consequences reaching well beyond the incident itself, and according to Verizon's 2025 data 64 per cent of organisations that were attacked did not pay the ransom.
Post-mortem and conclusions
The final phase, lessons learned, is where organisations often fall short. After an incident a post-mortem should be held — a meeting of the IRT at which the team analyses what went well, what went badly and what can be improved. The post-mortem should be low-pressure and focused on processes, not on blaming individuals — the goal is learning, not punishment. The output should be a list of recommendations to be implemented in order to prevent similar incidents in the future.
Containing an incident is key to limiting the damage.
To illustrate the process, consider a practical scenario: Monday, 3.30 p.m., a network administrator notices an alert from the monitoring system on the File Server — abnormally high disk activity — while employees report problems accessing files. The administrator opens the incident management procedure and notifies the security manager. After a brief analysis, the security manager concludes that this looks like a ransomware attack — a message appears on users' screens demanding payment and stating that all files have been encrypted. The incident procedure is triggered, and within five minutes the IRT convenes a crisis meeting. The decision: disconnect the File Server from the network immediately and tell all users to switch off their computers to prevent the malware from spreading. If possible, shut down the company VPN to prevent remote access. At the same time, communication has to be prepared for management and, ultimately, for customers and the media.
In this scenario, at 4.00 p.m. the team establishes that the attacker has access to the network drives. At 4.30 p.m. the analysis indicates that the attack came through a weak configuration of the RDP (Remote Desktop Protocol) server, which allowed the attacker to brute-force the administrator password. At 5.00 p.m. all systems are disconnected from the network. At 5.30 p.m. the security manager has to decide: report to the President of UODO now, or wait for more accurate information? The GDPR does not allow waiting too long — a breach must be reported within seventy-two hours. In this scenario, the decision is to report to the President of UODO on Tuesday morning, once more information has been gathered. In parallel, the team begins work on identifying which data has been compromised — the GDPR requires the data subjects to be notified if there is a high risk to their rights and freedoms.
Tuesday, 9.00 a.m., the team confirms that the entire file infrastructure is infected, covering the data of all the company's customers. The President of UODO must be notified. A notification is drawn up (a note setting out what happened, when it happened, how much data is affected, what the potential impact on the data subjects is and what actions are being taken) and sent to the President of UODO electronically. In parallel, the team starts work on eradication — the analysis indicates that the attacker was in the system for at least four days before the files were encrypted. Where possible, digital forensics is carried out — analysis of logs and disks in search of any backdoor left behind. On Thursday, after three days of work, the team confirms that the attacker has been eliminated from the system, and recovery begins — restoring files from a backup known not to have been infected.
Alongside the technical phases, the team has to manage communication. Employees need to know what has happened and what they should do. Management has to be kept up to date on progress. Customers have to be told that their data may have been at risk — and that message should be honest and transparent. PR has to be ready to respond to the media.
Documentation is critical. Every action taken during the incident should be logged — who did what, when, and what decisions were taken. This documentation not only helps in understanding what happened, but will also matter in the event of regulatory proceedings or litigation.
After the incident, the post-mortem should propose remedial actions. In the RDP scenario, these might include: enabling multi-factor authentication on all administrator accounts; changing the default RDP port (which is not "security through obscurity" as such, but greatly reduces automated scanning); implementing a more restrictive firewall policy that limits access to administrative services to authorised IP addresses only; or introducing network segmentation that limits the spread of malware in the event of a future attack.
Incident management does not end with the technical aspects — it has to be integrated into the organisation. The procedure must be known to all employees, and the IRT must be trained and tested regularly — and where in-house resources fall short, its role can be taken over by support from an external incident response team. The remedial actions from the post-mortem have to be genuinely implemented, not merely recommended. Organisations that do this can substantially reduce recovery time and limit the damage in the event of an attack, and in doing so protect their reputation and their financial position.
What this cycle looks like in a real event is shown in our accounts of the ransomware attack on Nowa Ruda and the data leak at the University of Warsaw.
