GDPR- סעיף 29 - דיווח על פריצת אבטחה

דיווח על אירועי אבטחה הוא חלק אינטגראלי מהחוק הישראלי. החל מה – 8 למאי, יש לדווח לרשות להגנת הפרטיות על אירועים מסוג זה.

במקביל, החל מה – 25 למאי, חברות ישראליות רבות גם כפופות לחובת דיווח לרגולטורים באירופה, עם כניסתו לתוקף של ה – GDPR.

הניתוח המצורף מסביר את השינויים בעמדת הרגולטורים באירופה בעניין הדיווח לאירועים. חשוב להכיר ולהתמצא מבעוד מועד בעמדת הרגולטורים ובשינויים שבין עמדותיהם באוקטובר 2017 ובפברואר 2018.

 

 

ARTICLE 29 WORKING PARTY:

GUIDELINES ON PERSONAL DATA BREACH NOTIFICATION

  • By Daniel Kobrinski & Dan Or-Hof

HIGHLIGHTS CHART:  Before getting to the comprehensive chart, for quick reference and review immediately below is a shorter Highlights Section chart that points out the most notable points of change or difference between the February and October Guidelines.   Following the shorter Highlights Section is the Main Chart. 

HIGHLIGHTS OF THE DIFFERENCES BETWEEN FEBRUARY AND OCTOBER GUIDLELINES

 

v  The Possible Consequences of a Personal Data Breach (Section I. B.3)

o   If controllers fail to notify either the supervisory authority or data subjects of a breach then supervisory authority has corrective measures at its disposal, including administrative fine of up to 10 million EUR or up to 2% of annual turnover. Note, that in some cases there could be more than one infringement connected with the same case.  For example, failure to notify the breach on one hand could also reveal absence of adequate security measures, another separate infringement.

o   February Guidelines makes reference to the WP29 guidelines on administrative fines, which state that if there are several different infringements committed together, the supervisory authority is able to apply the fines at a level which is “effective, proportionate and dissuasive” within the limit of the gravest infringement.

o   The October Guidelines did not include reference to a limit of the gravest infringement.

 

v  Notification to the Supervisory Authority

“When to Notify"

o   Article 33(1) – In case of personal data breach, the controller shall notify the supervisory authority within 72 hours (after becoming aware of it), unless the breach is unlikely to result in risk to the rights and freedoms of natural persons. 

o   February Guidelines make reference to Recital 87, which states:

o   “It should be ascertained whether all appropriate technological protection and organizational measures have been implemented to establish immediately whether a personal data breach has taken place and to inform promptly the supervisory authority and the data subject.

o   October Guidelines do not mention Recital 87 and this language in this section.

 

v  When does a controller become “aware?”

There is a 72-hour time frame for controller to notify of breach after having become “aware” of it.  WP29 considers that a controller should be regarded as having become “aware” when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.

o   February Guidelines, with reference to Recital 87, state that GDPR requires the controller to implement all appropriate technical protection and organizational measures to establish immediately whether a breach has taken place and inform promptly the supervisory authority and the data subjects.  

o   Whether the notification was made without undue delay is established by taking into account the nature and gravity of the breach and its consequences and adverse effects for the data subjects.

o   This puts an obligation on the controller to ensure that they will be “aware” of any breaches in a timely manner in order to take appropriate action.

 

o   October Guidelines do not contain this language obligating controller to establish immediately whether a breach has taken place.

 

v  Notification to the Supervisory Authority, continued.

 

The February and October guidelines list some practical steps to take –

o   Information concerning all security-related events should be directed towards a responsible person or persons with the task of addressing incidents, establishing the existence of a breach and assessing risk.

o   Risk to individuals as a result of a breach should then be assessed (likelihood of no risk, risk or high risk), with relevant sections of the organization being informed.

o   Notification to the supervisory authority, and potentially communication of the breach to the affected individuals should be made, if required.

