AVG-compliance voor websites: wat het echt kost om er een te bouwen

De meeste AVG-adviezen online zijn geschreven voor juristen of voor mensen die een beleidsgenerator kopen. Heel weinig is geschreven voor de persoon die een editor moet openen en iets moet veranderen.

Deze gids is van de tweede soort. Hij loopt door wat de Algemene verordening gegevensbescherming vraagt van een website en de systemen erachter, uitgedrukt als dingen die je bouwt, configureert of verwijdert. We doen dit werk voor bedrijven in de EU sinds de verordening in 2018 van toepassing werd, en het patroon van wat er misgaat is in die tijd nauwelijks veranderd.

Eén ding vooraf: de AVG is niet makkelijker geworden doordat er nieuwere regels bij kwamen. Ze is belangrijker geworden, want vrijwel alles in de huidige golf EU-digitale regels gaat ervan uit dat je persoonsgegevens al op orde zijn.

Begin met een eerlijke data-inventarisatie

Bijna elk mislukt AVG-project dat we hebben overgenomen liep op dezelfde plek vast. Het team schreef eerst het beleid en ontdekte de data daarna.

Breng vóór alles in kaart welke persoonsgegevens je site echt verzamelt. Niet wat de productspecificatie zegt. Wat er in de database staat, in de logs, in het analyticsplatform, in het CRM, in de supporttool, in de marketingautomatiseringsstack, in de errortracker, in de CDN-logs en in de scripts van derden op de pagina.

In de praktijk betekent dat:

• Het schema doorspitten. Elke kolom die een persoon kan identificeren, alleen of in combinatie met een andere kolom.
• Het netwerktabblad lezen bij een echte paginalading. Elk uitgaand verzoek naar een domein dat je niet beheert is een mogelijke doorgifte van persoonsgegevens, want een IP-adres plus een user agent zijn persoonsgegevens.
• Nagaan wat je errortracker vastlegt. Stacktraces bevatten routinematig e-mailadressen, tokens en request bodies.
• Logbewaring controleren. Toegangslogs met IP's die eeuwig blijven staan zijn een van de meest voorkomende bevindingen en een van de makkelijkst op te lossen.

Leg het vast als verwerkingsregister. Artikel 30 vereist het toch al voor de meeste organisaties, en de versie die nuttig is voor ontwikkelaars is een tabel met systeem, data, doel, grondslag, bewaartermijn en ontvangers.

Kies een grondslag per doel, niet per systeem

Artikel 6 geeft je zes grondslagen. De fout die we het vaakst zien is er één kiezen voor het hele product.

Je hebt vrijwel zeker meerdere doelen tegelijk lopen. Een bestelling uitvoeren is overeenkomst. Fraudecontroles zijn meestal gerechtvaardigd belang of wettelijke verplichting. Facturen bewaren voor de wettelijke termijn is wettelijke verplichting. Marketingmail is toestemming in de meeste lidstaten. Niet-essentiële analytics is toestemming, vanwege de ePrivacy-regels over toegang tot randapparatuur en niet vanwege de AVG zelf.

Het praktische gevolg is dat je datamodel moet weten welk doel elk record dient. Kun je het marketingprofiel niet scheiden van het bestelrecord, dan kun je een marketingbezwaar niet honoreren zonder de bestelgeschiedenis te breken. Die scheiding is een schemabeslissing en die is pijnlijk om achteraf in te bouwen.

Toestemming moet echt zijn, en moet worden vastgelegd

Als je op toestemming leunt, moet die vrij, specifiek, geïnformeerd en ondubbelzinnig zijn, en moet je die later kunnen aantonen.

Concreet:

• Niets niet-essentieels vuurt voordat de gebruiker handelt. Dat geldt voor het analyticsscript, de advertentiepixel, de chatwidget, het lettertype van een CDN van derden en het A/B-testscript.
• Weigeren moet net zo makkelijk zijn als accepteren. Zelfde laag, zelfde prominentie, zelfde aantal klikken. Toezichthouders behandelen alles anders als dark pattern, en zijn daar consistent in geweest.
• Toestemming is per doel. Eén schakelaar voor «analytics en marketing en personalisatie» is niet specifiek.
• Intrekken is net zo makkelijk als geven. Een permanente link of zwevende knop, geen e-mail naar support.
• Bewaar het bewijs: tijdstempel, de toestemmingsstring of de status van elke categorie, de bannerversie en de tekst die de gebruiker te zien kreeg. Zonder de versie kun je een twee jaar oude toestemming niet verdedigen.

