Moet ik altijd binnen 72 uur melden bij de AP?

Alleen meldplichtige datalekken vragen om melding. Of dat in jouw geval verplicht is, beoordeelt een privacy-advocaat of een Functionaris Gegevensbescherming. De 72 uur start op het moment van ontdekking.

Mag ik de site eerst opschonen voordat ik onderzoek doe?

Beter niet. Onderzoek heeft de besmette toestand nodig om scope vast te stellen. Maak eerst een volledige back-up, doe daarna de analyse, schoon pas op. Anders heb je geen bewijs meer als de AP of een verzekeraar vragen stelt.

Wat als ik geen logs heb?

Dat maakt de scope-analyse moeilijker. Wat er nog kan: hosting-account-logs, database-aanmaaktijden van verdachte gebruikers, plugin-logs (Wordfence, Sucuri). In het rapport vermeld je dat de scope onzeker is. Dat is een eerlijke uitkomst.

Heb ik een dure forensisch specialist nodig?

Voor MKB-incidenten meestal niet. Een ervaren webmaster kan de logs en database doorlopen en een goed onderbouwd rapport opleveren. Voor zware corporate incidenten of strafrechtelijke trajecten ligt dat anders.

Kan ik dit zelf doen?

De technische opschoning is voor wie ervaring heeft mogelijk. De juridische beoordeling is dat niet. Voor een MKB-eigenaar zonder IT-achtergrond is een externe webmaster plus een privacy-advocaat de gangbare combinatie.

Wat als het incident al een paar weken geleden is gebeurd?

Dezelfde stappen, maar de scope-analyse wordt lastiger naarmate logs vervallen (op veel hosting blijven access-logs maximaal 30 dagen bewaard). Hoe sneller je begint na ontdekking, hoe completer het beeld.

Datalek website stappenplan: de eerste 72 uur

Heb je een datalek vermoeden? Doe dit nu, in deze volgorde: site isoleren, scope bepalen, klok van 72 uur starten, juridisch advies inwinnen, technische opschoning plannen. Geen paniek, wel structuur. Een datalek is vervelend, maar het is geen ramp die binnen het uur is opgelost door één snelle actie.

Dit artikel is een praktisch stappenplan voor de eerste 72 uur na de ontdekking van een datalek. Het richt zich op de technische en organisatorische stappen die ik als webmaster oppak. Voor het juridische deel verwijs ik consequent naar een privacy-advocaat: zij beoordelen of melding bij de Autoriteit Persoonsgegevens (AP) verplicht is, hoe getroffenen geïnformeerd moeten worden en welke documentatie nodig is.

Ik werk vanuit Terneuzen aan onderhoud, herstel en hardening van bestaande sites. Bij een echte spoedsituatie reken ik tegen €105 per uur (1,5x standaard). Geen 24/7-bereikbaarheid, wel spoedwerk in overleg.

Datalek-respons stappenplan voor de eerste 72 uur met klok als deadline-indicator en checklist op werkplek

Wat een datalek precies is

Niet elke security-issue is een datalek. De definitie volgens de AVG: een inbreuk op de beveiliging die per ongeluk of onrechtmatig leidt tot vernietiging, verlies, wijziging, ongeautoriseerde verstrekking of toegang tot persoonsgegevens.

In de praktijk gaat het bij websites om situaties zoals:

Een hack waarbij de aanvaller toegang had tot een database met klant- of ledengegevens
Een formulier-injection waardoor verzonden gegevens onderschept konden worden
Een verkeerd geconfigureerde back-up die publiek toegankelijk was
Een verloren laptop of USB-stick met klantgegevens
Een phishing-incident waarbij iemand toegang heeft gegeven tot het CMS

Een gewone hack zonder persoonsgegevens (defacement van een statische pagina, een redirect-injectie zonder data-uitlek) is technisch geen datalek volgens de AVG. Een hack wel een security-incident, en de aanpak hieronder is hetzelfde tot het moment van melding.

De juridische beoordeling of het wel of geen meldplichtig datalek is, ligt bij een privacy-advocaat of een Functionaris Gegevensbescherming. Hun afweging vraagt om kennis van wat er precies is gelekt, voor hoeveel personen en met welke gevoeligheid.

Uur 0 tot 4: isoleren en feiten verzamelen

