Een beleid voor gegevensbewaring en -verwijdering implementeer je niet met één enkele DELETE-instructie. In een PHP-applicatie kan dezelfde informatie voorkomen in meerdere tabellen, bestanden, caches, logs en externe services. Als het proces alleen de hoofdrij verwijdert, kunnen er actieve kopieën achterblijven; als je verwijdert zonder afhankelijkheden te controleren, kunnen processen stukgaan of kunnen gegevens worden verwijderd die bewaard hadden moeten blijven.
Het praktische doel is om elke regel om te zetten in een workflow die de betrokken gegevens identificeert, de juiste actie uitvoert, uitzonderingen afhandelt en controleerbaar bewijs achterlaat. Het beleid moet worden afgestemd met de verantwoordelijke teams voor product, technologie en data, en worden getoetst aan de verplichtingen die voor de organisatie gelden. Ga niet uit van universele wettelijke bewaartermijnen: die zijn afhankelijk van de context en moeten worden gevalideerd voordat je ze automatiseert.
Begin met categorieën en bewaarteregels
Classificeer informatie op basis van het doel en het gebruik ervan voordat je de verwijdering ontwerpt. Een profiel, een adres dat nodig is voor een lopende transactie, een activiteitenhistorie en een boekhoudkundig register kunnen verschillende regels hebben, ook als ze bij hetzelfde account horen.
Leg voor elke categorie ten minste het volgende vast:
- Doel en verantwoordelijke: waarom de gegevens worden opgeslagen en welk team beslist over het bewaren ervan.
- Gebeurtenis die de regel activeert: bijvoorbeeld het sluiten van een account, het beëindigen van een relatie of een gevalideerd verzoek.
- Termijn en voorwaarde: wanneer de actie wordt beoordeeld of uitgevoerd, met inbegrip van eventuele gerechtvaardigde opschortingen.
- Actie: verwijderen, anonimiseren, beperkt toegankelijk bewaren of doorsturen voor handmatige beoordeling.
- Afhankelijkheden: systemen en processen die moeten zijn afgerond voordat de zaak als afgehandeld kan worden beschouwd.
‘Bewaren’ betekent niet dat je gegevens voor onbepaalde tijd houdt omdat dat handig is. Er moet een reden, een afgebakende reikwijdte en een datum of voorwaarde voor beoordeling zijn. Als een deel van de informatie nodig blijft voor een operationeel doel, scheid die gegevens dan van de rest en beperk wie er toegang toe heeft.
Breng kopieën, verwijzingen en gekoppelde systemen in kaart
De inventarisatie moet het werkelijke traject van de gegevens volgen, niet alleen het databaseschema. Controleer gerelateerde tabellen, JSON-velden, geüploade bestanden, exports, zoekindexen, caches, queues, applicatielogs en geïntegreerde systemen. Neem ook de workflows op die kopieën maken, zoals rapportages, supporttools, analytics of importprocessen.
Noteer voor elke locatie met welke identifier je de gegevens kunt vinden, wie verantwoordelijk is, hoe je ze verwijdert of bijwerkt en wat er gebeurt als het systeem niet beschikbaar is. Controleer relaties via foreign keys en applicatielogica: een relatie in de database kan verwijdering via cascade verhinderen, terwijl een cascadeverwijdering juist meer kan verwijderen dan bedoeld.
Behandel back-ups als een afzonderlijk geval. Mogelijk kun je daarin niet één item verwijderen zonder de volledige back-up terug te zetten. Bepaal hoe de toegang wordt beperkt, hoelang back-ups worden bewaard en welke procedure voorkomt dat verwijderde gegevens na een herstel terugkeren in actieve systemen. Leg de beslissing vast en valideer deze met de verantwoordelijken voor infrastructuur en compliance.
Bepaal wanneer je verwijdert, anonimiseert of bewaart
Fysieke verwijdering verwijdert de gegevens uit een actief systeem, maar is niet altijd de juiste keuze voor elk record. Anonimisering kan geschikt zijn wanneer je statistische informatie wilt bewaren en de mogelijkheid om die effectief aan een persoon te koppelen kunt wegnemen. Een naam vervangen door een stabiele identifier is niet voldoende als een andere tabel de relatie kan reconstrueren.
Beperkte bewaring kan geschikt zijn voor gegevens die nog nodig zijn voor een transactie of een gevalideerde verplichting. Houd die gegevens apart, met specifieke toegangsrechten en een beoordelingsregel. Als niet met zekerheid kan worden bepaald welke actie passend is — bijvoorbeeld vanwege een geschil, een onbekende afhankelijkheid of een inconsistentie in de identiteit — stuur de zaak dan naar een beoordelingsqueue in plaats van te improviseren.
Controleer ook de functionele gevolgen: wat gebeurt er met bestellingen, abonnementen, tickets, API-sleutels of gedeelde documenten wanneer een account verdwijnt? Het gedrag moet expliciet zijn en consistent blijven in de interface, de PHP-logica en de gekoppelde services.
Implementeer een idempotente en observeerbare workflow
Een verwijderingsproces wordt meestal op de achtergrond uitgevoerd, via een queue of een geplande taak. Modelleer de zaak met expliciete statussen, bijvoorbeeld: aangevraagd, gevalideerd, in uitvoering, wacht op externe systemen, voltooid of vereist beoordeling. Definieer toegestane statusovergangen en wie een uitzondering opnieuw mag proberen of afsluiten.
Idempotentie is essentieel: het herhalen van een stap mag geen dubbele effecten of schade veroorzaken. Controleer voordat je een bestand verwijdert of het bestaat; controleer bij het verwerken van een verzoek de huidige status; gebruik bij het aanroepen van een externe service idempotentiemechanismen als die beschikbaar zijn. Als je dit niet kunt garanderen, leg dan het antwoord vast en ontwerp eerst een reconciliatieproces voordat je blind opnieuw probeert.
Een conceptueel PHP-schema kan de orkestratie scheiden van de acties per systeem:
foreach ($steps as $step) {
if ($step->isComplete($requestId)) {
continue;
}
$step->execute($subjectReference);
$step->markComplete($requestId);
}Dit voorbeeld lost geen gedistribueerde transacties op: een database en een externe provider delen niet noodzakelijkerwijs één transactie. Sla de voortgang betrouwbaar op, handel fouten per stap af en maak het mogelijk het werk te hervatten. Als een bewerking halverwege mislukt, moet de status aangeven wat nog ontbreekt; de zaak mag niet als voltooid worden weergegeven.
Leg de uitvoering vast zonder nog een kopie van persoonsgegevens te maken
Traceerbaarheid maakt het mogelijk vast te stellen wie of welk proces heeft gehandeld, wanneer dat gebeurde, op welk verzoek en met welk resultaat. Registreer interne operationele identifiers, statussen, stappen en foutcodes die nuttig zijn voor diagnose. Vermijd het kopiëren van namen, e-mailadressen, documenten, bestandsinhoud of volledige API-payloads naar logs.
Een gepseudonimiseerde gebruikersidentifier kan nog steeds gevoelig zijn als deze iemand opnieuw identificeerbaar maakt. Beperk de toegang tot het log, beperk de bewaartermijn en scheid waar mogelijk operationele informatie van de identiteit. Foutmeldingen moeten helpen het getroffen systeem te vinden zonder persoonsgegevens bloot te leggen in monitoringtools.
Controleer het resultaat en bereid uitzonderingen voor
Tests moeten zowel het normale geval als gedeeltelijke fouten omvatten. Gebruik testgegevens en controleer de locaties uit de inventaris, niet alleen de hoofdtabellen. Neem scenario’s op zoals een relatie die verwijdering verhindert, een ontbrekend bestand, een externe provider die niet beschikbaar is, een nieuwe poging en een uitzondering waarvoor beoordeling nodig is.
Een bruikbare operationele checklist vraagt: zijn alle bekende kopieën gevonden? Is voor elke categorie de beoogde actie uitgevoerd? Zijn er stappen blijven openstaan? Hebben externe systemen het resultaat bevestigd? Bevatten de logs alleen de noodzakelijke informatie? Blijft het proces veilig wanneer het opnieuw wordt uitgevoerd? Voeg periodieke controles toe om nieuwe tabellen, integraties of gegevensroutes te ontdekken die buiten de inventaris zijn gebleven.
Hypothetisch voorbeeld: een account sluiten
Stel dat iemand vraagt om diens account in een PHP-applicatie te sluiten. De workflow valideert het verzoek en raadpleegt de vastgelegde regels voor profielgegevens, bestanden, activiteit en informatie die verband houdt met lopende transacties. Het profiel en de daarvoor in aanmerking komende bestanden worden verwijderd; bepaalde records worden beperkt toegankelijk bewaard als daar een goedgekeurde reden voor is; gegevens die voor analyse bestemd zijn, blijven alleen behouden als ze effectief zijn geanonimiseerd.
De applicatie registreert elke stap zonder het e-mailadres of de inhoud van de bestanden op te nemen. Als een externe service niet reageert, blijft de zaak openstaan en probeert een later proces het opnieuw of vraagt het om tussenkomst, afhankelijk van het beleid. De zaak wordt pas als voltooid gemarkeerd wanneer alle vereiste acties zijn bevestigd of wanneer een formele uitzondering is vastgelegd en goedgekeurd.
Neem voordat je de implementatie start de nog openstaande beslissingen: welke systemen bevatten de gegevens, wie uitzonderingen goedkeurt, wat ‘voltooid’ voor elke bestemming betekent, hoe back-ups worden behandeld en wie fouten beoordeelt. Zo wordt een voornemen om gegevens te verwijderen een onderhoudbaar, controleerbaar en veilig proces.
