Opinie

De on-premise softwareleverancier: specifieke situaties

12 april 2019, 22:56

In een vorige opinie schreef ik dat de on-premise softwareleverancier niet een Verwerker wordt als er situaties zijn waarin hij in contact komt met data van de klant. Waardoor je in veel situaties kunt volstaan met geheimhoudingsverklaring en geen verwerkersovereenkomst hoeft te regelen. Uit de reacties die ik heb gekregen kwam het verzoek om een paar concrete situaties uit te werken. Bij deze.

Warning: long read. Ik verzamel in deze post de situaties waarover ik in gesprek ben geraakt. Dit is dus een verzameldossier.

Nog even de argumenten

Je bent pas een Verwerker als de Verantwoordelijke jou Verwerker maakt. Er moet een opdracht zijn die specifiek gericht is op het Verwerken van Persoonsgegevens voor de Verantwoordelijke. Die Verwerking moet plaatsvinden ten behoeve van de Verwerkingsverantwoordelijke. Op basis van de Handleiding AVG en opinie 169 van de EDPB worden die begrippen uitgelegd tot:

Verantwoordelijke heeft opdracht gegeven specifiek voor het verwerken van persoonsgegevens.
De Verwerking vindt plaats binnen die opdracht, binnen het mandaat dat de Verwerker heeft.
De Verwerking is de 'primaire opdracht', niet een bijproduct van een grotere opdracht. Dit volgt eigenlijk uit 1, maar 'verwerking als hoofdopdracht' is een makkelijke one-liner en het benadrukken waard.

Aan de andere kant geldt dan ook:

Als de Verwerking niet voortvloeit uit een specifieke opdracht tot Verwerking, maar als bijzaak ontstaat uit een algemenere opdracht ben je zelf de Verantwoordelijke.
Alles dat je buiten mandaat doet (Verwerkingen dus die buiten de opdracht vallen) zijn Verwerkingen waar je zelf Verantwoordelijke voor bent. Denk aan systeemlogs.

De relevante passage uit de Handleiding AVG is (mijn onderstreping):

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.

Met deze argumenten kunnen we specifieke situaties, of eigenlijk specifieke diensten van de leverancier, beoordelen. Om te zorgen dat je ieder punt apart kunt lezen zit er wat herhaling in.

Supportmedewerker krijgt screenshot

Geen Verwerker. Het screenshot kan natuurlijk Persoonsgegevens bevatten en de medewerker ziet die. Die raadpleging is inderdaad een Verwerking onder de AVG. Maar er is geen specifieke opdracht voor het Verwerken van Persoonsgegevens; dat is niet de primaire opdracht van de supportmedewerker. Argumenten 1, 2 en 3 falen.

Conform de Handleiding AVG is de leverancier hier Verwerkingsverantwoordelijke, omdat de Verwerking als bijzaak ontstaat uit een andere opdracht (namelijk het leveren van support). Het gaat dan dus kennelijk om een derdeverstrekking: het verstrekken van Persoonsgegevens van de klant (Verantwoordelijke) naar de leverancier (andere Verantwoordelijke). Conform AVG lid 6 moet daar een grondslag voor zijn.

Dan hoor ik vaak "6b", oftewel "uitvoering overeenkomst". Die vlieger gaat niet op, omdat de grondslag voor 6b de uitvoering van een overeenkomst is waarbij betrokkene partij is. In het geval van een on-premise leverancier is er natuurlijk een overeenkomst tussen leverancier en de klant voor het leveren van support, maar bij die overeenkomst is de betrokkene (de klant van de klant) geen partij.

Dan roep je wellicht "gerechtvaardigd belang" van de Verantwoordelijke en dus art. 6f. We hebben het nog over de verstrekking aan de leverancier en voor die Verwerking is de klant de Verantwoordelijke. Die moet dus verdedigen dat het verstrekken van het screenshot "noodzakelijk" is. Daar kun je over twisten: ik denk dat in de meeste gevallen dat screenshot helemaal niet noodzakelijk is.

Ik zie twee punten van aandacht:

Het verstrekken van Persoonsgegevens (van betrokkenen die geen partij zijn bij een overeenkomst) via een screenshot in het kader van support lijkt mij onrechtmatig. Leg eerst maar eens uit dat het verstrekken van het screenshot "noodzakelijk" is vanuit de klant - die een verwerkingsgrond moet hebben om die data aan de leverancier te geven. Verdedig even "6f".
De leverancier moet zelf ook een grond hebben om die gegevens in het screenshot te verwerken nu hij die eenmaal heeft. Let wel: de leverancier is voor het verwerken van het supportticket en het screenshot zelf de Verantwoordelijke. Ik zie niet welke grond er voor die Verwerking zou moeten zijn en ik zou dus geneigd zijn die gegevens direct te vernietigen.

