Heb je nou voor pentesten óók al een verwerkersovereenkomst nodig?

Wie penetration testing oftewel securityonderzoek naar binnendringmogelijkheden uitvoert, moet een verwerkersovereenkomst sluiten met zijn opdrachtgever. Dat maak ik op uit een recente Linkedinblog die me attendeerde op een uitspraak van de Saksische Autoriteit Persoonsgegevens van die strekking. Wat natuurlijk enige onrust gaf bij professionele pentesters, want je hébt al zo’n papierwinkel voordatje aan de slag kan en moet er dan ook nog een verwerkersovereenkomst bij voor het geval je persoonsgegevens tegenkomt? Nou ja, formeel wel maar er zijn trucjes.

Bij een pentest ga je bij een klant aan de slag om zwakheden in zijn systeem te vinden. Je probeert binnen te dringen, zeg maar wat je anders computervredebreuk zou noemen. Vandaar die papierwinkel: je wilt dat je klant een pentest waiver of toestemmingsverklaring tekent waarin duidelijk vaststaat dat je niets tegen zijn wil doet, en dus niets dat wederrechtelijk en daarmee strafbaar kan worden.

Dat is voor klanten dan weer spannend, want wat als je nu iets stukmaakt tijdens dat onderzoek of verder kwam dan ingeschat en daar raak je iets dat echt niet de bedoeling was? Dat geeft dus de nodige onderhandeling vaak.

Sinds de AVG is daar een extra risico bij gekomen. Het is natuurlijk mogelijk dat je bij je security-onderzoek persoonsgegevens tegenkomt, denk aan een database met klantgegevens waar je bij kunt. Als je die database dan vervolgens downloadt (“het zal toch niet waar zijn”) dan ben je persoonsgegevens aan het verwerken, in het AVG-jargon.

En dat is dan even lastig, want hoezo mág jij dat van de AVG? Als zelfstandig ingehuurd onderzoeker heb je daar geen grondslag voor, je hebt geen toestemming van de betrokken klanten en je hebt ook geen contract met ze. Vandaar het advies: werk als verwerker, als hulpje van je opdrachtgever. Dan is wat je doet met die gegevens zijn probleem (althans; waarom dat mág dat onderzoek). Alleen zit je dan met de tegenpool dat je niet meer mag doen met die gegevens dan hij je toestaat.

Nu zou dat in de praktijk wel mee moeten vallen, want wat je gaat doen is normaliter niet meer dan een kopie maken, vastleggen wat je gevonden hebt en dan vernietigen (of teruggeven). En dat is precies wat een verwerker ook zou doen.

Het wordt alleen op formele gronden ingewikkeld: oh jee we hebben een verwerker jongens, dus hier is de standaard verwerkersovereenkomst die de boekhouder ook moet tekenen. En daarin staan dan vele dingen zoals een passend securitybeleid (met auditclausule, dus de klant komt bij jou, securityonderzoeker, kijken of je wel veilig bent – de meest hilarische case die ik had was dat de verwerker verklaarde periodiek pentests op zichzelf uit te voeren), medewerking aan inzage- en verwijderverzoeken en ga zo maar door dat echt zwaar over de top is voor zo’n onderzoek. Zeker omdat het ook nog eens aan onbeperkte aansprakelijkheid gekoppeld is.

Wat mij betreft mag je dát dus afwijzen. Je kunt in je pentest waiver of AV volstaan met een verklaring dat je verwerker bent, dat je de AVG zult naleven en dat je alle kopieën van data na logging van de gebeurtenis zult wissen, behalve eventuele kopieën die nodig zijn voor de gewenste rapportage.

Arnoud

2 reacties

  1. In plaats van een soort tussenvorm – en daarmee juridische onduidelijkheid en dus discussie – te creëren kan je ook beargumenteren dat de pentestende partij zelfstandig verwerkingsverantwoordelijke is en dus rechtstreeks door de AVG geadresseerd wordt om netjes met de persoonsgegevens die hij als pentester (onverhoopt) verkrijgt om te gaan en alles te doen wat de AVG voorschrijft. De grondslag voor rechtmatigheid van de verwerking uit de AVG is dan “de verwerking is noodzakelijk voor de behartiging van de gerechtvaardigde belangen van de verwerkingsverantwoordelijke of van een derde”. In dit geval is de opdrachtgever wiens systeem noodzakelijkerwijze gepentest wordt dan dus de derde in wiens belangen behartigd worden door de pentestende partij. En de betrokkenen zijn ook dergelijke derden. Het is ook in hun belang dat de verwerkingsverantwoordelijke zijn systeem laat pentesten.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.