De meeste organisaties hebben inmiddels een DPIA-template. Het probleem is vaak niet dat het template ontbreekt, maar dat het te weinig dwingt tot een correcte of volledige invulling. In de praktijk levert dat DPIA’s op die tekortschieten op precies de punten die ertoe doen: de verwerking is niet scherp genoeg in kaart gebracht, de risico’s zijn niet ingevuld of relevant, de koppeling met maatregelen is niet navolgbaar en de juridische onderbouwing is te dun om in een toezicht- of auditcontext stand te houden.

Artikel 35 lid 7 van de Algemene Verordening Gegevensbescherming (AVG) bepaalt wat er minimaal in DPIA moet staan: (a) een systematische beschrijving van de beoogde verwerkingen en de doeleinden, (b) een beoordeling van noodzaak en evenredigheid, (c) een beoordeling van de risico’s voor de rechten en vrijheden van betrokkenen, en (d) de beoogde maatregelen en waarborgen om die risico’s aan te pakken en compliance aan te tonen. Een DPIA-model dat één van deze onderdelen “veronderstelt” in plaats van documenteert, is in toezicht- en auditcontext zelden verdedigbaar, omdat niet zichtbaar is hoe de organisatie tot haar keuzes is gekomen. 

Een DPIA is dus bedoeld als beslisinstrument vóór de start of wezenlijke wijziging van een verwerking met een hoog risico (art. 35 lid 1 AVG). De organisatie moet vooraf begrijpen wat de verwerking precies inhoudt, welke risico’s daaruit volgen, welke maatregelen nodig zijn en waarom die maatregelen afdoende zijn. Als het template die vragen niet afdwingt, krijg je geen echte beoordeling. De vraag is dus niet of er een DPIA-template bestaat, maar of dat template de juiste diepgang en onderbouwing afdwingt.

Vijf praktische controlepunten om jouw DPIA-template langs te leggen 

Als je een DPIA-model praktisch wilt beoordelen, helpt het om vijf controlepunten te hanteren die ervoor zorgen dat het model voldoet aan de AVG: 

1. Dwingt het template tot een zorgvuldige beschrijving van de verwerking?

Een DPIA kan niet beter zijn dan het begrip dat de organisatie heeft van haar eigen verwerking. Toch is dit het onderdeel dat in de praktijk het vaakst wordt afgeraffeld. Er staat dan iets als “wij verwerken persoonsgegevens van klanten ten behoeve van onze dienstverlening” en daarmee houdt de beschrijving op.

Een goed DPIA-template dwingt tot meer. Het vraagt om een concrete beschrijving van de verwerking: welke persoonsgegevens worden verzameld, van wie, langs welke weg en met welk doel. Het maakt inzichtelijk hoe het IT-landschap eruitziet: welke systemen zijn betrokken, waar worden gegevens opgeslagen, welke koppelingen bestaan er tussen systemen en welke datastromen lopen er naar externe partijen? Het identificeert alle betrokken partijen en hun AVG-rol: wie is verwerkingsverantwoordelijke, is er sprake van gezamenlijke verwerkingsverantwoordelijkheid, welke verwerkers en subverwerkers zijn betrokken en wat doen zij feitelijk met de gegevens? [1]

Zonder die basis is elke vervolgstap (risicoanalyse, maatregelen, juridische onderbouwing) gebouwd op aannames in plaats van feiten. Een template dat hier niet voldoende ruimte en sturing biedt, produceert DPIA’s die er netjes uitzien maar de werkelijkheid niet weerspiegelen.

2. Dwingt het template tot het identificeren van de échte risico’s?

Een risicoanalyse met alleen labels als “datalek”, “discriminatie” of “gebrek aan transparantie” levert geen bruikbaar inzicht op. Het probleem is niet dat die risico’s irrelevant zijn, maar dat ze op dit abstractieniveau niets zeggen over de specifieke verwerking die beoordeeld wordt.

Een goed DPIA-template vraagt om scenario’s: wat kan er concreet misgaan, wie wordt daardoor geraakt, hoe ernstig is dat voor de betrokkenen en hoe waarschijnlijk is het dat dit scenario zich voordoet? Dat vereist dat de invuller terugkoppelt naar de beschrijving uit controlepunt 1, aangezien de risico’s afhangen van het type gegevens, het type betrokkenen, de technologie, de schaal en de context van de verwerking. [2]

