Privacy Friendly

Opinie

De on-premise softwareleverancier: wel of geen verwerker?

17 maart 2019, 17:36

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


Na het schrijven van deze opinie heeft de EDPB in juli 2021 een tweede versie uitgegeven van haar advies over het verwerkerschap.
Daarin wordt in punt 83 een opmerkelijke uitspraak gedaan:

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.

Hugo Leisink
18 maart 2019, 09:09
Duidelijk verhaal. Echter, ik heb in de praktijk vaak genoeg gezien dat een consultant die zich alleen met de software bezig moet houden, ook vaak genoeg helpt met allerlei klusjes rondom de data. Dit gebeurt dan omdat hij 'zo handig is met de software en met computers'. Het lastige is dat dat soort kleine opdrachten niet van de klant in z'n geheel komen, maar van individuele medewerkers. Maakt het dan wel of niet een opdracht tot verwerking? En moet je daar dan een verwerkersovereenkomst voor hebben of is een geheimhoudingsverklaring dan nog steeds voldoende? Het lijkt me in ieder geval niet verkeerd om met dat soort mogelijke situaties in de toekomst rekening te houden.
Frans Dondorp
20 maart 2019, 11:00
@Hugo: dat zijn inderdaad de randgevallen die dit soort discussies zo lastig maken. Ik zou denken dat als de primaire taak van de consultant gericht is op het verwerken van data (bij conversies) de leverancier (voor die klus) verwerker wordt en er dus een opdracht, mandaat en VOK moet zijn. Als echter de consultant op locatie (en op een PC van de klant) een lijstje inleest en configuratie doet, krijgt hij niet zelf beschikking over de data en is er dus ook geen beschermingsplicht nodig. Wel ziet hij data en dus moet geheimhouding geregeld worden. En vanuit de beveiligingsplicht van de Verantwoordelijke is het zaak om hem te begeleiden en te controleren wat hij doet. Uiteraard.

Tricky. Correct me if I'm wrong.
Rob Haans
21 maart 2019, 12:32
Per punt zie ik toch wel situaties waar een leverancier wel degelijk een verwerker zou zijn:
1. Als ik support bestel voor een applicatie die uitkeringsgegevens verwerkt, dan geef ik wel degelijk ook de opdracht om gegevens te verwerken. Het raadplegen van gegevens is namelijk noodzakelijk om support te kunnen leveren. Het wordt wat anders bij een geo-applicatie waarin ik zelf bepaal welke data ik erin stop. Het support is dan veel meer technisch ingestoken en kan makkelijk buiten de data om gebeuren.
2. Het oplossen van een softwareprobleem kan in veel gevallen juist betrekking hebben op de verwerking van persoonsgegevens. Het hangt dus af van de aard van de software en niet of deze in de cloud staat of on-premise.
3. Juist bij on-premise software is support of consultancy iets wat in mandaat gedaan wordt, wat de organisatie ook zelf zou kunnen regelen/doen. Het is afhankelijk van het kennisniveau of ambitie van de organisatie of deze wel of niet support of consultancy afneemt. Bij een cloudleverancier valt bijv. technisch support onder de verantwoordelijkheid van de leverancier zelf.

Het gevaarlijke van deze redeneergang vind ik dat álle (ICT-)dienstverleners als niet-verwerkers te bestempelen zijn. Is een partij die uitkeringsprocessen (beoordelingen) ondersteunt een verwerker? Het beoordelen van uitkeringsaanvragen is niet letterlijk een gegevensverwerking, maar het is wel functioneel hetzelfde omdat het verwerken van gegevens noodzakelijk is om de dienst uit te voeren.
Frans Dondorp
22 maart 2019, 09:18
@Rob: dank voor jouw reactie. Mijn punt is dat een Verwerker een specifieke opdracht tot het Verwerken van gegevens moet hebben gekregen. Het feit dat je Persoonsgegevens kunt zien, maakt niet dat jij een Verwerker bent - of dat we jou een Verwerker moeten maken (door het geven van een opdracht tot verwerking). Er zijn wel meer derden die in contact kunnen komen met gegevens.

Zolang de gegevens niet 'in het bezit' van de leverancier komen, is er niet zoveel dat in een eventuele Verwerkersrelatie geregeld moet worden. De verantwoordelijkheid voor de technische en organisatorische beveiliging gaat niet over naar de leverancier. Het gaat eigenlijk alleen om geheimhouding. Bij cloud is dat geheel anders, omdat daar de opslag en beveiliging juist wel door de leverancier gebeurt. Mijn reactie zou dus zijn:

1. Ik kan niet beoordelen of het raadplegen van gegevens noodzakelijk is voor het bieden van support. Dat zal lang niet altijd het geval zijn. Zolang je geen gegevens onder beheer brengt van de leverancier (datasets uitwisselt) gaat het alleen om raadplegen - en dat kun je veel makkelijker afdekken met geheimhouding.
2. Ik zou geen voorbeeld kunnen bedenken van een softwareprobleem dat alleen opgelost kan worden door te beschikken over persoonsgegevens van echte personen. Dat zou ook betekenen dat de leverancier moet beschikken over productiedata om te kunnen testen. Als dat echt zo voorkomt, dan zie ik ook een Verwerkersrelatie. Ik ben wel benieuwd naar zo'n voorbeeld.
3. Het gaat dan om een opdracht en een mandaat specifiek voor het verwerken van persoonsgegevens. Dat zie ik niet zo snel.

Een Verwerker is pas een Verwerker als jij hem Verwerker maakt. Ik zeg niet dat alle (ICT-)dienstverleners niet-verwerkers zijn, want het komt natuurlijk voor dat (ICT-)dienstverleners juist wel in opdracht persoonsgegevens verwerken. Ik bedoelde mijn punt de andere kant op: het is niet zo dat een ICT-dienstverlener die on-premise software levert tot Verwerker gemaakt moet worden enkel vanwege het bieden van support of consultancy. Zelfs als daar specifieke uitzonderingen voor te bedenken zijn, moeten we de regel en de uitzondering niet vermengen. Dat zou heel veel schelen in het aangaan van onnodige verwerkersovereenkomsten, discussies en audits.
Rob Haans
22 maart 2019, 13:39
We zien dat veel on-premise leveranciers geen verwerkersovereenkomst meer wíllen sluiten, ook al wil een verantwoordelijke opdrachtgever dat soms wel. Dan is de uitweg die door het bovenstaande verhaal geboden wordt lastig, ook al is een juist.

Om een onduidelijkheid uit de weg te helpen, wat is een verwerkersovereenkomst meer dan met vastleggen van afspraken met een derde die verwerkingen verricht? Ook in de gevallen die jij bespreekt wil je afspraken maken over:
- de wijze van inbellen of inloggen in de applicatie
- wel of geen aanwezigheid van eigen personeel
- geheimhouding

Wat is er mis om deze afspraken vast te leggen en het een verwerkersovereenkomst te noemen?

Een groot probleem is dat er veel onnodige verwerkingen plaatsvinden: testomgevingen werken vaak niet zonder echte persoonsgegevens. Veel on-premise software is gewoon niet opgezet met Privacy by design in het achterhoofd. Dat moeten we oplossen in plaats van verschuilen achter ruimtes in de wet..
Frans Dondorp
26 maart 2019, 09:58
@Rob: Met jouw conclusie ben ik het helemaal eens. Mijn bedoeling is echter alles behalve het "schuilen achter ruimtes in de wet". Een verwerkersovereenkomst moet voldoen aan de eisen die art. 28 lid 3 daaraan stelt, waaronder regelingen over beveiliging en audits. Een setje afspraken is dus niet hetzelfde als een verwerkersovereenkomst.

Aan de kant van de leveranciers zie je nu dat er teveel onnodige verwerkersovereenkomsten gesloten worden, waarin opdrachtgevers allerlei uiteenlopende eisen stellen, zowel procedureel als technisch. Dat levert onnodig complex contractbeheer op. In die verwerkersovereenkomsten wordt dan veel geeist (met name in de sfeer van beveiligingsmaatregelen, auditplichten en boetes) wat voor de on-premise situatie lang niet altijd relevant is en wat alleen maar tot verwarring leidt. Doordat iedere opdrachtgever een eigen "model" of "standaard" hanteert, heeft de leverancier weinig onderhandelingsruimte. Wonderlijk is ook dat in die verwerkersovereenkomsten technische eisen aan de software kunnen worden gesteld die nog niet golden toen de software werd gekocht.
Het is maar zeer de vraag of de leverancier die bedolven wordt onder verwerkersovereenkomsten nog weet welke plichten hij tegenover een specifieke klant heeft.

Mijn betoog is dus juist dat door beter te beoordelen of een leverancier ook echt een Verwerker is we makkelijkere en duidelijkere afspraken kunnen maken in eenvoudige geheimhoudingsverklaringen een (inderdaad) eenvoudige DAP's. En dus juridisering en contractuele luchtkastelen voorkomen.