Cybersecurity incident vs personal data breach: what is the difference?

Why the question comes up at all

The first source of doubt is linguistic. In most organisations the word “incident” means anything that went wrong in the systems — 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.

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.

The third source is organisational and the most practical. The determination is usually made in a single meeting and led by a single role — 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.

What to establish before deciding

What each concept covers

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 — together with the data processed in electronic form. The point of reference is therefore the system and the service that system supports.

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 — the definition covers data transmitted, stored or otherwise processed.

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 it may lead to one of the listed consequences. The third condition is often read too narrowly. It is enough that the consequence is possible — a lost storage device holding data is a breach even if nobody accessed the data.

One terminological caveat is needed here, because without it the two documents look contradictory. A “security incident”, as the guide uses the term, is a general concept and also covers events outside ICT systems. An “incident” 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.

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. 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.

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.

Who each obligation applies to

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.

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 before they merge the two tracks into a single procedure.

There are also the transitional provisions, without which the picture is false. The amendment to the KSC act entered into force on 3 April 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 — including incident handling and reporting — within 12 months, that is by 3 April 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 — 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.

From which moment time starts running

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 of a significant incident. The deadline towards the President of UODO runs from becoming aware of a breach, that is, from the moment the controller obtained sufficient certainty that an event concerning personal data had occurred.

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 covered in a separate material on incident response.

What threshold triggers a notification

The thresholds are built differently too and cannot be used interchangeably. What must be reported is a significant 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: the number of users affected by the disruption, the duration of the incident’s effect on the service, the geographical spread and other factors specific to the sector.

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 31 October 2018, issued under the original act. It contains thresholds for six sectors of the former operators of essential services — from energy and transport to digital infrastructure — 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.

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 covered in a separate material on the notification threshold.

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.

What each notification contains

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: 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.

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.

What the difference looks like in brief

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

The table puts the concepts in order but does not replace the assessment of a specific event. What decides is what the event actually covered, not how it was labelled in the first internal ticket.

Where the outcome of both determinations is recorded

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.

A single ticketing system will serve both obligations only if it has separate fields: the moment of detection and the moment of awareness apart, the incident classification and the breach determination apart, 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’s first question about when and on what basis the organisation decided the matter.

Four configurations of a single event

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

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.

Most common mistakes

• A determination made by a single role. The security team closes the matter as a low-severity incident and the information never reaches the data protection officer. What is missing then is not so much the notification as the assessment of whether there was anything to notify.
• Carrying thresholds across regimes. Assessing a breach by the number of affected service users instead of by the risk to individuals systematically understates the result, because an event of limited reach can involve special categories of personal data.
• A shared register without separate fields. One date, one status and one set of reasons mean the organisation has failed one of the two documentation obligations.
• Copying the content of one notification into the other. A description of the effect on the service does not answer questions about the categories and number of individuals or the likely consequences for them, so a notification built that way is incomplete from the outset.
• Concluding that failing to qualify under the KSC act removes breach obligations. The regimes have different personal scopes. An organisation outside the register of essential and important entities is fully subject to the GDPR.
• Treating the KSC transitional period as a suspension of all obligations. The adjustment deadlines concern only the obligations under the KSC act. The duty to notify a breach runs unchanged throughout.

Conclusions and next steps

After every event two questions have to be asked separately: whether the event affected or could have affected the security of information systems, and whether it touched personal data or could have led to that. The answer to the first does not decide the answer to the second, and settling one regime does not close the other. An organisation that asks only one of those questions is not so much taking a bad decision as failing to take the second one at all.

Before the next event it is worth settling four things. Who asks the second question and at what point in handling the matter. How the register is built so that it holds two moments, two determinations and two sets of reasons. Where the incident classification thresholds come from and by what criteria the risk to individuals is assessed. From when the obligations under the KSC act genuinely bind the organisation, taking the transitional provisions into account.

Separating the two determinations does not increase the number of procedures. It usually leads to one procedure in which two decisions have named owners and separate places in the documentation — and it is that change, rather than the scale of the event itself, that later decides what the organisation is able to demonstrate.

Related materials

• What to do after detecting an incident? — the order of actions in the first 24 hours, preserving evidence and the parallel running of deadlines.
• Does every data breach need to be reported? — the notification threshold and the assessment of risk to the rights and freedoms of individuals.
• Does every organization fall under NIS2? — the qualification of an entity, which decides whether incident obligations arise at all.
• What should a personal data breach register contain? — what to record once the event has been classified, including where there is no breach.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), Article 4(12), Article 33 and Article 34, consolidated text — EUR-Lex: eur-lex.europa.eu (accessed 19 August 2026)
• Act of 5 July 2018 on the National Cybersecurity System, Article 2(3d), (5), (7) and (14), Articles 11, 12 and 12a, consolidated text — Chancellery of the Sejm, ISAP: isap.sejm.gov.pl (in Polish; accessed 19 August 2026)
• 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 and 33 — transitional provisions, Journal of Laws: dziennikustaw.gov.pl (in Polish; accessed 19 August 2026)
• Regulation of the Council of Ministers of 31 October 2018 on the thresholds for treating an incident as significant (Journal of Laws 2018, item 2180) — Chancellery of the Sejm, ELI: api.sejm.gov.pl (in Polish; accessed 19 August 2026)
• Guide to personal data breaches, version of 20 February 2025 — Personal Data Protection Office (UODO): uodo.gov.pl (in Polish; accessed 19 August 2026)
• Other obligations and provisions related to breaches — Personal Data Protection Office (UODO): uodo.gov.pl (in Polish; accessed 19 August 2026)