Een kwetsbaarheid is nog geen datalek

Een kwetsbaarheid is een zwakke plek in je beveiliging; een datalek ontstaat pas als persoonsgegevens daadwerkelijk zijn ingezien, gewijzigd, verloren of vernietigd. De meldtermijn van 72 uur uit de AVG start daarom pas als je redelijk zeker weet dat er gegevens zijn geraakt. Tot die tijd onderzoek je direct en leg je elke stap en afweging vast.

Marcel van Langen
Delen op X (Twitter) Delen op Facebook Delen op LinkedIn Delen via WhatsApp Delen op Pinterest Delen via e-mail Delen op Reddit Meer manieren om te delen

Er komt een kwetsbaarheid op je bord. Uit een pentest, via een mail van je leverancier of omdat een collega iets vreemds ziet in de rechten op een gedeelde map. De reflex is bij veel organisaties dezelfde: snel melden bij de Autoriteit Persoonsgegevens, want de klok tikt. Begrijpelijk, maar vaak te vroeg. In dit stuk lees je wat het verschil is tussen een kwetsbaarheid en een datalek, wanneer de meldtermijn echt begint en wat je in de tussentijd vastlegt. Handig voor privacy officers, informatiebeveiligers en iedereen die op vrijdagmiddag weleens zo'n mail heeft gekregen.

In het kort

  • Een kwetsbaarheid is een oorzaak. Een datalek is een gevolg: persoonsgegevens zijn echt geraakt.
  • De 72 uur gaan lopen als je redelijk zeker weet dat er gegevens zijn geraakt. Onderzoek mag eerst, maar dan wel meteen.
  • Meld je niet, leg dan vast waarom. En los de kwetsbaarheid hoe dan ook op.

Vrijdagmiddag, kwart voor vijf

Je kent het wel. Je bent eigenlijk al met je hoofd in het weekend en dan komt er een mail binnen van een softwareleverancier. "Wij hebben een beveiligingsprobleem in onze applicatie verholpen. Het probleem bestond sinds de update van drie weken geleden." Einde bericht. Of het pentestrapport komt binnen en daar staat een bevinding in met het label high: via een foutje in de toegangsrechten konden ingelogde gebruikers bestanden van andere klanten opvragen.

Wat nu? Het voelt als een datalek. De 72 uur uit de AVG schieten door je hoofd. Moet je nu al bellen, mailen, melden?

De aanleiding voor dit artikel was een scherp LinkedIn-stuk van Marlon Domingus, met privacyjurist Jeroen Terstegge als gast. Hun stelling: een kwetsbaarheid is nog geen datalek, en organisaties melden vaak te snel. Daar zijn we het van harte mee eens. Wij wilden er alleen een praktische kant aan toevoegen: wat doe je op dat moment concreet, en hoe zorg je dat je over een halfjaar nog kunt uitleggen waarom je deed wat je deed?


Drie begrippen die door elkaar lopen

Het helpt om eerst de begrippen uit elkaar te trekken. In de praktijk worden ze namelijk dagelijks door elkaar gebruikt.

  • Kwetsbaarheid: een zwakke plek in je beveiliging. Een ongepatchte server, een verkeerde instelling, een te ruim rechtenprofiel. Er hoeft nog niets mee gebeurd te zijn.
  • Beveiligingsincident: er is iets misgegaan in je beveiliging. Een kwetsbaarheid die ontdekt is, een phishingmail waarop iemand heeft geklikt, een gestolen laptop.
  • Datalek: een beveiligingsincident waarbij persoonsgegevens daadwerkelijk zijn vernietigd, verloren, gewijzigd, verstrekt of ingezien door iemand die dat niet mocht. Zo staat het in artikel 4 lid 12 van de AVG.

Een vergelijking. Je ontdekt 's ochtends dat je auto de hele nacht niet op slot heeft gestaan. Dat is een kwetsbaarheid, en eerlijk gezegd ook een beetje dom. Maar voordat je aangifte doet, kijk je eerst of je laptop nog op de achterbank ligt. Ligt hij er nog en is er niets aan de hand? Dan heb je geluk gehad. Is hij weg? Dan heb je een probleem van een heel andere orde.

