Opinie

Binnen de gegevensbescherming wordt regelmatig gesproken over privacyrisico's. Dat vind ik eigenlijk best vreemd. In het woord risico schuilt namelijk een zekere onzekerheid. Die onzekerheid kennen we vanuit de informatiebeveiliging: risico = kans × impact. Het gaat daarbij om het maken van een inschatting van een mogelijk incident in de toekomst. Echter, wanneer spreken we binnen gegevensbeschermingeigenlijk van kans? Gegevensbescherming kent zeker ook de beveiliging van persoonsgegevens, zoals benoemd in artikel 32, maar hoe zit dat met de overige artikelen? Denk aan zaken als dataminimalisatie, inzagerecht, transparantie, rectificatie en wissing van gegevens, bescherming tegen profilering, etc. Is daarbij sprake van kans? Je hebt dat als verantwoordelijke op dit moment goed ingericht of niet. Daar hoef je dus geen inschatting voor de toekomst bij te maken. Ja, het niet goed ingericht hebben van dat soort onderwerpen vormt een risico voor de betrokkenen, maar wellicht is het dan eerlijker om het te hebben over gegevensbeschermingsonkunde (bij de verantwoordelijke) in plaats van privacyrisico's.

Lees hier verder. >>>

Sinds september 2019 bestaat de NEN-ISO/IEC 27701 standaard. NEN omschrijft deze standaard als volgt:

NEN-ISO/IEC 27701 specificeert eisen en geeft richtlijnen voor het inrichten, implementeren, onderhouden en continu verbeteren van een managementsysteem voor privacy-informatie ('Privacy Information Management System', PIMS) in de vorm van een uitbreiding op ISO/IEC 27001 en ISO/IEC 27002 voor privacymanagement binnen de context van de organisatie

De 27001 en 27002 standaarden gaan over informatiebeveiliging. Iedereen die een beetje verstand heeft van gegevensbescherming, weet dat gegevensbescherming meer is dan alleen de beveiliging van persoonsgegevens. Is het dus verstandig om een standaard die een organisatie grip moet geven op gegevensbescherming, te baseren op een standaard voor informatiebeveiliging? In dit artikel ga ik in op die vraag.

Waar bestaat 27701 precies uit? De eerste vier hoofdstukken zijn inleidende hoofdstukken. Hoofdstuk 5 is een aanvulling op 27001 en hoofdstuk 6 is een aanvulling op ISO 27002. Hoofdstuk 7 is bedoeld voor verwerkingsverantwoordelijken en bevat een opsomming van waar je als verwerkingsverantwoordelijke volgens de AVG aan moet voldoen. Hoofdstuk 8 is vergelijkbaar met hoofdstuk 7, maar dan voor verwerkers.

Lees hier verder. >>>

In haar verslag over 2017 en 2018 heeft de Saksische toezichthouder (DPA) de vraag behandeld of een penetratietest moet worden gezien als een verwerking door een Verwerker. Dit bericht is alweer van enige tijd geleden maar levert in de praktijk nog steeds vragen op. In de discussies die ik heb kunnen vinden (links onderin) mis ik de brontekst en het kernargument. Daarom toch nog ook deze bijdrage aan dit debat.

Zoals je hier gewend bent: wij proberen volledig te zijn. Dus: 'warning: long read'.

Managementsamenvatting: nee, geen verwerker.

In heel veel IT-relaties is het niet zo eenvoudig om te duiden in welke gevallen er sprake is (of zou moeten zijn) van verwerking door een Verwerker. Ik schreef daar, op basis van EDPB opinie 169, ook al eerder over in 'de on-premise softwareleverancier'. Voor penetratietests wordt een vergelijkbare vraag gesteld: een externe pentester kan immers data zien, downloaden, verwerken. Moet je dan een verwerkersovereenkomst sluiten?

Lees hier verder. >>>

Onderstaand mijn vertaling van het advies uit paragraaf 4.3.4 van het rapport (link). Mijn Duits is niet perfect, dus als er fouten in staan hoor ik dat graag (in de comments). De onderstreping is door mij toegevoegd.

