Opinie

In haar verslag over 2017 en 2018 heeft de Saksische toezichthouder (DPA) de vraag behandeld of een penetratietest moet worden gezien als een verwerking door een Verwerker. Dit bericht is alweer van enige tijd geleden maar levert in de praktijk nog steeds vragen op. In de discussies die ik heb kunnen vinden (links onderin) mis ik de brontekst en het kernargument. Daarom toch nog ook deze bijdrage aan dit debat.

Zoals je hier gewend bent: wij proberen volledig te zijn. Dus: 'warning: long read'.

Managementsamenvatting: nee, geen verwerker.

In heel veel IT-relaties is het niet zo eenvoudig om te duiden in welke gevallen er sprake is (of zou moeten zijn) van verwerking door een Verwerker. Ik schreef daar, op basis van EDPB opinie 169, ook al eerder over in 'de on-premise softwareleverancier'. Voor penetratietests wordt een vergelijkbare vraag gesteld: een externe pentester kan immers data zien, downloaden, verwerken. Moet je dan een verwerkersovereenkomst sluiten?

Het "Saksische advies" is niet eenvoudig te vinden zonder een tip. Daarom: hier. Je zoekt paragraaf 4.3.4. Het is uiteraard een advies in het Duits. Ik heb voor het gemak een 'best effort' vertaling gemaakt, met alle denkbare disclaimers over mijn beheersing van de Duitse taal.

Verwerking vs Verwerker

Hamvraag is natuurlijk of de pentester een Verwerker is in de zin van de AVG. Dat vertaalt zich naar de vraag of er daadwerkelijk opdracht tot verwerking van persoonsgegevens is gegeven. Of er mandaat is gegeven om namens de opdrachtgever persoonsgegevens te verwerken. Dat kan het geval zijn, maar dat hoeft niet. Als data-exfiltratie geen onderdeel van de opdracht is ('steel de database' vs 'breek in') kan ik de pentester toch moeilijk als verwerker zien, ook al is het denkbaar dat hij bij een geslaagde inbraak persoonsgegevens ziet. Zoals eerder gezegd: "gegevens verwerken maakt je geen Verwerker". Het mandaat (of 'de primaire opdracht' zoals de Handleiding AVG stelt) is essentieel voor de verwerkersrelatie en dat mandaat krijg je niet per ongeluk. Als het goed is krijg je ook geen mandaat 'voor het geval dat'.

Dat geldt ook voor pentesters. De Saksische DPA erkent dat ook expliciet in haar advies. Een pentester is normaliter geen Verwerker in de zin van de AVG (lid 4), omdat (ook naar Saksische overtuiging) de pentest-opdracht niet primair ziet op het verwerken van persoonsgegevens. So far so good.

Dan wordt het interessanter. De Saksische DPA stelt dat het mogelijk is dat de pentester persoonsgegevens kan verwerken. Dat klopt uiteraard, omdat het niet te voorspellen is wat de pentester kan doen in het systeem van de opdrachtgever als hij succesvol is. De DPA stelt (in mijn vertaling):

Op basis van de uitgevoerde test bestaat, afhankelijk van de opdracht, de mogelijkheid dat door de opdrachtnemer die de test uitvoert persoonsgegevens verworven, uitgelezen of op de een of andere manier verwerkt worden. Als dit niet kan worden uitgesloten, adviseer ik de verantwoordelijken om de opdrachtnemer te binden door middel van een verwerkersrelatie, zodat deze niet wettelijk optreedt als 'derde' en de opdrachtgever de baas blijft over de gegevens.

... naar mijn idee een vreemde opmerking. En een vreemde juridische constructie. Om zes redenen.

• Als je iemand Verwerker maakt, leg je vast dat de Verwerker 'ten behoeve' van jou (art. 4 lid 8) persoonsgegevens verwerkt. Je mandateert de Verwerker om namens jou te verwerken. Het lijkt mij heel vreemd om 'voor het geval dat' iemand te mandateren voor een nog onbekende handeling. In deze situatie weten we helemaal nog niet tot welke verwerking de pentester in staat zal zijn en hem op voorhand alvast mandateren lijkt mij heel dubieus.
  Natuurlijk schep je met die constructie ook eisen en daar gaat het de DPA om (lijkt mij: aanname van mijn kant). Juridisch neem je dan de pentester mee naar art. 28, met het betekenisvolle 'uitsluitend', de passende technische en organisatorische maatregelen en de verwerkersovereenkomst in lid 3. Heel logische eisen allemaal, maar die kun je ook stellen zonder de verwerkersrelatie - namelijk in de overeenkomst van opdracht.