o   At the same time, the controller should act to contain and recover the breach.

February Guidelines, (but not the October Guidelines) also add to this list –

o   Documentation of the breach should take place as it develops

 

v  Joint Controllers 

The February Guidelines contain a section on Joint Controllers.  The October Guidelines do not mention Joint Controllers.

Article 26 states joint controllers should determine their responsibilities respectively, including determining which of the parties has responsibility for complying with the obligations of Articles 33 and 34.  WP29 recommends that joint controllers should set out contractually which controller will take the lead on GDPR breach notification obligations.

 

 

v  Processor Obligations (Section II.A.4)

Article 33(2)– if a processor is used by a controller and the processor becomes aware of a breach of the personal data, it must notify the controller “without undue delay”.

o   The processor does not need to first assess the likelihood of risk arising from a breach before notifying the controller; it is the controller that must make this assessment on becoming aware of the breach. The processor just needs to establish whether a breach has occurred and then notify the controller.

o   In principle, the controller should be considered as “aware” once the processor has informed it of the breach.   

o   The February Guidelines specifically mention “informed”, whereas in the October Guidelines, the Controller should be considered as “aware” once the processor has become aware.

 

v  Cross-Border Breaches and Breaches at non-EU establishments  

In the February Guidelines they reference Cross-Border breaches and mention non-EU establishments. In the October Guidelines, they only mention breaches affecting individuals in more than one Member state.  

o   Art 3 deals with territorial scope of GDPR when it applies to processing by a controller or processor that is not establish in the EU.

o   Art 3(2) – GDPR applies to processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:

§  (a) offering of good or services (regardless of payment) to such data subjects in the Union, or

§  (b) the monitoring of their behavior as far as the behavior takes place within the Union.

 

v  Communication to the Data Subject (Section III)

Art 34 – When personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.  (Higher threshold than for notifying Supervisory Authority)

o   Information to be provided – Nature of the Data Breach in Clear and Plain Language

§  Description of the nature of the breach

§  Name and contact of the DPO or other point of contact

§  Description of the likely consequences of the breach

§  Description of measure taken or proposed by controller to address the breach

 

v  Contacting Individuals

o   Breach should be communicated to affected subjects directly, unless doing so involves disproportionate effort.  In such case, there should be a public communication.

o   February Guidelines differ from October Guidelines in that they say if breach affects data subjects who the controller has not previously interacted with, or those who reside in a different Member State or other non-EU country from where the controller is established, communication in the local national language could be acceptable, taking into account the resource required.

 

o   In February Guidelines, (but not in October) there is reference to Recital 86– such communication should be made in close cooperation with supervisory authority, and with guidance from other relevant authorities such as law enforcement.

 

o   Recital 88 –notification should take into account the legitimate interests of law enforcement authorities where early disclosure could hamper the investigation of the circumstances of a breach.  This means, in some cases, the controller may delay communication of the breach to individuals.

 

o   February Guidelines – Whenever its not possible for controller to communicate to an individual because there is insufficient data stored to contact the individual, the controller should inform the individual as soon as its reasonable feasible.

 

v  Accountability and record keeping (Section V)

 

§              Documenting breaches

o   Controller must keep documentation of all breaches, regardless of need for notification

o   February Guidelines (and not October) refer to Accountability principle of the GDPR, contained in Article 5(2).

§  The purpose of recording non-notifiable breaches, as well notifiable breaches, also relates to the controller’s obligations under Article 24, and the supervisory authority can request to see these records.

§  Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not

§  The GDPR does not specify a retention period for such documentation

 

§     Role of the Data Protection Officer

The DPO must also cooperate with the supervisory authority and act as a contact point for the supervisory authority and for data subjects.

o   February Guidelines also add –

§  for documenting breaches, the controller or processor may wish to obtain opinion of its DPO. DPO could be tasked with maintaining such records.

