Pentesten en de AVG: mag een pentester bij persoonsgegevens?

Over de vraag of een pentest verplicht is, wordt in Nederland veel geschreven. Over de vraag of een pentest zélf aan de privacyregels voldoet, opvallend weinig – terwijl juist daar de meeste organisaties op vastlopen zodra de jurist meekijkt.

Dit artikel behandelt beide kanten: wat de AVG over testen zégt, en wat de AVG van de test zelf verlangt.

De AVG is de enige regeling die testen bij naam noemt

Dit verrast bijna iedereen, dus meteen maar: de bepaling die periodiek testen met zoveel woorden voorschrijft staat niet in NIS2 of in de Cyberbeveiligingswet, maar in de AVG.

Artikel 32 lid 1 sub d verplicht de verwerkingsverantwoordelijke en de verwerker tot passende technische en organisatorische maatregelen, waaronder – waar passend – “een procedure voor het op gezette tijdstippen testen, beoordelen en evalueren van de doeltreffendheid van de technische en organisatorische maatregelen ter beveiliging van de verwerking”.

Let op de woorden waar passend. Ook dit is geen absolute plicht: het is een norm die met het risico meebeweegt. Verwerkt u weinig en weinig gevoelige gegevens, dan volstaat minder. Verwerkt u medische gegevens, betaalgegevens of gegevens van grote aantallen mensen, dan wordt het lastig vol te houden dat u de doeltreffendheid van uw maatregelen nooit toetst.

Ter vergelijking: de Cyberbeveiligingswet – de Nederlandse invulling van NIS2, in werking sinds 15 augustus 2026 en van toepassing op zo’n 8.000 organisaties – noemt het woord pentest nergens. Die wet vraagt om een risicoanalyse en om passende en evenredige maatregelen. Wie beweert dat NIS2 een pentest verplicht stelt, verwijst naar de verkeerde regeling.

De andere kant: een pentest is zelf een verwerking

Zodra een tester persoonsgegevens kan inzien – en dat kan bijna altijd, want in vrijwel elke applicatie zitten namen, e-mailadressen of klantdossiers – is de test zelf een verwerking in de zin van de AVG. Daarmee gelden er drie dingen.

1. U heeft een grondslag nodig

De gangbare grondslag is gerechtvaardigd belang, artikel 6 lid 1 sub f. Het belang is evident: u wilt weten of de maatregelen die de gegevens van uw klanten en medewerkers beschermen daadwerkelijk werken. Dat belang staat bovendien niet op zichzelf – artikel 32 vraagt er zelf om.

Wat in de praktijk vaak misgaat: organisaties denken dat zij toestemming van medewerkers nodig hebben voor een phishingsimulatie. Dat is meestal juist de verkeerde grondslag. Toestemming moet vrij gegeven zijn, en in een gezagsverhouding is dat zelden het geval; bovendien maakt een simulatie waarvoor iedereen vooraf tekent de meting waardeloos. Gerechtvaardigd belang past hier beter, mits u de afweging vastlegt en de uitvoering proportioneel houdt.

2. De tester is verwerker – dus een verwerkersovereenkomst

Voert een externe partij de test uit, dan is die partij verwerker en bent u verwerkingsverantwoordelijke. Artikel 28 verlangt dan een verwerkersovereenkomst. Daarin horen ten minste:

• het onderwerp, de duur, de aard en het doel van de verwerking;
• welke categorieën persoonsgegevens en betrokkenen in beeld kunnen komen;
• dat de verwerker uitsluitend op uw instructie handelt;
• geheimhouding voor iedereen die feitelijk aan de test werkt;
• de beveiligingsmaatregelen aan de kant van de tester;
• of, en zo ja onder welke voorwaarden, subverwerkers zijn toegestaan – bij pentests: onderaannemers;
• dat gegevens na afloop worden gewist of teruggegeven, met een termijn;
• dat de verwerker meewerkt aan uw eigen verplichtingen, waaronder de meldplicht.

Die laatste twee zijn de punten die in standaardcontracten van leveranciers het vaakst ontbreken.

3. Dataminimalisatie geldt ook tijdens de test

Het uitgangspunt is testen op nagemaakte of geanonimiseerde gegevens. Dat is niet alleen juridisch netter, het is technisch vaak ook prettiger werken.

Kan dat niet – en soms kan het echt niet, omdat een fout in de bedrijfslogica zich alleen laat aantonen op realistische data – dan gelden de gewone regels:

• de tester bekijkt niet méér gegevens dan nodig om de bevinding aan te tonen;
• bewijsmateriaal wordt zo veel mogelijk afgeschermd; een schermafdruk waarop één rij zichtbaar is, bewijst hetzelfde als een export van tienduizend rijen;
• bewijs wordt versleuteld opgeslagen, met een korte bewaartermijn en een afgesproken moment van vernietiging;
• het rapport zelf bevat geen persoonsgegevens die er niet in hoeven te staan.

Wat als de tester een écht datalek aantreft?

Dit gebeurt vaker dan offertes doen vermoeden: tijdens een test blijkt dat gegevens al langer toegankelijk waren, of dat er sporen van een eerdere inbraak zijn.

Op dat moment gaat het niet meer over de test. Er ligt dan mogelijk een inbreuk in verband met persoonsgegevens en de klok van 72 uur uit artikel 33 begint te lopen voor de melding bij de Autoriteit Persoonsgegevens – tenzij het onwaarschijnlijk is dat de inbreuk een risico oplevert. Is het risico voor betrokkenen hoog, dan volgt bovendien een melding aan die betrokkenen zelf op grond van artikel 34.

Daarom hoort in het contract te staan wat de tester doet bij zo’n vondst: onmiddellijk stoppen met verder onderzoek op dat spoor, u langs een afgesproken kanaal informeren, en het bewijs bewaren op een manier die uw eigen onderzoek niet in de weg zit. Een leverancier die dit pas in het eindrapport meldt, kost u dagen van een termijn die er maar 72 uur is.

Phishingsimulaties: de gevoeligste categorie

Simulaties tegen medewerkers verdienen aparte behandeling, om twee redenen.

Privacy. U verwerkt gegevens over gedrag van identificeerbare personen. Dat kan, maar het vraagt om terughoudendheid in de uitvoering en in de rapportage.

Arbeidsverhouding. Een simulatie die individuele medewerkers afrekent op een klik, meet niet de weerbaarheid van de organisatie maar beschadigt het vertrouwen dat u juist nodig heeft om meldingen binnen te krijgen.

De praktische norm die beide problemen tegelijk oplost:

Resultaten worden uitsluitend geaggregeerd gerapporteerd;
individuele medewerkers worden niet beoordeeld of geïdentificeerd.

Daarnaast: betrek de ondernemingsraad tijdig. Een simulatieprogramma raakt personeelsvolgsystemen en is precies het soort onderwerp waarover u beter vooraf dan achteraf het gesprek voert. En informeer medewerkers vooraf dát er gedurende het jaar geoefend wordt – niet wanneer, en niet met welk scenario. Dat behoudt de meetwaarde en neemt het verrassingselement uit de arbeidsrechtelijke kant weg.

Hoe wij dat inrichten staat bij social engineering en bij PhishGun.

Heeft u een DPIA nodig voor een pentest?

Doorgaans niet voor de test zelf. Een gegevensbeschermingseffectbeoordeling hoort bij een verwerking die waarschijnlijk een hoog risico oplevert, en een afgebakende beveiligingstest op uw eigen systemen is dat zelden.

Twee situaties liggen anders. Als u structureel op productiegegevens test, en als u een doorlopend simulatieprogramma inricht dat gedrag van medewerkers over langere tijd vastlegt, is de vraag wél terecht. In beide gevallen: leg het voor aan uw functionaris voor gegevensbescherming voordat het programma begint, niet erna.

Wat u vastlegt vóór de test begint

Kort samengevat

De AVG is niet de reden om géén pentest te laten uitvoeren – zij is een van de weinige regelingen die er expliciet om vraagt. Wat de AVG wél verlangt, is dat de test net zo zorgvuldig met gegevens omgaat als de systemen die getest worden.

In de praktijk is dat een kwestie van vooraf vastleggen: de grondslag, de verwerkersovereenkomst, wat er met bewijs gebeurt, en wat er gebeurt als er iets échts wordt aangetroffen. Vier afspraken, allemaal te maken vóór de eerste testdag.

Wilt u dit netjes inrichten voordat u laat testen? Bespreek het in een gratis adviesgesprek, of lees eerst wat een pentest precies is en waar u op let bij het kiezen van een leverancier.

Gerelateerde diensten van Haxoris: pentesten van webapplicaties en infrastructuur · security audit van de IT-omgeving · social engineering en phishingsimulaties