Het eerste wat ik doe na een melding: niets onomkeerbaars doen. Geen bestanden meteen verwijderen, geen database leegmaken, geen “snelle fix” via FTP. Eerst zekerstellen wat er is gebeurd.

Site isoleren. Hangt af van de situatie. Bij een actieve aanval die nog loopt: site in maintenance-mode of tijdelijk offline. Bij een passieve ontdekking: alleen de admin-toegang resetten en de site online houden, zodat klanten niet onnodig schrikken.

Toegang beperken.

Alle WordPress-wachtwoorden van admin-accounts resetten
Application passwords intrekken (Users > Profile > Application Passwords)
Sessies forceren afsluiten (alle gebruikers automatisch uitloggen)
Hosting-wachtwoord wijzigen, FTP-accounts checken
API-tokens van plugins die externe diensten gebruiken roteren

Feiten vastleggen. Wat is er gevonden, door wie, op welk moment, via welk kanaal? Schrijf het op. Datum, tijd, schermafbeelding. Dit wordt belangrijk voor de melding en voor je eigen administratie.

Niet versturen. Nog geen mails naar klanten. Geen tweet, geen LinkedIn-bericht. Eerst weten wat er aan de hand is.

Voor wie hier vastloopt: stuur me een bericht. Ik reageer binnen 4 uur op werkdagen, of in overleg spoed buiten kantooruren.

Uur 4 tot 24: scope bepalen

In de eerste 24 uur is de hoofdvraag: welke gegevens van welke personen zijn precies geraakt?

Logs analyseren. Access-logs op de webserver, security-plugin-logs (Wordfence, Sucuri), database-query-logs als die zijn ingeschakeld. Zoek naar:

IP-adressen die afwijken van legitiem verkeer
POST-requests met verdachte payloads
Toegang tot endpoints die normaal niet worden gebruikt (/wp-admin/admin-ajax.php met onbekende actions, custom endpoints)
Aanmaak of wijziging van gebruikersaccounts in de database

Database controleren. Welke tabellen waren toegankelijk? Bij een SQL-injection: was het alleen lezen, of ook schrijven? In WordPress bevat wp_users mailadressen, in WooCommerce zit wp_wc_customer_lookup veel meer (volledige naam, adres, telefoon, bestelgeschiedenis).

Externe systemen. Heeft de site een koppeling met Mailchimp, HubSpot, een CRM? Is daar via API-tokens toegang verkregen? Dat kan de scope flink uitbreiden.

Het doel van deze fase is niet om de aanval te stoppen (dat is in fase 1 al gebeurd), maar om de scope eerlijk in kaart te brengen. “We weten het niet” is een acceptabele uitkomst als je het serieus hebt onderzocht. Onder de pet vegen is dat niet.

Datalek melden via het officiële formulier van de Autoriteit Persoonsgegevens binnen 72 uur na ontdekking

De 72-uurregel en de AP-melding

De AVG schrijft voor dat een meldplichtig datalek binnen 72 uur na ontdekking gemeld wordt bij de Autoriteit Persoonsgegevens. Officiële informatie staat op de pagina van de AP over datalekken.

De klok start op het moment dat een verantwoordelijke binnen de organisatie kennis krijgt van het datalek. Dat is dus niet het moment van de hack zelf, maar het moment van ontdekking.

Meldplichtig of niet? Dat is geen technische vraag. De afweging hangt af van:

Soort persoonsgegevens (e-mailadres versus BSN of medische data)
Aantal getroffen personen
Risico op materiele of immateriele schade
Of de gegevens versleuteld waren

Dit is precies waar een privacy-advocaat of Functionaris Gegevensbescherming nodig is. Ik geef daar geen juridisch advies over. Wat ik wel kan: de feiten technisch onderbouwen die zij nodig hebben om die afweging te maken. Welke tabellen, welke kolommen, hoeveel records, welke tijdvensters.

Ben je MKB zonder eigen FG? Twee routes voor juridisch advies:

Een privacy-advocaat (er zijn gespecialiseerde kantoren, een uur consult kost gemiddeld tussen €200 en €400)
Een externe Functionaris Gegevensbescherming via een privacy-bureau

Voor de melding zelf is een online formulier op de site van de AP beschikbaar. Heb je niet alle informatie binnen 72 uur, dan kun je een voorlopige melding doen en later aanvullen. Niets melden bij twijfel is een slechter idee dan een nuancering aanbrengen.