§  DPO should play key role in prevention, preparation and notification.  WP29 recommends that DPO is informed throughout the entire breach and notification process.  

 

 

MAIN CHART

 

 

Guidelines on Personal data breach notification – Revised Guidelines, February 2018

(Feb guidelines)

 

Guidelines on Personal data breach notification – October 2017 

(Oct guidelines)

 

I. Personal Data Breach Notification

 

B. What is a Personal Data Breach Notification?

 

1.  Definition: Article 4(12) defines it as…. “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed;”

 

The Feb guidelines expand upon terms contained in the definition.

 

·         “Destruction” is where the data no longer exists, or no longer exists in a form that is of any use to the controller.

·         “Damage” is where personal data has been altered, corrupted, or is no longer complete.

[Interestingly, the term “Damage,” is not mentioned in the Article 4(12) definition.]

·         “Loss” of personal data – this should be interpreted as the data may still exist, but the controller has lost control or access to it, or no longer has it in its possession.

·         “Unauthorized” or “unlawful” processing may include disclosure of personal data to (or access by) recipients who are not authorized to receive (or access) the data, or any other form of processing which violates the GDPR.

[Unlawful or Unauthorized are not used to modify the term processing in the 4(12) definition]

 

The Feb guidelines provide an Example of loss of personal data.

·         Example: where a device containing a copy of controller’s customer database has been lost or stolen.

·         Example: where the only copy of a set of personal data has been encrypted by ransomware, or encrypted by the controller using a key no longer in its possession.

 

[The Oct guidelines do not have this section]

 

 

B. What is a Personal Data Breach Notification? (continued)

1.  Definition: Article 4(12) defines it as…. “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed;”

 

What is a Personal Data Breach?

 

·         A breach is a type of security incident.  However, the GDPR only applies when there is a breach of personal data.  A personal data breach has the consequence that the controller will be unable to ensure compliance relating to processing of personal data as outlined in Article 5 of the GDPR.

 

·         This highlights the Difference between a security incident and a personal data breach – while all personal data breaches are security incidents, not all security incidents are necessarily personal data breaches.

 

Types of Personal Data Breaches

Categorized according to three well-known security principles

·         Confidentiality breach: unauthorized or accidental disclosure of or access to personal data.

·         Integrity breach: unauthorized or accidental alteration of personal data.

·         Availability breach: accidental or unauthorized loss of access or destruction of personal data.

 

Note: a breach can concern a mixture of all three of these.

An “Availability breach” is the least clear of the three categories.

Permanent vs Temporary Loss

When there has been permanent loss of or destruction of personal data, it is always regarded as an “availability breach.”

When there is a temporary loss of availability, this is considered to be a type of security breach, since the lack of access to the data can have a significant impact on the “rights and freedoms of natural persons.”

o   It goes on to clarify that when personal data is unavailable due to planned system maintenance, this is not a breach of security.

 

A breach involving temporary loss of availability should be documented in accordance with Article 33(5).

 

However, such breach may or may not require notification to the supervisory authority and communication to the affected individuals.

 

“Need to notify” depends on the likelihood and severity of the impact on “the rights and freedoms of natural persons” as a result of the lack of availability of personal data.  The Controller needs to assess the breach and will need to notify “unless the breach is unlikely to result in a risk to individuals rights and freedoms.” This is to be assessed on a “case by case basis.”

 

o   Stated in another way: if the breach is not likely to result in a risk to individual rights and freedoms, then the controller does not need to notify the supervisory authority and/or affected individuals.

 

Examples given by Guidelines:

·         In the case of a Hospital, if medical data about patients becomes temporarily unavailable, this could present a risk to individuals rights and freedoms since it could put patients lives at risk.

·         Conversely, if a media company is not able to send out a newsletter to subscribers due to their systems being unavailable for several hours because of a storm, this is unlikely to be a risk to individuals rights and freedoms.

 

