GDPR-dataretentie: wat bewaren, wanneer verwijderen, en waarom de meeste teams het fout doen

Het retentieprobleem waar niemand voor plant

De AVG geeft je geen spreadsheet met bewaartermijnen. De regel is veel lastiger te implementeren: bewaar data alleen zolang je een geldige reden hebt, en verwijder het wanneer die reden vervalt.

De meeste teams denken hier pas over na wanneer iemand een "verwijder mijn data"-verzoek indient — en dan ontdekken ze dat het e-mailadres van de gebruiker in 10 verschillende tabellen staat, drie externe tools en de backup van gisteren. Er is geen eigenaar voor de beslissing "hoe lang bewaren we dit?" omdat die beslissing nooit expliciet is genomen.

In 2023 kreeg Meta een boete van €1,2 miljard voor het doorsturen van EU-data naar de VS zonder adequate juridische basis. Maar het zijn niet alleen techgiganten. Kleine bedrijven in heel Europa krijgen regelmatig boetes van €5.000–50.000 voor ontbrekend retentiebeleid of het negeren van verwijderverzoeken. De Estse gegevensbeschermingsautoriteit (Andmekaitse Inspektsioon) is ook actief — handhaving is reëel, zelfs voor bedrijven met een handvol medewerkers.

Rechtsgrondslag: de basis van elke retentiebeslissing

Je kunt niet bepalen hoe lang je data bewaart zonder te weten waarom je het überhaupt verzamelde. De AVG definieert zes rechtsgronden voor het verwerken van persoonsgegevens. In de praktijk komen er drie in bijna elk project voor:

• Toestemming — de gebruiker zei ja. Data blijft tot ze nee zeggen.
• Overeenkomst — je hebt de data nodig om een dienst te leveren. Data blijft zolang het contract actief is.
• Gerechtvaardigd belang — je onderbouwt de zakelijke noodzaak zelf en bepaalt de scope en duur.

Hier wordt het lastig: hetzelfde e-mailadres kan onder verschillende rechtsgronden worden verwerkt in verschillende contexten. Je facturatiesysteem bewaart het op basis van "overeenkomst." Je nieuwsbrief-tool op basis van "toestemming." Je analytics verwijst ernaar op basis van "gerechtvaardigd belang." Elke context heeft een eigen bewaartermijn — voor hetzelfde veld, in dezelfde database, van dezelfde persoon.

Daarom kan retentie geen enkele regel zijn die globaal wordt toegepast. Het is een beslisboom die begint bij waarom je elk stuk data hebt.

Datakaart: voordat je beleid schrijft

Je kunt geen retentiebeleid bouwen zonder te weten wat je opslaat en waar. Een datakaart hoeft geen document van 40 pagina's te zijn — maar moet wel vier vragen beantwoorden voor elk type persoonsgegevens dat je bewaart:

• Welke persoonsgegevens zijn het? (naam, e-mail, IP-adres, aankoopgeschiedenis…)
• Waar staan ze? (welke databasetabel, welke externe dienst, welke backup)
• Op welke rechtsgrondslag verwerk je ze?
• Wie is eigenaar van de beslissing over de levenscyclus?

Die laatste vraag is belangrijker dan mensen verwachten. Als niemand eigenaar is van de retentiebeslissing, neemt niemand die — en data hoopt zich voor altijd op. Dit is geen technische oefening. Het is een gesprek tussen developers, producteigenaren en degene die compliance bewaakt. Het resultaat is een gedeeld begrip, geen configuratiebestand.

Een bewaartermijn bepalen voor elk datatype

De logica is altijd dezelfde: waarom heb je het verzameld → wanneer is dat doel bereikt → is er een externe verplichting om het langer te bewaren?

Een paar concrete voorbeelden:

• Contactformulier-inzending — doel is bereikt wanneer je hebt geantwoord (of besloten dat niet te doen). Een redelijke bewaartermijn: 6 maanden, daarna verwijderen.
• Transactierecord — belastingwetgeving vereist het bewaren van financiële gegevens. In Estland is dat 7 jaar op basis van de Boekhoudwet. Maar "financieel record" betekent de transactiedatum, het bedrag en de belastingcategorie — niet per se het volledige profiel, het verzendadres of telefoonnummer van de koper.
• Marketingvoorkeuren — bewaren tot de gebruiker toestemming intrekt. Geen toestemming = geen data.
• Serverlogbestanden — gerechtvaardigd belang bij beveiligingsmonitoring. 90 dagen is gangbaar; 12 maanden is de bovengrens die de meeste toezichthouders redelijk achten zonder specifieke onderbouwing.

Een belangrijk detail: verschillende velden binnen hetzelfde databaserecord kunnen verschillende bewaartermijnen hebben. Een bestelrecord bewaart mogelijk het bedrag en de datum 7 jaar (belastingverplichting), terwijl de klantnaam en het adres na 2 jaar worden geanonimiseerd (niet langer nodig voor het oorspronkelijke doel). Een hele tabel als één retentie-eenheid behandelen is de meest voorkomende shortcut — en de meest voorkomende fout.

Drie soorten "verwijdering" — en waarom soft delete er niet bij hoort

Wanneer iemand zegt "we hebben de gebruiker verwijderd," bedoelen ze meestal één van drie dingen. Slechts twee tellen mee onder de AVG:

• Soft delete — een vlag gaat van 0 naar 1. De data is verborgen in de interface maar staat nog in de database, verschijnt nog in backups, en is zichtbaar bij directe queries. Juridisch is dit geen verwijdering. Het is verhulling. De AVG kijkt niet naar je UI — het kijkt of de data bestaat.
• Anonimisering — persoonlijke identificatoren worden onomkeerbaar verwijderd. Het record bestaat nog, maar kan niet meer aan een persoon worden gekoppeld. Juridisch zijn geanonimiseerde gegevens geen persoonsgegevens meer. De AVG is er niet meer op van toepassing.
• Harde verwijdering — de data is fysiek verwijderd. Weg uit de database, weg uit indexen, uiteindelijk weg uit backups wanneer die roteren.

De meest voorkomende illusie: "we doen soft-delete bij gebruikers, dus we zijn compliant." Nee. Als de data herstelbaar is, is het niet verwijderd. Als je beheerpaneel een "Herstellen"-knop heeft voor verwijderde gebruikers, heb je niets verwijderd.

Pseudonimisering is geen anonimisering

Een e-mailadres vervangen door een hash voelt als anonimisering. Dat is het niet. De AVG trekt een scherpe lijn tussen beide:

• Pseudonimisering — persoonsgegevens worden zo getransformeerd dat ze niet aan een persoon kunnen worden toegeschreven zonder aanvullende informatie (zoals een sleutel of opzoektabel). De data geldt nog steeds als persoonsgegevens onder de AVG omdat heridentificatie mogelijk is.
• Anonimisering — heridentificatie is onmogelijk, zelfs in combinatie met andere beschikbare data. Pas dan stopt de AVG met van toepassing te zijn.

De toets is niet of jij iemand kunt heridentificeren — maar of iemand dat redelijkerwijs zou kunnen. Een e-mail wissen maar een zeldzame voornaam + stad + geboortedatum in hetzelfde record laten? Die combinatie kan een persoon identificeren. De AVG doorziet het.

Echte anonimisering vereist controle van de volledige combinatie van resterende velden, niet alleen het één voor één blanco maken van voor de hand liggende identificatoren.

Anonimiseren of verwijderen: wanneer wat

De beslissing is eenvoudig zodra je de juiste vraag stelt: heb je het record nog ergens voor nodig nadat de persoon weg is?

• Anonimiseren wanneer de data dient voor analytics, rapportage of auditing. Een bestelrecord (datum, bedrag, productcategorie) zonder persoonlijke identificatoren is nog steeds waardevol voor business intelligence.
• Verwijderen wanneer de data uitsluitend bestaat om een persoon te identificeren of te contacteren. Namen, e-mails, telefoonnummers, fysieke adressen — als er geen zakelijk doel is zonder de identiteit, verwijder het volledig.

Een valkuil om te vermijden: gedeeltelijke anonimisering zonder de resterende combinatie te controleren. Je verwijdert de naam en het e-mailadres van een bestelling, maar laat het bezorgadres, de besteldatum en een nicheproduct staan. In een kleine stad kan die combinatie naar precies één persoon wijzen. Anonimisering is alleen echt wanneer de volledige resterende dataset de heridentificatietoets doorstaat.

Intrekking toestemming vs. recht op verwijdering: verschillende rechten, verschillende reacties

Deze twee verzoeken komen in dezelfde inbox maar activeren verschillende processen:

Intrekking toestemming ("ik wil geen marketing-e-mails meer") stopt verwerking op basis van toestemming — maar data verzameld op een andere rechtsgrondslag blijft. Als je datzelfde e-mailadres ook bewaart op basis van een overeenkomst (omdat de gebruiker een actieve klant is), verwijder je het niet. Je stopt met nieuwsbrieven versturen, maar het e-mailadres blijft in je facturatiesysteem.

Recht op verwijdering ("verwijder alles wat je over mij hebt") is breder — maar niet absoluut. Je kunt weigeren als je een wettelijke bewaarplicht hebt (belastinggegevens bijvoorbeeld) of als een gerechtvaardigd belang zwaarder weegt. Je moet echter binnen 30 dagen reageren, uitleggen wat je hebt gedaan of waarom je hebt geweigerd, en de beslissing documenteren.

Deze verzoeken als hetzelfde behandelen is een veelgemaakte fout. Een intrekking van toestemming vereist geen volledige datapurge. Een verwijderverzoek overschrijft niet automatisch wettelijke bewaartermijnen. Elk verzoek heeft een eigen workflow en een eigen antwoordsjabloon nodig.

De praktische conclusie

Retentie is geen enkel beleidsdocument dat je één keer schrijft en vergeet. Het is een reeks beslissingen — één per datatype, één per rechtsgrondslag, één per opslaglocatie — die expliciet genomen, helder gedocumenteerd en automatisch afgedwongen moeten worden.

Begin met de datakaart. Definieer bewaartermijnen op basis van rechtsgrondslag en doel. Kies anonimisering of verwijdering per datatype. Bouw de workflow voor intrekking van toestemming en verwijderverzoeken apart. En zorg dat iemand eigenaar is van elke beslissing — niet "het team," niet "juridisch," maar een specifiek persoon die kan uitleggen waarom deze data zo lang wordt bewaard.

In het volgende artikel vertalen we deze principes naar code: hoe je retentiebeleid implementeert in Laravel met geplande opschoning, cascade-regels voor gerelateerde records en een workflow voor het recht op verwijdering die daadwerkelijk werkt in productie.