Privacy, retentie, anonimisering en gegevensbescherming

25.1 Doel van dit hoofdstuk

Dit hoofdstuk legt vast hoe OefenHub persoonsgegevens, privacygevoelige gegevens, historische context, retentie, anonimisering, tijdelijke bestanden, technische snapshots, logging en gegevensbescherming technisch behandelt.

Het hoofdstuk is een technische uitwerking van bestaande functionele en niet-functionele uitgangspunten. Het introduceert geen nieuwe juridische grondslagen en vervangt geen privacybeleid, verwerkersafspraken of formele juridische documentatie.

25.2 Scope

Dit hoofdstuk beschrijft:

• welke soorten gegevens privacy- of gegevensbeschermingsimpact hebben;
• welke module eigenaar is van welke privacygevoelige brondata;
• hoe snapshots, soft links en historische context gebruikt worden;
• hoe accountanonimisering technisch doorwerkt in domeinen;
• hoe retentie per gegevenssoort wordt ingericht;
• hoe tijdelijke exports, PDF-bestanden en technische bestanden worden behandeld;
• welke gegevens nooit in logs, snapshots of exports mogen worden opgeslagen;
• hoe logging, securitylogging, joblogging en ticket snapshots privacyveilig blijven;
• hoe herstel, backup, restore en beheeracties privacygrenzen respecteren.

25.3 Afbakening

Onderwerp	Wel in dit hoofdstuk	Niet in dit hoofdstuk
Privacygedrag	Technische opslag-, retentie-, anonimisering- en loggingregels	Juridische grondslag of privacybeleidtekst
Persoonsgegevens	Technische classificatie en verwerking binnen modules	Juridische DPIA of verwerkersovereenkomst
Anonimisering	Technische account- en snapshotverwerking	Beleidskeuze of verzoekprocedure buiten applicatie
Retentie	Technische bewaartermijnen, cleanup en herstelgedrag	Juridische bewaarplicht buiten bekende requirements
Exports	Tijdelijke PDF/outputbestanden en cleanup	Permanente documentmanagementoplossing
Logging	Veilige technische logging en verboden inhoud	Keuze voor concrete externe loggingprovider

Wanneer tijdens implementatie blijkt dat een privacyregel functioneel of juridisch ontbreekt, wordt die niet stilzwijgend in het Technisch Ontwerp opgelost. Dan moet de impact worden teruggeleid naar het Functioneel Ontwerp, de Software Requirements Specification, database-informatie of beleidsdocumentatie.

25.4 Ontwerpprincipes

Principe	Technische betekenis
Dataminimalisatie	Modules slaan alleen gegevens op die nodig zijn voor de eigen verantwoordelijkheid.
Brondata blijft bij eigenaar	Privacygevoelige brondata wordt niet onnodig gekopieerd naar andere modules.
Soft link over modulegrenzen	Cross-module persoonsverwijzingen worden standaard soft links, eventueel met snapshot.
Historie zonder actuele persoonsgegevens	Historische reconstructie blijft mogelijk zonder verwijzing naar actuele persoonsgegevens van geanonimiseerde accounts.
Geen credentials in OefenHub	Wachtwoorden, tokens, refresh tokens en identity-providerinterne gegevens worden niet opgeslagen in OefenHub.
Tijdelijke output is tijdelijk	PDF-bestanden en exportbestanden zijn output, geen permanente brondata.
Logs zijn technisch, niet inhoudelijk	Logs bevatten correlation en foutcontext, maar geen antwoorden, tokens, wachtwoorden of gevoelige payloads.
Retentie is expliciet	Bewaartermijnen en cleanup worden per gegevenssoort of domein vastgelegd.
Bij twijfel veilig	Bij twijfel wordt minder inhoud opgeslagen, langer bestaande toegang geblokkeerd of meer expliciete beheercontrole vereist.

25.5 Gegevensclassificatie