It should be noted that although loss of availability of a controller’s systems might only be temporary and might not have an impact on individuals, it may still require notification for other reasons.

Example: Infection by ransomware that leads to a temporary loss of availability that itself does not present a risk to individuals rights and freedoms; however notification could still be required because the network intrusion may also be qualified as a confidentiality breach (i.e. personal data is accessed by the attacker) and this could be a risk to the rights and freedoms of individuals.

 

In short, “temporary availability” breaches are more difficult to assess and the controller will need to measure the likelihood and severity of the impact on the rights and freedoms of natural persons concerned.

3. The Possible Consequences of a Personal Data Breach

 

·         The importance of being able to identify a breach, to assess the risk to individuals, and then notify if required, is emphasized in Recital 87 of the GDPR

 

Further guidelines on assessing the risk to individuals are considered in section IV.

 

 

If controllers fail to notify either the supervisory authority or data subjects of a breach (even though Articles 33 and/or 34 are fulfilled) then supervisory authority has corrective measures at its disposal, including administrative fine of up to 10 million EUR or up to 2% of annual turnover.

 

Important note: in some cases, the failure to notify a breach could reveal either an absence of existing security measures or an inadequacy of the existing security measures. In that case, the supervisory authority will have possibility to issue sanctions for failure to notify the breach on the one hand, and absence of adequate security measures on the other hand, since they are two separate infringements.

 

·         Makes reference to the the WP29 guidelines on administrative fines, which state: “The occurrence of several different infringements committed together in any particular single case means that the supervisory authority is able to apply the administrative fines at a level which is effective, proportionate and dissuasive within the limit of the gravest infringement”.  (seems to limit fine to the limit of the gravest infringement)

 

·         [This paragraph did not exist in the Oct guidelines.]

 

I.                    Article 33 – Notification to the Supervisory Authority

 

A.      When to Notify

 

1.       From Article 33(1) – In case of personal data breach, the controller shall notify the supervisory authority within 72 hours (after becoming aware of it), unless the breach is unlikely to result in risk to the rights and freedoms of natural persons.

 

Feb Guidelines include a section here that references Recital 87.

 

Recital 87 states:

 

“It should be ascertained whether all appropriate technological protection and organizational measures have been implemented to establish immediately whether a personal data breach has taken place and to inform promptly the supervisory authority and the data subject. The fact that the notification was made without undue delay should be established taking into account in particular the nature and gravity of the personal data breach and its consequences and adverse effects for the data subject. Such notification may result in an intervention of the supervisory authority in accordance with its tasks and powers laid down in this Regulation.”

 

Oct guidelines do not include this paragraph from Recital 87

 

When does a controller become “aware?”

 

(As stated above, there is a 72-hour time frame for controller to notify of breach after having become “aware” of it).

 

·         WP29 considers that a controller should be regarded as having become “aware” when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.

 

·         Feb guidelines again (with reference to Recital 87 above) state that GDPR requires the controller to implement all appropriate technical protection and organizational measures to establish immediately whether a breach has taken place an inform promptly the supervisory authority and the data subjects.   Whether the notification was made without undue delay is established by taking into account the nature and gravity of the breach and its consequences and adverse effects for the data subjects.

 

·         This puts an obligation on the controller to ensure that they will be “aware” of any breaches in a timely manner in order to take appropriate action.

 

·         Oct guidelines does not have this paragraph]

 

 

 

 

 

 

 

 

 

 

 

 

·         Not in Oct guidelines

 

When, exactly, a controller can be considered to be “aware” of a particular breach will depend on the circumstances of the specific breach?

 

This (becoming “aware”) will depend on the circumstances of the specific breach.

 

In some cases it might be clear from outset there is a breach, while in others it may take time to establish if personal data has been compromised.  the emphasis should be on prompt action to investigate an incident to determine whether personal data have indeed been breached, and if so, to take remedial action and notify if required.

 

Examples

 