De oorspronkelijke tekst staat onderin, zowel ter referentie als verantwoording.

Lees hier verder. >>>

Bezint eer ge begint. Dit geldt voor alles, ook voor de verwerking van persoonsgegevens. Een goede DPIA is naar mijn idee de basis voor een goede en eerlijke verwerking. Alleen hebben we nog een lange weg te gaan daarin, denk ik.

Ongeveer een jaar geleden zijn wij begonnen met het ontwikkelen van een eigen DPIA model. De reden daarvoor was omdat we vonden dat er geen goed model beschikbaar was. De enige beschikbare was het model Gegevensbeschermingseffectbeoordeling Rijksdienst (GEB Rijksdienst), maar deze vonden we te weinig sturend, legde te weinig de vinger op de zere plek en vergde daardoor de aanwezigheid van een expert om er een goede invulling aan te geven. Zeker voor MKB organisaties was het uitvoeren van een DPIA daardoor geen eenvoudige opgave.

Lees hier verder. >>>

Door ons en vele anderen is uitvoerig geschreven over toestemming als grondslag. Over dat toestemming als grondslag het laatste redmiddel is. Op andere blogs lees je vooral ook veel over dat die toestemming 'vrijelijk' moet zijn: geinformeerd, ondubbelzinnig, zonder dwang. Vermoedelijk is toestemming een van de moeilijkste onderwerpen van de AVG.

De discussie die ik minder vaak hoor is hoe onhandig toestemming is om mee te werken. De AVG gaat immers veel verder dan het vragen om toestemming. Je moet die toestemming administreren (art. 7 lid 1). Je moet er op voorbereid zijn dat de betrokkene zijn toestemming op ieder moment kan intrekken en vanaf dat moment dus jouw grondslag wegneemt. Elke keer als ik ergens lees dat toestemming nodig is, vraag ik me af of die administratie ook echt gevoerd wordt en wat er gebeurt bij intrekking.

Het meest recente voorbeeld is de Boxmeerse Kermis. Ook hier kunnen we discussieren over de vraag of toestemming wel nodig is: als publicatie plaatsvindt voor een journalistiek doel zitten we in de uitzonderingen van art. 43 UAVG.

Lees hier verder. >>>

Artikel 30 van de AVG eist dat een verwerkingsverantwoordelijke een register bijhoudt van de verwerkingsactiviteiten die onder zijn verantwoordelijkheid plaatsvinden. En dat is heel logisch. Om de overige artikelen van de AVG te kunnen naleven, moet je natuurlijk wel weten om welke gegevens het precies gaat. Veel organisaties leggen vanwege deze verplichting zo'n verwerkingsregister aan, gebruikmakend van zelf gemaakte Excelsheets tot aan specifiek daarvoor ontwikkelde tooling. En hoewel je met zo'n verwerkingsregister voldoet aan een van de vele eisen vanuit de AVG, is de vraag of het hebben van zo'n apart register de juiste aanpak is. Persoonsgegevens zijn namelijk niet het enige soort gegeven dat om goed beheer en om goede beveiliging vraagt. Ook voor andere vertrouwelijke bedrijfsinformatie geldt dat het goed zicht hebben erop noodzakelijk is om ze goed te kunnen beheren en beveiligen. Eigenlijk wil je als organisatie een centraal overzicht hebben van alle bedrijfsinformatie. Of iets een persoonsgegeven is en de verwerking daarvan dus onder de AVG valt, zou eigenlijk niet meer dan een attribuut van informatie in dat centrale overzicht moeten zijn.

Lees hier verder. >>>

Busreiziger Michiel Jonker heeft een rechtszaak aangespannen tegen de Autoriteit Persoonsgegevens (AP), vanwege de weigering van de AP om handhavend op te treden tegen vervoerbedrijf Breng/Connexxion. Connexxion weigert, net als veel andere Nederlandse vervoerbedrijven, sinds medio 2018 om in de bus betaling van kaartjes met contant geld te accepteren. Volgens Jonker is dit een schending van zijn privacy, omdat dit hem als busreiziger verplicht tot pinbetaling, waarbij zijn persoonsgegevens worden verwerkt. Jonker diende hierover in juli 2018 een handhavingsverzoek in bij de AP.

