Opinie

Een van de meest gestelde AVG-vragen in de softwareindustrie is of je een verwerker bent als je on-premise software levert. En dus of in dat geval wel een verwerkersovereenkomst is vereist. De discussie gaat dan om ondersteunende diensten zoals consultancy (applicatiebeheer voor de klant bijvoorbeeld, of configuratiewerkzaamheden) en support (waaronder het 'inbellen'). Jouw medewerkers kunnen in contact komen met de persoonsgegevens die jouw klant verwerkt. Maar maakt dat van jou een Verwerker in de zin van de AVG?

Managementsamenvatting: nee.

Voor de niet-juristen: een begrip met een Hoofdletter is een begrip zoals bedoeld in de Wet, op deze site veelal de AVG of de Uitvoeringswet ('UAVG'). Het verschil tussen "verwerker" (wat jij ervan vindt) en "Verwerker" (wat de Wet ervan vindt) is dus juridisch relevant. Het leest wat lastiger, maar het dient een doel. Voor mij is het heel logisch. ;-/

Verwerking vs Verwerker

Bij on-premise komt de consultant of supportmedewerker mogelijk in contact met (Persoons-)gegevens van de klant. Doordat hij op locatie is of inbelt om (in een productieomgeving) een probleem op te lossen. Als dat gebeurt, is er sprake van een Verwerking, want raadpleging van Persoonsgegevens is ook een Verwerking. Helder. Art. 4 lid 2 AVG. Maar het enkele feit dat je Verwerkt, maakt je niet een Verwerker. Let op de hoofdletters: voor het in art. 4 lid 8 gedefinieerde begrip Verwerker worden meer eisen gesteld.

Verwerker

Uit art. 4 lid 8 volgt dat een Verwerker een orgaan is dat ten behoeve van de Verwerkingsverantwoordelijke persoonsgegevens verwerkt. De EDPB (de European Data Protection Board, voorheen bekend als WP29) heeft in een bekende opinie uitgewerkt wat een Verwerker is en wat niet. Die opinie is nog steeds leidend.

Een Verwerker is een partij die expliciet opdracht heeft gekregen om namens de Verantwoordelijke persoonsgegevens te Verwerken. We volgen hier de EDPB:

The existence of a processor depends on a decision taken by the controller, who can decide either to process data within his organization, for example through staff authorized to process data under his direct authority [..], or to delegate all or part of the processing activities to an external organization, i.e. [..] "a legally separate person acting on his behalf".
Therefore, two basic conditions for qualifying as processor are on the one hand being a separate legal entity with respect to the controller and on the other hand processing personal data on his behalf. This processing activity may be limited to a very specific task or context or may be more general and extended.

Er zit heel veel informatie in dit citaat. Ten eerste moet er een beslissing van de Verwerkingsverantwoordelijke zijn. Je wordt dus niet "per ongeluk" een Verwerker. Er is dus ook niet zoiets als een verwerker die een Verwerker wordt "omdat je in aanraking komt met persoonsgegevens". Je wordt alleen Verwerker als de Verwerkingsverantwoordelijke expliciet die keuze maakt.

Dat wordt nog duidelijker als we het over het mandaat gaan hebben. De EDPB heeft het over "on behalf". Dat kennen wij uit art. 4 lid 8 als "ten behoeve van de verwerkingsverantwoordelijke". De Verwerker moet namens de Verwerkingsverantwoordelijke de persoonsgegevens verwerken. Eigenlijk zegt de EDPB het vrij simpel door te stellen dat de Verantwoordelijke die Verwerking 'zelf zou kunnen doen of kan mandateren' aan een Verwerker - bijvoorbeeld om praktische, economische of technologische redenen. Uit die "on behalf" volgt dus ook dat er een mandaat moet zijn. De Verwerker mag niet meer of andere Verwerkingen doen dan diegenen die hij namens de Verwerkingsverantwoordelijke doet. De Verwerkingsverantwoordelijke blijft immers verantwoordelijk(e).