Klasse	Voorbeelden	Technische regels
Identificerende persoonsgegevens	naam, e-mailadres, profielgegevens, account-id in combinatie met naam	Opslaan bij eigenaar-module; niet onnodig dupliceren; anonimisering verplicht bij accountverwijdering volgens domeinregels.
Relationele persoonsgegevens	ouder-kindrelatie, docent-leerlingrelatie, vriendschap	Brondata bij Relationships; historisch herleidbaar zonder actuele persoonsgegevens.
Onderwijs- en oefengegevens	oefenruns, antwoorden, scores, statistieken, geschiedenis	Brondata bij Practice; toegang strikt via rolcontext; PDF/export alleen tijdelijk.
Communicatie-inhoud	privéberichten, systeemberichten, ticketdiscussies	Retentie, zichtbaarheid en anonimisering per domein; rich text gesanitized.
Technische snapshots	user agent, page URL, IP-adres, rolmomentopname	Alleen zichtbaar voor beheer/support waar nodig; geen vrije verspreiding naar reguliere gebruikers.
Security- en accessgegevens	access denied, verdachte poging, correlation-id	Standaard technische logs; geen gevoelige payloads; retentie en zichtbaarheid beperken.
Tijdelijke bestanden	PDF-export, tijdelijke renderbestanden	Buiten webroot, korte bewaartermijn, cleanup via Scheduling.
Credentials en tokens	wachtwoorden, refresh tokens, identity-provider tokens	Niet opslaan in OefenHub-database, logs, snapshots of exports.

25.6 Module-eigenaarschap van privacygevoelige data

Module	Privacygevoelige data	Eigenaarschap
Identity	interne accountstatus, profielbasis, externe providerreferentie	Eigenaar van interne accountdata en account lifecycle.
Authorization	rollen, roltoekenningen, rolcontext	Eigenaar van autorisatiecontext, niet van profieldata.
Relationships	relaties, uitnodigingen, relatie-events	Eigenaar van relationele koppelingen en relatiehistorie.
Catalog	docentcontent, niveaus, categorieën, oefeningen, history	Eigenaar van catalogusbrondata; persoonlijke verwijzingen soft link/snapshot.
Practice	runs, voortgang, antwoorden, scores, statistieken, gedeelde oefeningen	Eigenaar van oefenbrondata en historische resultaatcontext.
Communication	systeemberichten, privéthreads, readstates, templates	Eigenaar van mailbox- en communicatiedata.
Support	tickets, discussies, technische snapshots, sluitingen, heropeningen	Eigenaar van meldingsdata en supporthistorie.
LiveMonitoring	live-sessieaudit, online-/livesessiecontext	Eigenaar van live-meekijkregistratie, niet van oefenvoortgang.
Admin	beheercontent, beheerlogs, configuratiebeheer	Eigenaar van beheerbare content en beheerhandelingen.
Reporting	tijdelijke exportoutput en exportorkestratie	Geen permanente brondata-eigenaar voor resultaten.
Scheduling	jobmetadata, jobpogingen, foutstatussen	Eigenaar van technische joblifecycle en joblogging.

25.7 Identity en accountanonimisering

Accountanonimisering is een technische lifecycle-operatie op het interne OefenHub-account. De externe identity provider blijft eigenaar van credentials en providerinterne accountgegevens.

25.7.1 Technische doelen

Doel	Regel
Toegang beëindigen	Het interne account wordt niet langer regulier bruikbaar.
Actuele persoonsgegevens verwijderen	Naam-, profiel- en identificeerbare accountvelden worden vervangen of geleegd volgens vaste anonimiseringswaarden.
Historie behouden	Oefenruns, tickets, relatiehistorie, audit en beheercontext blijven reconstructeerbaar waar functioneel vereist.
Relaties beëindigen	Actieve relaties en uitnodigingen worden gedeactiveerd of niet langer accepteerbaar.
Geen credentialmutatie	OefenHub wijzigt geen wachtwoord of providercredential.

25.7.2 Vaste anonimiseringswaarden

Voor accountanonimisering gebruikt OefenHub vaste, herkenbare maar niet tot de oorspronkelijke persoon herleidbare waarden. Deze waarden zijn onderdeel van de technische baseline en moeten consistent worden toegepast in Identity, relevante snapshots, readmodels, exports en zichtbare historische context waar persoonsgegevens worden vervangen.

