AVG-verwijderverzoek bij SaaS: actieve data, back-ups en bewijs

Een klant stuurt vrijdagmiddag een verwijderverzoek. Je verwijdert het contact uit je CRM, zet de nieuwsbrief uit en krijgt maandag een keurige bevestiging van je SaaS-leverancier. Drie weken later staat dezelfde persoon nog in een export, een zoekindex en een oude back-up.

Dat is geen zeldzame technische randzaak. Het is het gevolg van een proces dat de zichtbare applicatie verwart met het hele datalandschap. Een goed antwoord op een AVG-verwijderverzoek volgt de data door je eigen systemen, replica’s, synchronisaties en leveranciers heen.

Een AVG-verwijderverzoek bij SaaS is het vinden, beoordelen en wissen van persoonsgegevens van één betrokkene in actieve systemen en kopieën. Als directe overschrijving technisch niet kan, stel je de kopie buiten gebruik. Je houdt alleen vast wat een concrete uitzondering rechtvaardigt, voorkomt dat synchronisaties de data terugbrengen en bewaart bewijs zonder een nieuw dossier vol persoonsgegevens te maken.

Wat heb je nodig voordat je begint?

Maak één eigenaar verantwoordelijk voor het dossier. Dat is meestal de privacycoördinator of functionaris gegevensbescherming. Geef die persoon een technische eigenaar voor de zoekactie en per SaaS een beheerder die de verwijdering kan uitvoeren. Zonder die namen blijft een verzoek hangen tussen klantenservice, IT en de leverancier.

Je hebt vervolgens deze bouwstenen nodig:

• Een intakekanaal. Gebruik een formulier, speciaal e-mailadres of ticketsysteem met ontvangsttijd, verzoeker, identiteitstatus en uiterste antwoorddatum.
• Een actuele bronnenkaart. Noteer per verwerking waar persoonsgegevens staan: CRM, facturatie, e-mailmarketing, helpdesk, chat, agenda, datawarehouse, objectopslag, rapportages, logs, zoekindexen, exports en back-ups. Denk bijvoorbeeld aan HubSpot, Gmail, Google Drive, Slack en Moneybird.
• Een stabiele match-sleutel. E-mail is een goed startpunt, geen volledige sleutel. Neem ook klantnummer, account-ID, telefoonnummer, oude e-mailadressen en eventuele externe ID’s mee.
• Toegang en bevoegdheden. Regel beheerrechten voor de relevante SaaS’en, API-toegang waar die bestaat en een veilige plek voor leverancierstickets. Zet geen volledige persoonsgegevens in een algemeen projectkanaal.
• De verwerkersovereenkomsten. Je moet weten welke leverancier voor jou verwerkt, welke subverwerkers worden ingezet, welke kopieën bestaan en hoe verwijdering en back-ups zijn geregeld.
• Een uitzonderingenregister. Leg vooraf vast wie beslist over wettelijke bewaarplichten, juridische claims, een hold, vrijheid van meningsuiting en andere gronden waarop gegevens gedeeltelijk mogen blijven staan.
• Een afsluitrecord. Bewaar verzoek-ID, scope, acties, uitzonderingen, leveranciersreacties, controles, antwoord en goedkeuring. Bewaar daarin geen ruwe export van de te verwijderen data.

Begroot geen productprijs die je nog niet hebt gecontroleerd. Gebruik voor deze gids een inspanningsband: bestaande licenties en beheeruren voor één of twee bronnen, een halve tot enkele werkdagen voor een leverancierstaak of hersteltest, en meerdere werkdagen voor een centrale workflow. De precieze raming staat verderop met haar aannames.

De AP-uitleg over gegevenswissing beschrijft dat je de identiteit controleert, binnen één maand reageert, back-ups meeneemt en zo specifiek mogelijk uitlegt wat je wel en niet hebt verwijderd. Dat is je minimale werkafspraak, geen optionele verfijning.

Hoe voer je een AVG-verwijderverzoek uit?

Je rondt een AVG-verwijderverzoek controleerbaar af door eerst identiteit en bronkaart vast te leggen, daarna uitzonderingen en suppressie te beslissen, actieve data en leveranciers te behandelen, back-ups buiten gebruik te stellen en pas na menselijke controle te antwoorden. Zo blijft per openstaand gegeven een reden, eigenaar, bewijs en einddatum zichtbaar.

Volg deze acht stappen en noteer na elke stap het resultaat.

Stap 1: registreer het verzoek en start de klok

Maak op het moment van binnenkomst een dossier aan. Noteer datum, tijd, kanaal, de letterlijke vraag in zo weinig mogelijk persoonsgegevens en de persoon die het verzoek behandelt. Label de aanvraag als verwijdering, beperking, bezwaar of uitschrijving. Een afmelding voor marketing is niet automatisch een volledige verwijdering.