Getroffenen informeren

Als de melding bij de AP wordt gedaan, moeten in veel gevallen ook de getroffen personen worden geïnformeerd. Wanneer dat verplicht is, hangt af van de risicoclassificatie. Ook dat is een juridische beoordeling.

Wat ik op technisch vlak voorbereid:

Een lijst van getroffen e-mailadressen op basis van de scope-analyse
Een mailtekst die helder is over wat er is gebeurd, welke gegevens zijn geraakt en wat de getroffene zelf kan doen
Een aparte pagina op de site met meer informatie en contactgegevens

De toon van de communicatie: zakelijk, eerlijk, geen verkooppraat en geen schoonmaakzinnen. Geen “uw veiligheid is onze hoogste prioriteit” als de hack juist liet zien dat dat onvoldoende was. Wel: wat is er gebeurd, wat doen we eraan, hoe voorkomen we het in de toekomst, waar kunnen ze terecht met vragen.

De inhoud van de tekst en de juridische formuleringen horen bij een privacy-advocaat. Ik bouw de technische infrastructuur (mail-flow, contactformulier, FAQ-pagina) en zorg dat de mailing zonder spam-issues uitgestuurd kan worden.

Technische opschoning

Parallel aan de juridische en communicatie-stappen loopt de technische opschoning. Dat is mijn kerngebied.

Volgorde voor een gehackte WordPress-site:

Volledige back-up van de huidige (besmette) staat voor forensiek
Site naar staging halen om in alle rust te werken
Malware-scan via WordFence of een handmatige check op verdachte bestanden
Core, plugins en thema’s volledig vervangen vanaf officiele bronnen (geen merge)
Database-tabellen controleren op extra gebruikersaccounts en onverwachte content
wp-config.php-keys vernieuwen, alle wachtwoorden roteren
Hardening: file permissions, WAF, security headers
Site terugzetten naar live, monitoring de eerste week verhoogd

Meer over de technische kant staat in mijn artikel over een gehackte WordPress-site herstellen. Daar gaat het in op de specifieke tools en commando’s.

Voor dit hele traject reken ik per uur. Spoedwerk in de eerste 72 uur is €105 per uur. Daarna terug naar het standaard tarief van €70 per uur (€95 voor servermigratie of database-werk). Een gemiddelde site is in 8 tot 16 uur opgeschoond, afhankelijk van de scope.

Logs analyseren en opschonen na een datalek met gefilterde suspicious entries voor forensisch onderzoek

Documentatie en evaluatie

Na de 72 uur is het werk niet klaar. De AVG vereist dat een organisatie ook ongemelde datalekken vastlegt in een intern register, en dat het incident wordt geëvalueerd.

Wat ik in een rapport opneem voor de klant:

Tijdlijn van het incident, met data en betrokkenen
Technische analyse: hoe is de aanvaller binnengekomen, welke kwetsbaarheid
Genomen maatregelen tijdens de respons
Structurele verbeteringen die zijn doorgevoerd
Aanbevelingen voor de toekomst (vaak: lopend onderhoud, betere logging, betere back-ups)

Dit rapport gaat naar de klant en eventueel naar hun privacy-advocaat. Ik onderteken het niet als juridisch advies, het is een technische beschrijving van het incident en de respons.

Voorkomen is goedkoper dan herstellen

Een datalek-incident kost een MKB-bedrijf gemiddeld een paar duizend euro aan herstelkosten, plus de tijd van de eigenaar, plus eventuele boetes en reputatieschade. Tegenover die kosten staat een lopend WordPress onderhoudscontract van €58 of €175 per maand.

Wat in een onderhoudscontract zit en wat helpt bij preventie:

Wekelijkse back-ups die ook echt werken bij een herstel
Updates van core, plugins en thema’s binnen redelijke termijn
Beveiligingsmonitoring met automatische meldingen
Periodieke hardening-checks (file permissions, security headers, plugin-audits)

Geen 24/7-support. Wel spoedwerk in overleg, tegen €105 per uur (1,5x).

Heb je een vermoeden van een datalek? Stuur me je URL, een korte beschrijving van wat je hebt gezien en wanneer. Ik kijk naar de logs en help je de scope bepalen. Voor het juridische deel verwijs ik je naar een privacy-advocaat. Meer artikelen staan in de categorie website beveiliging.