Wat is DPIA, wat doet het en moet ik er iets mee?

Een Data Protection Impact Assessment (DPIA), het is een cruciaal instrument om vooraf de privacyrisico’s van gegevensverwerking in kaart te brengen en te beoordelen. Door het uitvoeren van een DPIA kun je als organisatie proactief anticiperen op mogelijke risico's én zorgen voor een effectieve bescherming van de rechten van personen. Maar wat doet het nou precies? Moet ik er voor mijn organisatie ook iets mee? En zo ja, welke stappen zijn er te doorlopen en welke processen zijn er betrokken? Aschwin, onze Risk & Compliance Manager, neemt je er in deze blog in mee.

Een DPIA wordt ook wel een 'gegevensbeschermingseffectbeoordeling' (GEB) genoemd. Als organisatie moet je deze uitvoeren als een gegevensverwerking waarschijnlijk ‘een hoog risico inhoudt voor de rechten en vrijheden van natuurlijke personen’. De verplichting om een DPIA uit te voeren is daarom vastgelegd in onder andere de Algemene Verordening Gegevensbescherming (AVG). Het belangrijkste doel ervan is het uitvoeren van onderzoek naar de manier waarop de gegevensverwerking de rechten van de betrokkenen respecteert. Dit omdat de betrokkenen veelal zelf niet in staat zijn die controle uit te voeren. Als verwerker van die gegevens heb je daarom een zorgplicht: je wilt dat er netjes wordt omgegaan met de gegevens van de personen die bij de gegevensverwerking betrokken zijn.

Liever spreek ik daarom niet van een ‘verplicht handelen’, maar vanuit een ‘wil handelen’. Je wilt als organisatie dat er onderzocht wordt of en hoe de gegevens van personen netjes worden beschermd. Maar ook of er niet te veel gegevens worden verzameld en of die gegevens niet langer worden bewaard dan strikt noodzakelijk voor de toepassing waarvoor ze verzameld worden. Het maakt daarin niet uit in welke branche de gegevensverwerking plaatsvindt; het beschermen van (persoons)gegevens wil je altijd goed geregeld hebben. Er zijn echter een aantal branches waarbij het zeer waarschijnlijk is dat er gegevensverwerking plaatsvindt die als risicovol kan worden beschouwd. Een datalek kan daar vervelende gevolgen hebben voor de personen waarover de gegevens gaan. Je kunt daarbij denken aan de zorg, het onderwijs, de financiële sector en techbedrijven. Vaak is een DPIA daar dan ook verplicht. Hoewel, zoals ik eerder benoemde, wil ik eerder spreken van een wil om een DPIA uit te voeren.

Besef dat het bij een DPIA behorend onderzoek ook kan uitwijzen dat er geen persoonsgegevens bij de verwerking zijn betrokken, dan ben je snel klaar. Maar dan is het tenminste onderzocht en ligt het vast. Ook dat is compliance en het respecteren van privacy. Zo heb ik een tijd geleden een DPIA uitgevoerd voor de (mogelijke) ingebruikname van een cloudapplicatie, waarbij het onderzoek uitwees dat de gegevens werden opgeslagen in een datacenter in de USA. Buiten de Europese Economische Ruimte (EER) dus. De AVG heeft dan geen werking op die gegevens, en daarmee is er dus geen wettelijk kader om eisen aan die gegevensverwerking te stellen. Na wat verder onderzoek bleek ook dat het bedrijf niet was aangesloten bij het Data Privacy Framework. Bedrijven die hier wel bij zijn aangesloten en niet onder de werking van de AVG vallen, kunnen zich zo toch committeren aan de principes uit de AVG.

Een duidelijke ‘red flag’ dus voor deze cloudapplicatie. Maar die werd nog eens versterkt door het feit dat in hun privacystatement stond dat zij de persoonsgegevens gebruiken voor marketingdoeleinden, waarover derde partijen de beschikking krijgen en rechtstreeks gerichte marketingacties op deze personen uitvoeren. Een extra subverwerking die zeker niet bij het doel van de verwerking past. Het zal onnodig zijn aan te geven dat een DPIA als conclusie had dat de mogelijke ingebruikname niet in lijn is met de AVG, er werd negatief geadviseerd. Dat advies is door de directie overgenomen. Zo zie je dat het uitvoeren van een DPIA (ook al is het voor een onschuldig ogende maar o-zo-handige webapplicatie) kan leiden tot het deugdelijk beschermen van de privacy van betrokkenen.

