Ben ik verwerker bij de accounts van mijn klanten?

| AE 12634 | Privacy | 7 reacties

Een lezer vroeg me:

Zoals heel veel SaaS-diensten bied ik accounts aan voor bedrijfsmatig gebruik: één account per gebruiker, maar gekoppeld via een bedrijfsabonnement. Ben ik nu verwerker voor de gegevens in die accounts?
Het valt me inderdaad op dat vele SaaS-dienstverleners denken dat ze verwerker zijn omdat ze persoonsgebonden accounts hebben. Dat is alleen te kort door de bocht. Mogelijk komt dit door een spraakverwarring: je verwerkt dan wel persoonsgegevens, maar je bent pas verwerker als je dat doet in opdracht van een ander (de verwerkingsverantwoordelijke).

Wanneer ik een dienst afneem, en daarbij zijn mijn persoonsgegevens nodig (bijvoorbeeld voor een account + facturatie, of voor het tonen van mij als gebruiker aan andere gebruikers) dan is de dienstverlener gewoon de verwerkingsverantwoordelijke. Hij bepaalt immers wat er gebeurt met die gegevens van mij: waar worden ze getoond, wie heeft er toegang toe en waar mogen ze worden ingezet.

Ik zou die dienst namens mijn bedrijf kunnen afnemen. Dan kunnen ook collega’s een account krijgen binnen het bedrijfsaccount, en normaliter betaal ik dan maar één keer. Dit verandert alleen nog niets aan de situatie voor verwerkerschap: de dienstverlener bepaalt nog steeds wat er gebeurt met al die persoonsgegevens, van zowel mij als van mijn collega’s. Hij blijft dan dus verwerkingsverantwoordelijke.

Een dienstverlener wordt verwerker wanneer het verwerken van de persoonsgegevens onderdeel is van de dienst, want het juridisch criterium is dat ik als klant doel en middelen vaststel. Het triviale voorbeeld is een personeelsadministratie: ik upload dan een set personeelsgegevens met bijvoorbeeld loongegevens, en de SaaS-dienst genereert loonstroken. Voor die set is men dan verwerker, want ik bepaal wat ik upload (welke personeelsleden, welke gegevens) en waarom (ik wil loonstroken).

De accounts om toegang te krijgen tot de dienst zijn volgens mij geen onderdeel van de dienst, zodat daarvoor geen verwerkersovereenkomst met de klanten nodig is. Zolang de leverancier/dienstverlener zelf bepaalt wat hij doet met die accounts, is hij daar zelf verwerkingsverantwoordelijke voor.

Arnoud

RDC mag miljoenen Nederlandse autobezitters niet over datalek informeren

| AE 12584 | Privacy | 15 reacties

Ict-bedrijf RDC, waar de gegevens van miljoenen Nederlandse autobezitters werden gestolen, mag getroffen personen naar eigen zeggen niet over het datalek informeren. Dat meldde Security.nl onlangs. Het zou gaan om herleidbare gegevens van mogelijk 7,3 miljoen personen (afhankelijk van hoe veel dubbels er in de data zitten). Behalve om NAW-gegevens gaat het ook om e-mailadressen, kentekens, telefoonnummers en geboortedata, ideaal voor gerichte phishing natuurlijk. Maar RDC mag niets zeggen, omdat ze verwerker is.

Onduidelijk is hoe de datadiefstal kon gebeuren. De NOS (hoi Joost) ontdekte dat de data te koop stond, maar de RDC had vooralsnog geen verklaring over het hoe en wat. Wel heeft men direct een melding bij de Autoriteit Persoonsgegevens gedaan, en de autohandelaren voor wie zij werken ingelicht.

De RDC biedt het product AutoMotive Dashboard (AMD) aan. Dit “biedt u een geïntegreerd platform met databases en functionaliteit voor het analyseren van statistische automotive marktinformatie.” Hiervoor krijgt men data van de RDW, zoals informatie over de vervaldatum van apk-keuringen en grove informatie over de eigenaren van auto’s, zoals de cijfers van de postcode en geboortejaar.

En nee, dat is niet hetzelfde als NAW-gegevens, e-mailadressen, telefoonnummers, geboortedata et cetera. Kennelijk levert de RDW ruwe data aan RDC, die dan gaat anonimiseren? Dat lijkt me risicovol en onnodig, maar een andere verklaring heb ik niet.

In ieder geval, als RDC verwerker is van deze persoonsgegevens dan mag zij niet zelf een datalek melden bij de betrokkenen. De AVG legt die plicht nadrukkelijk bij de verwerkingsverantwoordelijke, hier dus de Rijksdienst voor het wegverkeer. RDC moet het datalek doorgeven aan die verantwoordelijke, daarna moet die beslissen of het datalek meldingsplichtig is. Dat is hier natuurlijk een gegeven, maar het is wel de RDW haar beslissing.

Het doet wel raar aan, want als het lek bij RDC zit dan kunnen die het beste aangeven wat er is gebeurd en wat er is gelekt. Maar omdat je als betrokkene uiteindelijk niets te maken hebt met uitbesteedpartijen en zorgvuldig geselecteerde partners, klopt het juridisch wel. De RDW meldt het aan jou, en als je dan claims hebt dan dien je die bij de RDW in. Die lost het intern maar op met RDC.

Arnoud

Onderzoek legt privacyrisico’s bij Google-diensten in het onderwijs bloot

| AE 12542 | Ondernemingsvrijheid | 20 reacties

