De negen datasoorten en hun standaardtermijnen
| Datasoort | Standaard | Waarom zo lang |
|---|---|---|
| events | 395 dagen | dertien maanden maken een jaar-op-jaarvergelijking mogelijk met een maand overlap |
| click_ids | 90 dagen | het langste attributievenster dat gangbaar is |
| consent_snapshots | 1.095 dagen | bewijs van rechtmatige verwerking gedurende de verjaringstermijn die de meeste beheerders hanteren |
| delivery_attempts | 90 dagen | genoeg om geschillen met platformen te onderzoeken en maandelijks af te stemmen |
| audit_log | 730 dagen | configuratie- en toegangshistorie voor twee jaarlijkse reviewcycli |
| chat_transcripts | 30 dagen | gesprekken met de AI-assistent zijn operationeel, geen dossiers |
| raw_archive | 14 dagen | replay-buffer voor incidenten; bevat onverwerkte payloads |
| dsar_records | 1.095 dagen | toont aan dat verzoeken zijn afgehandeld |
| ip_hashes | 30 dagen | alleen voor misbruikdetectie; de salt roteert, dus oudere hashes zijn sowieso onbruikbaar |
Elke termijn is een standaard, geen aanbeveling voor elk bedrijf. Een webwinkel met een retourtermijn van 14 dagen kan afleverpogingen inkorten tot 30 dagen; een B2B-bedrijf met salescycli van 9 maanden kan click-ID's tot die lengte verlengen als de vensters van zijn advertentieplatformen werkelijk zo ver reiken. Een termijn verlengen tot voorbij de standaard is een beslissing die je vastlegt in je register van verwerkingsactiviteiten; de wijziging zelf wordt naar het auditlog geschreven.
Reikwijdte en voorrang
Bewaartermijnen worden per organisatie ingesteld en kunnen voor events en click-ID's per site worden overschreven; afleverpogingen, auditlog en chattranscripten gelden organisatiebreed. De effectieve termijn is de site-overschrijving als die bestaat, anders de organisatiewaarde, anders de standaard. Inkorten geldt vanaf de volgende dagelijkse run; verlengen geldt alleen voor records die nog niet zijn verlopen — er is geen wederopstanding.
Handhaving
- Een retentiejob draait eenmaal per dag. Voor events past hij de effectieve termijn per site toe en verwijdert hij oudere rijen; de eventstore is per maand gepartitioneerd, dus het verlopen is meestal een partition drop in plaats van het verwijderen van losse rijen.
- Na het click-ID-venster worden click-ID's en platform-ID's verwijderd uit events die verder bewaard blijven, zodat een eventhistorie van dertien maanden niet dertien maanden aan attributie-identifiers meedraagt.
- Afleverpogingen, auditlog en chattranscripten worden per organisatie verwijderd met de termijn van die organisatie; dedup-sleutels, nonces en attributie-touchpoints verlopen volgens hun eigen schema.
- Elke run logt het aantal verwijderde rijen per datasoort; het workerlog is het bewijs dat het verlopen is uitgevoerd.
- Back-ups volgen dezelfde termijnen plus de back-upcyclus; de beveiligingspagina vermeldt de bewaartermijn van back-ups, zodat de totale levensduur bekend is.
Wat bewaartermijnen niet zijn
- Geen anonimisering. Aggregaten die uit events zijn berekend (dagelijkse aantallen, health scores, funnelpercentages) worden langer bewaard dan de eventtermijn, omdat ze geen persoonsgegevens bevatten; de beleidspagina benoemt ze expliciet.
- Geen bewaartermijn van het platform. Wat Meta of Google bewaren, volgt hun eigen voorwaarden; de subverwerkerspagina linkt naar de bewaardocumentatie van elk platform.
- Geen vervanging voor toestemming. Een korte bewaartermijn voor data die zonder rechtsgrond is verzameld, maakt het verzamelen niet rechtmatig.
Instellen
- Open Privacy → Bewaartermijnen en toets de standaardtermijnen aan je werkelijke rapportage- en attributiebehoeften.
- Kort alles in wat je niet kunt onderbouwen; verleng alleen met een schriftelijke reden.
- Bevestig de site-overschrijvingen voor sites in andere rechtsgebieden of met andere businessmodellen.
- Controleer de statuspagina na de eerste geplande run; de jobvermeldingen zijn je bewijs.