De gebruikstaak bepaalt welke gegevens nodig zijn
Begin met de handeling die de gebruiker of medewerker moet kunnen uitvoeren. Welke informatie is daarvoor noodzakelijk en waarom? Een registratieformulier kan bijvoorbeeld om een geboortedatum vragen terwijl alleen een leeftijdsgrens relevant is. Onderzoek of een minder gedetailleerd gegeven of een andere controle voldoende is. Leg de reden per belangrijk veld vast. Gegevens verzamelen omdat zij later misschien nuttig worden, past niet zonder meer bij doelbinding en minimale verwerking. De ontwerpanalyse maakt daarom onderscheid tussen noodzakelijke gegevens, optionele functies en informatie waarvoor nog geen duidelijk gerechtvaardigd doel bestaat.
Standaardinstellingen bepalen de eerste privacypositie
Gebruikers nemen niet altijd de tijd om iedere instelling te wijzigen. Daarom moeten standaardkeuzes worden beoordeeld op hoeveelheid gegevens, toegankelijkheid en bewaartermijn. Een nieuw account hoeft bijvoorbeeld niet standaard zichtbaar te zijn voor een onbeperkte groep personen. Ook uitgebreide logging of automatische gegevensdeling verdient een concrete rechtvaardiging. De AVG verlangt passende technische en organisatorische maatregelen in het ontwerp en bij de verwerking zelf. Dat betekent niet dat ieder systeem dezelfde instellingen krijgt. De keuzes moeten aansluiten op de doeleinden en risico's, maar de organisatie moet kunnen uitleggen waarom de standaardverwerking noodzakelijk en proportioneel is.
Toegang ontwerpen vanuit taken en situaties
Bepaal welke rollen gegevens mogen zien, wijzigen of exporteren. Een medewerker die een afspraak plant, heeft mogelijk geen toegang nodig tot alle achterliggende dossierinformatie. Onderzoek ook beheerdersrechten en tijdelijke toegang voor ondersteuning. Een eenvoudig rollenmodel kan onbedoeld te breed zijn wanneer vrijwel iedereen als beheerder wordt aangemerkt. Leg vast hoe rechten worden toegekend, periodiek gecontroleerd en beëindigd bij functiewijziging of vertrek. De gebruikersinterface moet die keuzes ondersteunen. Een intern beleid dat beperkte toegang belooft, is onvoldoende als het systeem ieder personeelslid zonder extra controle volledige exports laat maken.
Een formulier vraagt een document dat niet nodig blijkt
Een fictieve dienstverlener laat iedere nieuwe zakelijke contactpersoon een identiteitsdocument uploaden om een demo te boeken. Het doel is alleen een afspraak plannen en contact opnemen. Bij de ontwerpbeoordeling wordt onderzocht waarom zo'n document nodig zou zijn en of naam, zakelijke contactgegevens en een gewone bevestiging volstaan. Als geen passende noodzaak bestaat, wordt het uploadveld verwijderd in plaats van uitsluitend een langere uitleg toe te voegen. Het voorbeeld laat zien dat privacy by design het proces zelf verandert. De beste maatregel kan minder verzamelen zijn, waardoor ook opslag, toegang en latere verwijdering eenvoudiger worden.
Bewaren en verwijderen onderdeel van de architectuur maken
Bepaal hoe lang gegevens per doel nodig zijn en hoe verwijdering technisch plaatsvindt. Een bewaartermijn in beleid heeft weinig effect als exports, logs en testomgevingen onbeperkt blijven bestaan. Breng kopieën en koppelingen daarom in kaart. Ontwerp een verwijderroute die ook rekening houdt met herstel, wettelijke bewaring en aantoonbare uitzonderingen. De pagina over back-ups en verwijderverzoeken behandelt die bijzondere kopieën nader. Bij nieuwe systemen is het nuttig te controleren of gegevens per persoon of categorie kunnen worden gevonden en verwijderd. Een technisch ontwerp dat dit onmogelijk maakt, kan latere uitvoering van privacyrechten onnodig bemoeilijken.
Ontwerpkeuzes testen op werkelijk gedrag
Controleer formulieren, accounts en koppelingen met representatieve tests zonder onnodige echte persoonsgegevens. Kijk wat gebeurt bij een nieuw account, een gewijzigde rol, een export en verwijdering. Onderzoek ook foutmeldingen en beheerfuncties: zij kunnen meer informatie tonen dan de gewone interface. Een leveranciersbelofte over privacy vervangt deze controle niet. Leg bevindingen vast als concrete eisen met een verantwoordelijke en acceptatiecriterium. Wanneer een verwerking waarschijnlijk een hoog risico oplevert, moet bovendien worden beoordeeld of een DPIA nodig is. Privacy by design en een DPIA vullen elkaar aan, maar zijn niet hetzelfde document of dezelfde handeling.
Opleveren met beslissingen die later te onderhouden zijn
De uitkomst bevat een gegevensoverzicht, ontwerpkeuzes, resterende risico's en uitvoerbare verbeterpunten. Vermeld welke instellingen vóór ingebruikname moeten veranderen en welke controle na lancering plaatsvindt. Bij nieuwe functies wordt de beoordeling opnieuw betrokken, zodat een zorgvuldig begin niet door latere uitbreidingen wordt uitgehold. Producteigenaar, ontwikkelaar en verantwoordelijke leiding moeten weten welke privacykeuzes onderdeel van de acceptatie zijn. Zo wordt gegevensbescherming een onderhoudbaar onderdeel van het systeem en kan de organisatie aantonen waarom bepaalde informatie wordt verzameld, wie erbij kan en wanneer zij weer wordt verwijderd.
Bronnen bij dit onderwerp
- EUR-Lex — Algemene verordening gegevensbeschermingGeraadpleegd op 2026-09-13