Zo werkt het met datalekken ook. De AVG kijkt naar het gevolg, niet naar de oorzaak. Terstegge wijst er terecht op dat de gedachte "we kunnen niet uitsluiten dat er iets is gebeurd, dus melden we" uit de oude Wet bescherming persoonsgegevens (Wbp) komt. Die wet is sinds 2018 vervangen door de AVG, en dat criterium is niet meegekomen. Toch zit het bij veel organisaties nog diep in het systeem.

Dat de vraag "is het misbruikt?" ertoe doet, zag je goed bij twee bekende gevallen. Begin 2020 adviseerde het NCSC Nederlandse organisaties om hun Citrix-servers zo nodig uit te zetten vanwege een ernstige kwetsbaarheid. Heel veel organisaties waren kwetsbaar, maar lang niet overal is daadwerkelijk ingebroken. Bij de MOVEit-kwetsbaarheid in 2023 lag dat anders: daar werden bij honderden organisaties wereldwijd echt gegevens buitgemaakt. Dezelfde soort oorzaak, een heel ander gevolg.


Wanneer gaat de klok lopen?

Volgens artikel 33 AVG meld je een datalek zonder onredelijke vertraging en zo mogelijk binnen 72 uur nadat je er kennis van hebt genomen. De vraag is dus: wanneer heb je kennis genomen?

De Europese privacytoezichthouders hebben daar een antwoord op gegeven in de EDPB-richtsnoeren 9/2022 over het melden van datalekken. Kort gezegd: je hebt kennis genomen zodra je redelijk zeker weet dat er een incident is dat persoonsgegevens heeft geraakt. Niet op het moment dat je IT-afdeling een vreemd signaal ziet, en ook niet pas als het forensisch onderzoek helemaal klaar is. Ergens daartussen.

Dat geeft je ruimte voor een kort vooronderzoek. Maar let op: die ruimte is geen excuus om het op de stapel te leggen tot maandag. Wie een melding van een leverancier drie dagen laat liggen, kan niet volhouden dat de klok nog niet liep. Begin dus direct.

Zo'n vooronderzoek bestaat meestal uit een paar vragen:

  1. Welke persoonsgegevens waren via deze kwetsbaarheid bereikbaar, en van hoeveel mensen?
  2. Hoe lang bestond de kwetsbaarheid, en hoe makkelijk was hij te vinden?
  3. Wat zeggen de logbestanden? Zorg dat je ze veiligstelt voordat ze automatisch worden overschreven.
  4. Zijn er andere aanwijzingen voor misbruik, zoals afwijkend verkeer of meldingen van betrokkenen?

Logbestanden zijn overigens geen heilige graal. Er staat lang niet altijd in of iemand iets heeft ingezien, en soms zijn ze er gewoon niet. Dan onderbouw je je conclusie op een andere manier, bijvoorbeeld met een technische reconstructie of met de vraag wie de kwetsbaarheid überhaupt kon bereiken.

Weet je na dat vooronderzoek dat het mis is, maar heb je nog niet alle details? Meld dan toch op tijd. De AVG staat toe dat je in fasen meldt en later aanvult (artikel 33 lid 4).

Zit de kwetsbaarheid bij een leverancier die persoonsgegevens voor je verwerkt? Dan moet die verwerker een datalek zonder onredelijke vertraging aan jou melden. De afweging of er naar de AP moet, maak je als verwerkingsverantwoordelijke zelf. Een mail als die van vrijdagmiddag is dus vooral een startsein om door te vragen. Goede afspraken daarover in je verwerkersovereenkomst schelen een hoop gedoe. Meer daarover lees je in onze serie over leverancierbeoordeling.


Melden of niet?

