AVG (GDPR): 3 aandachtspunten uit de praktijk (en hoe Azure helpt)

De eerste grote boete van maar liefst 50 miljoen euro is uitgedeeld door de Franse privacywaakhond (CNIL). De grootste zoekgigant van de wereld, Google, zou onvoldoende transparant zijn geweest naar zijn eindgebruikers. Wij vroegen ons af hoe de wet bij organisaties dichter bij huis is geïmplementeerd en waar zij nog uitdagingen zien. En in het bijzonder, hoe dit bij software gedreven organisaties verlopen is. Dit zijn organisaties waar softwareontwikkeling en zelfontwikkelde systemen een centrale rol spelen in het succes van de organisatie.

Met behulp van een verkennend onderzoek, uitgevoerd bij een achttal organisaties, zetten we de drie grootste uitdagingen voor jou uiteen.

Databeveiliging, dataminimalisatie, datafiltering, anonimisatie, privacy by design, het zijn slechts enkele aspecten uit de AVG die van cruciaal belang kunnen zijn. Sommigen continu top-of-mind, anderen krijgen wellicht niet de aandacht die ze wel verdienen. Reflecterend, welke aspecten zorgen voor de grootste uitdagingen?

Middels een vragenlijst en expertinterview hebben we de volgende onderdelen van de AVG onderzocht bij een achttal organisaties:

• Dataminimalisatie. Hoe zorgt een bedrijf ervoor dat het de data in het oog houdt en alleen data opslaat waarvoor het toestemming heeft?
• Logging. Welke mutaties houdt het bedrijf bij? Maar ook de logging van metadata; hoe bewaart het bedrijf de toestemming van de gebruiker?
• Anonimisatie. Wat wordt er gedaan om data zoveel mogelijk te anonimiseren?
• Pseudonimisering. Maakt het bedrijf gebruik van pseudonimisering voor de juiste data?
• Databeveiliging. Hoe garandeert het bedrijf dat de data die het bezit veilig is opgeslagen?
• Inzicht. Weet het bedrijf welke data het heeft?
• Testdata. Wordt er duidelijk onderscheid gemaakt tussen productiedata en data die wordt gebruikt om te testen?
• Data filtering. Waar vindt daadwerkelijk filtering plaats?
• Rechten. Hoe is de autorisatie binnen het bedrijf ingericht? En hoe wordt die gehandhaafd?
• Derde partijen. Welke afspraken heeft het bedrijf met derde partijen om data uit te wisselen?
• Privacy by Default. Staan de instellingen bij het standaard gebruik van een applicatie of systeem zo privé mogelijk?
• Privacy by Design. Zijn de systemen die worden uitgebreid/gebouwd daadwerkelijk privacy bewust ontworpen en gebouwd?
• Het recht bij de eindgebruiker. Heeft een eindgebruiker daadwerkelijk de rechten (recht van verwijdering, recht van aanpassing, recht op beperking van verwerking en recht op inzage) van de AVG tot zijn beschikking?
• Verantwoording. Wat doet het bedrijf eraan om verantwoording af te leggen aan de eindgebruiker en de overheidsinstanties?

Op basis van de vragenlijsten en expertinterviews kwam er een duidelijke top 3 naar voren. Een top 3 van onderwerpen waar het minste aandacht voor is, waar software gedreven organisaties de grootste uitdagingen ervaren:

1. Pseudonimisering & Anonimisatie

2. Dataminimalisatie

3. Testdata

Hieronder lichten we ieder aspect toe.

Pseudonimisering zorgt ervoor dat een persoonsgegeven zonder aanvullende informatie niet meer te herleiden is naar een persoon. Het betekent dat bij het opslaan van persoonsgegevens gebruik moet worden gemaakt van versleuteling of andere pseudonimiseringstools.

Het toepassen van versleuteling is met de huidige stand van de technologie vaak gemakkelijk te regelen. In veel verschillende soorten databases is het mogelijk de gehele opslag te versleutelen. Maar er zijn ook databases waarin je nog een stap verder kunt gaan en dit automatisch per tabel, kolom of rij kunt doen. Een goed voorbeeld hiervan is de Azure SQL database, deze beschikt over de feature Always Encrypted. Dit is een techniek die ervoor zorgt dat alle data (of bepaalde delen) in de database, ook tijdens het transport vanuit de database, naar een applicatie versleuteld is, en weer ontsleuteld wordt wanneer het arriveert bij de applicatie.

Anonimisatie zorgt ervoor dat gegevens niet meer herleidbaar zijn naar een persoon. In tegenstelling tot pseudonimisering, zijn geanonimiseerde persoonsgegevens niet meer te ontsleutelen. Bij applicatieontwikkeling en data analyse is het cruciaal om anonimisatie in een zo vroeg mogelijk stadium toe te passen.

Een steeds grotere hoeveelheid data is voor bedrijven heel waardevol, bijvoorbeeld bij data analyse, prognoses of testdoeleinden. En veel analyses kunnen ook uitgevoerd worden wanneer er niet bekend is om wie het precies gaat. De waarde van de data is even groot, terwijl de privacy van de persoon wordt gegarandeerd.
Let op, de Autoriteit Persoonsgegevens noemt expliciet dat hashing, het creëren van een unieke code die niet teruggerekend kan worden naar de oorspronkelijke code, niet afdoende is om aan dit vereiste te voldoen.

