Tag: verwerker

About verwerker

Subscribe Feeds

Ben ik verwerker bij de accounts van mijn klanten?

Geplaatst op in 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

Geplaatst op in 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

Geplaatst op in 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?

Geplaatst op in 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 steeds meer mensen zich bewust van hun rechten omtrent persoonsgegevens. Je ziet dan ook vaker en vaker dat men op websites vergeetverzoeken, correctieaanvragen en dergelijke doet. Een site-beheerder moet daaraan meewerken, maar helaas gebeurt dat niet altijd.

We kennen deze problematiek van andere juridische domeinen, zoals het auteursrecht. Je gaat dan hogerop in de keten, en je spreekt de hoster aan. Volgens de gewone regels voor aansprakelijkheid (art. 6:196c BW) moet een hoster ingrijpen als een klant evident (onmiskenbaar) onrechtmatig handelt. De site of publicatie weghalen bijvoorbeeld, of de klant dwingen een correctie door te voeren.

Bij auteursrechtinbreuk is dat relatief simpel: weg die film, weg die muziek. Of er komt discussie, van wie is die foto eigenlijk, en dan is de overtreding niet meer evident. Daar kom je nog wel uit.

Bij privacykwesties is dit een stuk lastiger. Is dit vergeetverzoek terecht of is de informatie nog actueel? Is er toestemming gegeven (en/of niet ingetrokken) of is het beroep op een legitiem belang hier juist? Is dit hergebruik binnen de doelbinding? Daar kom je gewoon niet uit als hostingbedrijf.

Een complicatie is dat veel hosters zich opstellen als verwerkers, oftewel partijen die de informatie uitsluitend in opdracht van de klant online zetten. Dan mógen ze niet eens zelf besluiten om in te grijpen, ook al is de overtreding nog zo evident. Onder de AVG moet een verwerker verzoeken van betrokkenen doorspelen naar de verantwoordelijke (de klant dus) en die het laten afhandelen.

Wel is het zo dat een verwerker verplicht is verwerking te staken als deze evident in strijd is met de AVG. Hij moet dan in discussie met de verantwoordelijke over hoe verder. Effectief komt dat volgens mij op hetzelfde neer: je zegt dan alsnog tegen de klant, volgens mij gaat hier iets mis met deze persoonsgegevens op je site, hoe ga je dat oplossen of haal ik de site/pagina offline? De route is anders maar het resultaat volgens mij gelijk.

Heb je als verwerker zelf ook een grondslag nodig?

Geplaatst op in 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 voldaan”. Als de vv zich kan beroepen op bijvoorbeeld toestemming, dan is het niet nodig dat de vw nog een andere grondslag aandraagt.

De grondslag uitvoering overeenkomst vereist dat de betrokkene daarbij partij is (zie tekst artikel 6 lid 1 sub b AVG), of in ieder geval vermoedelijk gaat worden (de precontractuele fase). Bij de verwerkersovereenkomst is de betrokkene geen partij dus die kan geen deel uitmaken van de overeenkomst.

Debiteurenbeheer in opdracht van een dienstverlener valt m.i. onder uitvoering overeenkomst, incasso hoort vrij evident bij het nakomen van een contract lijkt me zo. Toestemming van de betrokkene is niet aan de orde. Uw klant heeft een dienstovereenkomst (of bij producten een verkoopovereenkomst). U als verwerker neemt de taak van de incasso op u, en u doet dat onder de grondslag van de uitvoering van die overeenkomst.

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

Geplaatst op in 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 handeling daarmee is een verwerking, dus moet er dan toch alsnog gauw een verwerkersovereenkomst komen?

Het klopt dat je aan het verwerken bent als je persoonsgegevens langs ziet komen. Zelfs de enkele handeling van het wissen daarvan, is naar de letter van de AVG een verwerking. Maar persoonsgegevens verwerken wil niet zeggen dat je een verwerker bent.

Een verwerker ben je als je in opdracht persoonsgegevens verwerkt waar de opdrachtgever verwerkingsverantwoordelijke voor is. Die ander bepaalt het doel (dit moet je doen) en kiest de middelen (of tekent daarvoor af). Dat is de wettelijke definitie. Mijn salarisadministrateur is dus een verwerker, en mijn cloud-mailprovider is dat ook. Beiden doen wat ik zeggen dat ze moeten doen met de persoonsgegevens van mijn personeel en klanten.

Wie data tegenkomt buiten een opdracht, is dan ook per definitie geen verwerker. Volgens de AVG ben je dan zelf verwerkingsverantwoordelijke, oftewel je bepaalt zelf wat je er mee mag en moet. En dat is in dit geval heel simpel: je hebt geen grondslag om die gegevens te mogen hebben, dus moet je ze vernietigen. (De grondslag voor die vernietiging is dan ook de wettelijke plicht, artikel 6 sub c AVG.)