Er zijn er nog meer, maar de essentie is dat, als de verzamelde gegevens in handen komen van een onbevoegde of worden ingezet voor een andere verwerking dan waarvoor ze verzameld zijn, een betrokken persoon schade kan ondervinden. Met dit handvat kun je zelf, ook als de techniek vordert, nog steeds bepalen of de verwerking een ‘hoog risico’ vormt.

De EDPB (European Data Protection Board), zeg maar de overkoepelende instantie die de landelijk opererende toezichthouders verbindt, heeft nog een paar richtlijnen voor het bepalen van een verwerking met ‘hoog risico’:

• Subverwerking zonder dit af te stemmen

• Verwerking van gegevens van kwetsbare personen (kinderen, ouderen, et cetera)

• Als de verwerking grote gevolgen kan hebben (zoals uitsluiting et cetera)

Het is een hele lijst, en dat is nog niet eens alles. Daarom is mijn devies: ongeacht of een verwerking een ‘hoog risico’ vormt, voer altijd een DPIA uit waarbij je meteen naar het doel van de verwerking kijkt in relatie tot welke gegevens worden verzameld en of deze niet subverwerkt worden. Leg dat vast in jouw DPIA en handel van daaruit: Dan ga je netjes om met privacy.

De wettelijke kaders van het AVG geven organisaties een goede instructie wanneer het uitvoeren van een DPIA verplicht is. Een belangrijk criterium hierbij is: vormt de verwerking mogelijk een ‘hoog risico’ voor de betrokkene? Maar hoe weet je dat? Mijns inziens weet je dat pas als je er onderzoek naar doet. Feitelijk het onderzoek, dat netjes in het DPIA is gekaderd, geeft je precies dat handelingsperspectief dat antwoord geeft op die vraag. Vandaar mijn devies om altijd een DPIA uit te voeren, zo heb je meteen compliant verslaglegging. Het scheelt je veel werk om DORA-compliant te zijn of te worden.

Zonder twijfel is de grootste uitdaging, en dit zal een punt van herkenning voor de lezer zijn, de inventarisatie van de keten van materiele subverwerking. Vaak wil de partij waarmee je zaken doet niet te veel prijsgeven over welk deel van de verwerking is ondergebracht bij een partij waarmee zij zaken doet. Merk op dat de AVG, maar zeker ook de DORA, vereist dat die subverwerkers in beeld zijn. Sterker nog: de verwerkingsverantwoordelijke moet daarvan in kennis worden gesteld. Vooraf. En dat is helemaal niet raar. Je hebt immers een plicht naar de verwerkingsverantwoordelijke met zorg om te gaan met diens persoonsgegevens. Daar hoort bij dat je vooraf aangeeft welke partijen toegang hebben tot welk deel van de persoonsgegevens.

Een tweede uitdaging is het vaststellen van de methode van gegevensbescherming. Als de verwerking door een derde partij geschiedt en die partij heeft géén extern auditprogramma, dan wordt het een lastig verhaal. Soms, maar dat is de minderheid, heeft men een gegevensbeschermingsprogramma opgezet en is men nog niet toegekomen aan de certificering daarvan. Maar in de meeste gevallen kan geen zuiver of afdoende uitsluitsel worden gegeven over de methode van gegevensbescherming, zowel technisch als organisatorisch. Voor de AVG, maar ook voor de DORA en de Cyberbeveiligingswet (NIS2), vormt dat een probleem. Persoonlijk denk ik dat het niet hebben van een passende certificering of assurancerapportage op termijn een knock-out criterium kan gaan worden.

Het is soms onderbelicht, maar een DPIA kan goed helpen de risico’s in beeld te krijgen. Immers, een risico is een toekomstig potentieel incident. Hoe mooi is het proactief toekomstige incidenten te verminderen of zelfs te mitigeren (voorkomen)? Een bestuurder zal hier blij van worden. Als uit het DPIA blijkt dat een bepaalde voorgenomen verwerking zodanige risico’s met zich meebrengt dat dit een impact op de organisatie kan hebben, dan wil je dat heel graag weten en helpt de DPIA de organisatie vooruit. Er is nog meer bijvangst die uit het DPIA kan komen: Een gewijzigde privacyscope van de betrokkenen. Het kan zijn dat een verwerking nieuw of een uitbreiding is op het bestaande privacybeleid van een organisatie. De AVG schrijft dan voor dat de medewerkers hierover geïnformeerd worden. Een prima middel is dat uit te voeren door de verwerking op te nemen in het privacystatement. Een DPIA helpt jou als organisatie dit te signaleren.

