Je opent op een maandagochtend een mail van je hostingpartij of je softwareleverancier. Er is ingebroken op hun systemen. Mogelijk zijn klantgegevens buitgemaakt, ze zoeken het nog uit, en ze houden je op de hoogte. Op dat moment begint er een klok te lopen die de meeste ondernemers niet horen tikken. De hack zit bij hen, maar het datalek is van jou. En wat je in de eerste 72 uur doet, bepaalt of dit een vervelende week wordt of een boete plus een stapel klanten die hun vertrouwen kwijt zijn.
Deze gids is geen configuratiehandleiding voor je IT. Hij gaat niet over hoe je je eigen netwerk dichttimmert, maar over wat je doet als een derde partij die jouw klantdata beheert wordt gehackt. Voor de ondernemer of teamlead die plots aan zet is, zonder security-afdeling, met een juridische deadline en klanten die antwoord willen. Na het lezen weet je of dit jouw meldplicht is, wat je binnen 72 uur bij de Autoriteit Persoonsgegevens regelt, wat je je klanten vertelt, en hoe je voorkomt dat je straks vastzit aan de partij die je net liet zakken.
Waarom de hack bij je leverancier jouw datalek is
Hier struikelt bijna iedereen over dezelfde denkfout: "het is hun systeem, dus hun probleem." Onder de AVG werkt het precies andersom.
Een verwerkingsverantwoordelijke is de organisatie die bepaalt waarom en hoe persoonsgegevens worden verwerkt. Schakel je een leverancier in die dat feitelijk voor je uitvoert, dan is die de verwerker. Lekt er data bij de verwerker, dan blijf jij als verantwoordelijke degene die het moet melden en die de betrokkenen moet informeren.
De AP is er helder over: de organisatie die bepaalt met welk doel en op welke manier persoonsgegevens worden verwerkt, is de verwerkingsverantwoordelijke, ook als een clouddienst of softwarepartij de gegevens fysiek onder zich heeft. Je webshopplatform, je boekhoudpakket, je CRM, je hostingpartij: stuk voor stuk verwerkers die jouw data draaien in jouw opdracht. Worden zij gehackt, dan is het jouw naam die in de meldingsbrief aan je klanten staat.
Dat is geen theorie. Toen een hack bij de IT-leverancier van Lidl klantgegevens van de webshop op straat legde, was het de retailer die verantwoording moest afleggen, niet de anonieme toeleverancier. En een inbraak op een klantportaal kan tien dagen onopgemerkt blijven en miljoenen klanten raken voordat iemand het doorheeft. Onder de AVG ben je voor een leverancier of dochter die je gegevens beheert net zo aansprakelijk als voor je eigen serverkast.
Wat je nu bij de hand moet hebben
De eerste 72 uur verlies je niet aan techniek, maar aan zoeken: naar wie je moet bellen, naar het contract, naar wie mag beslissen. Dat zoekwerk hoort vóór het incident klaar te liggen. Dit is de map die je wilt hebben op het moment dat de mail binnenkomt:
- Een verwerkersregister: welke leverancier verwerkt welke persoonsgegevens, van welke categorie betrokkenen, en waar staan die gegevens. Zonder dit overzicht kun je niet eens beoordelen of dit lek jou raakt.
- De verwerkersovereenkomst per leverancier, met daarin de afspraak dat ze je bij een datalek zonder uitstel informeren en je helpen bij je melding.
- Contactgegevens die je onder druk nodig hebt: het incident- of securitycontact van je leverancier, je functionaris voor gegevensbescherming als je die hebt, en een jurist of privacyadviseur.
- Een leeg datalekregister en een meldsjabloon, zodat je niet tijdens de crisis een format zit te bedenken.
- Een besluit dat je vooraf neemt: wie in jouw organisatie de knoop doorhakt en de melding indient, ook 's avonds en in het weekend.
Dit klaarleggen is precies het huiswerk dat de cybersecurity-basischeck in vijf lagen je aanraadt: een incidentplan op papier, offline, met wie je belt en in welke volgorde. Een plan dat alleen in het systeem staat dat plat ligt, is onbereikbaar op het moment dat het telt.
De eerste 72 uur, stap voor stap
Zodra je redelijke zekerheid hebt dat er echt iets is gelekt, loop je deze zes stappen af. Niet netjes na elkaar afwachtend, maar grotendeels parallel: de klok voor de AP tikt door terwijl je de rest regelt.
Stap 1: Bevestig de feiten, schriftelijk. Bel je leverancier en vraag door tot je vijf dingen zwart op wit hebt: wat is er precies gebeurd, welke persoonsgegevens zijn geraakt, van hoeveel betrokkenen, wanneer is het ontdekt, en is de toegang inmiddels dicht. Leg elk antwoord vast met een tijdstip. Deze tijdlijn is later je bewijs richting de AP en je verweer als een klant je aansprakelijk stelt.
Stap 2: Start de klok en bepaal je rol. Je 72 uur begint zodra je een redelijke mate van zekerheid hebt dat zich een beveiligingsincident heeft voorgedaan, niet pas als je alles weet. Ben jij verwerkingsverantwoordelijke voor deze gegevens, en dat ben je meestal, dan is de melding jouw taak. Wacht daar niet op je leverancier: die moet jou informeren, maar meldt niet in jouw plaats bij de AP.
Stap 3: Beperk de schade. Sluit gecompromitteerde toegang af, reset wachtwoorden en API-sleutels die bij de leverancier in het spel waren, en laat de betrokken koppeling of het account blokkeren. Ga ervan uit dat gelekte inloggegevens worden misbruikt en roteer ze, in plaats van te hopen dat het meevalt.
Stap 4: Meld bij de AP binnen 72 uur. Is het lek meldplichtig, dan doe je de melding via het meldloket van de AP: je moet een datalek binnen 72 uur na kennisname melden bij de Autoriteit Persoonsgegevens. Je hoeft niet compleet te zijn. Geef de aard van het lek, de categorieën en het aantal betrokkenen, de waarschijnlijke gevolgen en de maatregelen die je neemt. Ontbrekende details vul je later aan. Te laat en volledig is slechter dan op tijd en voorlopig.
Stap 5: Informeer je klanten als het risico hoog is. Levert het lek waarschijnlijk een hoog risico op voor je klanten, dan moet je ze zo snel mogelijk zelf inlichten. Schrijf feitelijk: wat er is gebeurd, welke van hun gegevens het betreft, wat jij eraan doet en wat zij zelf kunnen doen, bijvoorbeeld alert zijn op phishing. Eén helder bericht is beter dan drie geruststellende die elkaar tegenspreken.
Stap 6: Registreer alles. Elk datalek gaat in je interne datalekregister, ook de lekken die je uiteindelijk niet meldt. Leg de inbreuk, je risico-inschatting, de gevolgen en je maatregelen vast. Meld je niet, dan is die vastgelegde afweging je onderbouwing als de AP er later naar vraagt.
Moet je het melden, en aan wie?
Twee losse beslissingen, die veel ondernemers door elkaar halen. De eerste: melden bij de AP. De tweede: je klanten informeren. Ze hebben elk een eigen drempel.
Melden bij de AP is de norm, niet de uitzondering. Je meldt een datalek, tenzij het onwaarschijnlijk is dat het een risico oplevert voor de rechten en vrijheden van de betrokkenen. Mijn vuistregel: twijfel je, dan meld je. Dat de lat laag ligt, zie je aan de cijfers.
Het aantal datalekmeldingen bij de AP steeg van 37.839 in 2024 naar 44.374 in 2025, gedreven door account-overnames en phishing. Melden hoort er inmiddels bij; niet-melden valt op. Val je ook onder de Cyberbeveiligingswet, dan loopt daar een tweede meldspoor naast met eigen termijnen: de NIS2-meldplicht meldt in 24 uur, 72 uur en een maand aan je CSIRT, los van deze AVG-melding bij de AP.
Je klanten informeer je alleen bij een hoog risico. Hier ligt de drempel hoger: informeren is verplicht als het lek waarschijnlijk een hoog risico oplevert voor de betrokkenen. Of dat zo is, weeg je aan een paar factoren: de aard van het lek, hoe gevoelig en hoeveel gegevens er zijn, hoe makkelijk mensen te identificeren zijn, en hoeveel slachtoffers er zijn. Namen met e-mailadressen en bestelhistorie is iets anders dan een uitgelekt medisch dossier of een BSN. Die weging wordt scherper nu datalekken door account-overnames en AI-gedreven phishing sterk toenemen.
De keuzehulp hieronder loopt dezelfde afweging in het kort langs. Het geschreven kader blijft leidend als je twijfelt.
Beheert de gehackte leverancier persoonsgegevens die jij in jouw opdracht laat verwerken?
De valkuilen die je datalek erger maken
- Wachten op je leverancier voordat je iets doet. Je meldtermijn loopt vanaf jouw redelijke zekerheid, niet vanaf hun definitieve rapport. Start je eigen klok en je eigen dossier meteen.
- Aannemen dat de leverancier wel meldt. De verwerker moet jou informeren, maar de melding bij de AP en aan je klanten is jouw wettelijke plicht. Reken er niet op dat een ander hem voor je doet.
- De melding uitstellen tot je alles weet. Een onvolledige melding op tijd is beter dan een complete melding te laat. Meld met wat je hebt en vul aan.
- Klanten geruststellen met halve waarheden. Een eerste bericht dat het bagatelliseert en een tweede dat het terugneemt, kost je meer vertrouwen dan het eerlijke verhaal in één keer. Schrijf feitelijk en zonder juridische mist.
- Geen verwerkersovereenkomst, of niet weten welke leverancier welke data heeft. Dan kun je het risico niet eens inschatten en sta je met lege handen richting de AP. Dit is het werk dat vooraf hoort, niet tijdens de brand.
- Alles mondeling afhandelen. De AP en je aansprakelijkheid draaien om aantoonbaarheid. Wat je niet hebt vastgelegd, is later moeilijk te bewijzen.
De keten-nasleep: je leverancier aanspreken en je exit
De melding is de deadline. De keten is de rekening. Als de eerste dagen achter de rug zijn, komt de vraag die bepaalt of dit eenmalig blijft: sta je nog steeds vast aan de partij die je liet zakken?
Spreek je verwerkersovereenkomst aan. In die overeenkomst staat, of hoort te staan, dat je leverancier je zonder uitstel informeert, passende beveiliging treft, meewerkt aan je melding en een audit toelaat. Heb je die overeenkomst niet, dan sta je zwak: zonder verwerkersovereenkomst zijn zowel jij als je leverancier in overtreding, nog los van het lek zelf. Vraag na een incident een schriftelijke reconstructie op en toets die aan wat je contract belooft.
Weet waar de aansprakelijkheid ligt. Richting je klant ben jij het eerste aanspreekpunt: een betrokkene kan schadevergoeding claimen bij de verwerkingsverantwoordelijke. Dat je leverancier de fout maakte, verhaal je vervolgens via je contract op die leverancier, maar dat is jouw regres, geen excuus richting de klant. Een verwerkersovereenkomst zonder heldere aansprakelijkheids- en vrijwaringsafspraken laat je met de schade zitten.
Regel je exit voordat je hem nodig hebt. Een leverancier die net je data lekte en bij wie je niet weg kunt, is een dubbel risico. De wet geeft je hier meer ruimte dan een paar jaar geleden: clouddiensten moeten je data sinds 12 september 2025 machineleesbaar teruggeven, en vanaf 12 januari 2027 mogen ze geen overstapkosten meer rekenen. Dat recht werkt alleen als je het opeist en je systeem niet vastzit in leverancier-eigen formaten. Test daarom nu of de export echt werkt en of je hem in een ander systeem kunt laden. Hoe je dat portfoliobreed aanpakt, per systeem weegt en gefaseerd afbouwt, staat in het draaiboek voor vendor lock-in en digitale soevereiniteit. En bedenk dat continuïteit na een cyberaanval iets is dat je vooraf ontwerpt, niet iets dat je achteraf koopt.
| Taak | Verwerkingsverantwoordelijke (jij) | Verwerker (je leverancier) |
|---|---|---|
| Melden bij de AP | Ja, binnen 72 uur bij een meldplichtig lek | Nee, meldt aan jou |
| Klanten informeren | Ja, bij een waarschijnlijk hoog risico | Nee |
| De ander waarschuwen | Niet van toepassing | Ja, zonder uitstel na ontdekking |
| Datalekregister bijhouden | Ja, voor jouw verwerkingen | Ja, voor de lekken die hij ziet |
| Aansprakelijk richting de klant | Eerst aanspreekbaar | Via jouw contract, achteraf |
Zo pakt een webshop het aan
Neem een webshop met 12.000 klanten, die zijn winkel draait op een extern SaaS-platform en zijn boekhouding in Moneybird. Op dinsdagochtend om 09:20 meldt het platform dat er via een gecompromitteerd beheerdersaccount ongeautoriseerde toegang is geweest. Naam, adres, e-mailadres en bestelhistorie van alle klanten waren inzichtelijk. Betaalgegevens niet: die lopen via Mollie en staan buiten het platform.
Zo verloopt de rest van de dinsdag en de woensdag:
- 09:20 tot 11:00. De ondernemer bevestigt schriftelijk bij het platform wat er is geraakt en sinds wanneer, en legt de tijdlijn vast. Het beheerdersaccount is inmiddels geblokkeerd en alle wachtwoorden en API-sleutels worden geroteerd.
- 11:00 tot 14:00. Rol bepaald: de webshop is verwerkingsverantwoordelijke, het platform is verwerker. Risico gewogen: naam, adres, e-mail en bestelhistorie van 12.000 mensen is geen verwaarloosbaar risico, dus melden bij de AP is verplicht. Een hoog risico is het niet zonneklaar, maar de combinatie van adres en koopgedrag maakt gerichte phishing makkelijk, dus kiest de ondernemer voor proactief informeren.
- Woensdag, binnen 72 uur. Melding bij de AP via het meldloket, met de aard van het lek, ongeveer 12.000 betrokkenen, de categorieën gegevens en de genomen maatregelen. Tegelijk een nuchtere mail aan alle klanten: wat er gebeurde, welke gegevens het betreft, dat er geen betaalgegevens zijn geraakt, en de waarschuwing om alert te zijn op phishingmails die naar hun bestelling verwijzen.
- De week erna. De ondernemer vraagt het platform om een schriftelijke reconstructie, toetst die aan de verwerkersovereenkomst, en ontdekt dat een volledige data-export alleen als onleesbare dump beschikbaar is. Dat wordt het startpunt van een exit-plan, zodat een volgende hack bij deze leverancier geen gijzeling meer is.
Wat deze webshop redde, was geen securitytool. Het was dat hij binnen twee uur wist wie welke data had, welke rol hij had, en dat de betaalgegevens buiten het gehackte systeem liepen. Die drie feiten lagen er al voordat de mail binnenkwam.
Zelf regelen of laten inrichten
Je incident-paraatheid is deels een kwestie van standaardwerk en deels van maatwerk. Het eerlijke beeld: de juridische bouwstenen koop je kant-en-klaar, het echt kunnen handelen zit in hoe goed je je eigen stack kent.
| Aanpak | Wat het is | Past bij | Let op |
|---|---|---|---|
| Standaard: sjablonen en DPO-dienst | Modelverwerkersovereenkomsten, een meldsjabloon, eventueel een externe functionaris gegevensbescherming | Wie de basis juridisch wil dichtzetten zonder eigen jurist | Een sjabloon in een la is geen werkend proces; je moet het koppelen aan je echte leveranciers en data |
| Eenmalig: jurist of consultant | Een privacyadviseur die je register, je overeenkomsten en je meldproces eenmalig inricht | Wie snel een onderbouwd startpunt en een onafhankelijke blik wil | De kennis vertrekt met de adviseur; borg dat het in je eigen proces landt en actueel blijft |
| Maatwerk: in je eigen systemen | Een verwerkersregister dat meeloopt met je stack, werkende exports die je zelf draait, en zicht op welke koppeling welke data raakt | Wie het overzicht wil laten meebewegen met zijn systemen in plaats van in een losse spreadsheet | Vraagt ontwerp- en bouwwerk vooraf, maar levert precies het overzicht op dat je in het eerste uur nodig hebt |
De meeste ondernemers combineren: sjablonen en een adviseur voor de juridische basis, en maatwerk waar het overzicht moet meebewegen met je koppelingen tussen systemen. Het verschil tussen een vinkje en echte paraatheid zit niet in het contract, maar in de vraag of je op de ochtend van de hack binnen een uur weet waar je staat.
De map die je hoopt nooit te openen
Een hack bij je leverancier is geen technisch incident dat je aan je IT'er delegeert. Het is een bestuursmoment: een deadline van 72 uur, een klantrelatie op het spel, en een keten waarin jij het aanspreekpunt bent. De bedrijven die er goed doorheen komen, hebben zelden de beste firewall. Ze wisten, voordat de mail binnenkwam, wiens data waar stond, welke rol ze hadden, en hoe ze hun gegevens terugkrijgen. Die kennis bouw je niet op tijdens de crisis. Je legt hem nu klaar, in de saaie map die je hoopt nooit te hoeven openen. En juist omdat een lek bij een derde partij geen kwestie van of maar van wanneer is, is dat voorwerk de goedkoopste verzekering die je hebt.
Veelgestelde vragen
Incidentklaar, niet incident-verrast
Voordat een leverancier je data lekt, breng ik in kaart welke partij welke gegevens beheert en zorg ik dat je er zelf uit komt, van verwerkersregister tot werkende export. Ik denk mee als ondernemer, ontwerp het en bouw het end-to-end.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