Een interessante zaak. Aan de ene kant heb ik begrip voor het argument van Connexxion. Overvallen in de bus zijn onacceptabel. Aan de andere kant, hoe groot is dat probleem daadwerkelijk en is het niet meer accepteren van contant geld de enige oplossing? Waarom de OV-chipkaart als enige betaalmogelijkheid? Voordat ik daar verder op in ga, even wat achtergrond over de invoering van de OV-chipkaart.

Lees hier verder. >>>

Sinds de komst van de AVG hebben cybersecurityexperts er een extra uitdaging bij, namelijk het beveiligen van persoonsgegevens. De valkuil voor hen is dat zij, door onvoldoende kennis van de AVG, denken dat dat het enige is wat gegevensbescherming inhoudt. Echter, het beveiligen van gegevens is slechts 1 van de 99 artikelen uit de AVG.

Ik hoor ook regelmatig geluiden over de FG die half op de stoel van de CISO gaat zitten, omdat hij/zij zich geroepen voelt om een inhoudelijke mening of reactie te geven over artikel 32. Echter, het feit dat de AVG een artikel bevat over informatiebeveiliging, maakt dat niet automatisch een verantwoordelijkheid van de FG.

Lees hier verder. >>>

De uitkomsten van een DPIA worden doorgaans geheim gehouden. Ze worden beschouwd als interne bedrijfsinformatie. Eigenlijk is dat gek. Je brengt namelijk risico's in kaart voor anderen; de betrokkenen. Die zouden moeten mogen weten welk risico ze lopen. Toch?

Ik heb het vermoeden dat de houding ten opzichte van de resultaten van een DPIA afkomstig is uit de risicoanalyse. De resultaten daarvan worden ook als interne bedrijfsinformatie gezien. En dat is niet zo vreemd. Het gaat immers om risico's voor de organisatie. Maar juist dat is het grote verschil met een DPIA. Risicoanalyse: risico's voor jou. DPIA: risico's voor anderen. We moeten dus loslaten dat het in kaart brengen van risico's altijd betekent dat de resultaten daarvan vertrouwelijk zijn. Artikel 5 van de AVG stelt dat gegevens moeten worden verwerkt op een wijze die transparant is. Hoort zicht op de risico's daar niet gewoon bij?

Lees hier verder. >>>

Een veel gemaakte fout rondom de Algemene Verordening Gegevensbescherming (AVG) is dat voor de verwerking van persoonsgegevens altijd toestemming nodig is. Om persoonsgegevens te mogen verwerken heb je een grondslag nodig. In normaal Nederlands betekent dit dat je een juridisch onderbouwde reden moet hebben om dit te mogen doen. De AVG biedt meerdere grondslagen, waar toestemming er slechts een van is. Voordat we dieper ingaan op toestemming, bekijken we eerst welke grondslagen de AVG biedt.

Lees hier verder. >>>

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.

Lees hier verder. >>>

Nog steeds bestaat er discussie over de vraag of de tijd die Verwerker neemt voor het melden van een datalek aan Verwerkingsverantwoordelijke af gaat van de 72 uur die Verwerkingsverantwoordelijke heeft. Dat is vreemd, want art. 33 lid 1 AVG is vrij duidelijk:

Indien een inbreuk in verband met persoonsgegevens heeft plaatsgevonden, meldt de verwerkingsverantwoordelijke deze zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur nadat hij er kennis van heeft genomen [...] Indien de melding aan de toezichthoudende autoriteit niet binnen 72 uur plaatsvindt, gaat zij vergezeld van een motivering voor de vertraging.

Ten eerste is het natuurlijk zaak om de melding zo snel mogelijk te doen en dus zonder onredelijke vertraging. Het liefst natuurlijk eerder dan 72 uur: dat is nadrukkelijk een maximale termijn.

Ten tweede is de termijn van 72 uur dus de termijn voor Verantwoordelijke: art. 33 lid 1 zegt nadat hij. Ingeval van een Inbreuk bij een Verwerker begint de termijn dus op het moment waarop de Verantwoordelijke kennis neemt van de melding.