1. In the case of a loss of a USB key with unencrypted personal data,  it might not be possible to know if unauthorized persons gained access to that data.  Nevertheless, even though even though controller may not be able to establish a confidentiality breach, such a case has to be notified as there is a reasonable degree of certainty that an availability breach has occurred; the controller would become “aware” when it realized the USB key had been lost.

 

4. A cybercriminal contacts the controller after having hacked its system in order to ask for a ransom. In that case, after checking its system to confirm it has been attacked the controller has clear evidence that a breach has occurred and there is no doubt that it has become aware.

 

Examples

 

In the case of a loss of a CD with unencrypted data,  it might not be possible to know if unauthorized persons gained access.  Nevertheless, such a case has to be notified as there is a reasonable degree of certainty that an availability breach has occurred; the controller would become “aware” when it realized the CD had been lost.

 

 

 

 

A cybercriminal contacts the controller after having hacked its system in order to ask for a ransom. In that case the controller has clear evidence that a breach has occurred and there is no doubt that it has become aware.

 

After being informed of a potential breach by an individual, a media organization, or another source, or when it has itself detected a security incident, the controller may undertake a short period of investigation in order to establish whether or not a breach has in fact occurred. During this period of investigation the controller may not be regarded as being “aware”.  However, its expected an investigation should begin as soon as possible and establish with reasonable degree of certainty if a breach took place.

 

·         Once controller has become aware, a notifiable breach must be notified without undue delay, and when feasible, within 72 hours.

·         However, a controller may already have an initial assessment of the potential risk that could result from a breach as part of a data protection impact

assessment (DPIA) made prior to carrying out the processing operation concerned. However, the DPIA may be more generalized in comparison to the specific circumstances of any actual breach, so an assessment taking into account those circumstances will need to be made. For more detail on assessing risk, see section IV.

·         The controller should therefore have internal processes in place to be able to detect and address a breach. It is important that when a breach is detected it is reported upwards to the appropriate level of management so it can be addressed and, if required, notified in accordance with Article 33 and, if necessary, Article 34.

·         The controller should also have in place arrangements with any processors the controller uses, which themselves have an obligation to notify the controller in the event of a breach (see below).

 

Some practical steps to take –

 

·         Information concerning all security-related events should be directed towards a responsible person or persons with the task of addressing incidents, establishing the existence of a breach and assessing risk.

·         Risk to individuals as a result of a breach should then be assessed (likelihood of no risk, risk or high risk), with relevant sections of the organization being informed.

·         Notification to the supervisory authority, and potentially communication of the breach to the affected individuals should be made, if required.

·         At the same time, the controller should act to contain and recover the breach.

 

·         Documentation of the breach should take place as it develops

 

It should be clear that there is an obligation on the controller to act on any initial alert and establish whether a breach has occurred. This brief period allows for some investigation. However, once controller has established with some reasonable degree of certainty that a breach has occurred, if the conditions of Article 33(1) have been met, it must notify supervisory authority without undue delay and no later than 72 hours.

 

Joint Controllers

* Article 26 concerns joint controllers.  The joint controllers should determine their responsibilities respectively.  This include determining which of the parties has responsibility for complying with the obligations of Articles 33 and 34.  WP29 recommends that joint controllers should set out contractually which controller will take the lead on compliance with GDPR breach notification obligations.

 

Oct guidelines have no section on Joint Controllers

 

Processor Obligations.

The controller has overall responsibility for protection of personal data but the processor has an important role to play to assist the controller in compliance, including with breach notification.

 

·         Article 33(2) makes clear – if a processor is used by a controller and the processor becomes aware of a breach of the personal data, it must notify the controller “without undue delay”.

 

·         Note:  the processor does not need to first assess the likelihood of risk arising from a breach before notifying the controller; it is the controller that must make this assessment on becoming aware of the breach. The processor just needs to establish whether a breach has occurred and then notify the controller.

