Data voor altijd bewaren is een risico. Privacywetgeving eist dat je data verwijdert als je ze niet meer nodig hebt. Dit hoofdstuk behandelt bewaarbeleid (hoe lang je data bewaart) en verwijderprocessen (hoe je verwijderverzoeken van gebruikers en opschoning van systemen afhandelt).
Waarom bewaarbeleid ertoe doet
Wettelijke eis
De AVG (GDPR) en vergelijkbare wetten vragen om bewaarbeleid. Je moet data verwijderen als je het genoemde doel hebt bereikt. "Alles voor de zekerheid altijd bewaren" botst met het principe van dataminimalisatie en kan tot boetes leiden.
Voordeel voor je organisatie
Oudere data is minder nuttig. Een event van 2 jaar geleden beïnvloedt zelden de beslissingen van nu. Oude data verwijderen verlaagt de opslagkosten, maakt back-ups eenvoudiger en verkleint de schade bij een datalek (er ligt minder data bloot).
Verwachtingen van gebruikers
Gebruikers verwachten dat je hun data verwijdert als je ze niet meer nodig hebt. Een to-do-app in de cloud hoort je taken te verwijderen als je je account opheft en ze niet eindeloos te bewaren. Duidelijk verwijderbeleid schept vertrouwen.
Bewaarbeleid vastleggen
Welke data? Hoe lang?
Verschillende soorten data hebben verschillende bewaartermijnen nodig:
Analytics-events: 12 maanden is gebruikelijk. Na een jaar worden oude events zelden nog geanalyseerd. Heb je meer tijd nodig, dan is 24 maanden redelijk. Bewaar niet voor altijd.
Klantaccountgegevens: Bewaar ze zolang het account actief is. Verwijder ze 90 dagen na opheffing van het account (zo is herstel nog mogelijk). Bewaar niet voor onbepaalde tijd.
Supporttickets: Bewaar ze 2 tot 3 jaar (verjaringstermijn voor geschillen). Verwijder ze daarna.
Financiële administratie: Bewaar ze 7 jaar (fiscale en wettelijke eisen). Verwijder ze daarna.
Marketinglijsten: Bewaar ze zolang de klant op de lijst staat. Verwijder gegevens 30 dagen na afmelding.
Langere bewaartermijnen voor specifieke situaties
Sommige data moet je misschien langer bewaren: fraudedetectie (bewaren als audittrail), juridische geschillen (bewaren tot ze zijn opgelost), naleving van regelgeving (verschilt per branche). Dit zijn uitzonderingen. De standaard is: verwijderen zodra het niet meer nuttig is.
Je beleid vastleggen
Schrijf je bewaarbeleid op: welke soorten data, de bewaartermijn per soort en de wettelijke grondslag om te bewaren. Maak het beschikbaar voor gebruikers in je privacybeleid. "We bewaren je gegevens X maanden en verwijderen ze daarna." Transparantie schept vertrouwen.
Geautomatiseerd verwijderen invoeren
Geplande verwijdertaken
Stel geautomatiseerde taken in die volgens een schema draaien (maandelijks, per kwartaal) en data na de bewaartermijn verwijderen. Voorbeeld: een taak die alle analytics-events ouder dan 12 maanden verwijdert. Laat dit automatisch lopen, zodat verwijderen niet met de hand hoeft en niet wordt vergeten.
Verwijderen na een gebeurtenis
Sommige data verwijder je na een gebeurtenis: als een gebruiker zijn account opheft, verwijder je zijn data. Als een gebruiker zich afmeldt, verwijder je zijn e-mailadres. Stel geautomatiseerde workflows in die verwijderen bij bepaalde gebeurtenissen.
Verwijderingen loggen
Log wanneer data wordt verwijderd (welke data, wanneer, waarom). Zo bouw je een audittrail op. Vragen toezichthouders waarom bepaalde data ontbreekt, dan kun je laten zien dat die volgens het beleid is verwijderd en niet is verborgen.
Verwijderverzoeken van gebruikers afhandelen
Het recht om vergeten te worden
De AVG (GDPR) geeft personen het "recht om vergeten te worden". Gebruikers kunnen vragen om verwijdering van hun persoonsgegevens. Je hebt 30 dagen om daaraan te voldoen (met uitzonderingen voor wettelijke verplichtingen). Dat betekent dat je op verzoek gebruikersdata moet kunnen verwijderen.
Verwijderworkflows inrichten
Stap 1: Verzoek ontvangen. De gebruiker dient een verwijderverzoek in via een supportformulier of de accountinstellingen.
Stap 2: Identiteit controleren. Bevestig dat het verzoek van de accounthouder komt (en geen vals verzoek is).
Stap 3: Data opsporen. Zoek alle data van deze gebruiker: account, analytics-events, supporttickets, e-maillijsten, back-ups.
Stap 4: Verwijderen. Haal de data uit live systemen en back-ups. Bevestig de verwijdering schriftelijk aan de gebruiker.
Stap 5: Loggen. Leg de verwijdering vast: wie het verzocht, wanneer en wat er is verwijderd.
Uitzonderingen op verwijderen
Je hoeft niet te verwijderen als je wettelijk verplicht bent de data te bewaren (fiscale gegevens, gerechtelijke bevelen), als je ze nodig hebt voor een genoemd doel dat nog loopt, of als de gebruiker na het verwijderverzoek toestemming heeft gegeven voor verdere verwerking. Maar dit zijn uitzonderingen. De standaard is verwijderen als erom wordt gevraagd.
Uitdagingen bij de invoering
Verspreide data
Gebruikersdata staat vaak verspreid over systemen: de live database, back-ups, diensten van derden (analytics-leveranciers, e-mailproviders) en laptops van medewerkers. Alle data vinden die weg moet, is ingewikkeld. Oplossing: houd een data-inventaris bij. Weet waar gebruikersdata staat. Neem verwijdereisen op in overeenkomsten met leveranciers.
Bewaren van back-ups
Back-ups bevatten gebruikersdata, ook na verwijdering uit live systemen. Hoe lang bewaar je back-ups? Je herstelt waarschijnlijk niet dagelijks uit back-ups van 3 jaar oud, maar juridische bewaarplichten kunnen vragen om ze te houden. Maak het duidelijk: back-ups mogen langer bewaard worden dan live data, maar ook die moet je uiteindelijk verwijderen.
Geanonimiseerde data
Echt geanonimiseerde data valt niet onder het recht op verwijdering (het is geen persoonsgegeven). Maar de meeste "geanonimiseerde" data is eigenlijk geaggregeerd of gepseudonimiseerd (omkeerbaar). Kun je de data weer herleiden, dan zijn het persoonsgegevens en moet je ze op verzoek verwijderen. Weet wat je echt opslaat.
Privacy by design: verwijderen in de architectuur
Ontwerp systemen vanaf het begin met verwijderen in gedachten. Gebruik datastructuren waarmee verwijderen efficiënt gaat. Meng geen soorten data met verschillende bewaartermijnen. Maak het makkelijk om gebruikersdata op te vragen en te verwijderen. Bouw je de verwijdermogelijkheid vooraf in, dan is naleving later eenvoudiger.
Wat is een realistische bewaartermijn voor analytics-data bij verschillende soorten bedrijven?
Blog of contentsite: 12 maanden is genoeg (weinig behoefte aan oude data). SaaS: 24 maanden (trendanalyse is nodig). Webshop: 24 tot 36 maanden (seizoensanalyse, fraudedetectie). Financiële sector of zorg: volg de regelgeving (vaak 6 jaar of meer). Bekijk je rapporten van de laatste 6 maanden: heb je data ouder dan X maanden niet gebruikt, verwijder dan alles daarbuiten. Pas de instellingen van je analytics-platform aan op automatisch verwijderen.
Wat is het exacte proces om binnen de wettelijke termijn op een verwijderverzoek te reageren?
Dag 1: verzoek ontvangen, identiteit controleren, vastleggen in het verzoeksysteem. Dag 2 tot 7: alle data in alle systemen opsporen (database, back-ups, diensten van derden). Dag 8 tot 20: verwijderen en de verwijdering controleren in de logs. Dag 28: de gebruiker een bevestiging sturen met wat er is verwijderd. Leg alles vast. De 30 dagen zijn strikt, dus direct beginnen is cruciaal.
[wemasy-accordion type="primary" wemasy-accordion title="Hoe weet ik of mijn "geanonimiseerde" data echt geanonimiseerd is of nog persoonsgegevens zijn?"]<p>Echte anonimisering: niet te herleiden (alleen geaggregeerde statistieken: "50% van de gebruikers klikte op de knop"). Pseudonimisering: omkeerbaar met een sleutel (gehasht gebruikers-ID, nog steeds persoonsgegevens). Vuistregel: heb je een opzoeksleutel of kun je kruisverwijzen met andere data, dan zijn het persoonsgegevens en moet je ze op verzoek verwijderen. Twijfel je, behandel het dan als persoonsgegevens.</p>[/wemasy-accordion]
Hoe lang moet ik back-ups bewaren, en hoe ga ik om met verwijderverzoeken voor data in back-ups?
Live data: direct verwijderen. Back-ups van 0 tot 30 dagen oud: verwijder uit alle kopieën. Back-ups van 30 tot 90 dagen oud: je mag ze houden als je er niet dagelijks uit herstelt. Back-ups van 90 dagen of ouder: moet je volgens de AVG (GDPR) uiteindelijk verwijderen (geen onbeperkte opslag). Maak een schema voor het verwijderen van back-ups: elk kwartaal controleren en back-ups ouder dan de beleidsdatum verwijderen. Noem de bevestiging van verwijdering in je antwoord aan de gebruiker.
Hoe ziet een stapsgewijze verwijderworkflow eruit voor data die verspreid staat over analytics, e-mail, CRM en leverancierstools?
Stap 1: een data-inventaris laat zien waar gebruikersdata staat (database, GA, e-mailplatform, CRM enzovoort). Stap 2: een geautomatiseerde verwijdertaak pakt de hoofddatabase aan. Stap 3: verwijderen in tools van derden, handmatig of via een API. Stap 4: leverancierscontracten eisen een bevestiging van verwijdering (SLA: 7 dagen). Stap 5: bundel de bevestigingen en stuur ze binnen 30 dagen in totaal naar de gebruiker.
[wemasy-accordion type="primary" wemasy-accordion title="Wat is het verschil tussen "operationele vertraging" en het overschrijden van de termijn van 30 dagen?"]<p>Acceptabele vertraging: data vinden op een onverwachte plek, echte technische problemen (maximaal 8 tot 10 dagen). Onacceptabel: "we komen er nog wel aan toe", wachten op de maandelijkse taak, vertraging bij het herstellen van data van meer dan 15 dagen. De 30 dagen gelden voor je antwoord en uitleg, niet voor de uitvoeringstijd. Kun je niet binnen 30 dagen verwijderen, dan is dat een overtreding. Meld vertragingen direct en leg vast waarom.</p>[/wemasy-accordion]