De handhaving hier is niet theoretisch. In september 2025 beboette de Franse toezichthouder op dezelfde dag Google voor 325 miljoen euro en Shein voor 150 miljoen wegens cookiepraktijken. Beide zaken draaiden om mechaniek in plaats van beleidsteksten: cookies geplaatst vóór enige interactie, en weigerknoppen die niet echt weigerden.

De regels zijn ook in beweging. Het Digital Omnibus-voorstel zou toestemming voor randapparatuur in de AVG zelf onderbrengen en browsersignalen bindend maken. We beschreven wat dat zou veranderen in cookietoestemming na de Digital Omnibus.

Bouw de machinerie voor betrokkenenrechten vroeg

De artikelen 15 tot en met 22 geven mensen recht op inzage, rectificatie, wissing, beperking, overdraagbaarheid en bezwaar. Je hebt een maand om te reageren, verlengbaar tot drie in complexe gevallen.

Teams handelen de eerste verzoeken meestal handmatig af, wat werkt tot het moment dat het niet meer werkt. Wat je wilt hebben, ruim voordat het volume komt:

Een resolver die een persoon over systemen heen vindt. Geef een e-mailadres, krijg alles terug: het account, de bestellingen, de supporttickets, het marketingprofiel, het analytics-ID, de logs. Als een mens moet onthouden dat er nog een reviewplatform van derden is met gegevens, vergeet iemand dat uiteindelijk.

Een verwijderpad dat bewaarplichten respecteert. Wissing is niet absoluut. Facturen moeten meestal blijven bestaan om fiscale redenen. Wat je nodig hebt is soft delete met doelgebonden harde verwijdering, zodat je het marketingprofiel kunt weghalen en het boekhoudrecord kunt behouden, en zodat dat record zelf op tijd vervalt.

Een overdraagbare export. Gestructureerd, gangbaar, machineleesbaar. JSON is prima. Een PDF van een gerenderde HTML-pagina niet.

Een bezwaarvlag die het hele systeem leest. Bezwaar tegen profilering moet de profilering echt stoppen, ook in de batchjob die om drie uur 's nachts draait en de vlag niet controleert.

Bewaren is een taak, geen beleidsregel

Opslagbeperking is het beginsel dat het vaakst wordt geschonden door verder goed gebouwde systemen, omdat verwijderen vereist dat iemand een taak schrijft en inplant waar niemand om vraagt.

Geef elke datacategorie een gedefinieerde levensduur en implementeer die vervolgens. Toegangslogs, sessies, verlaten winkelwagens, niet-geverifieerde aanmeldingen, gesloten tickets, oude back-ups en ruwe analyticsdata hebben allemaal een vervaltermijn nodig. Back-ups verdienen bijzondere aandacht: als je herstelproces verwijderde persoonsgegevens weer tot leven wekt, is je wissing incompleet, en het gebruikelijke antwoord is een gedocumenteerde back-uprotatie met maximumleeftijd plus het opnieuw toepassen van verwijderingen na elk herstel.

Doorgiften, subverwerkers en waar je stack echt draait

Doorgiften buiten de EER hebben een juridisch mechanisme nodig, meestal het EU-VS Data Privacy Framework voor gecertificeerde Amerikaanse ontvangers of standaardcontractbepalingen plus een transfer impact assessment elders.

De technische invalshoek is eenvoudiger dan de juridische: weet waar je data fysiek staat. Dat betekent de cloudregio van elke dienst, de locatie van je back-ups, de regio van je beheerde database, de CDN-edgeconfiguratie en, belangrijk, het supportmodel van elke SaaS-tool die je gebruikt. Een leverancier gehost in Frankfurt wiens supportteam productie benadert van buiten de EER is nog steeds een doorgifte.

Wij adviseren doorgaans persoonsgegevens in EU-regio's te houden als er geen sterke reden is om dat niet te doen. Het haalt een hele categorie discussie weg, en het kostenverschil is meestal ruis.

Houd een lijst van subverwerkers bij en houd die actueel. Artikel 28 vereist een schriftelijke overeenkomst met elk van hen, en die lijst is ook wat je klanten in due diligence zullen opvragen.

Beveiliging standaard, uitgedrukt als configuratie

Artikel 32 vraagt om passende technische en organisatorische maatregelen. Dat is bewust vaag, maar de basis voor een website in 2026 is niet onderhandelbaar:

• TLS overal, HSTS aan, geen mixed content.
• Wachtwoorden gehasht met een moderne, geheugenintensieve functie, en meervoudige authenticatie beschikbaar voor accounts met persoonsgegevens.
• Versleuteling in rust voor databases en back-ups.
• Toegang tot persoonsgegevens in productie beperkt op rol en gelogd, met reviews die daadwerkelijk plaatsvinden.
• Pseudonimisering waar mogelijk: het ID hashen in analytics, de koppeltabel apart en met beperkte toegang.
• Een geteste restore, niet alleen een back-up.

Gegevensbescherming door ontwerp en door standaardinstellingen in artikel 25 betekent dat de privacyvriendelijke optie degene is die je krijgt zonder iets te doen. Nieuwsbriefvinkje uit. Profielzichtbaarheid privé. Optionele velden optioneel.

Datalekmelding heeft een runbook nodig

Tweeënzeventig uur van kennisname tot melding bij de toezichthouder is niet lang, zeker niet als het lek op vrijdagavond wordt ontdekt. Het Digital Omnibus-voorstel zou dat naar zesennegentig uur brengen, maar dat is nog geen recht.

Bereid vooraf voor: wie roept een incident uit, wie beoordeelt of persoonsgegevens betrokken zijn, wie benadert de toezichthouder, wat staat er in de melding, en hoe informeer je betrokkenen als het risico hoog is. Schrijf het als runbook met benoemde rollen en oefen het één keer. De eerste keer dat je het gebruikt zou niet de eerste keer moeten zijn dat je het leest.

Het oppervlak van de site zelf

Een deel van de AVG is zichtbaar op de pagina, en het loont die details goed te doen, want dit zijn de dingen die mensen melden.

Je privacyverklaring moet de identiteit en contactgegevens van de verwerkingsverantwoordelijke noemen, de doelen en grondslagen, ontvangers en categorieën ontvangers, doorgiftemechanismen, bewaartermijnen, de volledige lijst rechten inclusief het klachtrecht bij een toezichthouder, en of er geautomatiseerde besluitvorming is. Schrijf in taal die een normaal mens kan volgen. Gelaagde verklaringen, met een korte versie die naar detail linkt, werken beter dan een muur tekst.

Formulieren moeten alleen verzamelen wat nodig is. Elk veld is een rechtvaardiging die je mogelijk moet geven. Zit het marketingtoestemmingsvinkje in dezelfde submit als de bestelling, dan moet het apart uitgevinkt en apart geformuleerd zijn.

Ingesloten content van derden is de stille misser. YouTube in privacyvriendelijke modus, kaarten achter een klik-om-te-laden-placeholder, lettertypen zelf gehost in plaats van van een CDN van derden. Elk van die wijzigingen is klein en haalt een bevinding weg.

Wat we het vaakst mis zien gaan

Na genoeg audits duikt steeds dezelfde korte lijst op:

1. Analytics die laadt vóór toestemming, meestal omdat een tagmanager door marketing is ingericht en nooit door engineering is nagekeken.
2. Weigerknoppen die toch toestemming afvuren door het standaardgedrag van een script van derden.
3. Helemaal geen bewaartaken, op geen enkele tabel.
4. Wissing die back-ups, logs en het CRM mist.
5. Een privacyverklaring die een datastroom beschrijft die achttien maanden geleden veranderde.
6. Subverwerkerslijsten die stoppen bij de drie voor de hand liggende leveranciers.
7. Toestemmingsregistraties zonder de versie van de getoonde tekst.

Geen van deze is een moeilijk probleem. Het is gewoon werk dat niemand heeft toegewezen.

Hulp krijgen

Wil je een tweede paar ogen op een bestaande site, dan doen we technische AVG-audits die een geprioriteerde backlog opleveren in plaats van een rapport: wat te repareren, in welke volgorde, met een schatting per punt. Bouw je iets nieuws, dan is het aanzienlijk goedkoper om datamodel en toestemmingsarchitectuur meteen goed te doen.

We dekken ook het bredere EU-complianceoppervlak, waaronder toegankelijkheid en toetreding tot de Europese markt. Je bereikt ons op office@c9group.dev.

Wij bouwen software. We geven geen juridisch advies, en de uitleg van een specifieke eis hoort bij je juristen. Wat we wel kunnen, is zorgen dat het systeem doet wat je juristen zeggen dat het moet doen.