Datalek melden: wanneer en hoe

Je hebt net een e-mail met een offerte naar de verkeerde klant gestuurd. Of je ontdekt dat je Notion-workspace op publiek stond, met klantbriefings erin. Of GitHub stuurt een alert: je .env bestand met database-credentials staat in een publieke repo.

Paniek? Begrijpelijk. Maar de stappen zijn helder. Dit is precies wat je doet.

Datalek ontdekt? Doe dit eerst

1. Beperk de schade. Verwijder het publieke bestand. Trek de verkeerde e-mail in als dat nog kan. Roteer gelekte credentials. Vergrendel het gecompromitteerde account. Schadebeperking gaat altijd voor analyse.

2. Bepaal wat er is gebeurd. Welke persoonsgegevens zijn betrokken? Van hoeveel personen? Zijn de gegevens versleuteld? Is er daadwerkelijk ongeautoriseerde toegang geweest, of alleen het risico daarop? Wees specifiek: "namen en e-mailadressen van 12 klanten" is nuttiger dan "klantdata".

3. Beoordeel: moet je melden? Zie de sectie hieronder. Kort door de bocht: als er persoonsgegevens onbeschermd bij een onbevoegde terecht zijn gekomen, is het antwoord waarschijnlijk ja. Twijfel je? Meld. De AP heeft liever een onnodige melding dan een gemiste.

4. Meld bij de AP binnen 72 uur via datalekken.autoriteitpersoonsgegevens.nl. Je hoeft niet alles te weten. Een voorlopige melding kan later worden aangevuld.

5. Informeer betrokkenen als er een hoog risico is voor hun rechten. Zie hieronder wanneer dit speelt.

6. Documenteer alles. In je datalekkenregister. Dit is verplicht, ook als je niet meldt bij de AP. Geen register? Maak er nu een aan. Het kost je vijf minuten.

Twijfel je na deze stappen of je beveiliging op orde is? Doe de Privacy Scan en check in 2 minuten waar je risico loopt.

Moet je melden bij de AP?

Niet elk incident is meldplichtig. De AVG (artikel 33) zegt: melden tenzij het "niet waarschijnlijk is dat de inbreuk een risico inhoudt voor de rechten en vrijheden van betrokkenen." Dat klinkt vaag. In de praktijk is het concreter dan je denkt.

Wel melden:

• Onversleutelde laptop gestolen met klantdata
• E-mail met financiële gegevens naar de verkeerde ontvanger
• CRM-account gehackt of wachtwoord gelekt
• Ransomware op je systeem met klantgegevens
• Klantendatabase per ongeluk publiek toegankelijk
• .env met productie-credentials op een publieke GitHub repo

Waarschijnlijk niet melden:

• Versleutelde laptop gestolen (FileVault of BitLocker aan, sterk wachtwoord)
• E-mail naar verkeerde persoon met alleen je eigen naam erin
• Mislukte inbraakpoging waarbij niemand bij data is gekomen
• Serverstoring zonder ongeautoriseerde toegang

Voor developers: een gelekte API-key die toegang geeft tot een productie-database met klantrecords is een ander verhaal dan een test-key voor een development-omgeving zonder echte data. Context bepaalt de ernst. Meer over gestolen apparaten lees je in het stappenplan bij diefstal.

De 72-uur klok

De klok begint op het moment dat je het datalek ontdekt. Niet op het moment dat het plaatsvond. Merk je vrijdagavond dat je donderdagochtend een e-mail verkeerd hebt verstuurd? Dan begint de 72 uur op vrijdagavond.

Ontdekt je verwerker het lek (je hostingpartij, je SaaS-tool)? Dan begint jouw klok zodra zij jou informeren. Precies daarom is het belangrijk dat je verwerkersovereenkomsten een meldtermijn bevatten. Als je verwerker er twee weken over doet om jou te informeren, heb jij een probleem.

Je hoeft niet alles te weten om te melden. Het AP-meldformulier biedt de optie voor een voorlopige melding. Doe de eerste melding met wat je weet en vul later aan via je referentienummer. De AP verwacht snelheid en transparantie, geen perfecte analyse.

Mis je de 72 uur? Meld alsnog. Leg uit waarom het langer duurde. Te laat melden is altijd beter dan niet melden.

Het AP-meldformulier: wat vragen ze?

Het formulier op datalekken.autoriteitpersoonsgegevens.nl vraagt het volgende:

• Aard van het incident. Categorieën: verloren apparaat, verkeerde ontvanger, hacking, ransomware, onbevoegde toegang, publicatie.
• Hoe ontdekt. Op welke manier kwam je erachter?
• Welke persoonsgegevens. Namen, adressen, financieel, medisch, BSN, inloggegevens.
• Hoeveel betrokkenen. Een schatting is voldoende.
• Of data versleuteld was.
• Genomen maatregelen. Wat heb je gedaan om de schade te beperken?
• Risicobeoordeling. Jouw inschatting van het risico, met toelichting.

Het formulier werkt met slimme vertakking: vervolgvragen zijn afhankelijk van je eerdere antwoorden. Je kunt tussentijds opslaan. Bewaar je referentienummer goed. Je hebt het nodig als je later wilt aanvullen of de melding wilt intrekken.

Praktische tip: maak een screenshot van je voltooide melding. Het formulier is niet terug te vinden op de AP-website zonder het referentienummer.

Wanneer moet je klanten informeren?

Naast de AP-melding moet je soms ook de betrokkenen zelf informeren (artikel 34 AVG). De drempel is hoger dan bij de AP-melding: "waarschijnlijk een hoog risico voor de rechten en vrijheden."

Hoog risico speelt bij:

• Onversleutelde financiële gegevens (IBAN, salarisstroken)
• BSN-nummers of kopieën van identiteitsdocumenten
• Medische of andere bijzondere persoonsgegevens
• Inloggegevens die hergebruikt kunnen worden

Je hoeft niet te informeren als de data effectief ontoegankelijk was (versleuteld met sterk wachtwoord) of als je maatregelen hebt genomen die het risico wegnemen. Denk aan wachtwoorden die je direct hebt gereset, of data die je hebt verwijderd voordat iemand erbij kon.

Wat zeg je tegen je klanten? Eerlijk en concreet. Schrijf het alsof je het uitlegt aan een collega: wat er is gebeurd, welke gegevens het betreft, wat je hebt gedaan om het op te lossen, wat zij zelf kunnen doen (wachtwoord wijzigen, bankafschriften checken), en hoe ze je bereiken voor vragen. Per e-mail is het meest gebruikelijk.

5 datalekken die kleine ondernemers het vaakst overkomen

1. E-mail naar de verkeerde persoon. Veruit de meestvoorkomende oorzaak. In 2024 ging het bij 18% van alle datalekmeldingen om een e-mailfout. Autocomplete kiest de verkeerde ontvanger, en een offerte met klantgegevens gaat naar iemand anders. Factuur met naam en adres? Waarschijnlijk melden. Alleen een tekst zonder persoonsgegevens? Registreren, niet melden. Meer hierover in het artikel over verkeerd verstuurde e-mails.

2. Gestolen of verloren apparaat. Laptop in de trein laten liggen, telefoon uit je zak gevallen. De encryptievraag bepaalt alles. Was FileVault of BitLocker ingeschakeld? Dan is het waarschijnlijk geen meldplichtig datalek. Was het niet versleuteld? Melden. Lees het complete stappenplan in het artikel over laptop-diefstal.

3. Gehackt account. Je e-mail of CRM is gecompromitteerd door een gelekt of geraden wachtwoord. Vaak het gevolg van wachtwoord-hergebruik. De aanvaller heeft potentieel toegang tot alle klantgegevens in dat account. Directe actie: wachtwoorden wijzigen, alle sessies intrekken, 2FA aanzetten, melden bij de AP.

4. Ransomware. Je bestanden zijn versleuteld door malware. Als die bestanden klantgegevens bevatten, is dit een datalek. Ook als de aanvaller de data niet heeft buitgemaakt: het feit dat je geen toegang meer hebt is al een inbreuk op de beschikbaarheid. Melden bij de AP.

5. Per ongeluk publiek gedeeld. Een Google Drive-map op "iedereen met de link", een Notion-pagina op public, een Trello-bord dat niet op privé stond. Klantgegevens die onbedoeld toegankelijk waren via het internet. Hoe lang het openbaar stond en of iemand het daadwerkelijk heeft benaderd bepaalt de ernst.

Developer-datalekken

Als developer heb je specifieke risico's die andere ondernemers niet hebben. De meeste worden niet veroorzaakt door hackers, maar door configuratiefouten.

.env op GitHub. Je pusht per ongeluk een .env bestand naar een publieke repository. Database-wachtwoorden, API-keys, tokens. Bots scannen publieke repos continu op secrets, en de gemiddelde tijd van lek tot exploitatie is ongeveer 8 minuten. GitHub scant tegenwoordig op bekende patronen en waarschuwt, maar niet alle secrets worden herkend. Roteer direct, check de git history (de secret zit ook in eerdere commits), en beoordeel of er toegang tot klantdata mogelijk was.