Stel dat er wel echt gegevens zijn geraakt. Dan ben je er nog niet. De AVG kent drie uitkomsten:

  • Onwaarschijnlijk risico: je registreert het datalek intern, maar meldt het niet bij de AP.
  • Risico: je meldt het datalek binnen 72 uur bij de Autoriteit Persoonsgegevens.
  • Hoog risico: je meldt het bij de AP én je informeert de betrokkenen zelf (artikel 34 AVG).

Melden is de regel, niet melden de uitzondering. Die uitzondering moet je kunnen onderbouwen. Factoren die meewegen zijn de gevoeligheid van de gegevens (een BSN of medische gegevens wegen zwaarder dan een e-mailadres), het aantal betrokkenen, hoe makkelijk mensen te herkennen zijn, de mogelijke gevolgen voor die mensen en wie de gegevens heeft gezien. Een e-mail met een klantenlijst die per ongeluk bij een collega van een andere afdeling belandt, is iets anders dan dezelfde lijst op een openbaar forum.

Wil je dat wat gestructureerder aanpakken? Het Europese agentschap ENISA heeft een methode om de ernst van een datalek te beoordelen. Die is al wat ouder, maar geeft een prima houvast als je je afweging op papier wilt zetten.

En bij twijfel? Dan meld je. Een melding die achteraf geen datalek blijkt, kun je aanvullen of intrekken. Daar krijg je geen boete voor. Te laat of niet melden is wel een zelfstandige overtreding.


Wat je hoe dan ook vastlegt

Hier zit naar onze bescheiden mening het belangrijkste punt, en het punt waar het in de praktijk het vaakst misgaat. Organisaties besteden veel energie aan de vraag "melden of niet", en daarna wordt het stil. Er is wat gemaild, iemand heeft gebeld met de leverancier, en een halfjaar later weet niemand meer precies wat er is besloten en waarom.

De AVG is daar duidelijk over. Volgens artikel 33 lid 5 leg je elk datalek vast, ook als je het niet meldt. En ga je niet melden, dan moet je kunnen laten zien hoe je tot die conclusie bent gekomen. Dat betekent in de praktijk:

  • wat er is ontdekt, wanneer, en door wie;
  • welke stappen je in het vooronderzoek hebt gezet en wat die opleverden;
  • je risicoafweging en het besluit om wel of niet te melden;
  • de maatregelen die je hebt genomen, en de afspraken met je leverancier.

Leg ook het beveiligingsincident vast als het uiteindelijk geen datalek blijkt te zijn. Dat lijkt overbodig, maar dat is het niet. Een kwetsbaarheid blijft namelijk een tekortkoming in je beveiliging, en daar heb je volgens artikel 32 AVG sowieso een verplichting. "Er is niets gelekt" betekent niet dat je de deur open kunt laten staan. Bovendien leer je ervan: komt dezelfde soort kwetsbaarheid drie keer terug, dan hoort die thuis in je risicoanalyse.

Even een terzijde voor organisaties die onder de Cyberbeveiligingswet vallen. Die wet heeft een eigen meldplicht voor significante incidenten, met een eerste melding binnen 24 uur. Dat staat los van de AVG: een incident kan significant zijn zonder dat er een persoonsgegeven bij betrokken is. Het omgekeerde kan ook. Twee meldplichten, twee afwegingen. Des te meer reden om alles op één plek bij te houden.


Zo leg je het vast in Normity

In Normity is een datalek gewoon een type incident, dat je zelf aanmaakt naast je andere incidenttypen. Je registreert het in dezelfde incidentmodule als andere beveiligingsincidenten, en je kunt een kwetsbaarheid dus net zo goed vastleggen als incident van een ander type. Blijkt na het vooronderzoek dat er toch gegevens zijn geraakt? Dan pas je het type aan en werk je in hetzelfde incident verder. Zo raakt de geschiedenis niet kwijt.

Normity - datalek registreren als incident

