Procedure datalekken: model stappenplan voor bedrijven

Een procedure datalekken is het draaiboek dat uw organisatie doorloopt zodra een datalek wordt vermoed: van detectie en beoordeling van het risico, via melding bij de AP binnen 72 uur, tot communicatie met betrokkenen en evaluatie. Zonder vast stappenplan verliest u de kostbare eerste uren, en juist die tellen: de meldtermijn van artikel 33 AVG begint te lopen zodra u van het lek op de hoogte bent. Hieronder vindt u een compleet procedure datalekken-model met de vijf fasen, de rolverdeling en escalatieafspraken met verwerkers.

Booking.com kreeg in 2021 een boete van 475.000 euro van de AP omdat het een datalek 22 dagen te laat meldde. Het lek zelf was niet het probleem — het te trage proces wel. Een vastgelegde procedure is precies wat zo’n boete voorkomt.

Key Takeaways

• De 72-uursklok start bij bekendwording van het lek, niet bij het afronden van uw onderzoek.
• Vijf fasen: detectie → beoordeling → melding AP → communicatie betrokkenen → evaluatie.
• Bij een hoog risico moet u ook de betrokkenen informeren (art. 34 AVG).
• Leg RACI-rollen vast: wie beoordeelt, wie meldt, wie communiceert.
• Verwerkers moeten u onverwijld informeren — verankerd in de verwerkersovereenkomst.

Fase 1 — Detectie en melding intern

Een lek kan van overal komen: een medewerker, een verwerker, een beveiligingssysteem of een externe melder. Zorg voor één duidelijk intern meldpunt (bijvoorbeeld een e-mailadres of formulier) dat iedereen kent. Elke medewerker moet weten: bij twijfel, melden.

Vanaf het moment van interne melding loopt de klok. Registreer direct datum en tijd in het datalekregister.

Fase 2 — Beoordeling van het risico

Beoordeel of het lek waarschijnlijk een risico voor betrokkenen inhoudt. Weeg de aard van de gegevens, het aantal betrokkenen, de gevoeligheid en of de gegevens versleuteld waren.

Risiconiveau	Actie	Basis
Geen risico	Alleen registreren	Art. 33 lid 5
Waarschijnlijk risico	Melden bij AP < 72 uur	Art. 33 lid 1
Hoog risico	Ook betrokkenen informeren	Art. 34

Twijfelt u tussen “geen” en “wel” risico, meld dan bij de AP — een onterechte melding is minder riskant dan een gemiste. De grondslagen en gegevenscategorieën die u hierbij weegt, vindt u in de gids over artikel 6 AVG.

Fase 3 — Melding bij de AP binnen 72 uur

Meld via het meldloket van de Autoriteit Persoonsgegevens. Kunt u nog niet alle informatie geven, meld dan tijdig en vul later aan — een gefaseerde melding is toegestaan (art. 33 lid 4). Beter een onvolledige melding binnen 72 uur dan een complete melding te laat. De volledige meldroute staat in de gids over een datalek melden bij de AP.

Overschrijdt u de 72 uur, dan moet u de vertraging motiveren. De Booking.com-zaak laat zien hoe zwaar de AP tilt aan te laat melden.

Fase 4 — Communicatie met betrokkenen

Bij een hoog risico informeert u de betrokkenen onverwijld en in duidelijke, eenvoudige taal (art. 34 lid 2): wat is er gebeurd, welke gegevens, wat zijn de gevolgen, wat kunnen zij zelf doen (bijvoorbeeld wachtwoord wijzigen) en waar kunnen zij terecht met vragen.

Vermijd juridisch jargon. De communicatie moet de betrokkene in staat stellen zichzelf te beschermen. Bereid deze communicatie voor vóórdat u haar nodig heeft: een conceptbrief en een korte lijst met veelgestelde vragen liggen dan klaar, zodat u onder tijdsdruk niet hoeft te improviseren. Kies bovendien bewust het kanaal — e-mail, brief of een bericht in de klantomgeving — dat de betrokkenen daadwerkelijk bereikt.

Fase 5 — Evaluatie en verbetering

Na afhandeling: wat ging er mis, en hoe voorkomt u herhaling? Pas zo nodig de beveiligingsmaatregelen aan. Structurele lekken uit dezelfde bron wegen zwaar mee als de AP later toch handhaaft.