Open database. Een MongoDB of Elasticsearch die zonder authenticatie aan het internet hangt. Bots scannen continu op open poorten. Als daar klantdata in zit, is het een datalek. Vaak ontdek je het pas als iemand je database heeft gekopieerd en ransom vraagt.

API die te veel retourneert. Je endpoint retourneert het volledige klantobject inclusief e-mail, telefoonnummer en adres, terwijl de frontend alleen de naam nodig heeft. Als die API publiek toegankelijk is zonder authenticatie, is elke request een potentiële inbreuk.

Logs met persoonsgegevens. Je applicatie logt request-bodies of error-messages met klantdata erin. Die logs staan in Sentry, Datadog of CloudWatch, toegankelijk voor het hele team. Of erger: in een publiek bereikbare log-directory.

CI/CD pipelines. Secrets in environment variables die zichtbaar worden in build-logs. Of een deployment-script dat credentials naar stdout schrijft. Zijn je secrets gemaskeerd? Zijn build-logs afgeschermd voor derden?

Preventie: tools als git-secrets, truffleHog of GitHub's ingebouwde secret scanning kunnen helpen om secrets in je codebase te detecteren voordat ze publiek worden. Vijf minuten configuratie kan je een hele datalekprocedure besparen.

Het datalekkenregister

Artikel 33 lid 5 AVG: je moet alle datalekken documenteren. Niet alleen de meldplichtige. Alle incidenten, inclusief je beoordeling en besluit om wel of niet te melden.

Dit hoeft geen complex systeem te zijn. Een spreadsheet of Notion-pagina met per incident deze kolommen:

• Datum ontdekking
• Wat er gebeurde
• Welke gegevens en hoeveel betrokkenen
• Beoordeling: risico voor betrokkenen?
• Besluit: gemeld bij AP ja/nee, betrokkenen geïnformeerd ja/nee
• Genomen maatregelen
• Status (afgehandeld/open)

Maak dit template nu aan. Niet als het misgaat, maar nu. Het kost vijf minuten en het ligt klaar wanneer je het nodig hebt. Als de AP ooit vraagt naar je datalekprocedure, is een ingevuld register het sterkste bewijs dat je het serieus neemt.

Wat gebeurt er na je melding?

Dit is het deel dat niemand je vertelt. Je hebt gemeld bij de AP, je datalekkenregister is bijgewerkt, je klanten zijn (indien nodig) geïnformeerd. En dan?

Bij de meeste meldingen van kleine ondernemers: niets. Je ontvangt een ontvangstbevestiging met een referentienummer. De AP beoordeelt of het incident verder onderzoek vereist. Bij een eenmalige menselijke fout van een ZZP'er is dat zelden het geval.

De AP ontving in 2024 bijna 38.000 datalekmeldingen. Het overgrote deel daarvan krijgt geen vervolgonderzoek. De AP richt zich op structurele overtredingen, grote verwerkingen en herhaalde incidenten. Niet op een freelancer die een keer een e-mail verkeerd stuurt.

Waar de AP wél op let: patronen. Als je drie keer hetzelfde type datalek meldt zonder dat je maatregelen neemt, is dat een ander verhaal. Dan wijst het op een structureel beveiligingsprobleem, en daar kan de AP wel op acteren.

Wil je zeker weten dat je basisbeveiliging in orde is? De Privacy Scan checkt in 10 vragen of je de belangrijkste maatregelen hebt getroffen.

De eerlijke inschatting

De meeste datalekken zijn geen spectaculaire hacks. In 2024 ging het bij 41% van alle meldingen om verkeerd verstuurde post en bij 18% om verkeerd verstuurde e-mails. Cyberaanvallen waren goed voor zo'n 4%. De overweldigende meerderheid van datalekken is het gevolg van gewone menselijke fouten.

Het overkomt iedereen. En dat is precies waarom de meldprocedure bestaat: niet om je te straffen, maar om betrokkenen te beschermen.

De contra-intuïtieve les: de AP wil dat je meldt. Ze hebben liever tienduizend meldingen te veel dan één gemiste melding waar iemand schade door lijdt. Het melden zelf is nooit het probleem. Verzwijgen, bagatelliseren of te laat handelen wel.

De beste bescherming blijft voorkoming. Encryptie op al je apparaten. 2FA op al je accounts. Een wachtwoordmanager. Geen klantdata in onbeveiligde tools. Maar als het toch misgaat: handel snel, documenteer alles, en wees eerlijk. Dat is wat de AVG vraagt. Niet perfectie, maar zorgvuldigheid.

Meer over je digitale beveiliging op orde krijgen lees je in het artikel over beveiliging voor ZZP'ers.