The most important element is the prescription that the processor act “…on behalf of the controller…”. Acting on behalf means serving someone else's interest and recalls the legal concept of “delegation”.

De opdracht moet expliciet gericht zijn op het verwerken van persoonsgegevens: 'a decision to process data'. We hebben het hier dus niet over een opdracht voor een bepaalde dienst waarbij de verwerking bijzaak is. De Handleiding AVG stelt dan ook:

U verwerkt ten behoeve van de verwerkingsverantwoordelijke persoonsgegevens wanneer de verwerking van persoonsgegevens uw primaire opdracht is. Met andere woorden, uw dienstverlening moet gericht zijn op het verwerken van persoonsgegevens ten behoeve van de verwerkingsverantwoordelijke. Wanneer de verwerking van persoonsgegevens niet uw primaire opdracht is, maar het een uitvloeisel is van een andere vorm van dienstverlening, dan bent u als dienstverlener zélf de verwerkingsverantwoordelijke voor deze verwerking. Oftewel, het enkele feit dat u een opdracht krijgt van de verwerkingsverantwoordelijke is niet voldoende om te kunnen spreken van verwerkerschap, de opdracht moet gericht zijn op het verwerken van persoonsgegevens.

Voor Verwerking door een Verwerker moet er dus sprake zijn van:

• een besluit om de gegevensverwerking door de Verwerker te laten doen (bewuste beslissing);
• een instructie / opdracht waarmee de scope van en het mandaat voor de Verwerking wordt bepaald;
• een Verwerking die (gedacht in verantwoordelijkheden) aan Verwerkingsverantwoordelijke toebehoort; die hij eigenlijk zelf zou moeten doen (de mandatering).

Dit is soms in de praktijk niet zo eenvoudig. Dat ligt niet aan jou: de EDPB stelt terecht "The [EDPB] recognises the difficulties in applying the definitions of the Directive in a complex environment".

Support en consultancy

Terug naar de hoofdvraag. Ben je een Verwerker als je supportwerkzaamheden en consultancy biedt bij on-premise? Nou, nee.

• Er is geen beslissing van de Verwerkingsverantwoordelijke (de klant) om Persoonsgegevens door jou te laten Verwerken in het kader van het bieden van support. De opdracht voor een Verwerker moet specifiek gaan om het Verwerken van Persoonsgegevens. Goede kans dat we het überhaupt nooit over Persoonsgegevens hebben gehad in de betreffende overeenkomst / SLA.
• Er is geen instructie om Persoonsgegevens te Verwerken noch ook om die gegevens op een specifieke manier te Verwerken. Het gaat immers om het oplossen van een softwareprobleem, niet om het verwerken van data of de inhoud van die data.
• Als je het oneens bent met de bovenstaande twee punten en toch vermoed een Verwerker te zijn, zou je die gegevens niet "namens" de Verwerkingsverantwoordelijke Verwerken. Er is geen mandatering en geen mandaat: je bent niet bezig met een Verwerking die de Verantwoordelijke anders zelf had gedaan.

De klant, de Verwerkingsverantwoordelijke, wil immers helemaal niet dat er Persoonsgegevens worden verwerkt door supportmedewerkers of consultants. Juist niet. Er is juist niet een instructie met betrekking tot Verwerking. Als je die gegevens zou Verwerken (waarschijnlijk inzien) zou je dat niet "namens" de klant doen. Ik zou denken dat de Verwerkingsverantwoordelijke (klant) juist probeert te voorkomen dat jij (leverancier) Verwerkt. De primaire werkzaamheden van support en consultancy zijn immers niet gericht op Persoonsgegevensverwerking - als dat gebeurt is het bijzaak.

