The GDPR is one of the most complex and far-reaching laws on privacy and data protection. Today’s complex IT environments makes this even more challenging. After all, organisations must ensure that their entire ecosystem meets the requirements of the GDPR.
This is not so easy, as the GDPR contains many open standards and imposes “efforts” on the controller (and to a limited extent on the processors). This can lead to frustrations within organisations. The GDPR may stipulate that something must be done, but it gives little direction as to when the result will actually be good (enough): it often remains unclear how something should be done.
GDPR is a general law
Sometimes we forget that the GDPR is a general law. This means, among other things, that the rules/terms of the GDPR are open for interpretation. For example, it says that organisations must provide an “adequate” level of protection for personal data, but it does not define what is meant by “adequate”.
The consequence? This gives most supervisory authorities (such as our GBA) a broad discretion in determining fines for non-compliance and data breaches under the GDPR.
Advantages and disadvantages
Open standards in the GDPR provide more flexibility. This is a blessing for the creative GDPR experts/jurists among us. At the same time, however, open standards mainly create ambiguity and uncertainty. Which is a nightmare for entrepreneurs.
An ambiguous GDPR is an advantage for creative GDPR experts/jurists: after all, there is room to fill in certain things. As a result, it is not always clear for organisations in advance what is exactly expected of them. Only a general framework is provided. This lack of clarity is a major disadvantage for entrepreneurs, who are willing to make an effort, but of course want to know where they stand.
Complementary to the GDPR
To shed some light on the issues in the GDPR, we need to look at the ever-growing published material from the European Data Protection Board, national supervisory authorities (such as our GBA), judges and European courts. It will therefore take some time before all aspects of the GDPR have been made clarified. We must also take into account that the interpretations and additions will “evolve” over time.
A data breach as a practical example
what does the GDPR say?
Article 4 of the GDPR provides a definition of what is meant by a data breach:
“A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”
This would mean that attempts to make a computer, computer network or service inaccessible or harder to reach would not directly fall under the definition of a data breach.
What does the European Data Protection Board say?
However, in 2016 the WP29 (now the EDPB) issued a guideline on the interpretation of a data breach, in which the definition from the GDPR is interpreted very broadly.
According to this broad interpretation, the temporary inability to access personal data is a breach of the availability of the personal data and therefore constitutes a data breach. This concern has subsequently also been adopted in the recent EDBP directive (status: open for public consultation) on examples for reporting data breaches.
A DDoS attack IS a data breach!
But what is it about?
DDoS attack (distributed denial of service) means that hackers make attempts to make a computer (network) inaccessible for regular visitors or users. To do so they use a large number of devices that they have previously been able to hack. This collection of hacked computers is also called a ‘botnet’. Often the owners of these hacked devices do not know that their computer is being used for cybercrime.
From the botnet, the hacker allows all devices to connect simultaneously to a selected server. This suddenly high concentration of data traffic means that the server no longer can process all these requests properly, with the result that the system first slows down considerably, and then even crashes. A successful DDoS attack will therefore result in the (temporary) inaccessibility of the selected server.
A server that is inaccessible to the public does not mean that the data stored on it is lost or corrupted. On the contrary, it can be argued that this data is still there, safe and sound.
It is even possible that the administrator of the server can still access the data via another method, so that it is not completely technically unavailable . In other words, a successful DDoS attack may bring down the portal through which the data is normally accessed, but will leave the underlying data untouched.
According to the EDPB, an incident will always be considered a breach of availability if personal data is permanently lostor destroyed, but also if an incident occurs that results in personal data being unavailable for a certain period of time.
The question that comes up here is, how far does this go? Should we look at this from a technical point or from the point of view of the data subjects (to whom the personal data belongs)?
Of course, we must analyse the situation from the point of view of the person concerned, since access to their personal data has temporarily failed. This is the entire principle of the GDPR: to protect the rights and freedoms of the data subjects. In other words, data subjects must remain in control of their personal data.
Therefore, the main implication of the loss of availability of the personal data is that the controller was temporarily deprived of access to the personal data in order to comply with data subjects’ requests for access, rectification, portability, etc.
The availability of any other technical means of accessing the central systems should be seen as a measure to overcome the personal data breach and not as an argument for concluding that there has not been a personal data breach.
A successful DDoS attack can therefore burden the data controller with an obligation to notify the responsible supervisory authority of a data breach, unless it is unlikely that the breach will pose a risk to the rights and freedoms of the data subjects! For any help with the analysis of this and how to tackle it, you can always call on our GDPR specialists at via firstname.lastname@example.org.
Written by Duygu Öztürk, CIPP/E, Privacy Chair theJurists, and Kris Seyen, Partner theJurists.