As of May 25, 2018, the AVG is applicable. The AVG includes a data breach notification obligation (arts. 32 and 33). The Article 29 Working Group has drafted Guidelines indicating how this mandatory notification should be interpreted.
This blog discusses the differences between the duty to notify under the AVG and our current duty to notify under Article 34a Wbp. It concludes that there are many similarities but also important differences. However, the Article 29 Working Party's Guidelines, which are supposed to clarify the duty to report, create ambiguity on a number of points.
The notification obligation under the AVG is similar to the notification obligation under the PDPA that we have known since January 1, 2016 (Art 34a), but also has some important differences textually. Following the publication of the Guidelines on Personal data breach notification under Regulation 2016/679 ("Guidelines") in October 2017, it is clear how the Article 29 Working Party believes the articles should be interpreted. This interpretation differs in points from the interpretation that the Autoriteit Persoonsgegevens Protection ("AP") has laid down in its Beleidsregels meldplicht datalekken ("Policy Rules") with respect to the notification obligation under the Wbp.
Currently, it is still difficult for organizations to determine whether a data breach has occurred and, if so, whether that data breach must be reported. Under the AVG, this seems to become even less easy. In this context, the Article 29 Working Group repeatedly advises to draw up a thorough incident response protocol so that it is clear which steps must be followed at the moment an incident is detected.
Under the Wbp, a data breach must be reported to the AP if, in short, there is a breach of security that has (a significant likelihood of) serious adverse consequences. This high threshold was implemented to prevent unnecessary reports.
Under the AVG, there must also be a breach of security. So far, nothing new. What is new is that "any personal data breach" must be reported to the AP unless it is unlikely to pose a risk. There seems little doubt that this is a lower threshold than the "serious adverse effect" threshold as it applies under the Wbp until May 25.
For a portion of data breaches, this lower threshold will not make a difference. If there is a data breach where "sensitive data" has been leaked (including special personal data, financial data, password/login name combination) it will have to be reported under both the Wbp and the AVG.
It gets trickier if there is no leakage of special personal data. Then the "nature" and "extent" of the leaked data must be used to determine whether a notification is required. Under the AVG, this consideration could lead to a notification sooner. The Guidelines include a number of circumstances that should be taken into account when assessing whether a notification to the AP is required. However, these points remain quite general so it remains difficult for organizations to make a proper consideration. Because the threshold for reporting will be lower under the AVG, the AP will have to deal with more rather than fewer reports.
After reporting to the AP, it must be determined under 34a Wbp whether the data subject must also be informed about a data leak. This must be done if the leak has 'probably adverse consequences' for the data subject. This threshold for reporting to the data subject seems lower than the threshold for reporting to the AP ('serious adverse consequences' versus 'likely adverse consequences') so that in practice a notification to the AP will also include a notification to the data subject. This is different only if there is proper encryption (see below).
Under the AVG, this is different. A notification to the AP must take place for every incident involving personal data unless the data breach is unlikely to pose a risk. A notification to the data subject must then take place if the data breach is likely to pose a high risk (Art. 34 AVG). Here the threshold for reporting to the data subject is higher than for reporting to the AP. For organizations, this means that after reporting to the AP, an actual new consideration must be made for reporting to the data subject.
Regarding informing the data subject, the AVG lists three exceptions in Article 34. If there is good encryption, the data subject does not have to be informed. In addition, informing is not required if this requires disproportionate effort. In that case, a public announcement will suffice. In the Policy Rules, the AP already included these two exceptions as well so nothing changes here in practice.
The third exception is less logical. If the controller has subsequently taken steps to ensure that the high risk is unlikely to recur, notification to the data subject is not required. This seems like mustard after the fact. A breach has occurred with all its consequences, but because retrospective measures have been taken, notification is not required. The Guidelines nuance the scope of this exception. An example is given of a hacker who has stolen data where the hacker can be caught before he has distributed the data. In such a case, the data breach has already occurred but measures have been taken such that there is no risk of further dissemination. Explained in this way, this exception does not add much to Article 34 AVG. If the hacker was not able to do anything with the data, there is no high risk for data subjects so the notification would not be required even on that basis.
Article 34a Wbp has a layered structure. First, an organization must determine whether a leak must be reported to the AP. If it does not, the matter is closed. There is then no need to consider whether notification to the data subject is required.
The Guidelines seem to maintain this layered structure and even assign supervisors a kind of advisory role. Supervisors can advise reporting organizations on how to inform those involved. However, this advisory role is immediately curtailed by the fact that the Guidelines state that the reporting party itself remains fully responsible for whether or not to notify the data subject. One cannot wait for any advice from the supervisor. In fact, the Guidelines indicate that under specific circumstances the party concerned must be notified first before the supervisor is informed.
There is thus no longer a layered structure as there was under the Wbp. In addition to assessing whether the data breach must be reported to the AP, it must at the same time be determined whether the data subject should not first be informed.
Article 33 AVG states that, in principle, a notification to the supervisor must be made within 72 hours (this is the same under the Wbp). It is important to determine when this deadline will run.
Under the Wbp, the 72-hour period starts to run from the moment the controller or processor learns of an incident that may be a data breach under Article 34a Wbp. Thus, the clock starts running with each discovery of an incident. The objection to this is that the responsible party gets into trouble if the processor does not report quickly enough. This can lead to a notification being made for safety in order to meet the deadline. The notification can then be withdrawn later. This is not in line with the legislator's desire to prevent unnecessary reporting as much as possible. On the other hand, the advantage is that there can be no discussion about when the deadline starts to run.
The AVG uses a different structure. Article 33 states that the 72-hour period starts to run at the moment the data controller has become aware ("is aware") of a data breach that must be reported. According to the Guidelines, there must be a "reasonable degree of certainty" that the data breach must be reported. To arrive at this degree of certainty, the controller has a "short period of investigation" to determine whether the incident is reportable.
This means that i) the start of the deadline is not dependent on a discovery by the processor and ii) the controller has time in certain cases to determine whether a data breach has occurred before the deadline starts. This gives the controller more time but also ensures that the deadline no longer starts at a fixed point in time. Organizations must determine when they are expected to be "aware.
The Article 29 Working Party further complicates matters. Namely, the Guidelines state that the processor is an extension of the controller. This means that the moment the processor becomes "aware," the controller is also deemed to be "aware. In that case, the 72 hours starts running from the moment of discovery by the processor.
Upon discovery of an incident by the processor (which will often be the case), it must first be determined whether the processor was "aware. If yes, then so is the controller and the 72-hour period begins at that point. If no, it must be determined whether the controller is "aware" at the time it receives the notification. If so, he has 72 hours to notify. If not, he has a limited time to investigate the incident. If he becomes "aware" sometime during this investigation, the 72-hour period starts at that point.
Incidentally, the Article 29 Working Party's explanation that the 72 hours start running as soon as the processor is "aware" is poorly reconciled with Article 33 AVG. After all, it means that the processor must independently determine whether there is a data breach that needs to be reported. However, that consideration should not be done by the processor, but should lie with the controller.
Article 34(3) AVG states that a notification to the data subject is not required if the personal data that has been leaked has been properly encrypted. In the Policy Rules, the AP also discusses this extensively so nothing seems to change on this point.
Here again, however, the Article 29 Working Group creates confusion. Indeed, in the Guidelines, it indicates that if the encryption is good, there is also no need to notify the regulator.
In itself, there is something to be said for this explanation. After all, if there is good encryption, there are no risks (or serious adverse consequences) for the protection of personal data. It can be argued that in that case no notification is required at all.
However, this explanation is poorly consistent with Article 34(3) AVG. This is because the exception in the context of encryption is included in the article about reporting to the data subject. It can be deduced that a data leak of encrypted data does have to be reported to the AP. After all, Article 33 AVG does not contain an exception for leaked encrypted data.
The Article 29 Working Party also plays little clarification on the last difference to be discussed here between the data breach notification obligation under the AVG and that under the Wbp. The Guidelines indicate that under circumstances, temporary unavailability of personal data is also a data breach that must be reported. An example is a hospital where the systems are down due to a DDOS attack resulting in operations being temporarily unavailable. No personal data was lost, nothing was accessed or copied, but the data is simply temporarily unavailable. The loss of a planned operation affects the individual's privacy so that it constitutes a data breach, the Guidelines say.
This interpretation of the Article 29 Working Party is, in my opinion, inconsistent with the AVG. The definition of a personal data breach is as follows:
"a breach of security resulting in the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or unauthorized access to, data transmitted, stored or otherwise processed;"
I do not see how a temporary inaccessibility of data, without having been destroyed or otherwise unlawfully processed, can fall under this definition.
The Guidelines indicate that this is only the case if the temporary inaccessibility has far-reaching consequences for the data subjects, which is unlikely to occur. In principle, if a retailer's website is down for a while, there will be no data breach. Nevertheless, in my opinion, this interpretation of the Article 29 Working Party goes too far.
The conclusion is that the data breach notification requirement under the AVG combined with the explanations in the Guidelines, makes it even less easy for organizations to determine whether a data breach must be reported. In any case, a good Incident Response Protocol is a must.
Read the Article 29 Working Group's Guidelines here.
This article can also be found in the Data Breach file
More articles by SOLV Lawyers