Iets wat enorm in opkomst is, Artificiële Intelligentie (AI). Op initiatief van de Europese Commissie heeft het Europees Parlement en Raad de ‘AI Act’ aangenomen. Hierin staan een aantal bepalingen die verplichtingen opleggen. Als gegevens door een AI-systeem of AI-model verwerkt worden, dan moet er een AIIA worden uitgevoerd, een AI Impact Assessment. Zonder in detail op de AIIA in te gaan, waarin het doel, de risico’s en de beheersmaatregelen van het AI-systeem of AI-model worden vastgesteld, is het noodzakelijk dat onderzoek vóór ingebruikname uit te voeren. Vandaar dat ik aan de DPIA-template de vraag heb toegevoegd of de verwerking geheel of gedeeltelijk gebruik maakt van een AI-systeem of AI-model. Bij een ‘Ja’ kan dan alsnog het traject van de AI Impact Assessment (AIIA) worden doorlopen.

Als een organisatie verplicht is een DPIA uit te voeren maar zij volgt die verplichting niet, dan is dat een inbreuk op de AVG. Daar staan sancties op. Laat ik het omdraaien: Waarom zou je geen DPIA willen uitvoeren? In de situatie van MSP-/ICT-dienstverlener: In veel gevallen zal een verwerking geschieden met persoonsgegevens van een ander, de klant. Je wilt graag weten wat er precies met die persoonsgegevens gebeurd, hoe die zijn beschermd, wie er nog meer bij kan, wat de bewaartermijn is etc. Je hebt daar een zorgplicht. Dat geldt ook als dit persoonsgegevens van de eigen organisatie zijn. Jouw eigen gegevens zitten daar ook tussen (!). Ik zou niet weten welk valide argument bestaat om een DPIA niet uit te voeren. En als resourcing een probleem is, gebruik dan een prettig in te vullen template die de kennishouder graag invult, je zult zien dat compliancy ook leuk kan zijn!

Gegevensbescherming in de breedste zin van het woord is een thema dat met de tijd steeds belangrijker wordt, maar ook meer aandacht krijgt. Gelukkig. Het is niet alleen een kwestie van garanties afgeven dat gegevens goed beschermd worden, het is ook aantonen dat die bescherming effectief is. Dat laatste wordt steeds belangrijker, ook in de keten van verwerkers. Je ziet daar wetgeving voor actief worden: DORA (Digital Operations Resilience Act), NIS2/Cyberbeveiligingswet en CRA (Cyber Resilience Act), om even de belangrijkste te noemen. Deze zijn, naast de AVG, van invloed op de mate van compliancy van gegevensbescherming.

Die gegevensbescherming beperkt zich dan niet enkel tot persoonsgegevens maar tot alle gegevens die verwerkt worden. Je zult alle gegevensstromen die verwerkt worden in beeld moeten hebben. Daarom is het handig om, als je een DPIA uitvoert en het blijkt dat er geen persoonsgegevens (maar wel andere gegevens) worden verwerkt, toch de subverwerkers en beveiligingsmaatregelen te inventariseren. Die kun je prima in de DPIA kwijt. Het is daarom helemaal niet raar om voor alle verwerkingen een DPIA uit te voeren en deze paraat te hebben bij een audit.

Wat zit er in het verschiet? Ik denk dat, als de tijd vordert, de auditdruk steeds groter zal gaan worden. Bedrijven ontkomen er dan niet aan om door middel van zelf georganiseerde externe audits compliance van hun gegevensverwerking aan te tonen. De meest voor de hand liggende is dan de certificering voor ISO 27001. Werk je met veel gegevens van derden of verwerk je veel ‘hoog risico’ gegevens, dan kan een ISAE 3000 / AICPA SOC 2 assuranceverklaring goed helpen. Besef dat dit flinke investering vergt, niet alleen voor de externe audit maar juist in het traject daar naartoe: de implementatie van technische en organisatorische beheersmaatregelen om aan die kaders te voldoen. Het kan het overwegen waard zijn eens te kijken naar het normenstelsel van het NIS 2 Quality Mark, dat je stapsgewijs door compliance leidt.