In een HR-context kan het gaan om uitsluiting, chilling effects (bijvoorbeeld wanneer werknemers hun gedrag aanpassen, minder vrij communiceren of afzien van het uitoefenen van rechten omdat zij vrezen dat gegevens daarover negatief worden geregistreerd of beoordeeld), of druk om in te stemmen met een verwerking terwijl weigering feitelijk geen optie is. Dit is een situatie waarin de EDPB kritisch is over de geldigheid van toestemming als grondslag. In fraude- of kredietprocessen liggen de risico’s eerder bij foutieve signaleringen, onterechte afwijzingen of onvoldoende mogelijkheden om fouten te corrigeren. Een template dat de invuller niet dwingt om dat onderscheid te maken, levert een risicoanalyse op die inwisselbaar is tussen verwerkingen, en dus per definitie te oppervlakkig. [3]

3. Legt het template een navolgbare koppeling tussen risico’s en maatregelen?

Dit is het punt waar de meeste DPIA’s het meest zichtbaar tekortschieten. Er staat een lijst met risico’s en daarnaast een lijst met maatregelen, maar de redenering ertussen ontbreekt. Welke maatregel adresseert welk risico? Waarom is juist die maatregel passend? En wat resteert er na het treffen van de maatregel aan risico?

Artikel 35 lid 7 sub d AVG vereist dat wordt beschreven welke maatregelen en waarborgen worden ingezet om risico’s aan te pakken en naleving aan te tonen. Een sterk template maakt daarom per risico ruimte voor concrete en toetsbare maatregelen: wie is verantwoordelijk voor implementatie, wanneer moet de maatregel zijn ingevoerd, hoe wordt vastgesteld dat de maatregel niet alleen op papier bestaat maar daadwerkelijk werkt, en wat zijn de bewijsmiddelen: configuratie, logging, testresultaten, auditrapporten.

Ook het restrisico moet expliciet zichtbaar zijn. Niet ieder risico verdwijnt volledig. Juist daarom moet het template dwingen tot een beoordeling van het risico dat overblijft nadat de maatregelen zijn ingevoerd. Als dat restrisico hoog blijft, is voorafgaande raadpleging van de toezichthouder niet vrijblijvend maar verplicht (art. 36 lid 1 AVG).

4. Borgt het template de juridische onderbouwing?

Technische en organisatorische maatregelen zijn noodzakelijk, maar niet voldoende. Een DPIA moet ook juridisch standhouden. In de praktijk is dat vaak de zwakste laag: er wordt een grondslag genoemd zonder dat die wordt onderbouwd, de noodzakelijkheids- en proportionaliteitstoets is niet meer dan een formaliteit, en de AVG-beginselen worden aangevinkt in plaats van ingevuld.

Een goed template dwingt af dat de juridische onderbouwing op dezelfde diepgang zit als de technische beschrijving. Dat betekent: een beargumenteerde grondslag die in de concrete context standhoudbaar is, een inhoudelijke toets op noodzaak en evenredigheid. Waarom zijn juist deze persoonsgegevens nodig, waarom kan het doel niet op een minder ingrijpende manier worden bereikt, hoe zijn bewaartermijnen onderbouwd en hoe zijn toegangsrechten ingericht in relatie tot het doel (art. 35 lid 7 sub b AVG)? Daarnaast moet het template zichtbaar maken hoe privacy by design en by default concreet zijn ingevuld: welke standaardinstellingen, welke dataminimalisatie, welk toegangsbeheer (art. 25 AVG). [4]

Zonder die juridische laag is de DPIA in feite een technisch risicoverslag met een AVG-label. Dat is in een toezichtcontext niet verdedigbaar, omdat niet zichtbaar is hoe de organisatie tot haar keuzes is gekomen.

5. Houdt het template de DPIA levend?

Een DPIA is geen eenmalige invuloefening. De AVG verlangt dat, waar passend, de zienswijze van betrokkenen of hun vertegenwoordigers wordt gevraagd (art. 35 lid 9 AVG). In een arbeidscontext kan dat betekenen dat de ondernemingsraad wordt betrokken. Zeker bij monitoring, beoordeling of nieuwe HR-technologie. Daarnaast kan op grond van de Wet op de ondernemingsraden instemming vereist zijn, bijvoorbeeld bij personeelsvolgsystemen (art. 27 lid 1 sub l WOR). Waar een functionaris voor gegevensbescherming is aangewezen, moet bovendien diens advies worden ingewonnen bij het uitvoeren van de DPIA (art. 35 lid 2 AVG). [5]