Puntje voor de SLA: screenshots met Persoonsgegevens worden bij ontvangst vernietigd. Wees in ieder geval gealarmeerd als je bij tickets standaard om een screenshot vraagt.

Het wordt nog erger bij outsourcing: als het screenshot naar een developer gaat buiten de EEG. Dan worden Persoonsgegevens buiten de EEG gebracht. Dan zitten we in de sfeer van de doorgifte uit hoofdstuk 5 AVG: alleen naar landen met een adequaatheidsbesluit, Binding Corporate Rules, model clauses, die hoek. Te gedetailleerd voor hier: de samenvatting is "niet doen", tenzij je dit kunt verantwoorden onder hoofdstuk 5.

In het (uitzonderlijke?) geval dat Persoonsgegevens noodzakelijk zijn voor het oplossen van het probleem kun je beter op locatie gaan of inbellen. Dan is natuurlijk nog steeds de opdracht hetzelfde, maar dan hebben we geen discussie meer over Persoonsgegevens die (onnodig) onder jouw beheer zijn gekomen. In het slechtste geval heb je dan gegevens gezien en hang je aan geheimhouding. Als professionele leverancier had je daar toch al voor getekend.

Supportmedewerker belt in

Geen Verwerker. Natuurlijk kan de medewerker Persoonsgegevens zien en dat is een Verwerking onder de AVG. Maar er is geen specifieke opdracht voor het verwerken van Persoonsgegevens; het verwerken van Persoonsgegevens is niet de primaire opdracht van de supportmedewerker. Argumenten 1, 2 en 3 falen.

Conform de Handleiding AVG is de leverancier hier Verwerkingsverantwoordelijke, omdat de Verwerking als bijzaak ontstaat uit een andere opdracht (namelijk het leveren van support). Naar mijn idee is het relevant dat de medewerker de gegevens alleen ziet - en nooit het 'houderschap' van die gegevens krijgt (waardoor we het niet over beveiliging hoeven te hebben en de leverancier die gegevens niet kan doorsturen of lekken). De medewerker doet hier hetzelfde of vergelijkbaar werk als de consultant op locatie (zie hieronder). Natuurlijk ziet de medewerker Persoonsgegevens, maar hij kopieert ze niet en slaat ze niet op. Het enige risico is dan dat de medewerker die gegevens niet geheim houdt. Daar is de geheimhoudingsverklaring voor.

Voor de fijnslijpers: als de medewerker de sessie opneemt of screenshots maakt, zijn we bij de vorige discussie aanbeland. Of als hij de gegevens opschrijft. De medewerker mag dat niet doen omdat hij zijn geheimhouding dan schendt, de leverancier mag die data niet opslaan omdat hij er geen grond voor heeft en de klant (als die meewerkte) mag niet meewerken aan de opname omdat hij geen grond voor derdeverstrekking heeft. Dan ga ik er inderdaad van uit dat de klant als Verantwoordelijke zich voor het verstrekken van een screenshot/opname niet kan beroepen op "gerechtvaardigd belang".

Denk ook even aan support vanuit het buitenland. Een supportmedewerker die remote vanuit India werkt bevindt zich buiten de EEG en dan worden Persoonsgegevens (via raadpleging) buiten de EEG gebracht. Dan zitten we in de sfeer van de doorgifte uit hoofdstuk 5 AVG: alleen naar landen met een adequaatheidsbesluit, Binding Corporate Rules, model clauses, die hoek. Te gedetailleerd voor hier: de samenvatting is "niet doen", tenzij je dit kunt verantwoorden onder hoofdstuk 5.

Consultant verzorgt training

Voor het verzorgen van trainingen aan eindgebruikers wordt vanzelfsprekend een realistische omgeving gebruikt. Als een separate trainingsomgeving niet beschikbaar is, komt het voor dat de productieomgeving wordt gebruikt. Ik zie daar weinig verschil met de situatie waarin een consultant op locatie werkt en een gebruiker uitlegt hoe het systeem werkt. Of hij dat persoonlijk doet of in klassikaal verband maakt voor de Verwerkingen naar mijn idee niet uit.

Geen Verwerker. Natuurlijk kan de consultant Persoonsgegevens zien en dat is een Verwerking onder de AVG. Maar er is geen specifieke opdracht voor het verwerken van Persoonsgegevens; het verwerken van Persoonsgegevens is niet de primaire opdracht van de consultant. Argumenten 1, 2 en 3 falen.

