Datalek bij je WhatsApp-API: meldplicht en eerste stappen onder de AVG

Een gelekte API-token, een verloren toestel met een actieve WhatsApp-koppeling, logs die per ongeluk telefoonnummers en berichtinhoud bevatten — dat zijn geen hypothetische risico's, dat zijn de meest voorkomende manieren waarop een WhatsApp-integratie uitlekt. Dit artikel is algemene informatie, geen juridisch advies; raadpleeg bij een concreet incident altijd een jurist of je functionaris gegevensbescherming (FG/DPO).

Wat telt als datalek onder de AVG

Een datalek (art. 4.12 AVG) is elke inbreuk op de beveiliging die leidt tot vernietiging, verlies, wijziging, onbevoegde verstrekking van, of onbevoegde toegang tot persoonsgegevens. Dat is breder dan "iemand heeft onze database gestolen": ook een verkeerd geadresseerde export, een medewerker die inlogt met een gedeeld wachtwoord dat niet ingetrokken werd na vertrek, of een API-token dat in een publieke GitHub-repo terechtkomt, valt erbinnen. Telefoonnummers en berichtinhoud zijn persoonsgegevens — vaak direct herleidbaar tot één persoon — dus een lek via je messaging-stack is evengoed een datalek als een lek via je CRM.

Wanneer moet je melden, en aan wie

Twee aparte verplichtingen, vaak verward:

• Melding aan de toezichthouder (in Belgie de Gegevensbeschermingsautoriteit, in Nederland de Autoriteit Persoonsgegevens) binnen 72 uur nadat je kennis kreeg van het lek — tenzij het onwaarschijnlijk is dat het lek een risico vormt voor de rechten en vrijheden van de betrokkenen. Een intern gelogd foutbericht zonder dat iemand extern toegang had, is doorgaans geen meldplichtig lek; een gelekt API-token waarmee berichten en telefoonnummers van klanten uitgelezen konden worden, meestal wel.
• Melding aan de betrokkenen zelf (art. 34 AVG) is alleen verplicht bij een hoog risico — bijvoorbeeld wanneer berichtinhoud met gevoelige informatie (gezondheid, financiële gegevens) blootgelegd is, of wanneer het lek identiteitsfraude mogelijk maakt.

Beide beoordelingen maak je zelf, als verwerkingsverantwoordelijke — niet je WhatsApp-API-leverancier. Documenteer de afweging altijd, ook als je besluit niet te melden: art. 33.5 AVG verplicht je om elk lek intern te registreren, gemeld of niet.

Typische lek-scenario's bij een WhatsApp-integratie

• Gelekt API-token. Wie je token heeft, kan berichten versturen en ontvangen uit naam van jouw nummer, en krijgt toegang tot je gespreksgeschiedenis. Dit is doorgaans een meldplichtig lek zodra het token buiten je eigen infrastructuur circuleerde (een publieke repo, een gedeeld logbestand, een gecompromitteerde server).
• Verloren of gestolen toestel met een actieve koppeling. Een paired sessie geeft toegang tot lopende gesprekken zolang hij niet ontkoppeld is. Zie onze uitleg van de QR-koppelflow en re-pairing voor hoe je een sessie zelf kan verbreken.
• Verkeerd geconfigureerd webhook-endpoint. Stuur je inbound berichten naar een test-URL die per ongeluk publiek bleef staan, dan loopt klantdata via een endpoint zonder de beveiliging die je productieomgeving wel heeft.
• Onvoldoende afgeschermde logs. Applicatielogs die ruwe webhook-payloads wegschrijven (telefoonnummer, berichttekst, media-links) zijn een lek zodra die logs breder toegankelijk zijn dan nodig — bijvoorbeeld in een gedeelde logging-dashboard zonder toegangscontrole.

Eerste stappen bij een vermoeden

1. Stop de blootstelling eerst, documenteer daarna. Ontkoppel een gecompromitteerd toestel direct via de dashboard of de disconnect-aanroep uit de pairing-flow; vraag bij een gelekt token of webhook-secret meteen om vervanging via support, zodat de oude waarde niet langer werkt.
2. Leg het tijdstip van ontdekking vast. De 72-uursklok start op het moment dat jij — niet je leverancier — kennis kreeg van het lek. Noteer dat tijdstip zo snel mogelijk, want het bepaalt je deadline.
3. Vraag bij je verwerker na wat er gebeurd is. Een WhatsApp-API-leverancier is onder je verwerkersovereenkomst verplicht om je bij te staan en je te informeren "zonder onnodige vertraging" zodra die zelf een incident vaststelt. Zie ons overzicht van wat een goede DPA moet regelen voor wat je daar contractueel kan verwachten.
4. Beoordeel het risico, niet de ernst van je eigen schrik. Een token dat één dag zichtbaar was in een private CI-log dat niemand anders zag, is een ander risicoprofiel dan een token dat weken lang publiek op internet stond. Documenteer die inschatting.
5. Meld, of documenteer waarom niet. Bij twijfel meld je — een onterechte melding kost veel minder dan een gemiste, verplichte melding.

Wat dit niet is

Een geweigerde send door de rate limiter, een bericht dat genegeerd wordt omdat de ontvanger STOP heeft gestuurd, of een tijdelijke API-timeout zijn geen datalekken — het zijn precies de beveiligingsmaatregelen die een lek elders moeten voorkomen. Verwar een storing niet met een inbreuk; dat bespaart je onnodige meldingen en houdt je register betrouwbaar voor de gevallen die er wel toe doen.

Hoe TextMeFlow dit beperkt

EU-hosting (Parijs) houdt de verwerking binnen de EU, wat discussies over internationale doorgifte bij een incident vermijdt. Elke WhatsApp-koppeling is zelf te verbreken en opnieuw op te zetten zonder tussenkomst van support, zodat je bij een vermoeden van compromittering niet moet wachten op een ticket om de blootstelling te stoppen. Voor de volledige technische achtergrond van wat er over een webhook-verbinding loopt, zie de webhooks-documentatie.

Wil je zelf nagaan hoe je integratie reageert op een ontkoppeling of een token-wissel voordat het scherp staat? Test het rustig op het gratis plan.

Start gratis op TextMeFlow →