IT

Cloud-data echt verwijderen: hoe weet je het zeker?

16 mei 2026 · 8 min lezen · DeSnipperaar

De delete-knop in de cloud voelt definitief. Bestand weg uit interface, prullenbak geleegd, klaar. Maar achter die ene actie liggen verschillende systemen die elk hun eigen tempo hanteren in het daadwerkelijk verwijderen van data. Replicatie tussen datacenters, dagelijkse back-ups, logging-systemen, monitoring-snapshots: allemaal kopieen die niet automatisch meegaan in de delete. Voor verantwoorde organisaties is dit een belangrijk thema bij retention-beleid en bij het uitfaseren van een cloud-leverancier.

Drie lagen waarop een ‘delete' werkt

Laag 1: De applicatie

Wat je ziet als gebruiker. Een document verdwijnt uit Drive, een record wordt ‘archived' in een CRM, een mailbox wordt geleegd. Op deze laag is het vrijwel altijd zo dat de data alleen onzichtbaar wordt gemaakt; in de onderliggende database bestaat het record nog wel, vaak met een ‘deleted' flag.

Laag 2: De database

Records met deleted-flag worden periodiek echt verwijderd, soms na 30 dagen, soms na 90, soms pas bij een handmatige opschoonactie. Databases gebruiken vaak ‘soft delete' om te kunnen herstellen na fouten en om audit-logs intact te houden.

Laag 3: De fysieke opslag

Hier zit de echt onleesbare vernietiging. Op SSDs in een datacenter wordt de fysieke storage pas overschreven als nieuwe data ervoor in de plaats komt; tot dat moment ligt de oude data in cellen die de leverancier niet meer als bezet beschouwt maar fysiek nog leesbaar zijn. Hoe het verschil tussen wissen en vernietigen hier landt, lees je in dat artikel; voor cloud zit er bovendien een vierde laag bij: replicatie.

Wat replicatie doet

Cloudleveranciers repliceren data automatisch over meerdere datacenters voor betrouwbaarheid. Dat betekent: een delete moet zich verspreiden over alle replica's. AWS, GCP en Azure documenteren dat dit binnen seconden tot minuten gebeurt voor live data. Maar:

• Back-ups hebben hun eigen retentie en vallen vaak buiten de delete-keten.
• Snapshots die om operationele redenen worden gemaakt blijven behouden volgens een aparte cyclus.
• Logs en monitoring bevatten vaak data fragmenten in URL-paden, payloads of error-traces.
• Cache-lagen kunnen kortdurend kopieen vasthouden, soms in CDN-randpunten.

Cryptografische erasure: een elegante shortcut

De moderne aanpak in enterprise-cloud heet cryptographic erasure. Data wordt opgeslagen versleuteld; bij verwijdering wordt de sleutel vernietigd in plaats van de data zelf. Zonder sleutel is de versleutelde data effectief willekeurig, wat NIST 800-88 als een vorm van Purge accepteert.

Voordeel: de delete is instantaan, ongeacht hoeveel replica's er bestaan, want de sleutel is één object. Nadeel: je vertrouwt erop dat de leverancier de sleutel echt vernietigt en geen kopie bewaart in een sleutelmanagement-archief. Voor de meeste klanten en use-cases is die vertrouwensrelatie acceptabel; voor zwaar gereguleerde sectoren is het reden om aanvullende waarborgen te eisen. Lees meer over de NIST en DIN-standaarden.

Wat retentiebeleid moet vastleggen

1. Welke data hoort bij welke bewaartermijn. Zie de AVG-bewaartermijnen cheatsheet voor de wettelijke termijnen.
2. Hoe lang back-ups bestaan en wat dat betekent voor ‘recht op vergetelheid' verzoeken.
3. Wat in logs en audit-trails belandt en hoe lang die bewaard blijven.
4. Hoe je leverancier omgaat met deletes: synchroon delete in alle datacenters, of asynchroon? Krijg je daar bewijs van?
5. Cryptografische erasure-mogelijkheden per service.

Wat je leverancier behoort te leveren

• Een data-deletion-attestation op verzoek, met datum en omvang.
• NIST 800-88-conform proces voor de fysieke laag (drive replacement, secure-erase).
• Documentatie van back-up-cyclus en hoe deletes daarin propageren.
• Een SLA op delete-tijd, niet alleen op replicatie.
• Standaard contractuele clausules onder AVG bij grensoverschrijdende cloud.

Een delete-knop is een instructie, geen vernietiging. Vraag je leverancier expliciet om bewijs dat de instructie ook wordt uitgevoerd op fysiek niveau.

Wanneer cloud niet voldoet

Voor sommige data-categorieen is cloud-vernietiging niet genoeg. Patientendossiers, geheimhouderdomeinen of staatsgeheim moeten op dragers liggen waarvan je de fysieke vernietiging kunt bewijzen. Cryptografische erasure is dan onvoldoende; je wilt zien dat de schijf zelf is geshredderd. Voor on-premises hardware aan einde levensduur is dat de standaardroute, lees over hoe een harde schijf wordt geshredderd.

Praktisch stappenplan voor een uitfasering

1. Inventariseer welke data in de cloud staat en welke bewaartermijnen erop van toepassing zijn.
2. Bepaal of cryptografische erasure voldoet voor jouw classificatie, of dat fysieke vernietiging nodig is.
3. Vraag van je leverancier een data-deletion-attestation aan met datum en scope.
4. Voor data buiten cloud (export-files, eigen back-ups op USB of HDD): vernietig fysiek.
5. Bewaar attestation en certificaat in je verwerkingsregister.

---

Werkt je organisatie aan een cloud-uitfasering? Mail ons via desnipperaar.nl over fysieke restanten van je on-premise back-ups.