De GDPR verwacht dat bij de (her)ontwikkeling van systemen, producten of diensten in het ontwerp rekening wordt gehouden met het beschermen van de persoonsgegevens. Dit verschilt fundamenteel met het ‘Privacy by default’ principe, waar bijvoorbeeld op basis van standaard instellingen binnen een applicatie de maximale privacy van een betrokkene(n) wordt gewaarborgd. Denk bijvoorbeeld aan actief gebruik van ‘opt-in’ buttons in plaats van ‘opt-out’, waarbij de keuze altijd bij de betrokkene gelaten wordt.

De 7 principes

Ergens in de jaren ’90 van de vorige eeuw bedacht Kim Cameron de ‘7 laws of Identity’ die gebruikt zijn door Ann Cavoukian om de ‘7 foundational principles Privacy by Design’ te ontwerpen. Nieuw is het dus zeker niet. Privacy by Design kan gezien worden als een set vanarchitectuur principes die proactieve maatregelen in het ontwerp verwerken, in plaats van reactieve externe maatregelen buiten het ontwerp. Simpel gezegd, de applicatie, product of dienst heeft in de kern al bescherming van persoonsgegevens ingebouwd in plaats van een schil of lagen daaromheen die vaak technisch van aard zijn. Het beperkt zich niet alleen tot de applicatie, product of dienst zelf, maar het omvat ook het beleid van de organisatie. En als dat nog niet het geval is, zouden de organisatie kernwaarden ook de privacy moeten omarmen.

‍

‍

Twee principes uitgelicht

Wat betekenen deze principes nu concreet? In deze whitepaper lichten we de twee belangrijkste toe, namelijk Privacy embedded into design en Visibility and transparency.

‍

Privacy embedded into design

De basis van dit principe is dat privacy een integraal onderdeel van het ontwerp is. Met andere woorden: privacy moet behandeld worden als een requirement net als alle andere functionele requirements van een oplossing. Maar waar moet je dan precies aan denken?

‍

Data minimalisatie

Bij data minimalisatie moet er worden gewaarborgd dat er niet méér persoonsgegevens verwerkt worden dan strikt noodzakelijk is voor het doel van de verwerking.

Voorbeeld:

In het geval van een webshop is het vanzelfsprekend dat er naar naam en adres wordt gevraagd. Een geboortedatum of geboorteplaats is daarbij strikt gezien niet noodzakelijk. Tijdens het ontwerp zal er dus continue stil gestaan moeten worden welke persoonsgegevens noodzakelijk zijn en welke weggelaten kunnen worden. Mocht er bijvoorbeeld om marketingdoeleinden wel behoefte zijn aan dit soort additionele persoonsgegevens (profilering), dan kun je dit vermelden en zorgen dat het een optioneel veld wordt. Hierbij past dan een duidelijke omschrijving van waar en hoe deze gegevens zullen worden gebruikt.

Anonimiseren

Hier moet de vraag gesteld worden of het voor het product of de dienst noodzakelijk is om persoonsgegevens te verwerken of dat anonieme gegevens volstaan. Wanneer wel identificeerbase persoonsgegevens noodzakelijk zijn, is het van belang om na te denken over de beveiliging van deze gegevens.

Voorbeeld:

Stel dat we ooit een online kiessysteem krijgen, dan is het voor de validatie noodzakelijk om met direct identificeerbare persoonsgegevens toegang te krijgen. Het kiesresultaat zou dan niet samen met dit ID opgeslagen hoeven te worden, hooguit een geografisch kenmerk met een bijbehorend tijdstip.

Visibility and transparency

Dit principe gaat over verantwoordelijkheid en vertrouwen: niet één van de makkelijke principes om te implementeren in het ontwerp. In essentie kan dit principe opgedeeld worden in drie gebieden:

Openheid

Openheid gaat over informatievoorziening. In het ontwerp moeten mogelijkheden worden opgenomen zodat de betrokkene informatie kan krijgen over bijvoorbeeld hoe de persoonsgegevens gebruikt worden, bewaartermijnen en verdere verwerking. In een applicatie zou dat bijvoorbeeld kunnen door een button met ‘privacy transparantie’.

‍

‍

‍