Lees hier verder. >>>

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.

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.

Lees hier verder. >>>

De AP meldt dat de KvK stopt met de verkoop van namen en adressen van bedrijven. Het belangrijkste probleem daarmee is dat het adres van een ZZP'er in veel gevallen een prive-adres is.

Mij viel vooral dit citaat op:

Wolfsen: ‘De persoonsgegevens uit het Handelsregister zijn toch vooral bedoeld om de rechtszekerheid in het economisch verkeer te dienen. Dus om informatie te verkrijgen die je nodig hebt in het zakelijk verkeer. Zoals wie je leverancier is, wie de bestuurder van een bedrijf is en wie tekenbevoegd is enzovoort. Deze persoonsgegevens mogen natuurlijk niet voor hele andere doeleinden worden gebruikt.’

Wolfsen heeft evident gelijk over het doel van het Handelsregister. Voor wat betreft de gegevensbescherming ('privacywetgeving'...houd daar eens mee op) gaat het er vooral om dat het adres van een ZZP'er in veel gevallen zowel het bedrijfsadres van een onderneming is als het persoonlijke adres van een natuurlijk persoon. Het eerste is niet beschermd onder de AVG, maar het tweede wel. En aangezien de KvK met dit product in het tweede geval persoonsgegevens van natuurlijke personen verkoopt, gaat het mis.

Lees hier verder. >>>

In mijn opiniestuk over de verwarring tussen privacy en beveiliging tijdens een PIA, noemde ik concrete vrijheid en mentale vrijheid als basis voor privacy. Deze keuze heeft wellicht wat toelichting nodig, want ik wijk daarmee af van wat veel privacyspecialisten als onderverdeling hanteren, namelijk: lichamelijke privacy, territoriale privacy, informatieprivacy en communicatieprivacy. Op zich vind ik dit een interessante onderverdeling, maar naar mijn idee raakt dit niet de kern van wat privacy feitelijk is.

Neem territoriale privacy. Als een bekende je tuin inloopt als je met diegene hebt afgesproken, dan voel je je niet in je privacy aangetast. Als een wildvreemde spontaan je tuin inloopt, dan waarschijnlijk wel. Of lichamelijke privacy. Als je partner je aanraakt, ervaar je dat als prettig. Als een onbekend persoon je op straat aanraakt, ben je waarschijnlijk alert op wat komen gaat. Er is dus nog iets extra wat bepaalt of het betreden van je territorium of een betasting van je lichaam ook een inbreuk op je privacy is. Wat precies maakt dat een inbreuk op mijn territorium, mijn lichaam, mijn informatie of communicatie in sommige gevallen een inbreuk is op mijn privacy en in andere gevallen niet? En belangrijker, waarom is dat dan? Wat doet zo'n inbreuk met mij?

Lees hier verder. >>>

In het verleden heeft de AP het Burgerservicenummer (BSN) een 'bijzonder persoonsgegeven' genoemd. Ik herinner me dat uit 2016 maar wellicht was het al eerder.
Die woordkeus heeft grote gevolgen gehad: het BSN werd binnen de overheid een soort 'untouchable' gegeven. Het hielp natuurlijk niet dat de titel van dat stukje was "AP treedt op tegen verboden gebruik BSN". In de praktijk geldt voor het BSN sindsdien "verboden tenzij" en ik heb de stellige overtuiging dat die benadering te streng is.

Lees hier verder. >>>

De AP schrijft dat websites toegankelijk moeten blijven als de gebruiker tracking cookies weigert. De NOS bericht daarover met een naar mijn idee vrij onduidelijk verhaal over de vraag of dit nu terecht is of niet.

Voor de duidelijkheid: tracking cookies. Los van de technische details gaat het er hier om of je 'cross-site' gevolgd wordt. Of de krant (veelal door een derdepartij) mag laten volgen wat jouw interesses zijn bij online winkels, zodat je gerichte reclame kunt ontvangen. Je hebt geen idee wie jou volgt. Volgens het onderzoek uit "Je hebt wel iets te verbergen" kan het daarbij gaan om vele tientallen derdepartijen waar je nog nooit van hebt gehoord. Data-brokers die handelen in jouw persoonsgegevens, zonder dat je het weet. Zonder dat je weet wat zij over jou weten. Formeel zijn het verwerkingsverantwoordelijken waar je jouw betrokkenerechten bij kunt uitoefenen. Moet je wel weten wie het zijn.