Controleer de identiteit proportioneel. Een ingelogd klantportaal kan genoeg zijn. Bij een los e-mailbericht kun je een bevestiging vanaf het bekende account of een beperkte aanvullende vraag gebruiken. Vraag geen paspoortkopie als een lichtere controle volstaat. Als je twijfelt, vraag gericht om extra informatie en leg vast waarom.

De AVG geeft je één maand om actie te nemen of uit te leggen waarom je niet handelt. Bij complexe of talrijke verzoeken kun je met maximaal twee maanden verlengen, maar je meldt die verlenging binnen de eerste maand met reden. De wettelijke termijn en de plicht om ook bij een weigering tijdig te antwoorden bepalen dus meteen je interne deadline. Plan je technische controle niet op dag 29.

Resultaat van deze stap: een verzoek-ID, geverifieerde identiteit of een duidelijk gemarkeerde verificatievraag, plus een datum waarop het antwoord uiterlijk uit moet.

Stap 2: maak een bronkaart en match de betrokkene

Begin met de bronkaart, niet met de delete-knop. Zoek de betrokkene eerst in je eigen register en volg daarna de koppelingen. Noteer per bron de eigenaar, rol, locatie, match-sleutel, bewaartermijn, leverancier, subverwerker, verwijdermethode en status.

Zoek minimaal in:

• CRM-contacten, deals, tickets, notities en bijlagen.
• Facturatie, betaalprovider en orderadministratie.
• E-mailmarketing, formulieren, webinarlijsten en advertentiepubliek.
• Mailboxen, Google Drive, SharePoint, OneDrive, Slack en andere samenwerkruimtes.
• Productdatabase, zoekindex, cache, rapportages, datawarehouse en analysetool.
• Objectopslag, testomgevingen, exports, importmappen, logbestanden en vectoropslag voor zoek- of AI-functies.
• Leveranciers en subverwerkers die vanuit je SaaS of integratie gegevens ontvangen.

Gebruik meerdere zoekwaarden. Een gewijzigd e-mailadres of een contact dat alleen in vrije tekst staat, valt anders buiten de match. Bij samengestelde data helpt een combinatie van klantnummer, oude e-mail en telefoonnummer. Leg in het dossier vast welke varianten je hebt gebruikt, maar kopieer de gevonden persoonsgegevens niet naar elke taak.

De Europese privacytoezichthouders zagen in een gecoördineerde controle, gepubliceerd door de CNIL op 18 februari 2026, blijvende problemen met interne procedures, bewaartermijnen en het verwijderen van persoonsgegevens uit back-ups. Gebruik die bevinding als realitycheck voor je bronkaart. De drie grounding-casussen maken dezelfde keten tastbaar: oude ShipMonk-klantdata die na een eerdere verwijderbevestiging nog aanwezig bleek, het C-Track-incident dat Thomson Reuters pas maanden na ontdekking meldde en Dustin-systemen die na een inbraak offline gingen.

Resultaat van deze stap: per bron een matchstatus: gevonden, niet gevonden, niet toegankelijk, door leverancier te behandelen of nog te beoordelen.

Stap 3: bepaal per record wat je mag en moet wissen

Beoordeel de scope per doel en per veld. Het recht op wissing geldt bijvoorbeeld wanneer gegevens niet meer nodig zijn, toestemming wordt ingetrokken zonder andere grondslag, een geldig bezwaar slaagt of de verwerking onrechtmatig was. Het recht is niet absoluut. Een wettelijke verplichting, een taak van algemeen belang, archivering of onderzoek, vrijheid van meningsuiting en het instellen of verdedigen van een rechtsvordering kunnen een uitzondering vormen.

Een factuur is geen automatische uitzondering voor elk veld. De CNIL noemt het bewaren van een factuur als voorbeeld van een wettelijke verplichting, niet als algemene toestemming om een volledig klantprofiel te laten staan. Voor Nederland vermeldt de actuele overheidsuitleg dat facturen onderdeel zijn van de administratie en doorgaans zeven jaar worden bewaard, met tien jaar voor facturen over onroerende goederen. Diezelfde uitleg zegt ook dat de AVG nog steeds geldt voor persoonsgegevens op de factuur. De Nederlandse factuur- en bewaarplicht is dus een grond om het noodzakelijke factuurrecord te onderzoeken, niet om marketingvelden, telefoonnummers of vrije notities mee te bewaren.

Maak per rechtsgebied een uitzonderingsregel met deze velden:

• Jurisdictie en concrete wettelijke grond. Noteer de wet, het artikel of de bindende regel waarop je je baseert.
• Doel en minimale velden. Beschrijf waarvoor bewaren nodig is en welke velden strikt noodzakelijk zijn. Een veld dat alleen handig is, hoort niet in de uitzondering.
• Eigenaar en toegang. Benoem bijvoorbeeld finance als eigenaar en beperk inzage tot finance, privacy en bevoegde controleurs.
• Einddatum of eindtrigger. Leg een datum vast, of een controleerbare gebeurtenis zoals het verstrijken van de wettelijke termijn, en plan herbeoordeling.
• Status en bewijs. Zet de regel op 'te beoordelen', 'goedgekeurd' of 'vervallen' en koppel het besluit of advies zonder ruwe persoonsgegevens.