En dat is te voorkomen of te beperken. De Verwerkingsverantwoordelijke zou naar mijn idee actief moeten voorkomen dat Persoonsgegevens bij de supportmedewerker of consultant komen. Bijvoorbeeld door geen screenshot te sturen, of (als dat toch moet) de betrokken Persoonsgegevens zwart te maken. Door naast een consultant te zitten als die op locatie is, zoals je dat vanuit jouw informatiebeveiligingsbeleid gewend bent.

Mocht de klant in kwestie een gemeente zijn: de Vereniging Nederlandse Gemeenten (eigenlijk de Informatiebeveiligingsdienst daarvan) stelt in een factsheet vrij duidelijk:

Wanneer de gemeente on-premise software laat installeren en deze intern door de gemeente op de eigen server wordt beheerd, is er geen verwerkersovereenkomst vereist. De leverancier levert enkel het softwarepakket en heeft dus geen toegang tot de persoonsgegevens. Er is dan ook geen sprake van het verwerken van persoonsgegevens. De leverancier kan de gemeente wel ondersteunen in het beheer van de software. Als de leverancier dan – hetzij op afstand, hetzij op locatie – incidenteel toegang verkrijgt tot het systeem, is de leverancier nog geen verwerker. In dit geval kan de gemeente volstaan met een geheimhoudingsverklaring.

De discussie over het verwerkerschap heeft het bij Privacy Management Partners gehaald tot punt 5 van hun "10 grootste misverstanden over de AVG", waarbij zij gelijk aan de Handleiding AVG stellen:

[..] als de kernactiviteit van de dienstverlener niets met verwerking van uw persoonsgegevens te maken heeft, dan wel de gegevensverwerking slechts bijzaak is, dan is de dienstverlener geen verwerker en heeft u dus geen verwerkersovereenkomst nodig.

Als je kijkt naar het overige informatiebeheer is die positie ook logisch. De opslag is de verantwoordelijkheid van de klant. De backup ook. De fysieke toegang, het accountbeheer, de netwerkbeveiliging, de anti-virus: allemaal voor de klant. Je herkent hier de beveiligingsplicht ex art. 32 AVG die dus bij de klant ligt - niet bij jou. Bij Verwerkers zijn deze onderwerpen juist de reden waarom een verwerkersovereenkomst nodig is. In ons on-premise geval gaat het eigenlijk alleen om geheimhouding.

Wat moet je dan wel regelen?

Een geheimhoudingsovereenkomst. Eenvoudig te regelen tussen de klant en de leverancier, waarbij gesteld wordt dat alle informatie die de leverancier bij de uitvoering van werkzaamheden te zien krijgt, vertrouwelijk zijn en als zodanig worden behandeld, op straffe van een boete en/of strafrechtelijke vervolging. Standaard, in de IT-industrie bekend onder de Engelse term 'NDA'. In de meeste gevallen wordt deze Non-Disclosure Agreement gesloten tussen de klantorganisatie en de leverancier, waarin als eis is opgenomen dat de leverancier met alle medewerkers een geheimhoudingsovereenkomst heeft. Typisch als onderdeel van de arbeidsovereenkomst, al dan niet aangevuld door een VOG. Let dus wel even op bij onderaanneming, als je externen inhuurt die je bij de klant plaatst. Dit zijn typische processen/maatregelen uit hoofdstuk 7 van de NEN-ISO/IEC 27002.

Uitzonderingen

Geen Verwerker dus. Dat scheelt weer. Er zijn natuurlijk wel uitzonderingen. Het is heel goed mogelijk dat een on-premise leverancier een conversie uitvoert, een dataset inleest, een lijst met gebruikers opneemt, een lijst met e-mailadressen opvraagt... you name it. Dat gebeurt natuurlijk. Dat zijn Verwerkingen van Persoonsgegevens waar een Verwerkingsverantwoordelijke (de klant) expliciet opdracht toe heeft gegeven en die onder mandaat worden Verwerkt. Dat zijn bij on-premise vaak eenmalige acties, waarna de Verwerkingsverantwoordelijke zelf het beheer van die ingelezen datasets krijgt.

