First Steps and Internal Procedure in the Event of a Personal Data Breach

The first hours after a personal data breach has been discovered determine a great deal: the extent of the damage, compliance with the notification deadline, and the ability to demonstrate that the matter was handled properly. This page describes the internal procedure from detection through to the point at which the risk assessment and, where applicable, the notification take effect.

1. Detecting and containing immediately

1.1 Reporting a suspicion internally

Every response presupposes that a breach is detected at all and reported to the right place. Everyone in the organization should pass on a suspicion of a personal data breach internally without delay, as a rule to the data protection officer or to a designated reporting point. This requires a clear reporting channel that is known to all, and a culture around mistakes that places prompt reporting ahead of the search for culprits. Technical sources of indications, such as logging and alerting systems, belong in the same reporting channel.

1.2 Immediate containment measures

Even before the risk has been conclusively assessed, the obvious measures must be taken in order to stop the incident and to prevent it from spreading. Which measure is appropriate depends on the type of breach:

• Isolate the affected systems or disconnect them from the network.
• Reset compromised access credentials and block accounts.
• Remotely lock or wipe a lost or stolen device.
• Request an incorrect recipient to delete or return the data and obtain confirmation of the deletion.
• Restore data from a backup copy where availability is affected.

These measures matter twice over: they limit the damage, and they feed into the risk assessment, because a risk that has been effectively contained is to be classified as lower.

2. Preliminary review: does a breach exist?

Not every reported occurrence is a personal data breach. In the preliminary review, the competent unit clarifies whether the three requirements are met: a security incident that concerns personal data and impairs one of the protected interests of confidentiality, integrity, or availability. A transmission mistakenly based on the wrong legal basis, for example, infringes data protection law, but it is not a breach of data security and does not trigger the notification obligations under Articles 33 and 34 GDPR.

2.1 Immediate clarification instead of waiting

Where the suspicion is not confirmed of its own accord, the competent unit initiates the necessary clarification without undue delay in order to obtain certainty as to the nature and the extent of the matter. This clarification should begin as quickly as possible and be conducted with the requisite urgency. It serves to establish whether a breach exists, not to carry out a full forensic analysis; the latter can continue in parallel with the notification.

2.2 An unclear factual basis

The facts frequently do not lie open to view. For practical purposes, the following applies:

• Where an adverse outcome is established (for instance, a document from a personnel file surfaces in the press) without the route by which it got there having been clarified, a possible breach is to be inferred and the matter dealt with accordingly.
• Where the occurrence of a breach is established (for instance, an unintended outflow of data) without the cause being known, a breach is to be assumed.
• Where attack activity is documented but it is unclear whether it was successful (for instance, a reactivated account of a former employee), the controller bases its assessment on the premise that a breach has occurred (preliminary notification). It cannot exonerate itself by arguing that its own system is not transparent.
• Where it is demonstrable that no breach materialized, there is no personal data breach.

3. When does the breach count as known?

The point in time at which awareness is obtained is the starting point of the 72-hour period and thus the practically most important point in the entire procedure.

3.1 Sufficient certainty, not an initial suspicion

The breach is known as soon as the controller knows with sufficient certainty that a security incident has led to an impairment of personal data. A mere initial indication or suspicion is not yet sufficient for this. The following examples show when the threshold is crossed (EDPB, Guidelines 9/2022, paras. 33 et seq.):

• A lost unencrypted USB stick. Whether unauthorized persons have accessed it often cannot be established. The breach is nevertheless known at the moment the loss is noticed, because at least availability has been breached with sufficient certainty.
• An indication from a third party. Where a third party reports having inadvertently received a customer's data and provides evidence of this, the breach is known beyond doubt and immediately.
• A suspected intrusion. Where the controller notices a possible intrusion into its network, the breach is known only once the examination of the systems confirms the impairment.
• A ransom demand. Where an attacker makes contact after a hack with a ransom demand, the breach is known as soon as the controller has examined its system and confirmed the attack.