Veld / gegevenstype	Anonimiseringswaarde of gedrag	Technische regel
FirstName / voornaam	Anoniem	Vaste waarde voor geanonimiseerde accounts.
MiddleName / tussenvoegsel	#	Gereserveerde systeemwaarde voor geanonimiseerde accounts. Een reguliere gebruiker mag # niet als tussenvoegsel invoeren.
LastName / achternaam	Korte, niet-voorspelbare systeemcode	De code is uniek genoeg voor technische onderscheiding, maar mag geen oorspronkelijke persoonsgegevens bevatten.
E-mailadres in OefenHub	anoniem.<code>@verwijderd.acc	<code> gebruikt dezelfde of een technisch gekoppelde niet-voorspelbare systeemcode. De waarde moet voldoen aan unieke constraints en mag niet afleverbaar of herleidbaar zijn.
Weergavenaam	Afgeleid uit de geanonimiseerde naamvelden	Bijvoorbeeld Anoniem # <code> of een UI-specifieke samenstelling op basis van dezelfde velden.
Profielfoto/avatar	Neutrale standaardavatar of geanonimiseerde avatarreferentie	Vrije gebruikersafbeeldingen zijn niet toegestaan; avatarreferentie wordt naar een neutrale keuze gezet waar nodig.
Weergavenaam in snapshots	Vervangen door de geanonimiseerde weergave wanneer het snapshot persoonsgegevens van het geanonimiseerde account bevat	Snapshots blijven historisch bruikbaar, maar tonen geen actuele persoonsgegevens van het verwijderde account.
Actorvelden in historie	Technische id of soft reference mag blijven waar dat nodig is; zichtbare naamvelden worden geanonimiseerd	Historische reconstructie blijft mogelijk zonder actuele persoonsgegevens te tonen.

De systeemcode mag niet voorspelbaar, oplopend of uit oorspronkelijke persoonsgegevens afgeleid zijn. De code wordt technisch gegenereerd als onderdeel van de anonimiseeractie en blijft stabiel voor dezelfde geanonimiseerde accountcontext, zodat historie, exports en beheeranalyse consistent blijven.

25.7.3 Transactionele afbakening accountanonimisering

Accountanonimisering is een kritieke lifecycleworkflow. Identity is eigenaar van het actuele account en voert de deactivering en vervanging van actuele identificeerbare waarden atomair uit. Domeinen blijven eigenaar van hun eigen historische brondata, snapshots en readmodels. Zij verwerken zichtbare persoonsweergave volgens eigen privacyregels via idempotente naverwerking, cache-invalidatie of rebuild.

De workflow mag niet als succesvol worden vrijgegeven wanneer actuele accountvelden nog identificeerbaar zichtbaar blijven. Afgeleide projecties, exports en caches mogen tijdelijk achterlopen zolang reguliere toegang wordt geblokkeerd of geanonimiseerde weergave server-side wordt afgedwongen totdat naverwerking gereed is.

25.8 Snapshotbeleid

Snapshots houden historische context vast zoals die gold op het moment van uitvoeren, delen, communiceren of exporteren. Zij zijn geen tweede bron van waarheid voor actuele gegevens.

Snapshottype	Voorbeelden	Vulmoment	Mutatiegedrag
Runcontextsnapshot	niveau-, categorie-, oefening-, module- en gebruikerscontext bij run	Bij start van run of bij ontstaan bronrecord	Niet stilzwijgend bijwerken.
Gedeelde-oefening-snapshot	oorspronkelijke niveau-/categorie-/oefeningnaam	Bij delen	Niet bijwerken na cataloguswijzigingen.
Ticketsnapshot	user agent, page URL, IP-adres, rolmomentopname	Bij aanmaken melding	Niet herberekenen.
Communicatiesnapshot	afzenderweergave, namens-weergave, onderwerpcontext	Bij berichtcreatie	Niet stilzwijgend aanpassen.
Audit/history-snapshot	actornaam, rolcontext, oude/nieuwe waarde	Bij auditactie	Alleen anonimiseren volgens accountregels.

25.8.1 Snapshot en anonimisering

Situatie	Gedrag
Snapshot bevat geen persoonsgegevens	Snapshot blijft ongewijzigd.
Snapshot bevat naam/e-mailadres van geanonimiseerd account	Snapshot wordt vervangen door vastgelegde anonimiseringswaarde wanneer privacyregels dat vereisen.
Snapshot bevat onderwijscontext zonder persoon	Snapshot blijft historisch leidend.
Snapshot is nodig voor PDF/exportgeschiedenis	Export gebruikt geanonimiseerde snapshotwaarden wanneer account geanonimiseerd is.
Snapshot is technische supportdata	Zichtbaarheid en retentie worden beperkt tot beheer/support.

25.9 Soft links, persoonsgegevens en historische reconstructie