Voor die acties is de leverancier tijdelijk en eenmalig een Verwerker. De EDPB stelt ook dat je Verwerker kunt zijn voor een specifieke taak, die dus beperkt is in tijd en scope: "This processing activity may be limited to a very specific task". Als je dit soort klussen krijgt, is het dus niet gek dat de klant een verwerkersovereenkomst met jou wil (en moet) afsluiten. Het belangrijkste is dan de scope van de Verwerking, de duur van de overeenkomst, de geheimhouding en de teruggave van eventuele media.

Update

The EDPB notes that a service provider may still be acting as a processor even if the processing of personal data is not the main or primary object of the service, provided that the customer of the service still determines the purposes and means of the processing in practice.

Waarbij vervolgens een drietal voorbeelden wordt gegeven. Het tweede voorbeeld is daarbij opmerkelijk (mijn onderstreping):

Company Z hires an IT service provider to perform general support on its IT systems which include a vast amount of personal data. The access to personal data is not the main object of the support service but it is inevitable that the IT service provider systematically has access to personal data when performing the service. Company Z therefore concludes that the IT service provider - being a separate company and inevitably being required to process personal data even though this is not the main objective of the service – is to be regarded as a processor. A processor agreement is therefore concluded with the IT service provider.

Dit lijkt tegenstrijdig met al het bovenstaande is dit blogartikel. Naar mijn idee is dit echter alleen een aanscherping: de opdracht tot Verwerking kan ook bestaan als deze Verwerking structureel noodzakelijk is om uitvoering te geven aan de hoofdopdracht - en dus logisch volgt uit die hoofdopdracht. Merk op dat de EDPB het heeft over inevitably beging required to process personal data. Het criterium of er sprake is van Verwerking gaat nog steeds uit van de opdracht. Het criterium is niet verschoven naar 'het hebben van toegang'. Het enkel hebben van incidentele toegang tot persoonsgegevens, of het toevallig kunnen zien van persoonsgegevens, blijft onvoldoende voor verwerkerschap. De uitleg en praktische uitvoering van de opdracht is bepalend: als een opdracht (tot het leveren van support) onvermijdelijk en systematisch leidt tot het verwerken van persoonsgegevens, moet die opdracht zodanig uitgelegd worden dat die opdracht ook een opdracht tot Verwerking omvat. Met dus een verwerkersrelatie en een verwerkersovereenkomst tot gevolg.

Mijn voorbeeld zou een incident response zijn, uitgevoerd door een extern CERT. Een incident heeft plaatsgevonden en het CERT krijgt opdracht te evalueren wat er mis is gegaan en of de beveiliging nog op orde is. Die opdracht is niet expliciet gericht op het Verwerken van persoonsgegevens. Maar voor de uitvoering van die opdracht is het onvermijdelijk dat het CERT de logbestanden analyseert, waarschijnlijk op hun eigen systemen. Zoals ik het advies van de EDPB interpreteer, moet onder de vertrekking van de opdracht aan het CERT ook de opdracht tot Verwerking worden verstaan. En dus een verwerkersovereenkomst met scopebeperking, geheimhouding en meldplicht. Als je redeneert vanuit de risico's van de opdrachtgever is dat ook logisch.

Het blijft dus zaak om scherp op de opdracht te letten en rekening te houden met de uitvoering daarvan. Als die opdracht niet uitgevoerd kan worden zonder Verwerking, is er sprake van verwerkerschap. Dat betekent niet dat iedere IT-opdracht leidt tot Verwerking en dus overal verwerkersovereenkomsten voor nodig zijn. Het verzorgen van updates kan m.i. zonder Verwerking. Het oplossen van een bug ook (expliciet het derde voorbeeld bij punt 83 in het advies). Het analyseren van een database van een klant om een systeemfout op te sporen zal echter een verwerkersovereenkomst vereisen. Maar dat was al zo, want met die data op uw systemen moest de toepassing, de geheimhouding en de meldingsplicht toch al geregeld worden.