·         In principle, the controller should be considered as “aware” once the processor has informed it of the breach.   (Feb guidelines specify “informed”)

·         There is not explicit time limit within which processor must alert the controller, just “without undue delay.”

·         The Controller and Processor should have in their contract, specifications on how the requirements “of Processor alerting Controller without undue delay (Article 33(2))” are to be met, in addition to other provisions in the GDPR. 

This can include requirements for early notification by the processor.

 

 

 

 

 

 

 

 

·         In principle, the controller should be considered as “aware” once the processor has become aware

 

·         There is not explicit time limit within which processor must alert the controller, just “without undue delay.”

·         As is explained above, controllers are required to specify how the requirements expressed in Article 33(2) should be met in their contract with their processors.  

 

 

 

 

 

·         A processor could make a notification on behalf of the controller, if the controller has given the processor the proper authorization and this is part of the contractual arrangements between controller and processor.

·         Its important to note however, that the legal responsibility to notify remains with the controller (which is why it is key that the controller specifies that processors obligations in the contract. )

 

Providing Information to the Supervisory Authority

 

1. Information to Be Provided

 

Article 33(3) says that, at minimum, the notification should:

a.       Describe nature of personal data breach, including (if possible) the types of individuals (data subjects) and personal data records concerned

b.       Provide name/details of data protection officer, or other point of contact

c.       Describe likely consequence of attack

d.       Describe measures taken or proposed to be taken by the controller to address the personal data breach

·         Recital 85 clarifies that one of the purposes of notification is limiting damage to individuals. Thus, if the types of data subjects or types of personal data indicate a risk of a particular type of damage (identify theft, fraud, etc.), it is important the notification indicates these categories.  This is connected to describing the likely consequences of the breach.

·         When precise information is not available, GDPR allows for approximations to be made in numbers of individuals or personal data records affected. Important thing is addressing the adverse effects rather than providing precise figures.  Notification in phases is also a possibility. See below.

·         Controller can provide further details as more become known, or the supervisory authority may request further details as part of its investigation.

 

2.  Notification in Phases

Art 33(4): Where its not possible to provide information at the time, information may be provided in phases, without undue further delay.

·         GDPR recognizes controller will not have all necessary information within 72 hours of becoming aware of breach.

·         WP29 recommends that when the controller first notifies the supervisory authority, the controller should also inform the supervisory authority if the controller does not yet have all the required information and will provide more details later on.

 

3.  Delayed Notification

Art 33(1) – where notification to supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

·         This recognizes that controller may not always be able to notify a breach within that time period.

·         For example, a controller may experience multiple confidentiality breaches over a short time.  Controller might create a notification that “bundles” together information representing all of the breaches, and this could take more time.

 

C. Cross-Border Breaches and Breaches at non-EU establishments (difference in title of section)

 

1. Cross-border breaches

C. Breaches affecting individuals in more than one Member state

 

When there is cross bordering processing of personal data, a breach may affect subjects in more than one Member state.

 

Art 33(1) – makes clear that controller should notify the supervisory authority that is competent in accordance with Art 55 of the GDPR.

 

Art 55(1) states each supervisory authority is competent for its own member state.

 

Art 56(1) states supervisory authority of the main establishment of the controller or processor shall be competent to act as lead supervisory authority for cross border processing.

 

56(6) – The lead supervisory authority shall be the sole interlocutor of the controller or processor for cross border processing.

In summary, when there is a cross border breach, the controller will need to notify the lead supervisory authority. Therefore, when drafting its breach response plan, a controller must make an assessment as to which supervisory authority is the lead supervisory authority to notify.

 

When notification must be made to the lead supervisory authority, that is not necessarily where the affected data subjects are located, or indeed where the breach has taken place. When notifying the lead authority, the controller should indicate, where appropriate, whether the breach involves establishments located in other Member States, and in which Member States data subjects are likely to have been affected by the breach.

 