Cross-module verwijzingen naar gebruikers en andere domeinobjecten worden standaard als soft link opgeslagen. Dit voorkomt dat historische records onbedoeld verwijderd of onleesbaar worden door lifecycle-acties in een andere module.

Voorbeeld	Technisch patroon
practice.ExerciseRuns.UserId naar identity.Users	Soft link + relevante snapshots.
support.Tickets.CreatedByUserId naar identity.Users	Soft link + melderweergave/snapshot waar nodig.
communication.PrivateMessages.SenderUserId	Soft link + afzenderweergave/snapshot.
live.LiveViewAudit.ViewerUserId	Soft link + rolcontextsnapshot.
catalog.Levels.OwnerUserId	Soft link of modulekeuze volgens de database-informatie; zichtbare context via querycontract.

Binnen een domein blijven harde FK’s toegestaan waar de records dezelfde lifecycle delen. Over modulegrenzen is een harde FK een expliciete uitzondering.

25.10 Retentie per gegevenssoort

Gegevenssoort	Technisch uitgangspunt	Cleanup/einde lifecycle
Actieve accountdata	Zolang account actief of historisch nodig is	Anonimisering bij accountverwijdering.
Oefenruns en resultaten	Historische onderwijsresultaten blijven raadpleegbaar volgens toegangsregels	Niet hard verwijderen door gebruiker; anonimisering van persoonscontext waar nodig.
Docenttestruns	Tijdelijk, niet in reguliere geschiedenis	Opruiming via Scheduling.
Privéberichten	Functionele bewaartermijn van 3 maanden	Cleanup of participant-zichtbaarheid volgens Communication.
Systeemberichten	Geen generieke korte retentie in eerste baseline	Blijven waar nodig als gebruikersgerichte logging/ingang.
Tickets/meldingen	Historisch raadpleegbaar voor beheer en gebruiker binnen toegangsgrenzen	Geen hard delete als audit/reconstructie nodig is; anonimisering bij accountlifecycle.
Ticket technische snapshots	Beperkt zichtbaar, supportgericht	Retentie nader vastleggen; niet tonen aan reguliere gebruiker.
Beheerhistorie	Auditbaar zolang nodig voor reconstructie	Geen generieke automatische verwijdering zonder expliciet beleid.
LiveViewAudit	Audit van live-meekijksessies	Retentie nader bepalen op basis van privacy en beheerbehoefte.
Technische logs	Operationeel tijdelijk	Retentie via logbeleid en opslagprovider.
Security/access logs	Langer dan reguliere technische logs indien nodig voor analyse	Exacte termijn als open technisch/beleidsbesluit.
Tijdelijke PDF/exportbestanden	Standaard 24 uur	Cleanup via Scheduling; achterstandsignalering vanaf 48 uur.
TickerQ/jobmetadata	Nodig voor uitvoering, retry en analyse	Retentie per jobtype/status.

25.11 Retentie-implementatie

Retentie wordt niet opgelost met willekeurige hard deletes vanuit meerdere modules. Iedere module blijft eigenaar van eigen cleanup- en lifecyclebeleid.

Patroon	Toepassing
Soft delete/deactivatie	Relaties, beheerbare content, zichtbaarheid per participant.
Anonimisering	Accountlifecycle en persoonsgegevens in historische context.
Cleanup job	Testruns, tijdelijke exports, verlopen jobs, tijdelijke bestanden.
Retentie op readmodels	Herbouwbare projecties mogen worden verwijderd en opnieuw opgebouwd.
Geen automatische cleanup	Brondata die nodig is voor audit, onderwijsresultaten of historische reconstructie.

Cleanupjobs worden via Scheduling gepland en gelogd met correlation/job-id. De domeinmodule voert de inhoudelijke cleanup uit via publieke contracten.

25.12 Tijdelijke PDF- en exportbestanden

PDF’s en andere exportbestanden zijn tijdelijke output. De bron blijft de database, inclusief snapshots en module-specifieke renderrepresentaties.

Aspect	Regel
Opslaglocatie	Buiten webroot.
Toegang	Alleen via server-side geautoriseerde downloadresponse.
Bestandsnaam	Geschoond, begrensd en zonder gevoelige extra data.
Retentie	Standaard 24 uur vanaf creatie; langer bewaren vereist expliciete beheerreden.
Herdownload	Opnieuw genereren uit brondata in plaats van permanent bestand bewaren.
Cleanup	Via Scheduling, minimaal iedere 6 uur; fout bij cleanup mag brondata niet verwijderen.
Logging	Geen volledige PDF-inhoud of antwoordpayloads loggen.

