Een persoon aan een bureau werkt met een laptop en papieren.
GidsUitgebreide gids15 juli · 13:0111 min leestijd

Je IT-leverancier is gehackt: het stappenplan voor het mkb in de eerste 72 uur

Je softwareleverancier of hosting is gehackt en je klantdata is mogelijk gelekt. Dit is het incident-playbook: ben jij verantwoordelijke, is het meldplichtig bij de AP, wat vertel je je klanten, en hoe voorkom je dat je vastzit aan de gehackte partij.

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.
Klaarleggen voordat het misgaat: je incident-map
0/5

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.

Aantal gemelde datalekken bij de Autoriteit Persoonsgegevens per jaar (bron: Autoriteit Persoonsgegevens via Binnenlands Bestuur, april 2026)

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.

Moet je dit lek melden, en aan wie?

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.

TaakVerwerkingsverantwoordelijke (jij)Verwerker (je leverancier)
Melden bij de APJa, binnen 72 uur bij een meldplichtig lekNee, meldt aan jou
Klanten informerenJa, bij een waarschijnlijk hoog risicoNee
De ander waarschuwenNiet van toepassingJa, zonder uitstel na ontdekking
Datalekregister bijhoudenJa, voor jouw verwerkingenJa, voor de lekken die hij ziet
Aansprakelijk richting de klantEerst aanspreekbaarVia 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.

AanpakWat het isPast bijLet op
Standaard: sjablonen en DPO-dienstModelverwerkersovereenkomsten, een meldsjabloon, eventueel een externe functionaris gegevensbeschermingWie de basis juridisch wil dichtzetten zonder eigen juristEen sjabloon in een la is geen werkend proces; je moet het koppelen aan je echte leveranciers en data
Eenmalig: jurist of consultantEen privacyadviseur die je register, je overeenkomsten en je meldproces eenmalig inrichtWie snel een onderbouwd startpunt en een onafhankelijke blik wilDe kennis vertrekt met de adviseur; borg dat het in je eigen proces landt en actueel blijft
Maatwerk: in je eigen systemenEen verwerkersregister dat meeloopt met je stack, werkende exports die je zelf draait, en zicht op welke koppeling welke data raaktWie het overzicht wil laten meebewegen met zijn systemen in plaats van in een losse spreadsheetVraagt 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

Alisina Nawabi
Geschreven doorAlisina Nawabi

AI Product Engineer & Solutions Architect

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.

Meer informatie

Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.

Genoemde integraties

Dit artikel noemt deze tools. Ik koppel ze op maat aan je eigen systemen.

Gerelateerde artikelen

Vier zaken, één beweging: de AP neemt de datastromen van het AI-tijdperk onder handen
Signaal
6 min

4 jul 18:06

Vier zaken, één beweging: de AP neemt de datastromen van het AI-tijdperk onder handen

Uber, Yango, Odido, tien gemeenten. Los zijn het losse boetes, samen laten ze zien hoe de Autoriteit Persoonsgegevens de datastromen van het AI-tijdperk onder handen neemt. En waar dat jou raakt.

De AI-geletterdheidsplicht: de deadline ligt al achter je
Inzicht
6 min

21 jun 13:03

De AI-geletterdheidsplicht: de deadline ligt al achter je

Iedereen noemt augustus 2026 als de deadline voor de AI-geletterdheidsplicht. Dat is het verkeerde jaar. De plicht is al ruim een jaar van kracht, en geletterdheid is niet met terugwerkende kracht aan te tonen.

Wat je in een chatbot typt, krijg je nooit meer terug: de blinde vlek in je AI-gebruik
Inzicht
7 min

15 jul 09:00

Wat je in een chatbot typt, krijg je nooit meer terug: de blinde vlek in je AI-gebruik

De delete-knop in je chatbot haalt het gesprek alleen weg bij jou. Juridisch en technisch is je invoer een blijvende registratie, en dus verschuift de enige beslissing die telt naar het moment voor je op enter drukt.

AVG-checklist voor generatieve AI: zo zet je ChatGPT en Copilot rechtmatig in
Gids
Uitgebreide gids9 min

14 jul 14:47

AVG-checklist voor generatieve AI: zo zet je ChatGPT en Copilot rechtmatig in

Je gebruikt ChatGPT of Copilot, maar legde nergens vast op welke grondslag. Deze checklist loodst je langs de AVG voor generatieve AI: van de eerste vraag tot grondslag, verwerkersovereenkomst, DPIA en de waarborgen die de AP eist.

Digitale soevereiniteit is in Den Haag van praat een breekijzer geworden
Signaal
6 min

5 jul 14:54

Digitale soevereiniteit is in Den Haag van praat een breekijzer geworden

In zes weken blokkeerde de staat een Amerikaanse overname, trok DigiD naar een eigen cloud en koos Europees voor zijn supercomputer. Los is het beleid, samen laat het zien dat soevereiniteit van ambitie een instrument werd.

AI Act-transparantieplicht 2026: geen compliance-ramp, wel een deadline
Inzicht
6 min

17 jun 11:00

AI Act-transparantieplicht 2026: geen compliance-ramp, wel een deadline

De transparantieplicht uit de AI Act gaat 2 augustus 2026 in. Voor de meeste bedrijven is dat een checklist van een handvol punten, geen kwartaal vol compliance. De echte fout is wachten tot september.