If the controller has any doubt as to the identity of the lead supervisory authority then it should, at a minimum, notify the local supervisory authority where the breach has taken place.

 

2. Breaches at non-EU establishments

 

Art 3 concerns territorial scope of GDPR including when it applies to processing by a controller or processor that is not establish in the EU.

 

Art 3(2) states – GDPR applies to processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:

(a) offering of good or services (regardless of payment) to such data subjects in the Union, or

(b) the monitoring of their behavior as far as the behavior takes place within the Union.

 

Art 3(3) – GDPR applies to processing of personal data by a controller that isn’t in the EU, but in a place where Member State law applies vis a vis public international law.

 

Article 27 – requires a controller (and processor) to designate a representative in the EU where Article 3(2) applies. WP29 recommends that notification should be made to the supervisory authority in the Member State where the controller’s representative in the EU is established.

 

Similarly, where a processor is subject to Article 3(2), it will be bound by the obligations on processors, including the duty to notify a breach to the controller under Article 33(2).

 

 

 

No section on breaches at non-EU

 

D. Conditions where Notification is not required

 

Article 33(1) – breaches that are “unlikely to result in a risk to the rights and freedoms of natural persons” do not require notification to the supervisory authority.

Example – personal data is already publicly available and disclosure of such data does not constitute a likely risk to the individual.

 

III. Article 34 – Communication to the Data Subject

 

A. Informing Individuals

 

Art 34(1) states – When personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject (individual) without undue delay.

·         The threshold for communicating a breach to individuals is higher than for notifying supervisory authorities.

·         Without undue delay – as soon as possible.

·         Annex B of the guidelines provides many examples of when breach meets the “high risk” threshold.

 

B. Information to be provided

 

34(2) Communication shall describe in clear and plain language the nature of the personal data breach and contain at least –

·         Description of the nature of the breach

·         Name and contact of the dpo or other point of contact

·         Description of the likely consequences of the breach

·         Description of measure taken or proposed by controller to address the breach

C. Contacting Individuals

 

Breach should be communicated to affected subjects directly, unless doing so involves disproportionate effort.  In such case, there should be a public communication or similar measure where subjects are informed in an equally effective manner.

 

·         Controllers may need to ensure the communication is accessible in alternative formats and languages.

·         However, if breach affects data subjects who the controller has not previously interacted with, or those who reside in a different Member State or other non-EU country from where the controller is established, communication in the local national language could be acceptable, taking into account the resource required.

 

 

·         Controllers are best placed to determine most appropriate contact channel, and may wish to contact/consult supervisory authority on best way to inform data subjects, and most appropriate way to contact individuals.

·         Recital 86 points out – such communication should be made in close cooperation with supervisory authority, and with guidance from other relevant authorities such as law enforcement.

·         Recital 88 – advises that notification should take into account the legitimate interests of law enforcement authorities where early disclosure could hamper the investigation of the circumstances of a breach.  This means, in some cases, the controller may delay communication the breach to individuals.

·         Whenever its not possible for controller to communicate to an individual because there is insufficient data stored to contact the individual, the controller should inform the individual as soon as its reasonable feasible.

 

 

D. Conditions where communication is not required

Art 34(3) – three conditions where if met, notification to individuals is not required.

·         Controller has applied appropriate technical and organizational measures to protect personal data prior to breach, e.g. state of the art encryption, or tokenization

·         Immediately after breach, controller takes steps to ensure that the high risk posed to individuals rights and freedoms is not likely to materialize. (depends on nature of data)

·         It involves disproportionate effort to contact individuals (perhaps contact details have been lost) and instead controller must make a public communication or something similar.

In accordance with the accountability principle controllers should be able to demonstrate to the supervisory authority that they meet one or more of these conditions.

Note that notification might not initially be required, but conditions could change and the risk needs to be re-evaluated.