Ik twijfel nog of je als beheerder in zo’n situatie van een voor jou meldingsplichtig datalek moet spreken. Jij hebt immers geen geschonden beveiliging, zodat jij geen datalek hebt veroorzaakt. Maar je had wel data onder je op een plek waar die niet hoorde te zijn. Het meest logisch lijkt me echter dat je onmiddellijk de ‘echte’ verantwoordelijke in kennis stelt, waarna die wettelijk verplicht het lek zal moeten melden.

Arnoud

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

Geplaatst op in 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 schriftelijk te adviseren eerst toestemming te vragen of een acceptable use policy op te stellen?

De beste manier om hiermee om te gaan, is voor jezelf duidelijke regels te maken: hoe willen jullie werken, waar voel je je nog prettig bij en wanneer wordt het echt onacceptabel voor jullie als dienstverlener? Bedrijfsculturen kunnen verschillen natuurlijk, en soms is er gewoon een noodzaak om bij berichten te kunnen.

Dat protocol maak je onderdeel van de opdrachten met de klant, bijvoorbeeld als bijlage bij de SLA of als annex aan je verwerkersovereenkomst. (Je hébt toch een verwerkersovereenkomst met al je klanten? Dat ben je verplicht sinds de AVG gezien het soort dienstverlening.)

Vervolgens zeg je, wij hebben een zorgplicht en afspraken in het protocol en daar werken we onder. Je doet wat er is afgesproken, maar afspraken mogen niet tegen de AVG zijn. De AVG zegt, heb je gerede twijfel dan leg je het werk neer totdat het is opgehelderd. En “volgens ons is het legaal, doe het!!1!” is daarbij niet genoeg, er moet een inhoudelijke argumentatie komen.

Dat protocol mededelen doe je aan de klant, de werkgever in dit geval dus. Die heeft vervolgens de taak om het aan zijn personeel uit te leggen. Jullie hoeven dus niet de werknemers van de klant uit te leggen wat jullie precies wel of niet doen en waarom. En je hoeft al helemaal niet de werknemers akkoord te laten gaan met jullie privacy policies, acceptable use policies en ga zo maar door. Je sluit contracten met je klanten, niet met hun personeel.

Arnoud

Wanneer moet je nou met iemand een verwerkersovereenkomst sluiten?

Geplaatst op in Privacy, 36 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 iemand laten tekenen van een verwerkersovereenkomst is iets dat je kunt doen om AVG compliance aan te tonen, dus zullen er verwerkersovereenkomsten worden getekend. Tegen beter weten in dan ook vandaag, wanneer is iemand nou een verwerker?

De positie van een verwerker onder de AVG is in theorie heel simpel. Dat is een partij die door de verantwoordelijke is ingeschakeld om bepaalde dingen te doen met persoonsgegevens. De verantwoordelijk bepaalt daarbij wat er uiteindelijk moet gebeuren en hoe (“doel en middelen”, in de AVG terminologie), zij het dat de verwerker wel enige ruimte heeft om dit praktisch in te vullen.

Een simpel voorbeeld van een verwerker is een clouddienstverlener die jouw klantgegevens online opslaat. Jij kiest voor die clouddienst en welke gegevens je daar opslaat, de praktische invulling daarvan laat je aan de dienstverlener. Die is dus een verwerker. Géén verwerker is een clouddienst zoals Facebook, omdat die zelf bepaalt welke gegevens ze willen hebben en wat ze daarmee doen.

Natuurlijk zit je vaak met grijze gevallen. Zo’n clouddienst kan die klantgegevens gebruiken voor eigen “kwaliteitsdoeleinden”, of zelfs reclameprofielen opbouwen van die klanten en daar gerichte reclame aan tonen. Dan verschuift die dienstverlener van een zuivere verwerker toch meer richting een eigen verantwoordelijkheid. Er zijn helaas niet echt harde regels om hier een algemene scheidslijn in te trekken.

Ik heb een tijdje terug een advieswizard gemaakt die probeert met een aantal vragen een inschatting te maken. Dat werkt beter dan vage passages zoals in de Handleiding AVG van de Rijksoverheid, met daarin

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.

Hierdoor gaan mensen dus denken dat een clouddienstverlener of IT-supportbedrijf geen verwerker is omdat het gebruik van persoonsgegevens een “uitvloeisel” is van de echte opdracht. Er is niet één vuistregel, één formule om dit te bepalen. Je moet kijken naar alle factoren bij elkaar, en zo inschatten hoe veel eigen ruimte de dienstverlener heeft om te bepalen wat hij doet.

In ieder geval sluit je géén verwerkersovereenkomst met

  1. Je personeel. Die zijn immers gewoon deel van je eigen organisatie.
  2. Je vrijwilligers en ingehuurde krachten. Die vallen onder het kopje “personen onder gezag” van jouw organisatie en zijn dus geen verwerkers.
  3. De personen wiens persoonsgegevens je verwerkt. Ja, dit wordt geëist.
  4. Bedrijven die contactgegevens van jouw personeel in hun CRM systeem stoppen. Dat doen ze immers voor hun eigen bedrijfsvoering.

Overigens zou de verwerkersovereenkomst eigenlijk afgeschaft moeten worden, maar dat een andere keer.

Arnoud