25.13 Logging en privacy

Technische logging is bedoeld voor analyse, beheer, foutopsporing en securitymonitoring. Logging mag geen tweede opslagplaats voor functionele inhoud of persoonsgegevens worden.

25.13.1 Verplichte technische context

Veld	Doel
CorrelationId	Volgen van request, workflow, job en domeinacties.
UserId of geanonimiseerde actorreferentie	Herleidbaarheid waar toegestaan.
RoleContext	Analyse van autorisatie- en contextproblemen.
Module	Herleiden naar eigenaar.
Action	Begrijpen welke technische actie werd uitgevoerd.
EntityType en technische id	Alleen waar nodig; geen inhoudelijke payload.
JobId / AttemptNumber	Herleidbaarheid van scheduling.

25.13.2 Verboden loginhoud

Verboden inhoud	Reden
Wachtwoorden	Credentials horen nooit in OefenHub-logs.
Access tokens, refresh tokens, identity tokens	Credential-/sessierisico.
Volledige antwoordpayloads van leerlingen	Onderwijsinhoud en privacygevoelige data.
Volledige privéberichtinhoud	Communicatieprivacy.
Volledige ticketomschrijving in technische logs	Kan persoonsgegevens of gevoelige context bevatten.
PDF-inhoud of gegenereerde documenten	Tijdelijke output, niet logdata.
Ongefilterde request bodies	Kan credentials, persoonsgegevens of vrije tekst bevatten.
Connectionstrings en secrets	Secret disclosure.

25.14 Securitylogging en verdachte toegangspogingen

Er is geen apart OefenHub.Security project in de eerste baseline, maar securitygebeurtenissen worden wel technisch beschreven en gelogd.

Gebeurtenis	Loggingregel
Access denied op objectniveau	Log module, actie, actor, rolcontext, objecttype en redenklasse; geen objectinhoud.
IDOR-poging of ongeldige route-id	Log als securityrelevante toegangspoging zonder gevoelige data te tonen.
Herhaalde autorisatiefouten	Kan gebruikt worden voor technische analyse en rate limiting; standaard geen centrale persistente securityeventtabel.
Verdachte login/provisioningfout	Log correlation en providerreferentie op veilige manier; geen tokens of credentials.
TickerQ-dashboardtoegang geweigerd	Log als interne beheer-/securitygebeurtenis.
Rate-limit overschrijding	Log technische context en actor/ip waar toegestaan.

Securitylogging moet een beperkte zichtbaarheid hebben. Reguliere gebruikers krijgen nooit technische details of objectinhoud terug bij autorisatieafwijzingen.

25.15 Ticket technische snapshots

Ticket snapshots kunnen technische gegevens bevatten die nuttig zijn voor beheer en debugging.

Snapshotveld	Privacyregel
UserAgent	Alleen beheer/support; niet tonen aan reguliere gebruiker.
PageUrl	Geen tokens of gevoelige querystrings opslaan.
IP-adres	Beperkte zichtbaarheid en retentie; niet opnemen in gebruikersweergave.
Rollenmomentopname	Alleen als tekstuele snapshot voor contextanalyse.
Laatst gezien	Alleen wanneer functioneel nodig voor beheeranalyse.

Bij het verzamelen van PageUrl moet de applicatie voorkomen dat gevoelige route- of querydata onnodig wordt opgeslagen.

25.16 Communicatie en privacy

Communicatietype	Privacygedrag
Systeemberichten	Mogen functionele verwijzing bevatten via EntityType + EntityId, maar geen vrije technische URL.
Privéberichten	Participantgebonden zichtbaarheid en readstate; rich text gesanitized; retentie toegepast.
Thread-events	Onderdeel van privéthread, geen los systeembericht.
Systeemnotificaties	Geen mailboxdata; displayregels en browserwaarden mogen geen persoonsgegevens bevatten.
Namens-verzending	Afzenderweergave expliciet en alleen voor dat bericht.

Bij accountanonimisering wordt actuele identiteit verwijderd of vervangen zonder privéthreadinhoud generiek voor andere deelnemers te verwijderen, tenzij retentie of beleid dat vereist.