Een paar dingen die daarbij helpen:

  • Melding AP: je geeft per incident aan of het gemeld is bij de Autoriteit Persoonsgegevens, op welke datum, en met welk meldnummer. Deze velden zet je aan via je klantinstellingen.
  • Logboek: hier leg je stap voor stap vast wat je hebt onderzocht en besloten. Dat is precies de onderbouwing die je nodig hebt als je niet meldt.
  • Analyse: de oorzaak en de lessen die je eruit trekt.
  • Acties: de maatregelen om de kwetsbaarheid te dichten, met een eigenaar en een deadline.
  • Koppelingen: je koppelt het incident aan de betrokken applicaties, bedrijfsmiddelen en documenten, zoals het pentestrapport of de mail van je leverancier.
Normity - melding bij de Autoriteit Persoonsgegevens vastleggen

Het mooie is dat dit niet los staat van de rest van je managementsysteem. Je verwerkingsregister, je verwerkers en je risicoanalyse zitten in dezelfde omgeving. Wil je weten welke verwerkingen via die ene applicatie lopen, en dus welke persoonsgegevens er mogelijk bereikbaar waren? Dan klik je door. Hoe we privacy verder in Normity hebben ingericht, lees je in privacy bijhouden in Normity. Werk je met ISO 27001 of ISO 27701, dan koppel je het incident ook nog aan de bijbehorende normelementen. Voor de auditor is dat prettig, en voor jezelf eigenlijk ook.

Kortom: bij een kwetsbaarheid onderzoek je snel en leg je je afweging goed vast. Een paniekmelding op vrijdagmiddag is zelden nodig. En mocht je nieuwsgierig zijn hoe dat er bij jou uit zou zien, neem dan even contact met ons op. We laten het je graag zien.

kwetsbaarheid datalek datalek melden meldplicht datalekken 72 uur Autoriteit Persoonsgegevens AVG artikel 33 AVG artikel 34 AVG beveiligingsincident inbreuk in verband met persoonsgegevens datalekregister EDPB richtsnoeren 9/2022 ENISA pentest verwerker verwerkersovereenkomst Cyberbeveiligingswet incidentmanagement privacy Normity
Delen op X (Twitter) Delen op Facebook Delen op LinkedIn Delen via WhatsApp Delen op Pinterest Delen via e-mail Delen op Reddit Meer manieren om te delen

Veelgestelde vragen over kwetsbaarheden en datalekken

De vragen die we het vaakst krijgen over kwetsbaarheden en datalekken, met korte en feitelijke antwoorden.

Nee, niet automatisch. Een kwetsbaarheid is een zwakke plek in je beveiliging. Een datalek is er volgens artikel 4 lid 12 van de AVG pas als persoonsgegevens daadwerkelijk zijn vernietigd, verloren, gewijzigd, verstrekt of ingezien door iemand die dat niet mocht. Je moet dus eerst onderzoeken of de kwetsbaarheid ook echt is misbruikt.

De termijn van 72 uur uit artikel 33 AVG begint op het moment dat je redelijk zeker weet dat er persoonsgegevens zijn geraakt. Volgens de Europese privacytoezichthouders (EDPB) mag je daarvoor een kort vooronderzoek doen, maar dat moet je wel direct starten. Ken je nog niet alle feiten, dan mag je in fasen melden.

Melden bij de Autoriteit Persoonsgegevens is de regel. Je mag alleen afzien van een melding als het onwaarschijnlijk is dat het datalek een risico oplevert voor de betrokkenen, en die afweging moet je kunnen onderbouwen. Bij twijfel meld je. Een melding kun je later aanvullen of intrekken.

Ja. Artikel 33 lid 5 AVG verplicht je om elk datalek intern vast te leggen, ook als je het niet meldt. Leg vast wat er is gebeurd, wat de gevolgen zijn, welke maatregelen je hebt genomen en waarom je wel of niet hebt gemeld.

Een verwerker moet een datalek zonder onredelijke vertraging aan jou melden (artikel 33 lid 2 AVG). Jij bent als verwerkingsverantwoordelijke degene die beoordeelt of er gemeld moet worden bij de Autoriteit Persoonsgegevens. Vraag je leverancier daarom snel om de feiten die je voor die afweging nodig hebt.