Conform de Handleiding AVG is de leverancier hier Verwerkingsverantwoordelijke, omdat de Verwerking als bijzaak ontstaat uit een andere opdracht (namelijk het leveren van consultancy of het afronden van een implementatietraject). Naar mijn idee is het relevant dat de consultant de gegevens alleen ziet - en nooit de gegevens onder zich houdt. Natuurlijk ziet de consultant Persoonsgegevens, maar hij kopieert ze niet en slaat ze niet op. Het enige risico is dan dat de consultant die gegevens niet geheim houdt. Daar is de geheimhoudingsverklaring voor.

Consultant werkt op locatie

Geen Verwerker, tenzij. Natuurlijk kan de consultant Persoonsgegevens zien en dat is een Verwerking onder de AVG. Maar er is geen specifieke opdracht voor het verwerken van Persoonsgegevens; het verwerken van Persoonsgegevens is niet de primaire opdracht van de consultant. Argumenten 1, 2 en 3 falen.

Conform de Handleiding AVG is de leverancier hier Verwerkingsverantwoordelijke, omdat de Verwerking als bijzaak ontstaat uit een andere opdracht (namelijk het leveren van consultancy). Naar mijn idee is het relevant dat de consultant de gegevens alleen ziet - en nooit het bezit of beheer van die gegevens krijgt. Natuurlijk ziet de consultant Persoonsgegevens, maar hij kopieert ze niet en slaat ze niet op. Het enige risico is dan dat de consultant die gegevens niet geheim houdt. Daar is de geheimhoudingsverklaring voor.

De 'tenzij' is gericht op het Verwerken van een aangeleverde dataset. Als de consultant ter plaatse de opdracht krijgt "lees deze dataset even in" en hij houdt/beheert op zijn eigen laptop die dataset, dan zitten we bij "Consultant leest dataset in" - zie hieronder.

Consultant leest dataset in

Deze is lastig. De vraag is nu of de consultant een opdracht krijgt die specifiek gericht is op het Verwerken van een dataset en ook die dataset onder zijn beheer krijgt. In de meeste gevallen zal het gaan om een lijstje van gebruikers of een export uit een vorig pakket. Voor onze discussie is de essentie wat de opdracht is.

Als er geen specifieke opdracht is voor het Verwerken van een dataset, volgt de Verwerking kennelijk (als bijzaak) uit een andere opdracht (zoals support of applicatiebeheer) en is de situatie gelijk aan het verzorgen van consultancy op locatie - zie in dat geval het vorige punt.

Als er wel een specifieke opdracht is voor het Verwerken van een dataset, is er sprake van een verwerkingsopdracht. Net zoals bij het verzorgen van een conversie: zie het volgende punt.

Consultant voert conversie/migratie uit

Wel Verwerker. Er is een specifieke opdracht (namelijk de opdracht voor conversie/migratie) met betrekking tot Verwerking van Persoonsgegevens. De leverancier Verwerkt die gegevens ten behoeve van de Verantwoordelijke. Er is geen sprake van een derdeverstrekking: de leverancier Verwerkt niet voor zichzelf.

Voor deze situatie zou dus wel een verwerkersovereenkomst gesloten moeten worden. De data (van Verantwoordelijke) komt immers in beheer van de leverancier en het is dus zaak dat hij die goed beschermt. Dat het om een kleine klus gaat doet niet terzake: de EDPB zegt immers dat This processing activity may be limited to a very specific task in de bekende opinie 169.

Ook hier weer even opletten bij outsourcing: als de conversie in het buitenland wordt uitgevoerd. Als Persoonsgegevens buiten de EEG worden gebracht, zitten we in de sfeer van de doorgifte uit hoofdstuk 5 AVG: alleen naar landen met een adequaatheidsbesluit, Binding Corporate Rules, model clauses, die hoek. Te gedetailleerd voor hier: de samenvatting is "niet doen", tenzij je dit kunt verantwoorden onder hoofdstuk 5.

Consultant voert applicatiebeheer uit (al dan niet remote)

Zoals telkens gaat het om de inhoud van de opdracht. Ik ga er nu van uit dat de opdracht voor het bieden van applicatiebeheer (of het ondersteunen van de applicatiebeheerder) niet specifiek is gericht op het Verwerken van Persoonsgegevens. De consultant heeft dus niet de opdracht om persoonsgegevens bij te werken in het systeem, maar om bijvoorbeeld configuratie aan te passen.