3.2 The clarification phase

Before sufficient certainty is reached, during the initial short clarification, the breach does not yet count as known; the period does not yet run. This clarification must, however, begin as quickly as possible and be conducted swiftly. From the perspective of the supervisory authorities, only a narrowly limited period of at most around 24 hours from the emergence of sufficient indications is defensible for it; where the clarification takes longer, this must be explained in the notification (the Bavarian Data Protection Commissioner (BayLfD), guidance on the obligation to notify and the obligation to communicate, para. 70). The phase serves to establish whether a breach exists, not to carry out a full forensic analysis; the latter can continue in parallel with the notification.

3.3 Attribution of awareness within the organization

In an organization built on a division of labor, what matters is whose knowledge is attributed to the controller. What is decisive is the awareness of a unit responsible for handling the incident (a knowledge agent), for instance the management, the unit responsible for the data protection organization, the business department affected, or the competent IT unit. The controller must organize its flow of information in such a way that a breach reaches these units in good time. Where the delayed awareness is due to organizational fault, the relevant point in time is the one at which awareness would have been expected had matters proceeded properly.

Two special cases must be borne in mind:

• Knowledge held solely by the data protection officer is not attributed to the controller, because the officer is free from instructions and bound to secrecy; the officer nevertheless works towards minimizing the risk and towards internal onward reporting (see tasks of the data protection officer).
• In the case of processing on behalf of a controller, the breach counts as known to the controller only once the processor has informed it (Article 33(2) GDPR).

4. The internal report: what information is needed

The internal report to the data protection officer or to the reporting point forms the basis for the risk assessment, the notification, and the communication. As far as it is known, it should contain the following information, and missing information should be supplied subsequently without undue delay:

• What happened? As precise a description of the incident as possible.
• Whose data? The categories of data subjects concerned (for instance, employees, customers, patients).
• How many people? The approximate number of data subjects concerned.
• Which types of data? Which categories of personal data are affected, including an indication of special categories under Article 9 GDPR.
• How many records? The approximate number of personal data records concerned.
• Since when has there been awareness? The date and time at which sufficient certainty about the breach existed.
• Who is reporting and can be contacted? The reporting person and the contact point.
• Which consequences and measures? The likely consequences as well as the measures already taken and those proposed in order to address and to mitigate the breach.

Where the breach concerns processing that the organization carries out on behalf of another party, that circumstance also belongs in the internal report, because the contracting controller must then be informed.

5. Special constellations: processors and joint controllers

Anyone who identifies a breach as a processor reports it to the controller without undue delay (Article 33(2) GDPR). The processor is not obliged to assess the risk or to notify the supervisory authority itself; that is a matter for the controller. No 72-hour period of its own applies to the processor, but the obligation to report without undue delay does; an infringement of that obligation is punishable by an administrative fine in its own right. As soon as the controller has been informed by the processor, the breach counts as known to the controller and its period begins.

The following overview shows the reporting chain and makes clear that the controller's 72-hour period only begins to run upon the processor's report.

Who bears which obligation is summarized in the following table.

In practice, the data processing agreement should regulate the response to a breach in advance (EDPB, Guidelines 9/2022, paras. 45 et seq.):

• a specific internal reporting deadline (for instance, within 24 hours), so that the controller is able to meet its 72-hour period;
• designated contact persons on both sides and how they can be reached;
• the minimum content of the processor's report, modeled on the information that the controller will itself need later on;
• whether the processor may notify the supervisory authority in the name of the controller, for which a power of attorney is required and for which legal responsibility nevertheless remains with the controller;
• the obligation, in multi-client operations, to inform each affected controller individually.

The full mandatory content of the data processing agreement is set out under processor. In the case of joint controllers, it is advisable to regulate expressly in the arrangement under Article 26 GDPR which controller undertakes the notification.