Privacy by design betekent dat u gegevensbescherming in de inrichting van een verwerking verwerkt, vanaf de keuze van de middelen en gedurende het gebruik. Artikel 25 AVG verplicht de verwerkingsverantwoordelijke passende technische en organisatorische maatregelen te nemen die de beginselen van de AVG effectief uitvoeren. Privacy by default voegt daar een concrete standaard aan toe: alleen de persoonsgegevens verwerken die noodzakelijk zijn voor elk specifiek doel. Dat is geen universeel voorschrift om ieder systeem op de technisch strengst denkbare stand te zetten.
Deze gids vertaalt artikel 25 naar projectbeslissingen die u kunt beoordelen vóór de ingebruikname en tijdens het beheer. Het beoogde resultaat is een dossier waarin doel, ontwerpkeuze, werking en verantwoordelijke bij elkaar staan. Daarmee kan een team uitleggen waarom het bepaalde gegevens verzamelt, hoe toegang en bewaring zijn beperkt en welke controle laat zien dat de gekozen maatregelen werkelijk functioneren. Een privacyverklaring alleen levert dat bewijs niet.
De twee onderdelen van artikel 25
Artikel 25 lid 1 gaat over het ontwerpen en onderhouden van een rechtmatige verwerking. De beoordeling houdt rekening met de stand van de techniek, uitvoeringskosten, aard, omvang, context en doeleinden van de verwerking en risico’s voor de rechten en vrijheden van mensen. Die risico’s worden beoordeeld naar waarschijnlijkheid en ernst. De AVG-tekst noemt pseudonimisering als voorbeeld van een maatregel, niet als een verplichte techniek voor iedere situatie.
Artikel 25 lid 2 behandelt standaardinstellingen. De noodzakelijke beperking ziet op de hoeveelheid gegevens, de omvang van de verwerking, de opslagduur en de toegankelijkheid. Persoonsgegevens mogen in het bijzonder niet standaard zonder tussenkomst van de persoon toegankelijk worden voor een onbeperkt aantal mensen. De juiste instelling hangt samen met het specifieke doel en de context. Een vast voorschrift “alleen vrienden” voor elk platform zou die beoordeling ten onrechte vervangen door één technisch ontwerp.
Beide onderdelen geven uitvoering aan de beginselen van artikel 5 AVG. Rechtmatigheid en transparantie horen daar evenzeer bij als minimale gegevensverwerking en beveiliging. Een dienst die weinig gegevens bewaart maar mensen onjuist informeert, is daarmee niet vanzelf goed ontworpen. Beoordeel daarom de hele verwerking, inclusief formulieren, support, exports, leveranciers en de wijze waarop mensen hun rechten kunnen gebruiken.
Begin met een afgebakende ontwerpvraag
Beschrijf het werk dat het nieuwe proces moet verrichten. Een organisatie die afspraken plant, kan bijvoorbeeld beschikbaarheid en een contactmogelijkheid nodig hebben. Dat betekent nog niet dat iedere gebruiker een uitgebreid profiel moet invullen. Maak onderscheid tussen het plannen zelf, het versturen van herinneringen en eventueel latere marketing. Door die doelen apart te beschrijven, wordt zichtbaar welke gegevens en standaardinstellingen bij iedere functie horen.
Beoordeel vervolgens de rechtsgrond. Een technische oplossing kan een onrechtmatig doel niet repareren. Een contractuele relatie rechtvaardigt alleen de verwerking die onder de voorwaarden van artikel 6 lid 1 onder b noodzakelijk is voor een overeenkomst met de betrokkene of voor diens verzoek voorafgaand daaraan. De keuze om een extra analyse in algemene voorwaarden te beschrijven maakt haar niet automatisch noodzakelijk voor die overeenkomst.
Leg ook vast wie de besluiten neemt. De verwerkingsverantwoordelijke blijft verantwoordelijk voor artikel 25, ook wanneer een leverancier de software bouwt. Betrek mensen die het dagelijkse proces kennen, technische beheerders en de relevante privacydeskundigheid. Een ontwerper kan niet zelfstandig bepalen welke wettelijke bewaarplicht geldt; een jurist kan niet zonder technisch inzicht vaststellen of een verwijderinstelling alle kopieën bereikt. De samenwerking moet concrete vragen oplossen en besluitvorming mogelijk maken.
Ontwerp het datamodel rond noodzakelijke informatie
Gebruik een dataminimalisatietoets om ieder veld te verbinden met een doel. Vraag wat de verwerking niet meer kan uitvoeren als het veld ontbreekt. Onderzoek vervolgens een minder gedetailleerde waarde, een later verzamelmoment of een andere manier om het resultaat te bereiken. Een leeftijdsbevestiging kan in bepaalde situaties volstaan waar een volledige geboortedatum niet nodig is; een specifieke wettelijke registratieplicht kan juist exacte gegevens vereisen.
Maak een veld niet zonder verdere beoordeling optioneel. Ook vrijwillig verstrekte gegevens hebben een rechtmatig doel en passende grondslag nodig. Het proces moet bovendien duidelijk maken welke keuze de gebruiker heeft. Als een optioneel telefoonnummer vervolgens toch door de technische validatie verplicht wordt gesteld, klopt het ontwerp niet met het besluit. Controleer daarom zowel de gebruikersinterface als de achterliggende verwerking en de gegevens die gekoppelde systemen ontvangen.
Denk ook aan gegevens die de gebruiker niet zelf invult. Een toepassing kan automatisch locatie, gebruiksgeschiedenis of diagnostische informatie verzamelen. Beschrijf welke gebeurtenissen nodig zijn voor het doel en welke details kunnen worden weggelaten. Een formulier met drie velden is niet noodzakelijk minimaal als de achtergrondprocessen een veel omvangrijker profiel opbouwen. De ontwerpbeoordeling moet de feitelijke gegevensstromen volgen, niet alleen wat zichtbaar is op het scherm.
Standaardinstellingen zijn een uitvoerbaar besluit
Bepaal per functie welke verwerking zonder aanvullende actie plaatsvindt. Bij een nieuw account kan de dienst bijvoorbeeld beperkt zichtbare profielinformatie gebruiken, terwijl bredere publicatie een afzonderlijke keuze vergt. De keuze moet begrijpelijk zijn en overeenkomen met wat het systeem uitvoert. Maak een schermafbeelding of beschrijving van de instelling, maar controleer ook het resultaat vanuit een ander gebruikersaccount. Een label “privé” is geen bewijs van beperkte toegankelijkheid.
Beoordeel alle vier dimensies van lid 2. Een systeem kan weinig gegevens verzamelen maar deze standaard onbeperkt bewaren. Het kan korte bewaartermijnen hebben en tegelijk iedere medewerker toegang geven. Het kan intern afgeschermd zijn terwijl een standaardexport alle gegevens naar een leverancier stuurt. Door hoeveelheid, gebruiksomvang, opslagduur en toegang afzonderlijk te bespreken, voorkomt u dat één gunstige instelling als bewijs voor het hele ontwerp wordt gebruikt.
Een bewuste keuze van de gebruiker rechtvaardigt evenmin iedere daaropvolgende verwerking. Andere AVG-eisen en bijzondere regels blijven gelden. Leg daarom vast wat een instelling precies verandert en wat zij niet verandert. Een toestemming voor een nieuwsbrief hoort bijvoorbeeld niet stilzwijgend ook profilering voor externe partners in te schakelen. Koppel de informatie bij een keuze aan het betreffende doel en beoordeel een latere uitbreiding opnieuw.
Ontwerp toegang en beveiliging passend bij de risico’s
Bepaal welke taken toegang tot welke gegevens vereisen. Een planner heeft mogelijk beschikbaarheid nodig, terwijl een personeelsmedewerker aanvullende administratieve informatie nodig heeft. Scheid die toegangen waar dat passend is en maak duidelijk wie rechten kan toekennen en intrekken. Controleer ook tijdelijke accounts, externe ondersteuning en medewerkers die van functie veranderen. Een rolmodel dat alleen bij de eerste inrichting wordt ingevuld, kan tijdens het gebruik snel onjuist worden.
De beveiligingseisen van artikel 32 AVG hangen samen met artikel 25, maar beide bepalingen hebben hun eigen functie. Versleuteling, pseudonimisering, herstelmogelijkheden en evaluatie van maatregelen kunnen passend zijn afhankelijk van de situatie. Vermijd een standaardlijst waarin iedere techniek zonder toelichting verplicht wordt verklaard. Beschrijf welk risico een maatregel beperkt en hoe u vaststelt dat zij in de gekozen omgeving werkt.
Pseudonimisering kan bijvoorbeeld geschikt zijn voor een analyse waarbij namen niet nodig zijn. De extra informatie voor herleiding moet dan passend worden gescheiden en beschermd. De gegevens blijven persoonsgegevens wanneer herleiding nog mogelijk is. Een andere identificatiecode verandert een rechtmatigheidsvraag dus niet vanzelf in een technisch opgelost probleem. Onderzoek daarnaast of het beoogde resultaat met daadwerkelijk anonieme gegevens kan worden bereikt.
Bouw bewaring en rechten in het proces in
Voorzie een uitvoerbare manier om bewaartermijnen toe te passen. Beschrijf welke gebeurtenis de termijn laat beginnen, welke gegevens zij omvat en wie uitzonderingen beoordeelt. Automatische verwijdering kan nuttig zijn, maar is niet voor iedere verwerking de enige juridisch toegestane werkwijze. Het resultaat moet zijn dat gegevens niet langer identificeerbaar blijven dan gerechtvaardigd, met inachtneming van toepasselijke wettelijke verplichtingen en andere rechtmatige doeleinden.
Neem back-ups en herstelprocedures mee. Een verwijdering in de actieve database is niet het einde van de beoordeling als informatie later ongecontroleerd uit een reservekopie wordt teruggezet. Bepaal hoe verwijderinstructies bij herstel behouden blijven en hoe niet-actieve kopieën worden beschermd en uitgefaseerd. De AVG geeft niet één universele technische termijn voor het overschrijven van alle back-ups. De gekozen aanpak moet in de concrete omgeving uitlegbaar en uitvoerbaar zijn.
Ontwerp ook de afhandeling van inzage, correctie, verwijdering en andere toepasselijke rechten. Kan het team de gegevens van één persoon vinden zonder grote bestanden over anderen te exporteren? Zijn interne codes begrijpelijk te verklaren? Kan een fout in gekoppelde systemen worden hersteld? Een passende route voor inzageverzoeken is een ontwerpvoorwaarde die vaak beter vooraf wordt ingericht dan onder druk van een ontvangen verzoek.
Verbind een DPIA met de daadwerkelijke ontwerpkeuzes
Artikel 25 geldt niet alleen wanneer een DPIA verplicht is. Een gegevensbeschermingseffectbeoordeling is nodig als de verwerking waarschijnlijk een hoog risico inhoudt, en bij toepasselijke verplichte categorieën. Beoordeel die drempel apart. Het DPIA-stappenplan helpt de beoordeling organiseren; een DPIA-template helpt de inhoud vastleggen. De naam van een techniek of een enkele risicofactor is niet altijd voldoende om de juridische drempel te bepalen.
Als een DPIA nodig is, moet zij vóór de verwerking plaatsvinden. Verbind iedere relevante maatregel met het systeemontwerp en een verantwoordelijke voor uitvoering. Een DPIA die zegt dat toegang beperkt is terwijl de applicatie standaard iedereen toegang geeft, beschrijft geen afgeronde beheersing. Controleer of het restrisico hoog blijft. Als de voorwaarden van artikel 36 zijn vervuld, is voorafgaande raadpleging van de toezichthouder nodig voordat de verwerking begint.
Een DPIA kan tijdens het ontwerp tot aanpassing van het project leiden. Misschien is een minder gedetailleerde analyse voldoende, kan een externe koppeling vervallen of is de beoogde uitkomst onvoldoende gerechtvaardigd. Beschouw zulke conclusies als inhoudelijke beslissingen. Het doel is niet een formulier met uitsluitend groene vakken. Voor de beoordeling van risico’s voor mensen kan ook hun perspectief relevant zijn, met inachtneming van de voorwaarden van artikel 35 lid 9.
Inkoop: vraag bewijs voor uw eigen gebruikssituatie
Een leverancier kan verklaren dat een product privacyvriendelijk is, terwijl de uitkomst afhangt van de gekozen functies en instellingen. Beschrijf daarom uw noodzakelijke gegevens, toegangsrollen, bewaaraanpak en rechtenproces in de uitvraag. Laat de leverancier demonstreren hoe die situatie wordt ingericht. Vraag wat standaard aanstaat, welke aanvullende configuratie nodig is en welke beperkingen gelden. Een algemeen certificaat of verkoopdocument vervangt die concrete beoordeling niet.
Controleer de feitelijke rol van de leverancier en de relevante afspraken. In een verwerkersrelatie gelden de eisen van artikel 28, via een schriftelijke overeenkomst of andere bindende Unierechtelijke of lidstaatrechtelijke rechtshandeling, ook elektronisch. Die afspraken moeten aansluiten op wat de dienst technisch en organisatorisch doet. Een clausule die verwijdering belooft is onvoldoende wanneer niemand kan uitleggen hoe gekoppelde opslagplaatsen en subverwerkers worden meegenomen.
Bij vergelijking van software voor AVG-beheer kunt u onderzoeken hoe ontwerpbesluiten, maatregelen en bewijs met elkaar worden verbonden. Veronderstel geen automatische juridische beoordeling of volledigheidsgarantie. Een eenvoudige documentstructuur kan ook werken als zij actueel, toegankelijk en gekoppeld aan het project is. Het benodigde hulpmiddel volgt uit de samenwerking en complexiteit, niet uit een algemene verplichting om een specifiek product te kopen.
Controleer vóór ingebruikname wat het systeem werkelijk doet
Gebruik representatieve fictieve gegevens waar dat mogelijk is. Productiegegevens gebruiken voor ontwikkeling of controle is niet zonder meer toegestaan of categorisch altijd verboden: het vraagt een eigen rechtvaardiging, noodzakelijkheid en passende bescherming. Begin met alternatieven die geen echte personen blootstellen. Maak duidelijk wie een afwijking mag beoordelen en voorkom dat een volledige productie-export de standaardroute wordt omdat die technisch eenvoudig is.
Controleer de gegevens die daadwerkelijk worden opgeslagen en doorgestuurd. Probeer de route zonder optionele informatie, bekijk een account met beperkte rechten en beoordeel wat een verwijderactie bereikt. Leg een geconstateerde afwijking vast met eigenaar en oplossing. Een beleidsdocument dat de gewenste werking beschrijft, is niet voldoende wanneer de praktijk daarvan afwijkt. De controle moet aansluiten op de concrete ontwerpbeslissing die u wilt onderbouwen.
Een bruikbare ontwerpcontrole behandelt achtereenvolgens het afgebakende doel en de grondslag, noodzakelijke velden, standaardgebruik, toegang, bewaring, informatie, rechten en eventuele DPIA-maatregelen. Deze volgorde is een praktische werkwijze, geen wettelijk voorgeschreven afvinklijst. Verbind elk antwoord met bewijs of een nog openstaande actie. Zo wordt duidelijk welke punten een verantwoorde ingebruikname in de weg staan en welke beheerafspraken daarna moeten blijven werken.
Bestaande systemen blijven binnen de verplichting vallen
De verplichting houdt niet op na de eerste versie. De definitieve EDPB-richtsnoeren 4/2019 behandelen artikel 25 als een voortdurende opdracht en bespreken ook bestaande systemen. Een later ontdekt probleem is dus aanleiding om de verwerking te verbeteren. Het is onjuist om te zeggen dat privacy by design achteraf nooit meer kan worden toegepast of dat oudere systemen buiten de beoordeling vallen.
Onderzoek bij een bestaand systeem welke maatregelen direct uitvoerbaar zijn en welke een structurele aanpassing vragen. Soms kan een overbodige export worden uitgezet voordat een grotere wijziging gereed is. Een toegangsbeperking kan een tijdelijk risico verkleinen zonder alle problemen op te lossen. Beschrijf de resterende tekortkoming eerlijk en bepaal of voortzetting verantwoord is. Een toekomstig vervangingsproject rechtvaardigt niet automatisch ieder risico in de tussentijd.
Leg relevante veranderingen vast en verbind ze met het verwerkingsregister en andere passende documentatie. Artikel 30 vereist niet letterlijk dat elke ontwerpbeslissing in het register zelf staat. Een verwijzing naar een afzonderlijk besluit of risicoanalyse kan begrijpelijker zijn. Herbeoordeel de inrichting bij wijzigingen in doeleinden, gegevens, ontvangers, techniek of risico’s, en bepaal daarnaast een passende beheercontrole. Er is geen universele vaste reviewfrequentie voor alle systemen.
Veelgestelde vragen
Is privacy by default altijd de strengst mogelijke instelling?
De norm is dat standaard alleen de gegevens worden verwerkt die nodig zijn voor elk specifiek doel, over hoeveelheid, omvang, opslagduur en toegankelijkheid. Dat vereist een inhoudelijke beoordeling van de dienst. Een willekeurige technische instelling die het proces onbruikbaar maakt is niet automatisch de juiste oplossing. Het doel zelf moet bovendien rechtmatig zijn en mag niet kunstmatig worden verruimd om meer gegevens te rechtvaardigen.
Zijn versleuteling en automatische verwijdering altijd verplicht?
De AVG vraagt passende maatregelen en een effectief resultaat, geen identieke technische inrichting voor iedere organisatie. Versleuteling en automatische verwijdering kunnen passende middelen zijn, maar de keuze moet aansluiten op de gegevens, risico’s en verwerking. Als u een andere aanpak kiest, moet die de relevante verplichting ook daadwerkelijk waarmaken. Alleen zeggen dat een maatregel duur is, vormt geen volledige beoordeling.
Bewijst een DPIA dat artikel 25 is nageleefd?
Een DPIA kan belangrijke onderbouwing leveren, maar bewijst niet vanzelf dat maatregelen zijn uitgevoerd en blijven werken. Controleer de feitelijke inrichting en de aansluiting op de conclusies. Ook wanneer geen DPIA verplicht is, blijven de eisen van artikel 25 gelden. Het ontwerpbesluit, de uitgevoerde maatregel en bewijs van werking moeten samen een begrijpelijk geheel vormen.