If controller decides not to communicate breach to individuals, supervisory authority can still require it to do so if it determines breach is a high risk to individuals.

 

IV.  Assessing risk and high risk

 

A. Risk is a trigger for notification

 

 Notification to the competent supervisory authority is required unless a breach is unlikely to result in a risk to the rights and freedoms of individuals.

Communication of a breach to the individual is only triggered where it is likely to result in a high risk to their rights and freedoms.

 

B. Factors to consider when assessing risk

 

Recitals 75 and 76 – generally when assessing risk, consideration should be given to both the likelihood and severity of the risk to the rights and freedoms of data subjects.

Risk should be evaluated on the basis of an objective assessment.

·         Accordingly, when assessing the risk to individuals the controller will consider specific circumstances relating to the breaches severity and potential impact.

·         WP29 recommends to take into account the following criteria:

o   The type of breach

o   The nature, sensitivity, and volume of personal data

o   Ease of identification of individuals

o   Severity of consequences for individuals

o   Special characteristics of the individual

o   Special characteristics of the data controller

o   The number of affected individuals

o   General points

 

V. Accountability and record keeping

 

A. Documenting breaches

 

Controller must keep documentation of all breaches, regardless of need for notification

 

·         This is linked to the accountability principle of the GDPR, contained in Article 5(2). The purpose of recording non-notifiable breaches, as well notifiable breaches, also relates to the controller’s obligations under Article 24, and the supervisory authority can request to see these records. Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not

 

·         The GDPR does not specify a retention period for such documentation.

·         This is linked to the accountability principle of the GDPR, contained in Article 5(2).

 

 

 

 

Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not

 

 

B. Role of the Data Protection Officer

 

Relating to breach notification, the mandatory tasks of the DPO includes: providing data protection advice and information to the controller or processor, monitoring compliance with the GDPR, and providing advice in relation to DPIAs. The DPO must also cooperate with the supervisory authority and act as a contact point for the supervisory authority and for data subjects.

·         for documenting breaches, the controller or processor may wish to obtain opinion of its DPO. DPO could be tasked with maintaining such records.

·         DPO should play key role in prevention, preparation and notification.  WP29 recommends that DPO is informed throughout the entire breach and notification process.

 

 

VI. Notification obligations under other legal instruments

 

Controllers should also be aware of other legislation that may apply to them that might also require them to notify the supervisory authority of a personal data breach at the same time.

 

Examples of notification requirements in other legal instruments, and how these inter-relate with the GDPR, include the following:

 

·         Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation)

 

o   “Article 19(2) of the eIDAS Regulation requires trust service providers to notify their supervisory body of a breach of security or loss of integrity that has a significant impact on the trust service provided or on the personal data maintained therein. Where applicable—i.e., where such a breach or loss is also a personal data breach under the GDPR—the trust service provider should also notify the supervisory authority.”

 

o   This requires trust service providers to notify their supervisory body of a breach

 

·         Directive (EU) 2016/1148 concerning measures for a high common level of security of network and information systems across the Union (NIS Directive)

 

o   Articles 14 and 16 of the NIS Directive require operators of essential services and digital service providers to notify security incidents to their competent authority. As recognised by Recital 63 of NIS51, security incidents can often include a compromise of personal data.

o   Though NIS requires competent authorities and supervisory authorities to co-operate and exchange information that context, it remains the case that where such incidents are, or become, personal data breaches under the GDPR, those operators and/or providers would be required to notify the supervisory authority separately from the incident notification requirements of NIS.

 

o   Both operators of essential services and digital service providers are required to notify security incidents, which may include personal data, to their competent authority.

 

·         Directive 2009/136/EC (the Citizens’ Rights Directive) and Regulation 611/2013 (the Breach Notification Regulation).

 

o   Providers of publicly available electronic communication services within the context of Directive 2002/58/EC37 must notify breaches to the competent national authorities

 

 

 

VII.  Annex

 

SEE FLOWCHART