Home

Wat moet een melding van een datalek bevatten?

Eerder schreef ik een artikel (zie hier) over datalekken betreffende persoonsgegevens, en waar u die moet melden. Hierin richtte ik mij op het doorgronden van de ‘leidende toezichthoudende autoriteit’. In dit artikel richt ik mij op de inhoud van een melding van gegevensinbreuk volgens de AVG.

Voordat u dit artikel verder leest is het belangrijk om op te merken dat de melding aan één van twee belanghebbenden gericht kan zijn: de toezichthoudende autoriteit en/of de betrokkenen (de ‘slachtoffers’ van het datalek). Door gebruik te maken van AVG compliancesoftware kunt u dit proces ondersteunen en uw vermogen om aan de AVG-eisen te voldoen verbeteren.

Belanghebbenden op de hoogte brengen in het geval van een datalek

Artikelen 33 en 34 AVG onderscheiden drie verschillende scenario’s:

•   Een inbreuk resulteert waarschijnlijk niet in een risico voor de rechten en vrijheden van natuurlijke personen (art. 33(1) AVG). In dit geval is geen melding nodig, maar de inbreuk moet voor aansprakelijkheidsdoeleinden geregistreerd worden binnen uw organisatie.

•   Een inbreuk resulteert waarschijnlijk in een risico voor de rechten en vrijheden van natuurlijke personen (art. 33(1) AVG). In dit geval moet een melding worden gedaan aan de toezichthoudende autoriteit.

•   Een inbreuk resulteert waarschijnlijk in een groot risico voor de rechten en vrijheden van natuurlijke personen. In dit geval moet ook de betrokkene worden verwittigd, in aanvulling op de melding aan de toezichthoudende autoriteit (art. 34(1) AVG).

Er wordt gesteld dat de derde situatie onderhevig is aan drie uitzonderingen (art. 34(3) AVG):

•   De persoonsgegevens zijn op een zodanige manier weergegeven dat ze onbegrijpelijk zijn, bijvoorbeeld door encryptie (en de decryptiesleutel is nog steeds veilig);

•   Het hoge risico zal onwaarschijnlijk plaatsvinden dankzij erop volgende maatregelen;

•   De melding zou buitenproportionele moeite kosten.

Volgens mij zijn deze inbreuken echter geen echte uitzonderingen, omdat de eerste twee eigenlijk het ‘groot’ uit ‘groot risico’ wegnemen voor de betrokkene. En de derde is evengoed een melding op een andere manier.

Houd er alstublieft rekening mee dat de toezichthoudende autoriteit beslist over de noodzaak van een melding aan een betrokkene. Daarmee zijn zij degene die het begrip 'groot risico’ en de uitzonderingen interpreteren.

avg

Waar moet een melding uit bestaan?

Meldingen aan de toezichthoudende autoriteit worden gedaan onder art. 33 AVG. Volgens dit artikel moet een melding de volgende onderdelen bevatten:

  • de aard van de inbreuk, inclusief waar mogelijk:
    • de categorieën en het aantal betrokkene bij benadering;
    • de categorieën van persoonsgegevens en het betreffende aantal persoonsgegevensregisters;
  • de naam en de contactgegevens van de functionaris voor gegevensbescherming, of van een ander contactpersoon;
  • een beschrijving van de waarschijnlijke gevolgen van de inbreuk in verband met persoonsgegevens voor de betrokkene;
  • de genomen maatregelen om de inbreuk in verband met persoonsgegevens aan te pakken, waaronder de maatregelen ter beperking van de eventuele nadelige gevolgen daarvan voor de betrokkene;
  • indien de melding niet wordt gedaan binnen 72 uur nadat de verwerkingsverantwoordelijke notie van de inbreuk nam, moeten de redenen voor het oponthoud worden opgegeven

Houd er rekening mee dat u altijd een register van datalekken moet bijhouden, zelfs wanneer u ervoor kiest om de inbreuk niet te melden.

Inhoud van een melding aan de betrokkene

Aan de inhoud van een inbreukmelding aan de betrokkene worden de volgende eisen gesteld (art. 34 AVG):

  • de naam en de contactgegevens van de functionaris voor gegevensbescherming, of van een ander contactpersoon;
  • een beschrijving van de waarschijnlijke gevolgen van de inbreuk in verband met persoonsgegevens voor de betrokkene;
  • de genomen maatregelen om de inbreuk in verband met persoonsgegevens aan te pakken, waaronder de maatregelen ter beperking van de eventuele nadelige gevolgen daarvan voor de betrokkene;
  • indien de melding niet wordt gedaan binnen 72 uur nadat de verwerkingsverantwoordelijke notie van de inbreuk nam, moeten de redenen voor het oponthoud worden opgegeven.
     