Lees hier verder. >>>

Regelmatig hoor je term 'privacywet' als mensen de AVG bedoelen. Er is geen algemene 'privacywet'. Er is wel een wet die gaat over gegevens. Met name over gegevensbescherming. Ziedaar de naam: "Algemene Verordening.... Gegevensbescherming". Het was de oplettende lezer al opgevallen dat "AVG" geen P bevat. De echte kenner wist dat ook al over de Wbp: de "Wet bescherming persoonsgegevens" - niet de Wet bescherming privacy.

Waarom daarover zeuren? Goede vraag. Omdat privacy veel meer is dan gegevens. Meestal worden er vier gebieden van privacy onderscheiden. Territoriale privacy. Lichamelijke privacy. Communicatieve privacy ('briefgeheim'). En .... informationele privacy.

Als je dat zo leest snap je dat de AVG zich alleen richt op de informationele privacy. Het gaat om gegevens over jou en wat daarmee gebeurt. Als de buurman bij jou in de tuin staat kan dat heus wel een schending van jouw privacy zijn. Als iemand jou ongewenst betast in de metro is dat absoluut een schending van jouw privacy. Maar daar gaat de AVG niet over.

Het zou goed zijn als informatiespecialisten het meer hebben over 'gegevensbescherming' en minder over 'privacy'. Dat lijkt geneuzel, maar daarmee zouden wij ons meer realiseren dat het om ons vakgebied gaat. Niet (zozeer) over het abstracte begrip privacy, maar over de gegevens waar wij iedere dag mee werken en ons brood mee verdienen. Gegevensbescherming is gewoon onderdeel van informatiemanagement. Daar moet ik steeds aan denken als een privacy officer het over de 'privacywet' heeft terwijl de CISO aanvult dat de beveiliging 'AVG-compliant' moet zijn.

Lees hier verder. >>>

Organisaties kunnen op verschillende manier de privacy van betrokkenen schenden. Hoewel het lekken van persoonsgegevens daar slechts één van is, is dat wel hetgeen vaak de media haalt. Het beveiligen van persoonsgegevens wordt door velen dan ook als het belangrijkste onderdeel gezien van privacy en is om die reden in veel gevallen een belangrijk onderdeel van de data protection impact assessment (DPIA). Dit is naar mijn idee echter onjuist. In dit artikel is beschreven waar een DPIA feitelijk over moet gaan en waarom beveiliging daar niet in thuis hoort.

Voordat ingegaan wordt op de DPIA, eerst wat uitleg over beveiliging. Om zicht te krijgen op de risico's die horen bij het werken met bedrijfsinformatie, is het goed om een risicoanalyse uit te voeren. Bij een risicoanalyse wordt onder andere gekeken naar welke dreigingen een inbreuk kunnen maken op de beschikbaarheid, integriteit of vertrouwelijkheid van de informatie. Daarbij wordt bepaald wat de kans is dat een dreiging leidt tot een incident en wat de impact van een incident is.

Lees hier verder. >>>

In de eerste helft van 2018 zijn alle rijksambtenaren overgegaan naar een andere mobiliteitskaart. Daarbij zou ik zelf als rijksambtenaar overgaan van een naamloze mobiliteitskaart naar een waar mijn voorletters, achternaam en geboortedatum op vermeld staan. Ook zouden vele persoonsgevens naar de aanbieder van deze nieuwe mobiliteitskaart gaan, waaronder mijn thuisadres, telefoonnummer en naam van het minsterie en de afdeling waar ik werk. Ik, en vele collega's met mij, hadden daar de nodige bedenkingen bij. Mijn belangrijkste bezwaren waren tegen de verwerking van mijn thuisadres, naam en geboortedatum. Hieronder licht ik toe waarom.

Lees hier verder. >>>