Leg de evaluatie kort schriftelijk vast en neem hem op in het datalekregister. Zo bouwt u een dossier op dat laat zien dat uw organisatie leert. Dat dossier is dubbel waardevol: het stuurt uw beveiligingsinvesteringen én het toont bij een eventueel onderzoek dat u incidenten serieus behandelt.

Veelgemaakte fouten in de afhandeling

De drie klassieke fouten zijn steeds dezelfde. Ten eerste: te lang intern rondpompen voordat iemand de beoordeling maakt — elke dag die intern verloren gaat, gaat af van uw 72 uur. Ten tweede: wachten met melden tot het onderzoek helemaal rond is, terwijl een gefaseerde melding juist is toegestaan. En ten derde: de betrokkenen niet of te laat informeren bij een hoog risico, waardoor zij zichzelf niet tijdig kunnen beschermen.

Een vierde, subtielere fout is het onderschatten van de verwerkersketen. Als een subverwerker van uw leverancier een lek veroorzaakt, moet die informatie via meerdere schakels bij u terechtkomen — en dat kost tijd die u niet heeft. Contractuele meldtermijnen door de hele keten zijn daarom geen formaliteit maar een randvoorwaarde om de wettelijke termijn te halen.

Oefenen en actueel houden

Een procedure die in een la ligt, werkt niet onder druk. Oefen het draaiboek minstens één keer per jaar met een realistisch scenario — bijvoorbeeld een verloren laptop met klantgegevens of ransomware op een fileserver. Zo’n oefening legt de zwakke plekken bloot: weet iedereen waar het meldpunt is, wie beslist over melden, en hoe u binnen een uur de betrokken verwerkingen in beeld heeft?

Actualiseer de procedure bij elke wijziging in uw systemen, leveranciers of organisatie. Een nieuw CRM, een nieuwe cloudleverancier of een reorganisatie kan de meldketen breken zonder dat iemand het merkt. Koppel de review aan de jaarlijkse actualisatie van uw verwerkingsregister, zodat beide documenten synchroon blijven lopen.

RACI en verwerkers

Leg de rollen vast zodat niemand op iemand anders wacht:

• Verantwoordelijk ®: privacycoördinator / FG voert de beoordeling uit;
• Eindverantwoordelijk (A): directie/bestuur;
• Geraadpleegd ©: IT-beveiliging, juridisch;
• Geïnformeerd (I): communicatie, betrokken afdeling.

Verwerkt een leverancier gegevens voor u, dan moet die u onverwijld melden bij een lek. Neem een concrete termijn (bijvoorbeeld 24 uur) op in de verwerkersovereenkomst, anders haalt u de 72-uurstermijn nooit.

Hoe Legiscope hierbij helpt

De zwakste schakel in de meldketen is tijd. Legiscope structureert de risicobeoordeling, bewaakt de 72-uursklok en koppelt elk incident aan de betrokken verwerkingen en verwerkers, zodat u weet wie te informeren en welke termijn geldt.

FAQ

Wanneer begint de termijn van 72 uur te lopen?

Op het moment dat u van het datalek op de hoogte bent — niet wanneer u uw onderzoek heeft afgerond. Daarom is snelle interne detectie cruciaal: elke dag intern talmen gaat af van uw 72 uur richting de AP.

Wat als ik binnen 72 uur nog niet alles weet?

Meld dan gefaseerd (art. 33 lid 4 AVG). Doe eerst een melding met de bekende informatie en vul die later aan. De AP accepteert een gefaseerde melding; een te late complete melding is een overtreding.

Moet ik altijd de betrokkenen informeren?

Nee, alleen bij een hoog risico voor hun rechten en vrijheden (art. 34 AVG). Bij enkel een melding aan de AP zonder hoog risico hoeft u de betrokkenen niet apart te informeren. Documenteer de afweging wel in uw register.

Wat leert de Booking.com-boete ons?

Dat het proces telt, niet alleen het lek. Booking.com meldde 22 dagen te laat en kreeg 475.000 euro boete (AP, 2021). Een vastgelegde procedure met duidelijke rollen en interne meldtermijnen voorkomt precies deze vertraging. De les is niet dat het lek voorkomen had moeten worden — lekken gebeuren — maar dat de organisatie te traag reageerde toen het lek eenmaal bekend was. Snelheid in de eerste uren is het enige waar u bij een datalek echt grip op heeft.

---

Bronnen: de AVG-tekst op EUR-Lex en het datalekloket van de Autoriteit Persoonsgegevens.