Na het anonimiseren van een dataset blijft er altijd een vraag over, is het anoniem genoeg? Om hier achter te kunnen komen kun je gebruikmaken van k-anonimity. Dit is een model om te bepalen hoe gemakkelijk het is om een specifieke gebruiker uit de dataset te lichten op basis van een combinatie van eigenschappen.

Een van de manieren om privacy te waarborgen is dataminimalisatie; alleen de data die nodig is voor het doel van het systeem wordt bewaard.

In het ideale scenario wordt bij het binnenkomen van de data alleen de strikt noodzakelijke gegevens opgeslagen. Als dat niet mogelijk is moeten de gegevens meteen verwijderd worden zodra ze overbodig zijn. Een mooi voorbeeld is een bestelpagina bij een webwinkel. Als een product bij jou bezorgd moet worden, dan is jouw naam, adres en telefoonnummer nodig, en jouw e-mailadres voor de bevestiging en factuur. Op deze formulieren wordt echter vaak meer informatie verzameld. Informatie die het individuele klantprofiel dient te verrijken of die andere doeleinden dient die niets te maken hebben met jouw bestelling. Op zo’n webformulier zou het weglaten van de optionele velden de oplossing zijn die voldoet aan het beginsel van dataminimalisatie.

Dataminimalisatie is het gemakkelijkst toe te passen bij het implementeren van een nieuw systeem. Al tijdens de ontwerpfase moet worden gezorgd dat alleen de daadwerkelijk benodigde informatie wordt opgeslagen die nodig is voor de verdere verwerking, en dat redundante informatie verwijderd wordt zodra dat kan. Ook is het belangrijk de data te scheiden op basis van de doelen van een systeem. Data die is verzameld voor een specifiek doel aan het begin van het proces, moet idealiter meteen hierna verwijderd worden.

Testdata mag geen productiedata zijn, met als uitzondering de gevallen waarin aantoonbaar geen alternatief is.

Bij de verwerking van persoonsgegevens in de organisatie moet vooraf duidelijk zijn met welk doel dit gebeurt en op basis van welke grondslag. Dit moet gericht zijn op de primaire bedrijfsprocessen, denk aan een verzekeraar die polissen aanbiedt en zorgt voor efficiënte schadeafhandeling.

Primaire processen worden natuurlijk ondersteund door IT-processen. Processen die wij elke dag met veel plezier voor onze klanten aan het maken zijn. Als bij de IT-processen ook persoonsgegevens betrokken zijn, vallen deze processen onder ‘verwerking’ en zal moeten worden beoordeeld op welke grond en met welk doel deze verwerking plaatsvindt. Vaak is dit 1 op 1 te relateren aan het doel van het primaire bedrijfsproces. Maar soms is dit minder duidelijk.

Neem opnieuw ons voorbeeld. Mag software voor een webwinkel worden getest op basis van echte klantgegevens, zodat bestellingen in de toekomst nog sneller kunnen worden afgerond? Het is belangrijk om te kijken of alle eventuele alternatieven voor het doel ontoereikend zijn. Denk aan alternatieven als pseudonimisering of het gebruik van fictieve data. Als er toch voor productiedata wordt gekozen, zullen ontwikkelteams moeten kunnen aantonen dat testdata ontoereikend is.

Bij de eerder uiteengezette aandachtspunten begint de uitdaging vaak al bij de vragen “welke data hebben we exact?” en “wat betekent die data?”. Neem opnieuw een zorgverzekeraar en de dataset die zij gebruikt. Haar medewerkers weten dat zij jouw persoonsgegevens hebben en declaraties ontvangen, maar weten zij ook precies welke velden een declaratie heeft en wat dit voor gevolgen kan hebben in combinatie met een andere tabel?

Om hier een beter inzicht in te krijgen kun je gebruik maken van de Gegevensdetectie en -classificatie tool in Azure, speciaal voor de SQL Database. Hiermee geeft Azure je de mogelijkheid om het datamodel van een database te bekijken en per veld of kolom te bepalen welke classificatie die krijgt, bijvoorbeeld 'Confidentieel' of 'Confidentieel – GDPR'. Op basis van veld- en modelnamen helpt Azure je op weg door suggesties te geven voor de dataclassificering. Dankzij deze classificaties kun je maatregelen nemen in, bijvoorbeeld, het loggen van de database, maar ook een selectie maken van de velden die je bewaart.

De invoering van de Algemene Verordening Gegevensbescherming ligt inmiddels al weer een tijd achter ons. Maar databeveiliging, privacy by design, dataminimalisatie, anonimisatie en alle overige onderdelen zijn belangrijker dan ooit. En in het bijzonder geldt dit voor organisaties waar softwareontwikkeling en zelfontwikkelde systemen een centrale rol spelen in het succes van de organisatie.

Ben je bewust van de uitdagingen die er bij jouw organisatie spelen. Privacy en security zijn hoofdzaken, geen bijzaken.