Minstens zo belangrijk is dat de DPIA actueel blijft. De AVG verlangt dat wordt beoordeeld of de verwerking nog overeenkomstig de DPIA wordt uitgevoerd, in elk geval wanneer het risicoprofiel verandert (art. 35 lid 11 AVG). Een goed template bevat daarom een reviewdatum, een eigenaar en duidelijke triggers voor herbeoordeling: nieuwe doeleinden, uitbreiding van datasets, nieuwe technologie, veranderingen in de verwerkersketen, schaalvergroting, incidenten of klachten.

Extra gewicht bij AI en profilering

Bij AI-toepassingen, profilering of modellen die de uitkomst van een beslissing feitelijk sterk sturen, wordt de lat hoger. Een verwijzing naar “innovatieve technologie” of “algoritmische risico’s” is dan niet voldoende. Het template moet afdwingen dat de organisatie beschrijft welke persoonsgegevens het systeem gebruikt, hoe de logica doorwerkt in de besluitvorming, waar risico’s op bias of foutieve uitkomsten liggen, welke rol menselijke beoordeling feitelijk nog speelt en hoe betrokkenen een uitkomst kunnen laten controleren of corrigeren. [6]

Die eisen volgen uit een combinatie van de AVG-risicobenadering, de transparantie- en fairness-beginselen en de regels rond geautomatiseerde individuele besluitvorming (art. 22 AVG). Bij bepaalde toepassingen van hoog-risico-AI kan daarnaast onder de AI-verordening een afzonderlijke beoordeling van de impact op grondrechten vereist zijn (art. 27 AI Act). In de praktijk zal die beoordeling deels overlappen met de AVG-DPIA. Reden te meer om het template zo in te richten dat het de feitelijke impact van een systeem werkelijk analyseert, en niet alleen privacyvragen afvinkt. [7]

Conclusie

De vraag is niet of een organisatie een DPIA heeft, maar of het DPIA-template de juiste diepgang afdwingt. Een template dat de verwerking oppervlakkig beschrijft, risico’s abstract of algemeen houdt, maatregelen niet navolgbaar koppelt en de juridische onderbouwing als formaliteit behandelt, levert een DPIA op die er compleet uitziet maar bij de eerste serieuze toets niet standhoudt.

Juist daarom loont het om het eigen template kritisch langs deze vijf punten te leggen: niet op de vraag of alle vakjes kunnen worden ingevuld, maar op de vraag of het template de organisatie dwingt om de verwerking werkelijk te doorgronden, de risico’s concreet te maken en de keuzes zichtbaar en verdedigbaar vast te leggen.

Bronnen

1. Art. 35 lid 7 sub a AVG (systematische beschrijving verwerking en doeleinden). Zie ook WP29/EDPB, Guidelines on Data Protection Impact Assessments (WP248 rev.01), 4 oktober 2017, p. 9–10 (beschrijving verwerking als fundament van de DPIA).

2. WP29/EDPB, Guidelines on DPIA (WP248 rev.01), p. 11–12 (criteria voor hoog risico: scoring, profilering, systematische monitoring, innovatieve technologie, kwetsbare betrokkenen).

3. Zie over geldige toestemming bij machtsongelijkheid: EDPB, Guidelines 05/2020 on Consent under Regulation 2016/679, versie 1.1, 4 mei 2020, par. 21–23.

4. EDPB, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, versie 2.0, 20 oktober 2020.

5. Art. 35 lid 2 AVG (advies FG); art. 35 lid 9 AVG (consultatie betrokkenen); art. 27 lid 1 sub l WOR (instemmingsrecht OR). Zie ook AP, Lijst verwerkingen waarvoor een DPIA verplicht is, autoriteitpersoonsgegevens.nl/documenten/lijst-verplichte-dpia.

6. WP29/EDPB, Guidelines on Automated individual decision-making and Profiling (WP251 rev.01), 6 februari 2018.

7. Verordening (EU) 2024/1689 (AI Act), art. 27 (fundamental rights impact assessment voor deployers van hoog-risico-AI-systemen).