Archiveren, bewaren en persoonsgegevens wissen

Archiveren sluit de zichtbare levensfase van een editie af. Persoonsgegevens bewaren, exporteren en wissen volgen afzonderlijke regels. Technisch een databasebackup maken is geen privacyafhandeling.

Een editie archiveren

Controleer eerst lopende verplichtingen: communicatie, orders, vergoedingen en verwerking. Archiveer vervolgens de bedoelde editie en controleer dat zij uit de reguliere openbare en beheerselecties verdwijnt. Archiveren bewaart de bijbehorende administratie en kan worden hersteld.

Bewaartermijnen controleren

Behandel profielgegevens, praktische antwoorden, noodcontacten, berichten, audit en financiële documenten als verschillende categorieën. De termijnen kunnen vanaf een andere gebeurtenis lopen. Een algemeen “alles na 30 dagen verwijderen” is geen Omnia-regel.

Controleer de concrete installatie-instellingen en de moduleverplichtingen voordat een workerupgrade of opschoonronde draait. Bewaar niet onbeperkt omdat gegevens ooit bruikbaar zouden kunnen zijn.

Een bewaartermijn kan in dagen tellen of, sinds de gecontroleerde revisie, in kalendermaanden vanaf het einde van de editie in de tijdzone van het evenement. Nog geen enkele categorie gebruikt maanden. Beheerders vinden de instellingen bij beheer.

Assistentactiviteit en de MCP-audit

Elke aanroep van een MCP-tool laat één auditrecord achter met alleen metadata: tijdstip, soort actor, tool, bewerkingsreferentie en uitkomst. Argumenten, resultaten en inloggegevens worden niet opgeslagen.

Een persoon kan de eigen assistentactiviteit via de API lezen (/v1/me/assistant-activity).
Medewerkers met identiteitsbeheer kunnen het overzicht voor de hele organisatie lezen (/v1/admin/assistant-activity).
Records worden standaard 60 dagen bewaard; beheerders kunnen die termijn wijzigen.
De MCP-audit doet mee aan persoonswissing: records waarin de persoon actor of verantwoordelijke persoon was, worden verwijderd.

Voor geen van beide overzichten is al een scherm. Zie integraties voor wat assistentkoppelingen wel en niet kunnen.

Welke registratievoorwaarden een bezoeker accepteerde

De registratievoorwaarden van elk tickettype hebben een versienummer (zie registratievoorwaarden en hun versie). Een leadonthulling van een sponsor hoort de versie vast te leggen die gold bij de scan (LEAD-003, PRIV-006), zodat je ook na een wijziging van de voorwaarden kunt zien op welke tekst een onthulling berustte. Nu slaat Commerce de versie op en biedt hij haar aan andere modules aan; de leadscan die haar vastlegt is nog niet gebouwd, dus geen enkele onthulling heeft nu een versie. Alleen de huidige versie wordt als nummer bewaard. De eerdere tekst zelf bewaart deze functie niet, dus exporteer of noteer de tekst vóór je hem wijzigt als je hem later moet kunnen tonen.

Een wisverzoek volgen

De spec verlangt identiteitcontrole, passende bevestiging, waar van toepassing een bedenktijd en verwerking door alle betrokken domeinen. Houd voortgang en eventuele beperkingen zichtbaar.

Een succesmelding van CFP alleen is geen bewijs dat ook Commerce, bestanden en Identity klaar zijn. De totale uitkomst mag niet gereed heten zolang een betrokken domein nog niet is afgehandeld.

Bij persoonswissing blijft volgens de spec het persoon-ID bewaard zonder de persoonsgegevens; er wordt geen pseudoniem voor die persoon ingevoerd. Wettelijk of contractueel te bewaren records krijgen een begrensde reden en toegang. Een nieuwe registratie met hetzelfde adres koppelt niet automatisch terug aan de gewiste persoon.

De basis voor wissing in de gecontroleerde revisie

Persoonswissing staat standaard uit en is nog geen bruikbare dienst voor eindgebruikers. De productieroute voor wissing, met alle uitkomsten per domein, is nog open (platform #1821). Wat er is, is de coördinatie tussen domeinen en een eerste reeks deelnemers. Elk domein meldt een eigen uitkomst, bijvoorbeeld Erased, PersonalDataRemoved, NothingHeld of Failed:

Domein	Wat er gebeurt
Commerce: wachtlijst	Vermeldingen van de persoon worden gewist, of het domein meldt dat het niets bewaart.
Commerce: bestellingen, tickets, ticketoverdrachten	Persoonsgegevens worden verwijderd terwijl de rijen op hetzelfde persoon-ID blijven; er komt geen pseudoniem.
Sponsors: acceptatiejournaal	Er wordt niets verwijderd; PersonalDataRemoved betekent dat alleen het persoon-ID overblijft.
Identity: ontvangstbewijzen van actielinks	Bewijzen over de persoon worden gewist.
Formulieren: persoonsgegevens	Doet mee als eigen domein.
Integraties: MCP-audit	Records waarin de persoon actor of verantwoordelijke persoon was, worden verwijderd.

Een fout in één domein wordt alleen voor dat domein gemeld. Andere categorieën persoonsgegevens tellen nog als niet afgehandeld, dus een verzoek kan nog niet als gereed worden gemarkeerd.

Ontvangstbewijzen van actielinks. Elke bevestigde voltooiing van een actielink, zoals het claimen van een ticket of het bevestigen van een sponsoracceptatie, schrijft nu een bewijs Confirmed. Na een opschoonronde leest een bevestigde claim daardoor als bevestigd in plaats van onbekend. Het sponsorherstel bevestigt het bewijs na afronding. Een afgewezen voltooiing schrijft nog geen bewijs (#2577 open) en kan dus nog als onbekend lezen. Niet-afgehandelde bewijzen worden standaard na 30 dagen verwijderd.

Deze pagina beschrijft productgedrag en beheercontrole, geen algemene juridische bewaarinstructie. De volledige cross-module wisproef hoort bij de acceptatie van de geïnstalleerde release.