Als je geen concrete grond, minimale velden, eigenaar en einddatum per rechtsgebied kunt invullen, zet je het record niet op 'beperkt bewaren' maar op 'te beoordelen'. Laat een jurist of FG beslissen als een juridische claim, strafrechtelijk onderzoek of bijzondere categorie persoonsgegevens meespeelt.

Maak de beslissing zichtbaar in drie statussen:

1. Wissen. Het veld of record heeft geen geldige reden om te blijven.
2. Beperkt bewaren. Alleen het noodzakelijke onderdeel blijft staan, met grond, toegang, eigenaar en einddatum.
3. Niet wissen. De uitzondering is concreet vastgelegd en wordt aan de betrokkene uitgelegd.

Als je gegevens aan andere ontvangers hebt verstrekt, maak je ook voor hen een taak. De AVG verlangt dat je een uitgevoerde wissing of beperking aan ontvangers meedeelt, tenzij dat onmogelijk is of onevenredig veel moeite kost.

Resultaat van deze stap: een veldniveau-besluit dat een uitvoerder kan volgen zonder zelf de juridische afweging te verzinnen.

Stap 4: plaats de suppressieregel vóór je gaat wissen

De gevaarlijkste volgorde is: wissen, synchronisatie laten draaien, en daarna ontdekken dat het contact terug is. Zet daarom eerst een minimale regel in je suppressieledger klaar. Die bevat bijvoorbeeld een interne klant-ID en een HMAC van een genormaliseerd e-mailadres, plus status, doel, eigenaar, toegangsrol, aangemaaktatum en einddatum. Bewaar de sleutel van de HMAC apart in een secret manager en beperk toegang tot de gateway-service en de privacycoördinator.

Een HMAC is geen anonieme technische rest. Omdat de interne ID, de normalisatie en het geheime sleutelbestand de koppeling naar een natuurlijke persoon mogelijk maken, behandel je de HMAC als pseudonieme persoonsgegevens. De CNIL legt uit waarom pseudonimisering persoonsgegevens blijft: gebruik de ledger alleen voor het doel 'heraanmaak voorkomen', geef alleen de noodzakelijke service-accounts toegang, zet de waarde niet in algemene logs of analytics en laat haar vervallen op de vastgelegde einddatum. Een HMAC zonder doel, toegangsbeheer en vervaldatum is geen privacymaatregel maar een nieuw, slecht gedocumenteerd register.

Beschrijf per invoerroute wat native gebeurt en waar je eigen gateway nodig hebt:

• HubSpot UI en import. Na een permanente HubSpot-verwijdering blokkeert de native geanonimiseerde blocklist het opnieuw toevoegen van het primaire of aanvullende e-mailadres via de HubSpot-interface of een import. Dat is een productfunctie, geen controle van jouw eigen suppressieledger.
• HubSpot-formulier. HubSpot kan via een formulier een nieuw contactrecord aanmaken. Gebruik daarom een eigen formulier-endpoint of proxy die de identiteit normaliseert, de ledger raadpleegt en de submission afwijst of naar menselijke beoordeling stuurt vóór je haar naar HubSpot doorzet.
• Verbonden team-inbox. Een contact kan opnieuw worden aangemaakt wanneer het een e-mail stuurt naar een verbonden team-inbox. Laat een eigen mailgateway of relay de afzender controleren vóór doorlevering aan HubSpot. Een persoonlijk verbonden inbox-adres valt niet automatisch onder deze native route.
• API. Een API-request kan een nieuw contact aanmaken. Laat integratietokens alleen via je eigen API-gateway of worker werken, zodat een directe create- of upsert-call de suppressie niet omzeilt. De gateway schrijft een idempotent resultaat met verzoek-ID en status.
• Andere systemen. Laat ook marketingimports, CRM-syncs, datawarehouses en je eigen zoek- of vectorindex de ledger controleren. Als een leverancier geen hook of API biedt, pauzeer je de import of zet je een gecontroleerde handmatige stap in.

Pauzeer waar nodig de betrokken synchronisaties. Gebruik bij API’s een idempotente verwijderactie met een verzoek-ID, zodat een herhaalpoging geen nieuw record of dubbel ticket maakt. Bij een eenmalige export kun je de importmap tijdelijk afsluiten.

Resultaat van deze stap: een suppression-ID met eigenaar, doel, toegangsregels en einddatum, plus een routekaart die vastlegt welke invoer native wordt geblokkeerd en welke via je eigen gateway moet lopen.

Stap 5: wis actieve data, zoeklagen en replica’s

Voer de acties uit van de bronkaart en registreer per actie een tijd, uitvoerder, job-ID en resultaat. Verwijder productiegegevens, bijbehorende bestanden, zoekindexen, caches, rapportagekopieën en testdata. Een dashboard dat nog een naam kan tonen is geen afgeronde wissing.