Conform de Handleiding AVG is de leverancier hier Verwerkingsverantwoordelijke, omdat de Verwerking als bijzaak ontstaat uit een andere opdracht (namelijk het ondersteunen bij applicatiebeheer of het inrichten van het systeem tijdens het implementatietraject). Voor de consultant is het relevant of hij alleen gegevens inziet, of ook een dataset onder zijn beheer krijgt. In het eerste geval moeten we alleen geheimhouding regelen. In het tweede geval moeten we ook regelen dat de gegevens adequaat worden beschermd door de consultant en worden verwijderd na verwerking. Nogmaals: het lijkt alsof die consultant een Verwerker is, maar dat is afhankelijk van de opdracht - het kan ook een derdeverstrekking zijn aan de leverancier als zelfstandige Verantwoordelijke. Denk dus niet te snel "verwerkingsovereenkomst". Denk wel minimaal "geheimhoudingsovereenkomst".

Of de consultant op locatie werkt of remote, is naar mijn idee alleen relevant als de medewerker niet binnen de EEG werkt. Een consultant die remote vanuit India werkt bevindt zich buiten de EEG en (door het tonen op het scherm t.b.v. raadpleging) worden Persoonsgegevens dan buiten de EEG gebracht. Dan zitten we in de sfeer van de doorgifte uit hoofdstuk 5 AVG: alleen naar landen met een adequaatheidsbesluit, Binding Corporate Rules, model clauses, die hoek. Te gedetailleerd voor hier: de samenvatting is "niet doen", tenzij je dit kunt verantwoorden onder hoofdstuk 5.

Testen met productiedata

Ten eerste: hier zijn we natuurlijk tegen. De theorie is dat dit niet nodig is, maar we merken in de praktijk dat dit niet altijd te voorkomen is. Vooral in ketentests is in de praktijk niet altijd een volledige parallelle teststraat beschikbaar is en zijn sommige componenten in die keten productieomgevingen.

In het geval de leverancier/consultant een dataset krijgt om mee te testen zitten we in dezelfde hoek als "Consultant voert conversie/migratie uit". De vraag is dan of de leverancier een specifieke opdracht heeft om te testen met productiedata namens de Verantwoordelijke. Dan is hij dus Verwerker en is er een verwerkersovereenkomst voor de specifieke test-opdracht. Vergeet dan niet de volgende partner in de keten die de dataset verkrijgt als de ketentest slaagt.

Als niet expliciet is geregeld dat de leverancier Verwerker is voor het testen, is er een kans (namelijk afhankelijk van de opdracht) dat hij buiten zijn mandaat komt en dus Verantwoordelijke is. In dat geval moet de leverancier zelf een verwerkingsgrond hebben onder art. 6 en die zie ik niet. Vanuit de klant gezien hebben we het dan over een verstrekking aan de leverancier waar de klant onder artikel 6 ook een grond voor moet hebben. Ook die grond zie ik niet: roep "6f" en struikel over "noodzakelijk".

Bij een test met (echte) Persoonsgegevens zonder verwerkingsopdracht gaat de klant dus de mist in door het verstrekken van de data en de leverancier door het testen daarmee. De leverancier wordt niet gered door "6b": hij kan de test niet verdedigen op de verwerkingsgrond "overeenkomst" omdat de betrokkene geen partij bij die overeenkomst is.

Als je wilt testen met productiedata en dit wilt oplossen via de Verwerkers-route moet er een opdracht zijn voor het testen met productiedata. Die opdracht is slecht te rijmen met de verplichting "privacy by design" (art. 25) die op Verantwoordelijke rust. Dat concept geldt niet alleen voor producten, maar ook voor processen en dus ook op het testproces. Daarom is het zoeken naar een rechtvaardiging en is de Verwerkers-constructie "shaky at best". Het is grijs gebied en daarom hoor je hier als leverancier tegen te zijn. Ik zou dus adviseren om het niet te doen. Als het moet, zorg dan tenminste voor de technische en organisatorische waarborgen en wees voorbereid over een discussie waarom dit "noodzakelijk" is.

We zitten al op "niet doen". Het wordt nog lastiger als het plan is om te testen met productiedata buiten de EEG. Als Persoonsgegevens buiten de EEG worden gebracht, zitten we in de sfeer van de doorgifte uit hoofdstuk 5 AVG: alleen naar landen met een adequaatheidsbesluit, Binding Corporate Rules, model clauses, die hoek. Te gedetailleerd voor hier: de samenvatting is "niet doen", tenzij je dit kunt verantwoorden onder hoofdstuk 5. Het testen met productiedata en dat dan ook nog outsourcen buiten de EEG is dus "vlek op vlek".

Opmerkingen?

Er zijn veel leveranciers die hier duidelijkheid over willen hebben en we hebben allemaal baat bij de beantwoording van onze vragen. Als ik dus een argument mis, er domweg naast zit of een situatie mis lees ik dat graag in de reacties. Desnoods onder pseudoniem.