• Zoals gezegd zijn de mogelijke verwerkingen nog onbepaald op het moment van de opdracht en dus ook op het moment van het sluiten van de verwerkersovereenkomst. Terwijl die verwerkingen wettelijk in de verwerkersovereenkomst moeten staan. De "aard en doel van de verwerking, het soort persoonsgegevens en de categorieën van betrokkenen, en de rechten en verplichtingen van de verwerkingsverantwoordelijke" (art. 28 lid 3) bepalen de scope/inhoud van de verwerkingsrelatie. Die horen vooraf vast te liggen. De suggestie uit Saksen lijkt: maak de pentester alvast Verwerker en vul later maar in om welke verwerkingen en gegevens het gaat. Carte blanche.
• In het verlengde van art. 28: de pentester mag als Verwerker uitsluitend verwerken in opdracht van de Verwerkingsverantwoordelijke (art. 29). De pentester kan dus geen persoonsgegevens verwerken zonder (voorafgaande) opdracht van de opdrachtgever. De Saksische DPA suggereert (naar mijn interpretatie) dat we die situatie om kunnen draaien - door eerst een verwerkersrelatie met de pentester op te tuigen waarna we vervolgens de opdracht nog eens invullen. Dat is naar mijn idee alleen haalbaar met een heel liberale benadering van art. 29: namelijk met een opdracht die zo breed is dat 'ie onbepaald is.
  De pentester als Verwerker heeft ofwel een (specifieke) opdracht vooraf om persoonsgegevens te verwerken (een opdracht tot data-exfiltratie, waarbij een verwerkersrelatie logisch is) ofwel, bij gebrek aan die voorafgaande opdracht, een verbod om dat te doen omdat hij dan buiten zijn bevoegdheid treedt. Het expres formuleren van een hele brede opdracht waarna de pentester als Verwerker onder mandaat naar eigen inzicht op basis van een carte blanche-opdracht kan verwerken komt niet over als een goed idee.
• Als je de pentester als Verwerker zou zien, geldt ook art. 28 lid 10. Daar wordt de pentester zelfstandig de Verwerkingsverantwoordelijke voor alle verwerkingen waarvan hij de doeleinden bepaalt - dus de verwerkingen die buiten de opdracht liggen en waar geen mandaat voor is. Dit is de keerzijde van het vorige argument: als je de pentester bewust als Verwerker wilt binden, omdat je daarmee de eisen van art. 28 lid 3 kunt afdwingen via de verwerkersovereenkomst, moet je dus ook een hele brede opdracht formuleren omdat de pentester anders alsnog via art. 28 lid 10 de Verantwoordelijke wordt en je (voor die verwerkingen die buiten de opdrachtformulering vallen) niets meer hebt aan de verwerkersovereenkomst. De scope van de verwerkersovereenkomst kan immers niet groter zijn dan die van de opdracht.
  Aangenomen dat we de scope van de verwerkersovereenkomst niet vooraf kunnen bepalen (zonder die 'carte blanche' te geven) levert de Verwerker-status dus eigenlijk niets op.
• Meer juridisch van aard: waarom zou de pentester een 'derde' zijn als hij geen Verwerker is? Het lijkt hier alsof de Saksische DPA een pentester ofwel als Verwerker ofwel als Derde ziet. Er is ook iets te zeggen (afhankelijk van de context, ik ben voorzichtig) om de pentester te zien als zelfstandige Verwerkingsverantwoordelijke die op basis van "uitvoering overeenkomst" (art. 6 lid 1 sub b) opereert. Of op basis van "gerechtvaardigd belang" (art. 6 lid 1 sub f) via Overweging 49.
• Als de opdrachtgever controle over data verliest omdat de pentester data verwerft, is een verwerkersrelatie niet de enige (en m.i. niet de juiste) methode om die controle te behouden. Niet in de laatste plaats omdat het vooral om bedrijfsinformatie zal gaan en niet alleen om persoonsgegevens. Als de pentester de verwerving binnen de opdracht kon doen, zal hij gehouden zijn aan geheimhouding en vernietiging, te regelen in de overeenkomst tot opdracht. Houdt hij zich daar niet aan, dan hebben we civielrechtelijke middelen (schadevergoeding, betaling opschorten) en ook strafrechtelijke (datadiefstal, evt. schending (bedrijfs)geheim). Je zou contractueel heel veel kunnen regelen, in de overeenkomst tot opdracht. Bijvoorbeeld door vast te leggen dat je (alsnog) aangifte van datadiefstal doet als blijkt dat de data niet z.s.m. vernietigd is. De verwerkersovereenkomst is voor wat betreft scope daar maar een onderdeel van.

Het probleem met de pentester als Verwerker is dus dat de (mogelijke) verwerkingen door de pentester a priori worden geplaatst onder een 'carte blanche' mandaat van de opdrachtgever, omdat je niet van te voren kunt weten waartoe de pentester in staat is of wat hij kan doen als hij mogelijkheden ontdekt. Daar is immers de pentest voor. Bovendien gaat het 'controle' argument juist ook over waardevolle informatie die niet persoonsgegevens zijn. Die je dus niet kunt regelen met een verwerkersovereenkomst.