Deze eisen weerspiegelen de vereisten uit art. 33 (3), met uitzondering van de aard van de overtreding. Dit is vreemd; men mag verwachten dat de betrokkene op zijn minst wordt geïnformeerd over de categorieën van persoonsgegevens die onderdeel uitmaken van het datalek. Op die manier kan de betrokkene reageren (bijvoorbeeld door het wijzigen van een gelekt wachtwoord).

Hoewel de artikelen 33 en 34 AVG geen afwijkingen in de nationale wetgeving toelaten is het ook belangrijk om te beseffen dat toezichthoudende autoriteiten een manier moeten bieden om inbreuken bij hen te melden. Zij kunnen bij het ontwerpen van de relevante (web)formulieren veel vrijheid nemen met betrekking tot de vragen die zij stellen. In de praktijk kan dit ertoe leiden dat er meer vragen worden gesteld dan welke deel uitmaken van de letterlijke artikelen 33 en 34.

The GDPR imposes many rights and obligations on organisations that require software support. Any software supplier will have to make decisions on how to interpret the GDPR. Because of the countless vague concepts in the Regulation, suppliers will have different interpretations. Therefore, it will be quite a challenge to connect software offerings to each other. Connections are desirable from a collaboration and efficiency perspective.

Some practical applications of software connections in the GDPR compliance domain are:

  • Data breach notifications to the supervisory authorities (instead of filling in web forms manually)
  • Connections between data discovery tooling and article 30 registers (in order to inventory uses of personal data automatically)
  • Data portability between different article 30 register software applications (enabling changing software suppliers while keeping data entered)
  • Exchange of processing activities between controllers and processors (allowing for easier completion of the article 30 register)

Most of these examples relate to article 30, requiring a register of processing activities. Many of the other rights and obligations of the GDPR relate to insight into an organisation's 'privacy landscape', and therefore will have some link to the article 30 register.

To establish software connections, applications need to 'talk' to each other. They often do this via so-called 'application programming interfaces' (APIs). For these to function, a standardised model of the GDPR is highly desirable. This model would describe the exact attributes of GDPR concepts such as personal data categories, data subject categories, controllers and processors.

Over the past months, we talked to many people about the description of processing activities in varying ways. For instance, one description had a purpose on the level of individual categories of personal data instead of only on a processing level. Another had linked personal data categories to data subject categories. And a third had assigned retention terms to systems instead of personal data categories.

We know that all these description choices were made with very good reasons, although they do not literally follow from the GDPR. Anyone describing a processing activity will have their own focus points, depending on their governance model as well as local policies and practices. The problem is that once descriptions will vary, it also becomes very difficult to reuse such descriptions among software systems.

In the current absence of further guidance from the European Data Protection Board (EDPB), organisations, law firms, consultancy firms and software suppliers also have to guess what the meaning is of the exact wording of GDPR articles, article 30 in particular. Being a lawyer, I know that it is impossible to remove all vagueness from a law. Concepts rarely have a binary meaning.

Of course, the text of the GDPR is full of political compromises, allowing important decisions to be made later in time, by supervisory authorities and courts. But there is a lot of uncertainty among privacy professionals about whether they comply. Even the Dutch Supervisory Authority, currently doing a survey among organisations in different sectors about their article 30 register, formulates its questions cautiously.

This high degree of uncertainty begs the questions: why was there not a more precise approach to, for instance, the article 30 register? A more formally specified description of elements and relations between them, explaining what entities and which relations should be kept for each processing record, would have helped decreasing that uncertainty. It would also facilitate the automated communication on the register between stakeholders.

Hopefully there will be clear guidance from the EDPB on the article 30 register soon, allowing controllers and processors to be more certain about the entities and relations they need to put into the register, as well as providing clarity on the degree of detail of the inventory. This will both increase legal certainty as well as improve efficiency of the software market for GDPR compliance.

Laurens Mommers
COO PrivacyPerfect

Laurens Mommers
COO PrivacyPerfect

PrivacyPerfect is een AVG compliance-softwareleverancier die in meerdere branches werkt.