Let goed op de verschillen tussen SaaS-producten:

• HubSpot. De actuele documentatie, laatst bijgewerkt op 19 augustus 2026, beschrijft 'CRM > Contacts > Actions > Delete > Permanent delete' voor één contact en vereist de bevoegdheid om contacten permanent te verwijderen. De purge kan tot 30 dagen duren, verwijdert het record en koppelingen met eerdere engagementgegevens en gebruikt een geanonimiseerde blocklist. Die blocklist blokkeert UI en import, maar niet de drie heraanmaakroutes uit stap 4: formulier, verbonden team-inbox en API. HubSpot verwijdert blogreacties niet automatisch. De HubSpot-route, purge en native blocklist horen daarom naast je eigen gateway- en controlebewijs in de leverancierstaak.
• Google Workspace. Verwijder niet blind een heel gebruikersaccount om één betrokkene te wissen. De beheerdocumentatie, gecontroleerd op 12 september 2026, meldt dat accountverwijdering gegevens kan overdragen of verwijderen en dat bepaalde data twintig dagen herstelbaar blijft. Shared drives hebben ook een andere eigenaar dan een persoonlijk My Drive-account. Het verschil tussen gebruikersdata, overdracht en het herstelvenster maakt een gerichte zoekactie nodig in Gmail, Google Drive, gedeelde drives en eventuele Vault-regels.
• Slack. Een werkruimtebeleid is geen persoonsgerichte verwijdering. De actuele Slack-documentatie, gecontroleerd op 12 september 2026, zegt dat betaalde werkruimtes standaard data bewaren zolang de werkruimte bestaat. Op het gratis plan zijn keuzes van 90 dagen of één jaar beschikbaar en dagelijkse verwijderingen kunnen na een beleidswijziging volgen. Controleer naast gerichte berichten ook privégesprekken, bestanden, exports en eventuele holds in Slack. De Slack-retentie-instellingen bepalen de technische route, niet automatisch de juridische uitkomst.
• Microsoft 365. Gebruik Microsoft Purview-retentiebeleid en retentielabels voor een geplande levenscyclus. Gebruik een eDiscovery-hold voor een concrete juridische zaak. De Microsoft-documentatie, bijgewerkt op 22 juli 2026, maakt duidelijk dat een hold verwijderen kan verhinderen en dat een eDiscovery-hold voorrang heeft zolang een beheerder hem niet vrijgeeft. Het onderscheid tussen levenscyclusbeleid en juridische hold voorkomt dat je een wettelijke bewaarplicht verwart met een reden om alles permanent vast te houden. Microsoft Purview-retentie hoort als status in je bronkaart.

Controleer na elke actie met een tweede methode. Zoek opnieuw via de beheerconsole en via de API of een export. Een geslaagde gebruikersinterface zonder controle van de onderliggende zoeklaag is een aanname.

Resultaat van deze stap: actieve data en direct gebruikte kopieën zijn gewist, met een per-bron bewijsregel en een expliciete lijst van wat nog openstaat.

Stap 6: stuur de leverancier een afgebakende taak

Een leverancierstaak moet uitvoerbaar zijn zonder heen-en-weer-mail. Geef het verzoek-ID, de rol van de leverancier, de relevante externe ID’s, de gegevenscategorieën, de systemen en subverwerkers die je wilt laten controleren, de gewenste actie en de antwoorddatum. Stuur geen brede vraag als verwijder alles wat je over persoon X hebt.

Gebruik dit direct herbruikbare sjabloon:

LEVERANCIERSTAAK
Verzoek-ID: [DSR-jaar-volgnummer]
Eigenaar: [naam/rol aan jouw kant]
Leverancier en tenant: [naam, regio, tenant-ID]
Scope: [records, velden, bijlagen, replica’s, indexen, exports, back-ups]
Match-sleutels: [externe ID’s; geen ruwe e-mail als dat niet nodig is]
Actie: [wissen / beperken / buiten gebruik stellen / opnieuw wissen bij herstel]
Subverwerkers en ontvangers: [namen en doorzetactie]
Bewijs vereist: [job-ID, tijdstip, telling, zoekmethode, controlepad, screenshot of export zonder inhoud]
Status: [open / bezig / geblokkeerd / voltooid]
Einddatum: [antwoorddeadline; voor back-up ook vervaldatum of trigger]
Escalatie: [contact, maximale reactietijd, volgende stap]
Herstelregel: [isoleren, ledger toepassen, opnieuw zoeken, productie vrijgeven]

Vraag concreet om:

• bevestiging welke tenant, database, objecten en bestanden zijn doorzocht;
• verwijdering uit productie, replica’s, zoekindexen, exports en analysetools;
• de status van back-ups, snapshots en herstelkopieën;
• namen van ontvangers of subverwerkers die dezelfde taak moeten uitvoeren;
• eventuele uitzondering, concrete grond, minimale velden, eigenaar en geplande einddatum;
• een technisch resultaat, zoals job-ID, tijdstip, aantal verwijderde objecten en controlewijze;
• de instructie die bij een herstelactie opnieuw moet worden uitgevoerd.

Artikel 28 AVG verplicht een verwerker om de verwerkingsverantwoordelijke, rekening houdend met de aard van de verwerking, te helpen bij verzoeken van betrokkenen. Gebruik die plicht in je verwerkersovereenkomst en in je operationele contactroute.

Een reactie van de leverancier is geen eindbewijs. De ShipMonk-casus met oude klantdata na een eerdere verwijderbevestiging laat zien waarom je scope, job-ID en controlepad vraagt, niet alleen een losse zin als geregeld.

De officiële C-Track-notificatie vermeldt dat C-Track op 30 juni 2026 onbevoegde activiteit ontdekte en dat een onbevoegde partij in maart bepaalde bestanden verkreeg. De notificatie zelf dateert de publicatie van de website niet. Reuters publiceerde op 2 september 2026 dat een onderdeel van Thomson Reuters het incident rond C-Track meldde. Gebruik die brongetrouwe tijdlijn als contractuele les: zet een meld- en reactietermijn in uren, benoem subverwerkers en vraag om bijgewerkte omvang, ook als de leverancier eerst alleen een voorlopige bevestiging kan geven.

Resultaat van deze stap: een leveranciersticket met eigenaar, deadline, scope, bewijsvereisten, status, einddatum en escalatiepad.

Stap 7: behandel replica’s en back-ups als een eigen uitvoerpad

Maak een harde scheiding tussen een actieve replica en een back-up. Een read replica, failoverdatabase, zoekindex of rapportagedataset die nog operationeel wordt geraadpleegd, behandel je als actieve data. Daar hoort een gerichte verwijderactie bij.

Een back-up is anders wanneer hij niet operationeel wordt gebruikt en alleen voor herstel wordt bewaard. De Nederlandse toezichthouder zegt dat back-ups onder het verwijderrecht vallen. Als overschrijven technisch niet kan, houd je bij welke persoonsgegevens verwijderd hadden moeten worden en voer je de wissing alsnog uit zodra je een back-up terugzet.

Als praktische veiligheidsmaatregel kun je een back-up met de te wissen data buiten gebruik stellen. De ICO werkt dat uit als 'beyond use': niet meer raadplegen, niet voor een nieuw doel gebruiken en alleen laten vervallen volgens een vast retentieschema. Die aanpak voor back-ups die niet meteen overschrijfbaar zijn is bruikbaar als operationeel ontwerp, maar vervangt geen Nederlandse juridische beoordeling.

Leg per back-up vast:

• welk systeem en welke periode de kopie bevat;
• of de kopie onveranderbaar, versleuteld of direct herstelbaar is;
• vanaf welk moment zij niet meer gebruikt mag worden;
• de eerstvolgende vervaldatum volgens het goedgekeurde schema;
• welke suppression-ID een herstelactie tegenhoudt;
• wie controleert dat een herstel in een geïsoleerde omgeving opnieuw wist.

Herstel je ooit een snapshot, doe dat eerst in een afgesloten omgeving. Pas de suppressie- en verwijderledger toe vóór aansluiting op productie. Controleer daarna met dezelfde match-sleutels als bij de intake.

Resultaat van deze stap: een back-upbesluit met status, vervaldatum en herstelprocedure, niet de vage notitie back-up valt buiten scope.

Stap 8: laat een mens vrijgeven en sluit aantoonbaar af

Automatisering mag matches vinden en taken aanmaken. Laat een bevoegde mens de vrijgave doen. Die controleert vier vragen:

1. Is de identiteit voldoende vastgesteld?
2. Is elke bron op de kaart behandeld of met reden opengezet?
3. Is elke uitzondering beperkt tot de noodzakelijke velden en voorzien van grond, eigenaar en einddatum per rechtsgebied?
4. Zijn leveranciers, ontvangers, back-ups, gateways en synchronisaties verwerkt?

Geef de betrokkene daarna een specifiek antwoord. Beschrijf welke categorieën je hebt verwijderd, uit welk type systeem en wanneer. Noem wat je nog niet kon verwijderen, waarom, hoe je het buiten gebruik houdt en wanneer het volgens schema verdwijnt. Bij een weigering vermeld je de reden en de mogelijkheid om een klacht in te dienen of naar de rechter te stappen.

Gebruik dit direct herbruikbare afsluitsjabloon:

AFSLUITRECORD
Verzoek-ID: [DSR-jaar-volgnummer]
Eigenaar: [privacycoördinator/rol]
Scope: [rechtsgebied, bronnen, systemen, categorieën en uitgesloten scope]
Identiteit: [methode en status, geen documentkopie]
Besluit: [wissen / beperkt bewaren / niet wissen]
Uitzonderingen: [grond, minimale velden, eigenaar, toegang, status, einddatum per rechtsgebied]
Suppressie en gateways: [suppression-ID, doel, toegang, status, einddatum, testresultaat]
Leveranciers en ontvangers: [ticket-ID, subverwerker, bewijs, status, einddatum]
Back-ups: [kopie, periode, buiten gebruik, vervaldatum, herstelregel, eigenaar]
Bewijs: [job-ID’s, tijdstippen, tellingen, zoek- en controlemethode, links naar tickets]
Openstaande actie: [actie, eigenaar, status, einddatum of trigger]
Menselijke vrijgave: [naam/rol, datum/tijd, beslissing]
Antwoord betrokkene: [verzenddatum, categorieën, uitzonderingen en uitleg]
Dossierstatus: [open / geblokkeerd / vrijgegeven / gesloten]

Bewaar het record zelf volgens je interne bewaarbeleid. Een auditspoor is geen excuus om oude persoonsgegevens onbeperkt in een ticket te bewaren. Als een veld of leverancierstaak openstaat, blijft het dossier 'geblokkeerd' of 'in behandeling' met een eigenaar en einddatum, niet 'gesloten' omdat de inbox leeg is.

Resultaat van deze stap: een menselijke eindvrijgave, een specifiek antwoord en een afsluitrecord waarmee je per openstaand gegeven de reden, bewijs en einddatum kunt aantonen.

Waar gaat het in de praktijk mis?

Dezelfde fouten keren terug. Zet bij elke fout een eigenaar en een controle vast, anders blijft de waarschuwing theoretisch.

• Alleen op e-mail zoeken. Een oud adres, telefoonnummer of vrije tekst blijft staan. Gebruik een combinatie van stabiele ID’s en varianten, en bewaar in het dossier welke zoekwaarden zijn gebruikt.
• Eerst wissen en daarna synchroniseren. Een nachtelijke import maakt het contact opnieuw aan. Plaats de suppressieregel eerst, pauzeer de sync en test een herstel- of importscenario.
• HubSpot-native blokkade te breed uitleggen. De permanente blocklist dekt UI en import, niet automatisch formulier, verbonden team-inbox of API. Zet die routes achter je gateway en test ze afzonderlijk.
• De suppressie-HMAC als anoniem behandelen. Een HMAC die herleidbaar is met je interne ID of sleutel blijft pseudonieme persoonsgegevens. Beperk toegang, leg doel en vervaldatum vast en gebruik haar niet als analytics-ID.
• De SaaS-console verwarren met de hele SaaS. CRM-data kan terugkomen in formulieren, analytics, exports, logbestanden en een datawarehouse. Laat de bronkaart door de systeembeheerder en data-eigenaar tekenen.
• Een leveranciersmail accepteren als bewijs. Vraag scope, job-ID, tijdstip en behandelde kopieën. Controleer zelf waar dat kan, en leg de beperking vast waar dat niet kan.
• Een factuuruitzondering te breed maken. Een wettelijke grond voor een factuur is geen grond voor elk CRM-veld. Registreer per rechtsgebied de concrete norm, noodzakelijke velden, eigenaar en einddatum.
• Back-ups als algemene uitzondering gebruiken. Een back-up is geen reden om actieve data te laten staan. Markeer de kopie buiten gebruik, laat hem vervallen volgens een vastgesteld schema en verwerk de suppressie opnieuw bij herstel.
• Een juridische hold verwarren met retentie. Een wettelijke bewaartermijn zegt welke minimale gegevens nodig zijn. Een hold voor een claim bevriest een concrete zaak. Beide vragen een afzonderlijke beslissing en einddatum of vrijgave.
• Het afsluitrecord vullen met een volledige export. Daarmee maak je een nieuwe kopie van precies de data die je wilde verwijderen. Gebruik verzoek-ID’s, tellingen, veldnamen, hashwaarden en taakresultaten.
• Automatisch verwijderen zonder menselijke vrijgave. Een verkeerde match kan ook een andere klant, getuige of medecontractant wissen. Laat automatisering voorstellen en uitvoeren binnen afgebakende regels, maar laat uitzonderingen en finale vrijgave door een mens doen.

Een leverancier kan ook tijdelijk onbereikbaar zijn. Het Dustin-incident waarbij systemen na een inbraak offline gingen laat zien waarom een tweede contactroute en een lokale bronkaart nodig zijn voordat je leverancierstaak afhankelijk wordt van zijn portaal.

Welke aanpak past bij jouw SaaS-landschap?

Kies op de vorm van je data, niet op de bekendheid van je tool. Gebruik drie systemen als praktische startgrens voor maatwerk. Kies ook eerder voor een centrale workflow als één van deze signalen optreedt:

• Synchronisaties: twee of meer imports, webhooks of bidirectionele syncs kunnen dezelfde persoon opnieuw aanmaken.
• Verzoekvolume: je behandelt structureel meer dan vijf geverifieerde verzoeken per maand, of je hebt terugkerende pieken waarbij handmatige overdracht fouten veroorzaakt. Dit is een operationele startdrempel, geen wettelijke norm.
• API-dekking: elke kritieke bron heeft bij voorkeur een zoek-, verwijder- en statusroute. Zodra één kritieke bron alleen via handwerk bereikbaar is, maak je daar een expliciete subworkflow voor. Bij minder dan ongeveer 80 procent API-dekking over alle bronnen is maatwerk meestal de eerlijkste keuze.
• Holds: één actieve juridische hold vereist al centrale status en menselijke vrijgave, ook met maar één of twee SaaS’en.
• Back-ups: één onveranderbare of niet direct overschrijfbare back-up vraagt een eigen vervaldatum en herstelregel. Als zulke kopieën of hersteltests terugkeren, hoort de ledger in een workflow thuis.

Handmatige procedure met checklist past bij één of twee SaaS’en, weinig verzoeken, geen terugkerende sync-keten, voldoende beheerrechten en een back-upbeleid dat je per verzoek kunt volgen. Plan een tweede paar ogen en een vaste controle van de bronkaart.

Kant-en-klaar per SaaS past als de leverancier een volwassen verwijderfunctie en controleerbare status heeft, de keten uit één of twee bronnen bestaat, kritieke routes API-dekking hebben en er geen actieve hold of onduidelijke back-up is. Een native productfunctie versnelt het werk per tool, niet automatisch het bewijs over de hele keten.

Maatwerk workflow past bij drie of meer systemen, of eerder bij twee of meer synchronisaties, structureel meer dan vijf verzoeken per maand, minder dan ongeveer 80 procent API-dekking, een actieve hold, een terugkerende back-upuitzondering of meerdere rechtsgebieden. De workflow maakt één bronkaart, schrijft suppressieregels, routeert formulier-, inbox- en API-ingang, maakt leverancierstaken, wacht op bewijs en blokkeert menselijke vrijgave tot alle verplichte stappen klaar zijn.

Automatiseer niet de juridische beslissing omdat de technische route beschikbaar is. Automatiseer bronmatching, taakverdeling, herinneringen, statuscontroles en bewijsverzameling. Houd de keuze tussen wissen, beperkt bewaren en niet wissen bij de verantwoordelijke mens.

De tabel hieronder vergelijkt de routes met expliciete inspanningsbanden. Het zijn geen leveranciersprijzen. Aannames bij elke band: één betrokkene, bestaande beheerrechten, één organisatie en geen juridische adviesuren. Een halve dag is vier uur, een werkdag acht uur. Voeg bij een extra bron zonder API minimaal een halve dag controle toe. De wachttijd van een leverancier staat los van je eigen werkuren.

Welke kopie behandel je hoe?

• Dit zijn werkinschattingen voor planning, geen marktprijzen. De band veronderstelt bestaande accounts, documentatie en bevoegdheden; juridische beoordeling, licentie-upgrades, migraties en lange leverancierswachttijd vallen erbuiten. Productdetails in de tabel zijn gecontroleerd op 12 september 2026, behalve waar de HubSpot-documentatiedatum apart is genoemd.

Uitgewerkt voorbeeld: één verzoek door vijf SaaS-lagen

Stel: een installatiebedrijf ontvangt op 12 september 2026 om 09.01 uur een verzoek van een voormalige lead. De medewerker logt in via het klantportaal, waardoor de identiteit voldoende vaststaat. De interne antwoorddatum wordt 12 oktober 2026. De organisatie gebruikt HubSpot voor CRM en marketing, Google Workspace voor mail en bestanden, Slack voor interne samenwerking, Moneybird voor facturatie en een kleine eigen zoekindex voor servicekennis.

1. Intake en bronkaart

De behandelaar maakt verzoek 'DSR-2026-0912-014' aan. De match levert HubSpot-contact-ID '84721', een oud e-mailadres, twee formulieren en drie marketingmails op. In Gmail staan elf berichten en in Drive twee offertes. In Slack staan veertien berichten waarin het telefoonnummer wordt genoemd. In Moneybird staat factuur '2025-0142' met naam en factuuradres. De eigen zoekindex bevat één geïndexeerde offerte.

De bronkaart noemt per item de actie. HubSpot-contact, formulieren en marketingactiviteit worden gewist. Gmail, Drive, Slack en de eigen index worden gericht opgeschoond. Het factuurrecord krijgt pas een uitzondering nadat de eigenaar de concrete rechtsgrond voor deze Nederlandse administratie heeft ingevuld. Het feit dat een record in Moneybird staat, is op zichzelf niet genoeg.

