AVG / GDPR voor webapplicaties.

AVG-compliance is een technisch vraagstuk

De Algemene Verordening Gegevensbescherming (AVG) wordt vaak behandeld als een juridisch onderwerp. Dat is het ook — maar de implementatie is voor het grootste deel technisch. Je kunt de beste privacyverklaring ter wereld schrijven, maar als je applicatie de regels niet technisch afdwingt, ben je niet compliant.

Dit artikel richt zich op de technische kant: wat moet je webapplicatie concreet kunnen om aan de AVG te voldoen? Geen juridisch advies, maar een praktische leidraad voor ontwikkelteams en ondernemers die begrijpen dat compliance begint in de code.

Data-minimalisatie

Het basisprincipe van de AVG: verzamel alleen de persoonsgegevens die je daadwerkelijk nodig hebt, en bewaar ze niet langer dan noodzakelijk.

In de praktijk betekent dit:

• Vraag niet meer dan nodig. Heeft je contactformulier echt een geboortedatum nodig? Waarschijnlijk niet. Elk veld dat je toevoegt is een veld dat je moet beschermen, documenteren en kunnen verwijderen.
• Bouw retentiebeleid in je applicatie. Definieer per datatype hoe lang je het bewaart en automatiseer het opschonen. Inactieve accounts na 2 jaar verwijderen? Dat moet je applicatie zelf doen, niet een stagiair met een SQL-query.
• Anonimiseer waar mogelijk. Heb je data nodig voor statistieken maar niet meer herleidbaar tot een persoon? Anonimiseer proactief. Verwijder de koppeling met de persoon zodra die niet meer nodig is.

Je kunt de beste privacyverklaring ter wereld schrijven; als je applicatie de regels niet technisch afdwingt, ben je niet compliant.

Recht op verwijdering (Right to Erasure)

Gebruikers hebben het recht om hun data te laten verwijderen. Klinkt simpel, maar in de praktijk is dit een van de lastigste technische vereisten.

Het probleem: persoonsgegevens staan zelden op een plek. Ze zitten in je hoofddatabase, in log-bestanden, in backups, in third-party services die je via APIs hebt aangestuurd, in e-mailsystemen, in analytics tools. Een volledige verwijdering vereist dat je exact weet waar de data van een persoon zich bevindt.

Wat je applicatie moet kunnen:

• Een overzicht genereren van alle plekken waar data van een specifieke gebruiker is opgeslagen
• Data soft-deleten met een grace period (voor het geval van per ongeluk verwijderen)
• Na de grace period hard-deleten of anonimiseren op alle locaties
• Verwijderverzoeken loggen als bewijs dat je eraan hebt voldaan
• Cascading deletes correct afhandelen — verwijder je een gebruiker, dan moeten ook gerelateerde records worden opgeschoond

Consent management

Toestemming moet specifiek, geinformeerd en vrij gegeven zijn. Een pre-aangevinkt vakje telt niet. En toestemming voor het ene doel geldt niet automatisch voor het andere.

Technische vereisten:

• Registreer per gebruiker welke toestemmingen zijn gegeven, wanneer, en voor welk specifiek doel
• Maak het net zo makkelijk om toestemming in te trekken als om het te geven
• Koppel functionaliteit aan consent-status: stuur geen marketingmails als de toestemming is ingetrokken
• Bewaar een audit trail van consent-wijzigingen met timestamps
• Versioning van je privacy-voorwaarden — als de voorwaarden veranderen, moet je opnieuw toestemming vragen

Toestemming vragen is makkelijk. Toestemming netjes bijhouden, respecteren en kunnen bewijzen; dát is de echte uitdaging.

Verwerkersovereenkomsten en subverwerkers

Gebruik je externe services die persoonsgegevens verwerken — een e-mailprovider, analytics, een betaalsysteem — dan heb je met elke partij een verwerkersovereenkomst nodig. Maar de technische kant wordt vaak vergeten.

Zorg dat je applicatie documenteert welke data naar welke externe service gaat. Bouw dit in je architectuur: gebruik een service layer die externe API-calls centraliseert zodat je altijd weet welke persoonsgegevens je deelt en met wie. Dit maakt het ook eenvoudiger om van provider te wisselen als een verwerkersovereenkomst niet rond komt.

