{"id":4076,"date":"2026-07-30T10:00:00","date_gmt":"2026-07-30T08:00:00","guid":{"rendered":"https:\/\/www.lablogic.pl\/?p=4076"},"modified":"2026-09-13T22:48:52","modified_gmt":"2026-09-13T20:48:52","slug":"cybersecurity-incident-vs-personal-data-breach","status":"publish","type":"post","link":"https:\/\/www.lablogic.pl\/en\/cybersecurity-incident-vs-personal-data-breach\/","title":{"rendered":"Cybersecurity incident vs personal data breach: what is the difference?"},"content":{"rendered":"\n

Micha\u0142 Rutkowski<\/strong><\/a> \u2022 for data protection officers and security teams \u2022 published July 30, 2026 \u2022 updated August 19, 2026 \u2022 10 min read<\/p>\n\n\n\n

\n
\n
\n\n\n\n<\/div>\n<\/div>\n\n\n\n
\n
\n

Short answer<\/h2>\n\n\n\n

They differ in what they protect, and that is why they are determined separately. A cybersecurity incident \u2013 which the Polish Act on the National Cybersecurity System simply calls an incident \u2013 concerns the security of information systems and the continuity of the service, while a breach within the meaning of the GDPR concerns personal data and the rights of the individuals it relates to. The scopes of the two concepts overlap, but neither contains the other. There are incidents without a breach and breaches without an incident within the meaning of the act. A single event may therefore call for two independent determinations, two notifications with different content and two entries in separate records.<\/p>\n<\/div>\n\n\n\n

Why the question comes up at all<\/h2>\n\n\n\n

The first source of doubt is linguistic. In most organisations the word \u201cincident\u201d means anything that went wrong in the systems \u2014 from a failed login to a halt in production. That is the name of the queue in the ticketing system, the name of the procedure and the word used in meetings. The act gives the word a narrower meaning and attaches specific obligations to it, so from the moment an organisation falls under the national cybersecurity rules, the same word describes two different things.<\/p>\n\n\n\n

The second source is conceptual. Both definitions speak of security, so they sound like two names for the same state of affairs. Their centre of gravity is different, though. An incident describes the effect of an event on an information system; a breach describes the effect of an event on personal data. That distinction decides whether an obligation towards the data protection authority arises at all.<\/p>\n\n\n\n

The third source is organisational and the most practical. The determination is usually made in a single meeting and led by a single role \u2014 most often someone from the security team or from IT. If that person closes the matter with one determination, the second track is not consciously rejected, it is simply never opened. It shows later in the documentation. There is a technical description of the event and no trace of an assessment of whether the event touched personal data.<\/p>\n\n\n\n

What to establish before deciding<\/h2>\n\n\n\n

What each concept covers<\/h3>\n\n\n\n

The Act on the National Cybersecurity System (KSC) defines an incident as an event that has or may have an adverse effect on the security of information systems. The act describes the security of information systems itself as the resilience of those systems to events compromising the confidentiality, integrity, availability and authenticity of the data processed or of the related services. An information system means an ICT system or a set of devices and software intended for processing data \u2014 together with the data processed in electronic form<\/strong>. The point of reference is therefore the system and the service that system supports.<\/p>\n\n\n\n

The GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Here the point of reference is the data, not the system it sits in. The medium is irrelevant \u2014 the definition covers data transmitted, stored or otherwise processed.<\/p>\n\n\n\n

In its guide on breaches, the President of the Personal Data Protection Office (UODO) breaks that definition into three conditions that must be met together. The event is a security incident, it concerns personal data being processed and, in the wording of the guide, it may lead to one of the listed consequences. The regulation itself is narrower here, because Article 4(12) GDPR speaks of a breach of security leading to those consequences, while the guide frames the condition as a possibility. In practice the difference rarely decides a case, because loss of the data is itself one of the consequences named in the definition \u2014 a lost storage device holding data is a breach even if nobody accessed the data.<\/p>\n\n\n\n

One terminological caveat is needed here, because without it the two documents look contradictory. A \u201csecurity incident\u201d, as the guide uses the term, is a general concept and also covers events outside ICT systems. An \u201cincident\u201d within the meaning of the KSC act is narrower and relates solely to the security of information systems. Every personal data breach is therefore a security incident in that first, general sense, but not every one is an incident within the meaning of the act.<\/p>\n\n\n\n

Two typical divergences follow. A repelled attack, a blocked connection to a production system or a failure of an environment that holds no personal data all fall within the definition of an incident and are not breaches. It also works the other way round. A lost personnel file, a fire in an archive or a letter delivered to the wrong address are personal data breaches even though they touch no information system.<\/p>\n\n\n\n

The overlap is larger than usually assumed. Since the security of information systems covers the confidentiality of the data processed, an event compromising the confidentiality of personal data in a system will usually meet both definitions at once. Separating the two determinations is therefore not about choosing one of them, but about not overlooking the second.<\/p>\n\n\n\n

Who each obligation applies to<\/h3>\n\n\n\n

This question is settled before the event is assessed, not after. The obligations on handling and reporting incidents bind only essential and important entities, that is, organisations meeting the qualification criteria in the KSC act. The obligations on breaches bind every controller and every processor, irrespective of size, sector or entry in any register.<\/p>\n\n\n\n

In practice this makes for an asymmetric arrangement. Most organisations always have breach obligations, and incident obligations only once they have been qualified. Organisations without their status settled in writing usually start with establishing the scope of obligations under NIS2 and the KSC<\/a> before they merge the two tracks into a single procedure.<\/p>\n\n\n\n

There are also the transitional provisions, without which the picture is false. The amendment to the KSC act entered into force on April 3, 2026. Entities that met the criteria for being treated as an essential or important entity on that day implement the obligations under Chapter 3 of the act \u2014 including incident handling and reporting \u2014 within 12 months, that is by April 3, 2027. Entities that were previously operators of essential services report significant incidents under the new rules within 6 months of the amendment entering into force \u2014 for them the rules change at the beginning of October 2026. The obligations arising from the GDPR have no adjustment period and run independently of that timetable.<\/p>\n\n\n\n

From which moment time starts running<\/h3>\n\n\n\n

Each regime sets its own starting point and this is the most common source of error in documentation. The deadlines towards the competent CSIRT run from detection<\/strong> of a significant incident. The deadline towards the President of UODO runs from becoming aware<\/strong> of a breach, that is, from the moment the controller obtained sufficient certainty that an event concerning personal data had occurred.<\/p>\n\n\n\n

Those moments rarely fall in the same hour. Detection is a technical finding and happens early. Awareness requires knowing which data the event concerned, so it comes after analysis. A single shared date in the register means one of the two deadlines was counted wrongly. The order of steps in the first 24 hours and how to document them is set out in What to do after detecting an incident?<\/a>.<\/p>\n\n\n\n

What threshold triggers a notification<\/h3>\n\n\n\n

The thresholds are built differently too and cannot be used interchangeably. What must be reported is a significant<\/strong> incident, and the thresholds for treating an incident as significant are set by the Council of Ministers in a regulation, separately for sectors and sub-sectors. Entities for which the European Commission has set thresholds in an implementing regulation are excluded from that delegation. The criteria are quantitative. They cover the number of users affected by the disruption, the duration of the incident\u2019s effect on the service, the geographical spread and other factors specific to the sector.<\/p>\n\n\n\n

There is a gap here worth knowing about. Until new implementing provisions are issued, the existing ones apply, but for no longer than 12 months from the entry into force of the amendment. The act in force is the Regulation of the Council of Ministers of October 31, 2018, issued under the original act. It contains thresholds for six sectors of the former operators of essential services \u2014 from energy and transport to digital infrastructure \u2014 and uses the concept of an essential service, which the amendment no longer employs. For entities in the sectors added by the amendment there is therefore no threshold expressed in implementing provisions today. That is an assessment of the position rather than the wording of a provision; the gap is to be closed by a new regulation.<\/p>\n\n\n\n

On the GDPR side there is no table of thresholds at all. Notification is the rule, and the controller may depart from it only where its assessment shows that the breach is unlikely to result in a risk to the rights or freedoms of natural persons. The assessment is qualitative and concerns the consequences for people, not the scale of the disruption to a service. The mechanism of that assessment is set out in Does every data breach need to be reported?<\/a>.<\/p>\n\n\n\n

The practical consequence is that an event below the threshold of a significant incident may still be a notifiable breach, and a significant incident may be an event that touched no personal data at all. The outcome of one assessment does not decide the outcome of the other.<\/p>\n\n\n\n

What each notification contains<\/h3>\n\n\n\n

The difference is easiest to see by comparing the required content. A significant incident report describes the effect of the event on the provision of the service. It states which service it covered, how many users it affected, what the geographical spread was and whether it affected the provision of services by other entities. To that are added the causes, the course of events and the preventive and remedial action taken.<\/p>\n\n\n\n

A breach notification to the President of UODO describes something else. The nature of the breach together with the categories and approximate number of data subjects and data records, the contact details of the data protection officer, the likely consequences of the breach and the measures taken to address it. The first notification speaks about the service, the second about people. Practically the only thing they share is the chronology of the event, which is why the content of one cannot be copied into the other without omitting most of the required information.<\/p>\n\n\n\n

What the difference looks like in brief<\/h3>\n\n\n\n
Dimension<\/th>Incident \u2014 the KSC act<\/th>Breach \u2014 the GDPR<\/th><\/tr><\/thead>
What is protected<\/td>The security of information systems and the continuity of the service<\/td>Personal data and the rights and freedoms of individuals<\/td><\/tr>
Condition for it to arise<\/td>An effect on the security of the system \u2014 actual or possible<\/td>The event concerns personal data and may lead to their destruction, loss, alteration, disclosure or unauthorised access<\/td><\/tr>
Relevance of the medium<\/td>Information systems only<\/td>Any medium, including paper<\/td><\/tr>
Who it applies to<\/td>Essential and important entities<\/td>Controllers and processors<\/td><\/tr>
Start of the deadline<\/td>Detection of the incident<\/td>Becoming aware of the breach<\/td><\/tr>
Notification threshold<\/td>Quantitative thresholds in a Council of Ministers regulation<\/td>Assessment of the risk to the rights and freedoms of individuals<\/td><\/tr>
Who the notification goes to<\/td>The competent CSIRT<\/td>The President of UODO and, where the risk is high, the individuals as well<\/td><\/tr>
Who makes the determination<\/td>The security team, under the responsibility of the head of the entity<\/td>The controller, in practice with the DPO involved<\/td><\/tr>
Where the record remains<\/td>Registered incidents made available to the competent CSIRT<\/td>Breach documentation covering unreported breaches as well<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The table puts the concepts in order but does not replace the assessment of a specific event.<\/p>\n\n\n\n

\n\n

Remember<\/p>\n\n\n\n

What decides is what the event actually covered, not how it was labelled in the first internal ticket.<\/p>\n\n<\/div>\n\n\n\n

Where the outcome of both determinations is recorded<\/h3>\n\n\n\n

Each regime requires its own record. An essential or important entity gives the competent CSIRT access to information about registered incidents to the extent necessary for it to carry out its tasks. A controller documents any personal data breaches together with the circumstances, effects and remedial action taken, and the documentation has to enable the supervisory authority to verify compliance. The duty to document also covers breaches the organisation did not report.<\/p>\n\n\n\n

A single ticketing system will serve both obligations only if it has separate fields. It has to keep the moment of detection and the moment of awareness apart, the incident classification and the breach determination apart, and the reasoning behind each of the two decisions apart. A shared record with one date and one status looks tidy right up to the authority\u2019s first question about when and on what basis the organisation decided the matter.<\/p>\n\n\n\n

Four configurations of a single event<\/h2>\n\n\n\n
Situation<\/th>Incident under the KSC act<\/th>Breach under the GDPR<\/th>What follows<\/th><\/tr><\/thead>
Disruption of a process control system in which no personal data are processed<\/td>Yes<\/td>No<\/td>Handling and registration on the KSC side, classification against the thresholds; no obligations towards the data protection authority<\/td><\/tr>
Encryption of customer-facing systems by ransomware<\/td>Yes<\/td>Yes<\/td>Two tracks in parallel, two deadlines counted from different moments, two notifications with different content<\/td><\/tr>
Loss of paper documentation containing personal data<\/td>No<\/td>Yes<\/td>The GDPR track only \u2014 assessment of the risk to individuals, decision on notification, entry in the breach documentation<\/td><\/tr>
An event at a supplier processing data on the organisation\u2019s behalf<\/td>On the supplier\u2019s side, if it is covered by the act<\/td>On the organisation\u2019s side as controller<\/td>The supplier notifies the controller of the breach, and the controller decides whether to notify the authority<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The last row shows what causes the most trouble in practice. Both determinations may arise at two different entities in connection with a single event. The processing agreement should then set the time and channel for notification, because without it the controller learns of the matter at the end of the chain.<\/p>\n\n\n\n

Most common mistakes<\/h2>\n\n\n\n