25.17 Oefengegevens en privacy

Oefengegevens kunnen privacygevoelig zijn omdat zij voortgang, resultaten, niveaucontext en gedrag van kinderen bevatten.

Onderdeel	Regel
ExerciseRun	Alleen raadpleegbaar via rolcontext en objectautorisatie.
ExerciseRunProgress	Bevat antwoorden en timing; niet loggen of breed exposen.
Statistiekvelden	Alleen zichtbaar binnen toegestane context.
Geschiedenis	Niet verwijderen door leerling; blijft historisch met geanonimiseerde accountcontext waar nodig.
Live meekijken	Alleen read-only en auditplichtig; geen beheerder-livefunctie.
PDF-export	Tijdelijke output, server-side geautoriseerd, bron uit historische runcontext.
Gedeelde oefeningen	Snapshotcontext blijft historisch; relatieveranderingen trekken gedeelde ontvangen oefening niet automatisch terug.

25.18 Readmodels, caching en privacy

Readmodels en caches mogen geen ruimere gegevensset tonen dan de onderliggende brondata.

Regel	Toelichting
Contextgebonden cachekeys	Cachekeys bevatten rolcontext, gebruiker, kind/leerling en relevante filters.
Geen autorisatie uit cache	Autorisatie wordt niet vervangen door eerdere cachebeschikbaarheid.
Anonimisering invalidatie	Readmodels/caches met persoonsweergave moeten na anonimisering worden ververst of herbouwd.
Badgewaarden	Afgeleid; geen brondata en geen bewijs van toegang.
Rebuildbaar	Gematerialiseerde readmodels moeten veilig herbouwbaar zijn uit brondata.

25.19 Backup, restore en privacy

Backups kunnen persoonsgegevens bevatten en moeten daarom als gevoelige gegevensdragers behandeld worden.

Aspect	Regel
Backupopslag	Beperkt toegankelijk en beveiligd.
Hersteldoelen	RPO 5 × 24 uur en RTO 3 werkdagen gelden ook wanneer privacycontroles en naverwerking nodig zijn.
Restore naar niet-productie	Alleen met passende anonimisering of afgeschermde toegang.
Restore-impact op anonimisering	Restore mag geanonimiseerde accounts niet stilzwijgend terugbrengen als identificeerbaar actief account.
Incidentanalyse	Gebruik correlation en technische identifiers, niet vrije inhoudsdumps.
Tijdelijke exports	Geen onderdeel van noodzakelijke brondatarestore.

Wanneer een restore persoonsgegevens terugzet die inmiddels geanonimiseerd hadden moeten zijn, moet een naverwerking of beheerprocedure dat corrigeren voordat reguliere toegang wordt toegestaan. Deze privacy-naverwerking hoort bij het vrijgeven van de restore en mag niet worden overgeslagen om de RTO te halen.

25.20 Beheerrollen en gegevensbescherming

Beheerderstoegang is breed maar niet onbeperkt qua doelbinding. De technische implementatie moet onderscheid houden tussen beheer, support, configuratie en privacygevoelige inhoud.

Beheeractie	Privacyregel
Account beheren	Geen wachtwoorden of providercredentials tonen/wijzigen.
Gebruikersinstellingen corrigeren	Alleen ondersteunde instellingen; geen autorisatieomzeiling.
Ticketanalyse	Technische snapshots zichtbaar voor beheer, niet voor reguliere gebruiker.
Resultaatanalyse	Alleen via geldige beheer-/supportcontext; geen live meekijken als beheerder.
Categorie-/modulebeheer	Geen historische runs herschrijven.
Failed-job analyse	Jobpayloads mogen geen gevoelige vrije inhoud bevatten tenzij noodzakelijk en beperkt zichtbaar.

25.21 Gegevensbescherming per technische laag

Laag	Privacy-/beschermingsmaatregel
Web	Geen gevoelige browserstorage, geen autorisatie op clientstate, veilige foutmeldingen.
Application/module contracts	Objectautorisatie en scopecontrole per command/query.
Data/EF Core	Soft links, snapshots, delete behavior, schema-eigenaarschap.
Logging	Geen gevoelige payloads; correlation-id verplicht.
Scheduling	Jobpayloads minimaliseren; failed jobs beheerbaar maar beperkt zichtbaar.
Reporting	Tijdelijke bestanden, geautoriseerde downloads, cleanup.
SignalR	Geen gevoelige groepsnamen; server-side autorisatie bij start en reconnect.
Infrastructure	Secrets buiten broncode, TLS, headers, rate limits, interne dashboards afgeschermd.