Voor dit voorbeeld legt finance de uitzonderingsregel vast als: jurisdictie NL; concrete grond 'bewaarplicht van het factuurrecord voor de administratie'; minimale scope 'alleen de factuurvelden die voor deze wettelijke administratie nodig zijn'; eigenaar finance; toegang finance en privacy; einddatum 31 december 2032 als het interne schema de gewone zevenjarige factuurtermijn voor deze factuur toepast. De installatie is in dit voorbeeld geen factuur over onroerende goederen. Bij een andere rechtsgrond, factuursoort of jurisdictie moet de regel opnieuw worden ingevuld. Marketingnotities, telefoonnummer en het CRM-profiel vallen er niet automatisch onder.

2. Beslissing en suppressie

De eigenaar noteert: geen juridische claim, geen hold, wel de hierboven beschreven beperkte administratieve uitzondering. De suppressieregel krijgt ID 'sup-84721' en gebruikt de interne klant-ID plus een HMAC van het genormaliseerde e-mailadres. Die HMAC wordt behandeld als pseudonieme persoonsgegevens: doel 'heraanmaak voorkomen', toegang alleen voor de gateway-service en privacycoördinator, geen analyticsgebruik en een voorbeeld-einddatum van 12 maart 2027 volgens het interne suppressiebeleid. Die zes maanden zijn een beleidskeuze in dit voorbeeld, geen wettelijke standaard.

De eigen gateway voor marketingimports en de eigen index controleert de ledger. Het HubSpot-formulier loopt via een eigen endpoint vóór doorlevering. Het API-token is alleen beschikbaar in de gateway-worker. E-mail naar de verbonden team-inbox gaat via een relay die de afzender controleert. De native HubSpot-blocklist dekt in dit scenario alleen UI en import na permanente verwijdering; de gateway is nodig voor formulier, team-inbox en API. De behandelaar pauzeert de nachtelijke CRM-export tot alle taken klaar zijn.

3. Uitvoering per bron

In HubSpot voert een bevoegde beheerder Permanent delete uit op contact '84721' en bewaart het bevestigings-ID. Omdat de purge volgens de actuele documentatie tot 30 dagen kan duren, blijft die taak open tot de definitieve status binnen is. De beheerder controleert apart of de twee formulieren en blogreacties geen achtergebleven objecten vormen. De gatewaytest legt voor formulier, team-inbox en API vast: request, ledger-uitslag, geblokkeerd of doorgelaten, en tijdstip.

In Google Workspace verwijdert de systeembeheerder de elf Gmail-berichten, de twee Drive-offertes en de kopie in de gedeelde map, zonder het Workspace-account van een medewerker te verwijderen. In Slack worden de veertien berichten en gekoppelde bestanden behandeld binnen de rechten en retentie-instellingen van de werkruimte. De eigen zoekindex wordt opnieuw opgebouwd nadat de offerte is verwijderd.

De leverancier van de back-up bevestigt dat de dagelijkse snapshot van 12 september de oude gegevens nog bevat. Die snapshot wordt gemarkeerd als buiten gebruik voor dit dossier. De vervaldatum uit het goedgekeurde schema wordt in het leveranciersticket gezet. De restore-instructie zegt dat de suppression-ID vóór een herstel naar productie moet worden toegepast. Elke actie krijgt een bewijsregel met status, eigenaar, tijdstip en controlepad.

4. Menselijke vrijgave en antwoord

Op 18 september controleert de privacycoördinator de bronkaart. Alle actieve bronnen hebben een actie en controle. De factuur blijft alleen met de door finance aangewezen noodzakelijke factuurvelden staan, met de Nederlandse grond, eigenaar en einddatum in het uitzonderingenregister. Marketingvelden, vrije notities, e-mails, bestanden, Slack-berichten en de zoekindex zijn verwijderd. De HubSpot-purge blijft als leverancierstaak zichtbaar zolang de definitieve status nog niet binnen is.

Het antwoord aan de voormalige lead zegt daarom niet dat elk spoor op dezelfde seconde uit iedere back-up is verdwenen. Het vermeldt welke systemen en categorieën zijn gewist, welke minimale factuurvelden nog blijven wegens de concreet vastgelegde Nederlandse bewaarplicht, dat de snapshot buiten gebruik is geplaatst en wanneer die volgens schema vervalt. De brief noemt ook dat de gegevens aan de betrokken verwerker zijn doorgegeven voor dezelfde verwijderactie.

De eindbeoordelaar sluit het dossier pas wanneer de HubSpot-status binnen is, de gatewaytests voor formulier, team-inbox en API zijn opgeslagen, de restore-instructie getest is en de factuurexceptie een eigenaar en einddatum heeft. Het afsluitrecord bevat tellingen, ID’s, tijdstippen en taakresultaten, geen elf e-mails of een kopie van de offerte.

Een leverancier kan je proces versnellen, maar hij kan de verantwoordelijkheid voor je bronkaart en antwoord niet overnemen. Het doel is niet een indrukwekkende lege database. Het doel is dat je voor elk overgebleven gegeven kunt uitleggen waarom het er staat, wie dat heeft gecontroleerd, welk bewijs erbij hoort en wanneer de reden eindigt.