Het gebruik van Google Workspace in het onderwijs brengt vermijdbare privacyrisico’s voor leerlingen en studenten met zich mee. Dat meldde Nu.nl onlangs, op basis van onderzoek van de Hogeschool van Amsterdam (HvA) en Rijksuniversiteit Groningen (RUG) en een bijbehorende Kamerbrief hierover. De kern is dat wanneer je deze dienst afneemt, Google zelfstandig beslist wat zij met metadata doet – en daarmee dus geen volwaardige verwerker is. Ook zit je natuurlijk met het punt van Amerikaanse verwerking. Wat betekent dit nu voor de praktijk?

In de Kamerbrief staat de kern van de materie als volgt omschreven:
Google heeft als standpunt dat zij zichzelf als enige verwerkingsverantwoordelijke ziet voor metadata. Dit betekent dat zij mag bepalen voor welk doel zij metadata verzamelen en op welke manier dat gebeurt. Ook heeft Google in de privacyovereenkomsten opgenomen dat zij de voorwaarden rondom metadata eenzijdig mag aanpassen, zonder de gebruiker om toestemming te vragen.
De term metadata verwijst naar data over de echte data, in dit geval data over studiegedrag en gebruiksgedrag van de dienst. Dat is vaak waardevoller dan die echte data. Het zal Google een zorg zijn wat er op de slides staat, maar weten dat studenten gemiddeld tussen 20.53 en 02.20 inloggen om studiemateriaal te consumeren, dát is waardevol. En dan kan ze nog zo mooi zeggen dat “we nooit klantgegevens of servicegegevens (zoals gebruikersactiviteit) gebruiken voor advertentie-targeting”, die gegevens gaan ergens het zwarte gat in dat je Googleprofiel heet. En dat mag niet.

Het probleem is natuurlijk dat dat niet hoort; als je een verwerker bent dan ga je geen eigen dingen met data doen, ook niet met afgeleide data of metadata die je krijgt bij zo’n dienst. Maar het is ook weer heel logisch dat Google dat doet.

De vraag is nu bij de AP neergelegd hoe verder. Normaal zou je na het constateren van zo’n hoog risico in je DPIA een voorafgaand advies vragen (en wachten tot dat er is) maar dat kan niet omdat het onderwijs al op grote schaal draait op Google. De pragmatische oplossing is dus doorgaan tot er duidelijkheid is.

Nadeel hiervan is wel dat er een reële kans is dat de AP zegt dat dit niet kan, en dat onderwijsinstellingen weg moeten bij deze dienstverlener. Alsof de ICT’ers hier nog niet genoeg aan hun hoofd hebben, meelezende onderwijs-ICT-mensen u heeft mijn sympathie.

Arnoud

Moet je als hostingbedrijf AVG-verzoeken voor klanten honoreren?

| AE 11648 | Ondernemingsvrijheid, Privacy | 25 reacties

Een lezer vroeg me: Als hostingbedrijf krijgen wij steeds vaker klachten dat een website van een klant ten onrechte persoonsgegevens publiceert of anderszins de AVG overtreedt, bijvoorbeeld door verwijderingsverzoeken te negeren. Zijn wij verplicht hier gehoor aan te geven en zo ja welk niveau van inhoudelijke check moeten wij dan doen? Sinds de AVG zijn… Lees verder

Heb je als verwerker zelf ook een grondslag nodig?

| AE 11358 | Privacy | 2 reacties

Een lezer vreoeg me: Een verwerker hoeft geen eigen grondslag te hebben, die werkt onder de grondslag van de verwerkingsverantwoordelijke. Het is ook niet logisch want de grondslagen zouden dan altijd samenvallen; artikel 6 AVG zegt immers “De verwerking is alleen rechtmatig indien en voor zover aan ten minste een van de onderstaande voorwaarden is… Lees verder

Wat moet je doen met een ICT-beheerder die per abuis persoonsgegevens krijgt?

| AE 11200 | Privacy | 4 reacties

Een lezer vroeg me: In 2018 schreef je over verwerkerschap bij een derde partij zoals een ICT-beheerder. Je zei dat je geen verwerkersovereenkomst hoeft te sluiten met zo’n partij wanneer deze partij expliciet geen toegang wil hebben tot persoonsgegevens. Wat zou die partij dan wel mogen (of moeten) doen als hij toch persoonsgegevens krijgt? Iedere… Lees verder

Hoe moeten wij omgaan als ICT-bedrijf met AVG-schendende opdrachten van klanten?

| AE 10913 | Ondernemingsvrijheid, Privacy | 5 reacties

Een lezer vroeg me: Wij staan als ICT leverancier vaak tussen de werkgever (onze klant) en hun werknemers in. Als bijvoorbeeld een werkgever toegang tot meerdere inboxen wil van werknemers, dan doen wij dit niet zomaar. We krijgen dan een beetje een adviserende rol. Maar tot hoever gaan we? Is het genoeg om een klant… Lees verder

Wanneer moet je nou met iemand een verwerkersovereenkomst sluiten?

| AE 10538 | Privacy | 35 reacties

Het begint dagelijkse kost te worden voor veel organisaties: of je even een verwerkersovereenkomst wilt tekenen, want de AVG komt eraan en die eist grote zorgvuldigheid en compliance et cetera. Wat me daarbij opvalt, is dat die overeenkomsten opgedrongen worden aan allerlei partijen die überhaupt geen verwerkers zijn. Dat geeft hoogst merkwaardige spraakverwarring. Maar het… Lees verder