25.22 Anonimisering per domein

Domein	Verwacht gedrag bij accountanonimisering
Identity	Account deactiveren/anonimiseren; actuele profielwaarden vervangen.
Authorization	Rollen en contexten beëindigen of niet langer autoriserend maken.
Relationships	Actieve relaties deactiveren; open uitnodigingen niet langer accepteerbaar.
Catalog	Eigenaarschap/collaboratorcontext volgens domeinregels overdragen of historisch maken.
Practice	Runs behouden; persoonsweergave via snapshot/anonimiseringswaarden aanpassen waar nodig.
Communication	Deelname en mailboxzichtbaarheid volgens lifecycle; inhoud niet generiek hard verwijderen.
Support	Tickets behouden voor beheer/reconstructie; melder/beheerderweergave anonimiseren waar nodig.
LiveMonitoring	Live-audit behouden met geanonimiseerde viewer-/kindweergave waar nodig.
Admin	Beheerhistory behouden met geanonimiseerde actorweergave waar nodig.
Scheduling	Jobpayloads/statussen opschonen of anonimiseren wanneer zij persoonsverwijzingen bevatten.

25.23 Implementatiechecklist

Bij iedere wijziging die persoonsgegevens, snapshots, logging, exports, jobs of retentie raakt, wordt minimaal gecontroleerd:

• Is duidelijk welke module eigenaar is van de brondata?
• Bevat de wijziging persoonsgegevens of privacygevoelige inhoud?
• Is een harde FK, soft link of soft link + snapshot correct gekozen?
• Wordt historische context behouden zonder actuele persoonsgegevens onnodig vast te houden?
• Worden credentials, tokens, wachtwoorden en gevoelige payloads uitgesloten van logs?
• Is retentie of cleanup nodig?
• Is anonimisering beschreven voor nieuwe persoonsgegevens of snapshots?
• Zijn readmodels/caches na anonimisering of verwijdering herbouwbaar of invalideerbaar?
• Zijn tijdelijke bestanden buiten webroot en opruimbaar?
• Is beheerzichtbaarheid beperkt tot noodzakelijke rollen/contexten?
• Zijn backup/restore-effecten meegenomen?
• Is er testdekking voor privacy-, retentie- of anonimiseringsgedrag?

25.24 Teststrategie

Testtype	Doel
Anonimiseringstests	Controleren dat actuele persoonsgegevens verdwijnen en historische reconstructie behouden blijft.
Autorisatietests	Controleren dat privacygevoelige data alleen binnen geldige context zichtbaar is.
Loggingtests	Controleren dat verboden inhoud niet in logs terechtkomt.
Retentietests	Controleren dat cleanup jobs alleen bedoelde data verwijderen.
Exporttests	Controleren dat PDF/downloads geautoriseerd, tijdelijk en geanonimiseerd correct zijn.
Snapshottests	Controleren dat snapshots immutable zijn en alleen via anonimiseringsregels wijzigen.
Restoretests	Controleren dat herstelprocedures privacy- en anonimiseringsstatus respecteren.
Readmodeltests	Controleren dat caches/readmodels geen oude persoonsgegevens blijven tonen.

25.25 Implementatieverificaties

Punt	Te controleren in implementatie
Retentietermijnen	Definitieve termijnen voor technische logs, securitylogs, LiveViewAudit, jobhistorie en ticket snapshots vastleggen.
TickerQ-jobpayloads	Controleren dat jobpayloads geen onnodige persoonsgegevens bevatten.
Restoreprocedure	Technische procedure beschrijven voor restore na accountanonimisering.
Loggingprovider	Vastleggen welke velden standaard worden gescrubd of gemaskeerd.
CSP/securityheaders	Privacy- en securityimpact van externe assets en browserdata controleren tegen de vastgelegde CSP-baseline.
PDF-cleanuptermijn	Verifiëren dat 24-uursretentie, 6-uurscleanup en opslag buiten webroot technisch zijn ingericht.
Securityeventretentie	Controleren dat securityevents standaard in technische logging blijven en alleen domeineigen persistent worden wanneer hoofdstuk 19 dit toestaat.