Nadrukkelijk nog even de opmerking dat dat 'carte blanche' mandaat (of welk mandaat dan ook) niet onstaat door een verwerkersovereenkomst af te sluiten. Met een verwerkersovereenkomst regel je de inhoud van het mandaat, de regels waar de gemandateerde aan moet doen. Het mandaat zelf ontstaat echter uit de opdracht - het moet expliciet worden gegeven. Het enkel sluiten van een verwerkersovereenkomst (zonder een opdracht/mandaat tot verwerking) bereikt niets en lost ook niets op. Het gaat om de inhoud van de 'primaire opdracht', zoals ook de Handleiding AVG stelt. De primaire opdracht bij een pentest komt naar mijn idee (aangenomen dat er geen opdracht is voor exfiltratie) niet neer op de verwerking van persoonsgegevens namens de opdrachtgever. Dus geen Verwerker. Dus geen verwerkersovereenkomst.

Daarmee pleit ik ervoor het advies uit Saksen beleefd naast ons neer te leggen. De pentester is (net zoals de 'remote consultant') een externe partij wiens primaire opdracht niet is gericht op de verwerking van persoonsgegevens. Dat de pentester daarbij persoonsgegevens zou kunnen zien is m.i. niet anders dan een externe consultant die bij u ten kantore persoonsgegevens op de whiteboards kan zien. Is dat een goed idee? Nee. Is hij daarom Verwerker? Nee. Oplossing? Geheimhouding en vernietiging van data.

Misschien moeten we de Saksische suggestie lezen als "vul de opdracht aan met de eisen uit art. 28 lid 3". Waarbij we niet vergeten dat een pentest gaat om informatie in het algemeen en niet alleen om persoonsgegevens. Waarbij we niet vergeten dat de zorg uit Saksen (dat data openbaar zou kunnen worden) ook al civielrechtelijk en strafrechtelijk wordt geregeld: de pentester die buiten zijn opdracht gaat is juridisch heel gevaarlijk bezig. De focus moet dus op de opdracht liggen en niet op de randvoorwaarden voor de uitvoering voor het geval de uitvoerder in contact zou kunnen komen met persoonsgegevens. Als die opdracht (expliciet, primair) gericht is op verwerking van persoonsgegevens: akkoord. Zo niet: sluit niet een zinloze verwerkersovereenkomst af in de verwachting dat jouw data daardoor veiliger wordt. Schijnveiligheid is immers een dreiging.

Wat dan wel?

Als je met mij eens bent dat de pentester geen Verwerker is, is de logische vraag: wat regelen we dan wel?

Geheimhouding. Vernietiging van verworven data. Logging en audit van gewijzigde data. Eventuele schade door verstoring van systemen. Het invullen van 'rechtmatigheid' om de strafrechtelijke computervredebreuk buiten de deur te houden.

Een simpele civielrechtelijke overeenkomst. Daarmee zijn de ogen gericht op zorgvuldigheid, geheimhouding en potentiële schade, maar wordt de pentester niet in een (AVG-)positie gedwongen waarin hij niet thuishoort. Voordeel: uw waardevolle bedrijfsdata (die geen persoonsgegevens zijn) vallen ook onder die overeenkomst.

Pentest met exfiltratie, cryptoanalyse

Voor de volledigheid benadruk ik nog wel de uitzondering bij dit betoog. Als de opdracht van de penetratietest groter is en ook een opdracht bevat om specifieke gegevens van de klant te verwerken, is het natuurlijk een ander verhaal. Dat is bijvoorbeeld het geval bij een opdracht tot exfiltratie (waarbij de pentester bewust en conform afspraak een dataset bemachtigt) of bij een opdracht tot cryptoanalyse (waarbij de pentester versteutelde data die hij kon bemachtigen probeert te ontcijferen). Aangenomen dat in die data persoonsgegevens zitten, komt het Saksische advies logischer over. Er is dan immers wel een specifieke opdracht tot (die) verwerking. Nu de dataset in opdracht van de klant bij de pentester beland is, is het ook logisch dat de pentester verantwoordelijk is voor de beveiliging daarvan (op zijn systemen) en dat hij melding doet als daarbij iets mis gaat en een datalek ontstaat. Zoals je aanvoelt: in deze situatie past de verwerkersrelatie wel.

Links

Op LinkedIn is deze materie ook besproken (link) en op Security.nl ook (link). Opmerkelijk is dat op Security.nl gesteld wordt:

Wie penetration testing oftewel securityonderzoek naar binnendringmogelijkheden uitvoert, moet een verwerkersovereenkomst sluiten met zijn opdrachtgever. Dat bepaalde althans de Saksische Autoriteit Persoonsgegevens onlangs.

... en dat klopt dus niet. Het is een advies. Een advies dat ik graag even van bovenstaande context wil voorzien.