An employee sent a file to the wrong recipient, a storage system was left publicly accessible, or an attacker obtained administrator credentials. In each of these situations, the company needs to quickly determine whether personal data has been affected and whether obligations under the GDPR arise.
The company may have 72 hours to notify the supervisory authority. During this time, it must contain the incident, gather technical information, assess the risk to individuals, and decide whether notification is required. If there is no internal response procedure, the legal and technical teams begin determining their obligations only after the problem has been discovered, when part of the deadline has already been lost.
The GDPR uses the term personal data breach, which is broader than the commonly used term data leak. A breach is a security incident that results in the accidental or unlawful destruction, loss, alteration, disclosure of, or access to personal data.
Breaches are generally associated with one or more of the following consequences:
Therefore, unauthorized copying of a database, sending a document to the wrong recipient, deleting information without a backup, a ransomware infection, or prolonged unavailability of a critical system may fall within the scope of the GDPR.
An information security incident is not always a personal data breach. If an attacker gained access only to anonymized technical information, Articles 33 and 34 of the GDPR may not apply. This conclusion should be verified, as logs and technical identifiers can sometimes be used to identify an individual and may constitute personal data.
The legal assessment should be conducted in parallel with the technical investigation. Waiting for the final report may result in missing the notification deadline, while hastily deleting systems and logs may destroy important evidence.
The company records the time of the initial report, the source of the information, and the details available at that stage. System monitoring alerts, user reports, event logs, and internal communications related to the discovery of the incident should be preserved. An accurate timeline will help determine when the company had a reasonable degree of certainty that a breach had occurred and when the 72-hour period began.
The technical team closes external access, revokes compromised credentials, terminates active sessions, and isolates affected systems. The specific actions depend on the nature of the incident, but they should not destroy information required for the investigation. If data was mistakenly sent to a known recipient, the company contacts that person, asks them to delete the file, and requests confirmation that the information has not been copied or forwarded.
The company needs to establish which systems were compromised, which categories of personal data they contained, and how many individuals may have been affected. Payment, health, biometric information, documents, and credentials should be reviewed separately. Approximate figures are acceptable at the initial stage. The investigation continues after notification, so the scope of the incident can be updated as new facts become available.
The controller decides whether to notify the supervisory authority and data subjects. The processor informs the controller of the incident without undue delay and provides the information necessary to assess its consequences. If several contractors are involved in the processing, the DPA should be reviewed to determine who is responsible for the investigation, notifications, and communication with subprocessors.
The company analyzes the likelihood of harm to individuals and the severity of the potential consequences. It then determines whether an internal record is sufficient or whether the supervisory authority and users must be notified. The decision should be documented in writing. If no notification is made, the documentation should specify the data, circumstances, and measures on the basis of which the risk was considered unlikely.
The controller must notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of the breach. A company is considered aware when it has a reasonable degree of certainty that an incident involving personal data has occurred. An initial indication of unusual activity may be investigated. However, an internal investigation cannot be used to delay the start of the deadline if the facts already confirm that a breach has occurred.
If processing is performed by an external contractor, the contractor must notify the controller of the breach without undue delay. The GDPR does not establish a separate 72-hour deadline for processors. A specific timeframe is usually established in the DPA because the controller needs sufficient time to conduct its own assessment.
The absence of complete details does not justify postponing notification until the investigation is complete. The GDPR allows information to be provided in phases. The initial notification may contain the information currently available, with additional details provided later. If the deadline is missed, the controller must explain the reasons for the delay.
The company’s obligations depend on the risk to the rights and freedoms of individuals. The more serious the potential consequences, the broader the notification requirements.
| Assessment of Consequences | Notification of the Supervisory Authority | Notification of Users | What the Company Should Do |
| Risk to individuals is unlikely | Not required | Not required | Document the incident, risk assessment, and measures taken in the internal register |
| There is a likelihood of risk | Required within 72 hours, where feasible | Usually not required | Notify the supervisory authority and continue the investigation |
| High risk is likely | Required within 72 hours, where feasible | Required without undue delay | Notify the supervisory authority and affected individuals, providing recommendations on protective measures |
The table reflects the general approach under Articles 33 and 34 of the GDPR. The assessment must be based on the circumstances of the specific incident. The same type of data may create different levels of risk depending on its volume, the recipient, the safeguards applied, and the circumstances of the affected individuals.
Notification of the supervisory authority is required if the breach is likely to result in a risk to the rights and freedoms of natural persons. Notification is not required where such a risk is unlikely.
The assessment should take into account:
Disclosure of a single email address to a trusted counterparty and publication of a database containing passport, health, or payment data create different levels of risk. If a mistakenly sent file was immediately deleted, the likelihood of harm may be lower, but the circumstances should still be documented.
Encryption also does not automatically eliminate the need for an assessment. The company should determine whether the key was protected, whether the encryption algorithm can be circumvented, and whether the information remains available. The loss of a securely encrypted device may not create a risk of disclosure, but the absence of a backup may result in a loss of availability.
The notification should describe the nature of the breach, the categories and approximate number of affected data subjects, and the categories and approximate number of personal data records concerned. The company should provide the details of the DPO or another contact person, describe the likely consequences, and specify the measures taken or proposed to address the breach and mitigate its effects.
The supervisory authority needs a factual report. The company should explain which systems were affected, when the incident began and ended, what access the unauthorized party obtained, and why the company concluded that a risk exists.
The investigation continues after the initial notification. The company should provide material updates if the scope of the data, the number of affected individuals, or the assessment of the consequences changes.
The company must inform affected individuals of the breach if it is likely to result in a high risk to their rights and freedoms. The threshold is higher than for notifying the supervisory authority. Therefore, the supervisory authority may need to be notified even when users do not.
A high risk may arise from the disclosure of passwords, financial information, documents, health information, or data that could be used for fraud, discrimination, or identity theft.
The notification should be written in clear language. It should describe the nature of the breach, its likely consequences, the contact person, and the measures already taken by the company. Users should also be informed of specific steps they can take to protect themselves, such as changing their password, terminating active sessions, enabling multi-factor authentication, or contacting their bank.
Individual notification may not be required if the data was protected by measures that render it unintelligible to unauthorized persons or if the company has eliminated the likelihood of a high risk. Where individual notification would involve disproportionate effort, a public communication or comparable measure may be used. The decision should be justified, and the supervisory authority may require the company to notify affected individuals.
The controller must document all personal data breaches, including those it decides not to report to the supervisory authority. The records should describe the circumstances, consequences, and measures taken. If no notification was made, the risk assessment and the reasons for the decision should be retained. A brief statement such as “no risk” is not sufficient. The documentation should make clear what data was affected, who may have gained access to it, and which measures reduced the likelihood of harm.
Such a register helps demonstrate GDPR compliance during an audit and identify recurring issues. Several minor incidents caused by the same access settings may indicate a systemic deficiency even if none of the individual cases required notification.
Companies often start counting the 72-hour period only after completing their internal investigation. This approach may result in a missed deadline because the period is linked to the point at which the company has a reasonable degree of certainty that a breach has occurred.
Another mistake is waiting for final figures. The GDPR allows information to be provided in phases, so the absence of a complete list of affected individuals does not justify delaying the initial notification.
Problems also arise when working with contractors. A processor may report an incident several days later, the DPA may not specify contact persons or an information-sharing procedure, and the controller may be unable to quickly determine which data and subprocessors have been affected.
A public announcement cannot automatically replace individual notification. If the company has contact details for the affected individuals and can reach them without disproportionate effort, publishing a notice on the website may not be sufficient.
The company should have an incident response procedure, clearly allocated responsibilities, and an up-to-date contact list. The procedure should determine who may classify an event as a personal data breach, who communicates with processors, who prepares notifications, and where the incident register is maintained.
Notification templates and a list of required information should be prepared in advance. Agreements with processors should establish practical notification deadlines and an obligation to provide the information necessary for the risk assessment.
If a provider reports a breach after 72 hours or merely states that a possible incident has occurred, the controller may be unable to fulfill its own obligations on time.
Wolja Digital helps IT companies prepare data breach response procedures, allocate responsibilities between teams, and align contractual terms with processors.
In the event of an incident, we determine whether the GDPR applies, assess the risk to data subjects, review whether the supervisory authority and users must be notified, and help prepare notifications and internal documentation. Following the investigation, we analyze the causes of the breach and align DPAs, records of processing activities, security measures, and internal procedures with the product’s actual operations.