Encryptie

De AVG verplicht passende technische maatregelen om persoonsgegevens te beschermen. Encryptie is daar een essentieel onderdeel van.

In transit

Alle communicatie moet via HTTPS verlopen. Dit geldt niet alleen voor je frontend, maar ook voor API-communicatie tussen services, database-connecties en verbindingen met externe diensten. Gebruik TLS 1.2 of hoger. Lagere versies zijn niet meer acceptabel.

At rest

Gevoelige persoonsgegevens moeten versleuteld worden opgeslagen in je database. Dat betekent dat gegevens als BSN-nummers, medische data en financiële informatie onleesbaar worden bewaard en alleen door je eigen applicatie ontsleuteld kunnen worden. Niet alles hoeft versleuteld; maar identificerende en gevoelige data wel.

Backup-encryptie

Vergeet je backups niet. Een onversleutelde backup van je database bevat dezelfde persoonsgegevens als de database zelf. Versleutel backups standaard en beheer de encryptiesleutels gescheiden van de backups.

Logging en audit trails

Je moet kunnen aantonen dat je AVG-compliant bent. Dat vereist logging op twee niveaus:

Operationele logging: Wie heeft wanneer welke persoonsgegevens ingezien, gewijzigd of verwijderd? Dit is essentieel voor het detecteren van ongeautoriseerde toegang en het aantonen van compliance bij een audit.

Consent logging: Wanneer heeft een gebruiker toestemming gegeven of ingetrokken, voor welk doel, en op basis van welke versie van de voorwaarden? Deze logs moeten onwijzigbaar zijn — een append-only structuur is ideaal.

Zorg dat je logging zelf ook AVG-compliant is. Log geen onnodige persoonsgegevens in je applicatielogs. Een stack trace met een volledig gebruikersobject erin is een datalek als die logs niet goed beveiligd zijn.

Cookie consent

De cookiewet (ePrivacy-richtlijn) werkt samen met de AVG. Technisch moet je applicatie:

• Geen tracking cookies plaatsen voordat expliciete toestemming is gegeven
• Functionele cookies onderscheiden van analytics en marketing cookies
• De keuze van de gebruiker respecteren en opslaan
• Het makkelijk maken om de keuze later te wijzigen
• Third-party scripts (Google Analytics, Facebook Pixel) blokkeren tot consent is gegeven

Veel standaard cookie-banners zijn niet compliant: ze plaatsen cookies al bij het laden van de pagina en vragen pas daarna toestemming. Dat is te laat. De technische implementatie moet scripts conditioneel laden op basis van de consent-status.

Praktische checklist

Gebruik deze checklist om te beoordelen waar je staat:

• Alle communicatie verloopt via HTTPS met TLS 1.2+
• Gevoelige data is versleuteld opgeslagen in de database
• Backups zijn versleuteld
• Er is een werkend data-export mechanisme (recht op inzage)
• Er is een werkend data-verwijder mechanisme (recht op verwijdering)
• Consent wordt per doel geregistreerd met timestamps
• Cookie consent blokkeert tracking tot na toestemming
• Audit trails loggen toegang tot persoonsgegevens
• Retentiebeleid is geautomatiseerd
• Verwerkersovereenkomsten zijn aanwezig voor alle externe services
• Applicatielogs bevatten geen onnodige persoonsgegevens
• Er is een procedure voor het melden van datalekken (72-uurs verplichting)

Privacy is geen juridische verplichting die je achteraf oplost. Het is een feature die je vanaf dag één inbouwt.

Compliance als feature, niet als bijzaak

AVG-compliance is geen eenmalige actie maar een doorlopend proces. Het is het makkelijkst en goedkoopst als je het vanaf het begin meeneemt in je architectuur. Achteraf compliant maken van een applicatie die er geen rekening mee heeft gehouden is duur en foutgevoelig.

Behandel privacy als een feature van je product, niet als een juridische verplichting. Je gebruikers verwachten het, de wet eist het, en het bouwen ervan hoeft niet ingewikkeld te zijn — als je er van begin af aan rekening mee houdt.