ISO 27001 A.8.10: Veilig verwijderen van spelergegevens voor gamestudio's

Waarom spelergegevens die u niet verwijdert een strategische last zijn geworden

Spelersgegevens die u niet op tijd verwijdert, vormen al snel een beveiligings-, privacy- en regelgevingsrisico voor uw studio. Wanneer telemetrie, chatlogs en ondersteuningsgeschiedenissen nooit echt verdwijnen, brengt elke inbreuk of aanvraag meer systemen, meer bewijs en meer werk met zich mee dan nodig is. Door gegevens aan het einde van hun levenscyclus als een beheerd risico te behandelen, kunt u de impact van incidenten beperken, onderzoeken vereenvoudigen en de hoeveelheid informatie die kan worden misbruikt, beperken.

Spelersgegevens bevinden zich nu op het kruispunt van inkomsten, regelgeving en reputatie, dus onbeheerde retentie vergroot uw risico's stilletjes. Bijlage A.8.10 van ISO 27001:2022 stelt expliciet dat informatie moet worden verwijderd wanneer deze niet langer nodig is, op een manier die herstel voorkomt en die voldoet aan wettelijke, wettelijke, contractuele en interne vereisten. Die taal spreekt evenzeer over privacy- en gegevensbeschermingsverwachtingen als over klassieke informatiebeveiliging.

De meeste studio's weten al hoe ze live systemen moeten beschermen; veel minder studio's kunnen met zekerheid laten zien wat er met data gebeurt wanneer deze "niet langer nodig" is. Die leemte is precies waar A.8.10 zich bevindt. Het vraagt u om te stoppen met het behandelen van oude spelergegevens en logs als onschadelijke archieven, en ze te behandelen als assets die bewust moeten worden verwijderd. Of u nu voor het eerst ISO 27001 implementeert of een volwassen ISMS versterkt, deze controle is waar bewaarschema's en daadwerkelijke verwijdering samenkomen.

Gegevens die u niet hebt verzameld of niet op tijd hebt verwijderd, kunnen nooit worden gestolen, gedagvaard of tegen u worden gebruikt.

De verborgen kosten van het hamsteren van spelergegevens

Gehamsterde spelergegevens zijn op meer plekken verborgen dan de meeste teams verwachten, van oude telemetriepijplijnen tot vergeten testdatabases. Elke extra kopie vergroot de explosieradius als er een inbreuk plaatsvindt of als er vragen ontstaan over hoe lang gegevens worden bewaard, omdat u meer systemen in beeld hebt en meer bewijsmateriaal moet beoordelen dan gepland.

Als je eerlijk bent over waar spelersgegevens zich bevinden, vind je meestal veel meer dan alleen accounttabellen en betalingsgegevens. Typische voorbeelden zijn:

Verouderde telemetriepijplijnen die nog steeds gebeurtenissen ontvangen, ook al worden dashboards niet gebruikt.
Oude crashdumps met onbewerkte apparaat-ID's en stack traces.
Chatarchieven worden ‘voor de zekerheid’ bewaard ter moderatie, maar worden nooit gecontroleerd.
Kopieën van productiedatabases in testomgevingen en sandboxes.

Elk van deze kopieën vergroot de reikwijdte als er iets misgaat. Als een aanvaller in uw analysecluster terechtkomt, of een toezichthouder vraagt naar de bewaartermijn van gegevens van minderjarigen, kunt u niet zomaar naar uw hoofdaccountdatabase verwijzen en daarmee stoppen. U moet rekening houden met alle plekken waar gegevens in de loop der jaren naartoe zijn gegaan tijdens lanceringen, updates en experimenten.

Dit gaat niet alleen om beveiliging. Overmatige retentie ondermijnt ook het verhaal dat u vertelt over dataminimalisatie in privacy impact assessments, partnervragenlijsten en platformreviews. Als beleid voorschrijft dat u logs één jaar bewaart, maar systemen er stilletjes vijf jaar bewaren, heeft u al een geloofwaardigheidsprobleem voordat er iets misgaat. Voor teams die hun ISMS formaliseren, is het zichtbaar maken van deze inventarisatie vaak de belangrijkste stap in het verminderen van risico's.

Hoe niet-verwijderde logs incidenten verergeren

Onverwijderde logs maken incidenten trager, duurder en moeilijker te verklaren, omdat ze de hoeveelheid potentieel blootgestelde gegevens vergroten en de inspanning die nodig is om de impact te bepalen, vergroten. Wanneer de retentie niet per doel wordt gesegmenteerd, bewaart u uiteindelijk veel gevoeligere informatie veel langer dan het risico rechtvaardigt.

Wanneer u op een inbreuk reageert, zijn twee dingen direct van belang: hoe snel u kunt inschatten wat er is blootgelegd en hoe vol vertrouwen u die omvang kunt uitleggen aan leidinggevenden, partners en toezichthouders. Langdurige, slecht beheerde logs en telemetriepijplijnen werken beide doelen tegen, omdat ze routinematige sporen vermengen met zeer gevoelige informatie en alles jarenlang bewaren.

Het helpt om onderscheid te maken tussen de verschillende soorten logboeken die u bijhoudt:

Operationele logboeken: – voor prestaties, stabiliteit en foutopsporing.
Beveiligingslogboeken: – voor toegangscontrole, detectie van anomalieën en respons op incidenten.
Fraude- en anti-cheatlogs: – voor patroonanalyse en handhaving op lange termijn.

Beveiligings-, anti-cheat- en fraudeteams pleiten vaak voor langdurige retentie, en in sommige gevallen hebben ze gelijk. Het probleem is dat retentie zelden gesegmenteerd is. Routinematige authenticatielogs en zeer gevoelige fraude-indicatoren worden uiteindelijk op dezelfde manier behandeld en beide worden voor onbepaalde tijd bewaard.

In de praktijk betekent dit dat forensische teams enorme hoeveelheden data moeten doorspitten om te achterhalen wat er is gewijzigd, dat juridische teams moeten overwegen of zeer oude records nu wel of niet openbaar mogen worden gemaakt, en dat operationele teams de prestatie-impact van overvolle logbestanden moeten beheersen. ISO 27001 A.8.10 dwingt u om deze wildgroei te disciplineren door middel van expliciete limieten, automatisering en monitoring.

Waarom gamestudio's op unieke wijze kwetsbaar zijn

Gamestudio's lopen een bijzonder risico omdat ze diepgaande gedragsgegevens verzamelen over hoe mensen spelen, geld uitgeven en met elkaar omgaan, vaak met minderjarigen en kwetsbare spelers. Wanneer deze informatie langer wordt bewaard dan nodig, wordt het een gevoelige last in plaats van een nuttig bezit en wordt het veel moeilijker om incidenten of kritiek te beheren.

Gamebedrijven verzamelen een van de meest uitgebreide gedragsgegevens in de consumentenindustrie. Vaak volgen ze niet alleen uitgaven en inloggegevens, maar ook gameplay, chat, sociale grafieken, apparaatprofielen, locatietips en anti-cheatsignalen. Mogelijk verwerken ze ook gegevens van minderjarigen, spelers die zichzelf hebben uitgesloten of personen in gebieden met strenge privacyregels.

Dit alles maakt niet-verwijderde gegevens gevoeliger:

Wedstrijdgeschiedenis en chatlogs kunnen speelpatronen, relaties en in sommige gevallen ook gezondheidsproblemen of financiële stress onthullen.
Monetisatiegegevens over loot boxes en microtransacties sluiten nauw aan bij actuele debatten over consumentenbescherming.
Anti-cheat- en fraudesystemen kunnen gevoelige risicoprofielen van individuen afleiden of opslaan.

Neem een eenvoudig voorbeeld met minderjarigen. Een tiener speelt met toestemming van de ouders, chat over school en familie, besteedt geld via de kaart van een ouder en sluit vervolgens zijn of haar account. Als er jaren later nog steeds gedetailleerde wedstrijd- en chatlogs bestaan, houdt u onnodig een zeer gevoelige gedragsgeschiedenis bij van iemand die inmiddels volwassen is, zonder duidelijk doel. Hetzelfde geldt voor zichzelf uitgesloten of kwetsbare spelers van wie u de plicht hebt om zorgvuldig met de gegevens om te gaan.

Wanneer deze gegevens lang blijven bestaan nadat ze nodig waren, loopt u onnodig risico op privacy en reputatieschade. Door te voldoen aan A.8.10 kunt u dit risico op een gecontroleerde manier verkleinen, in plaats van te wachten tot een inbreuk, klacht of toezichthouder de kwestie oplegt. Een platform zoals ISMS.online kan u helpen dit helder te zien door beleid, gegevensinventarissen en controles in één overzicht te verzamelen. Zo kunt u bepalen wat echt bewaard moet blijven, wat geanonimiseerd moet worden en wat uiteindelijk verwijderd moet worden, en vervolgens aan auditors laten zien hoe die beslissingen worden gehandhaafd.

Demo boeken

Wat ISO 27001:2022 A.8.10 werkelijk van gamestudio's eist

ISO 27001:2022 Bijlage A.8.10 verwacht dat u verwijdering behandelt als een normaal onderdeel van de levenscyclus van spelergegevens, en niet als een bijzaak. U bepaalt zelf wanneer elk type informatie niet langer nodig is, kiest een geschikte verwijderings- of anonimiseringsmethode en bewijst vervolgens dat deze methoden daadwerkelijk worden toegepast in de systemen waarin die gegevens worden bewaard.

Op papier lijkt A.8.10 kort, maar het heeft grote gevolgen. Het vereist dat u informatie verwijdert wanneer deze niet langer nodig is, op een manier die herstel onmogelijk maakt en die in lijn is met wettelijke, reglementaire, contractuele en interne vereisten. Voor een gamebedrijf betekent dit dat verwijdering een ingebouwde activiteit is, niet een eenmalig script wanneer iemand zich de informatie herinnert.

In de praktijk wordt u gevraagd te beslissen wanneer elk type spelergegevens en -logboek niet langer nodig is, verwijderings- of anonimiseringsmethoden te kiezen die passen bij het risico, en aan te tonen dat deze methoden daadwerkelijk van toepassing zijn. A.8.10 werkt samen met Bijlage A.5.32 over bewaring en uw risicobehandelingsproces uit Clausule 6: u bepaalt wat u bewaart, hoe lang, en welke bedreigingen u met veilige verwijdering kunt beheersen.

Een begrijpelijke weergave van Bijlage A.8.10

U kunt A.8.10 begrijpen door het te beschouwen als vijf eenvoudige vragen over uw gegevens en uw beslissingen. Deze vragen gaan niet over het beschrijven van specifieke producten; ze gaan over het in eenvoudige bewoordingen kunnen uitleggen wat u bewaart, waarom u het bewaart en wat u doet als het niet langer nodig is.

U kunt A.8.10 zien als een opbouw van vijf vragen:

Over welke informatie gaat het?
Niet alleen 'persoonsgegevens' in de zin van privacy, maar alle informatie in systemen, apparaten of media: accounttabellen, gameplay-evenementen, fraudelogboeken, telemetrie, back-ups, exporten en meer.
Wanneer is het niet meer nodig?
Hier komt A.8.10 samen met A.5.32 over bewaarplicht en uw wettelijke verplichtingen. "Niet langer nodig" moet gebaseerd zijn op het doel en de wet, niet alleen op gemak.
Hoe verwijdert of anonimiseert u deze gegevens?
Logisch verwijderen, cryptografisch wissen, opslagopschoning, aggregatie en anonimisering kunnen allemaal geldig zijn, maar ze moeten wel bewust worden gekozen.
Wie is verantwoordelijk?
Beleid en procedures moeten de verantwoordelijkheid voor het definiëren van regels, het bedienen van verwijderingsmechanismen en het controleren of deze werken, vastleggen.
Hoe bewijs je het?
U hebt bewijs nodig: configuratie, logboeken, tickets en interne auditresultaten die aantonen dat verwijdering of anonimisering daadwerkelijk plaatsvindt.

Vanuit dat perspectief bezien is A.8.10 minder een ‘technologische’ controle en meer een brug tussen uw informatiebeheer – wat u bewaart en waarom – en uw technische implementatie – hoe u gegevens laat verdwijnen of onschadelijk maakt.

Hoe A.8.10 past in uw ISMS

A.8.10 werkt alleen als het geïntegreerd is in de rest van uw informatiebeveiligingsbeheersysteem. Het is gebaseerd op uw risicobeoordelingen en retentiebeslissingen en biedt concrete maatregelen die u kunt aanwijzen bij het beschrijven hoe u de impact van incidenten, audits en privacyklachten vermindert.

Als u al een informatiebeveiligingsbeheersysteem gebruikt, mag A.8.10 niet geïsoleerd worden gebruikt. Het maakt verbinding met:

A.5.32 – Bewaring: waarin staat dat je moet definiëren hoe lang informatie bewaard moet worden. A.8.10 is de uitvoeringsarm: wat gebeurt er aan het einde van die tijd?
Artikel 6 – Risicobehandeling: waarbij u beslist welke bedreigingen u wilt beperken door middel van veilig verwijderen, anonimiseren of minimaliseren.
Controles op logging en monitoring: omdat regels voor het bewaren van logboeken en verwijderingstaken moeten voldoen aan de behoeften op het gebied van beveiliging, fraude en privacy.
Cloud- en leverancierscontroles: omdat uw verwijderingsverhaal infrastructuur en diensten moet omvatten die u niet rechtstreeks beheert.
Toegangscontrole en encryptie: omdat effectieve verwijdering eenvoudiger is als gevoelige gegevens worden gescheiden en gecodeerd met goed beheerde sleutels.

Wanneer u uw controles documenteert, is het nuttig om deze koppeling expliciet te maken. Dit kan bijvoorbeeld door te verwijzen naar bewaartermijnen in uw verwijderingsprocedures en door in uw risicobehandelingsplan vast te leggen hoe A.8.10 specifieke bedreigingen, zoals gegevensretentie of overmatige bewaartermijnen, beperkt.

Het verschil tussen het negeren van verwijdering en het uitlijnen met A.8.10 is vaak groot:

Zonder behoud- en verwijderingsdiscipline	Uitgelijnd met A.8.10
Het bereik van incidenten is moeilijk te definiëren	Bereik gebaseerd op bekende, in kaart gebrachte gegevensopslag
Audits zijn reactief en pijnlijk	Audits volgen een gedocumenteerde levenscyclus
Privacyverdieping voelt inconsistent	Bewaartermijnen en systeemgedrag komen duidelijk overeen
Het vertrouwen tussen spelers en partners is fragiel	U kunt bewijs leveren van minimalisatie- en retentielimieten

Een ISMS-platform als ISMS.online maakt deze koppelingen eenvoudiger doordat u beleid, risico's, controles en bewijsmateriaal met elkaar in verband kunt brengen. Zo kunnen een auditor en uw eigen leidinggevenden een rechte lijn volgen van de vereisten op hoog niveau naar concrete acties in uw systemen.

Waar accountants eigenlijk op letten

Auditors hechten belang aan hoe u verwijderingsbeleid ontwerpt, implementeert en uitvoert, niet alleen aan een beleidsregel, omdat ze erop moeten vertrouwen dat uw garanties overeenkomen met de werkelijkheid. Ze willen zien dat er bewaarregels bestaan, dat deze technisch worden gehandhaafd en dat er toezicht wordt gehouden wanneer er iets misgaat, zodat ze kunnen vertrouwen op uw verklaringen over spelergegevens en -logs.

Auditors zullen nooit genoegen nemen met één beleidszin die luidt: "We verwijderen gegevens wanneer ze niet langer nodig zijn". Ze zoeken doorgaans naar drie bewijslagen:

Design: – gedocumenteerde beleidsregels, normen en procedures die bewaartermijnen, verwijderingsmethoden en verantwoordelijkheden voor verschillende gegevenstypen definiëren.
Implementatie: – systeemconfiguraties, automatiseringstaken en procesartefacten zoals geplande taken, regels voor de levenscyclus van objectopslag of databaseroutines die overeenkomen met wat de documenten beloven.
Bediening en bewaking: – logs, tickets en interne auditcontroles die aantonen dat verwijdering of anonimisering daadwerkelijk heeft plaatsgevonden, dat fouten worden gedetecteerd en gecorrigeerd en dat uitzonderingen worden geregistreerd en beoordeeld.

Voor spelergegevens en logs kan dit betekenen dat u het volgende laat zien:

Een retentie- en verwijderingsmatrix voor de belangrijkste gegevenscategorieën.
Een procedure voor het verwerken van verzoeken tot het wissen van spelers.
Schermen of exporten van database-, log- en opslagsystemen waarbij behoud en verwijdering zijn geconfigureerd.
Een voorbeeld van verwijderingslogboeken en bevindingen van interne audits.

Als u eenvoudige vragen als "waar kan ik zien dat chatlogs ouder dan achttien maanden worden verwijderd of geanonimiseerd?" kunt beantwoorden zonder dat u daar moeite voor hoeft te doen, bent u al een heel eind op weg om te voldoen aan A.8.10 en uw volgende audit een stuk minder pijnlijk te maken.

ISMS.online geeft u een voorsprong van 81% vanaf het moment dat u inlogt

ISO 27001 eenvoudig gemaakt

Wij hebben het harde werk voor u gedaan, waardoor u vanaf het moment dat u inlogt een voorsprong van 81% heeft. U hoeft alleen nog maar de lege plekken in te vullen.

Start

Van 'recht om vergeten te worden' tot bewaartermijnen: A.8.10 afstemmen op de AVG en de wereldwijde privacywetgeving

Veilig verwijderen is niet alleen een beveiligingskwestie; het gaat er ook om hoe je aan spelers en toezichthouders bewijst dat je privacyrechten respecteert. Privacywetten zoals de Algemene Verordening Gegevensbescherming (AVG) verwachten dat je de hoeveelheid gegevens die je bewaart minimaliseert, gegevens die niet langer nodig zijn wist en rechten zoals dataminimalisatie, opslagbeperking en het recht op gegevenswissing respecteert. Deze principes sluiten nauw aan bij A.8.10, dat je de praktische, operationele handvatten biedt om deze verwachtingen in echte systemen af te dwingen.

U hoeft geen privacyjurist te worden om goede verwijderingsmaatregelen te ontwerpen, maar u moet wel begrijpen hoe wettelijke verplichtingen zich vertalen naar bewaartermijnen en technisch gedrag in uw systemen.

Kernprincipes voor privacy waarop u moet voortbouwen

Drie algemeen erkende ideeën bepalen hoe lang je spelergegevens mag bewaren en wat je ermee moet doen. Ze komen in veel privacykaders voor en vormen gangbare referentiepunten voor toezichthouders bij het beoordelen van je praktijken.

Deze drie ideeën zijn:

Gegevensminimalisatie: – verzamel en verwerk alleen wat toereikend, relevant en noodzakelijk is voor uw doeleinden. Als u geen gedetailleerde telemetrie op spelerniveau nodig hebt, overweeg dan geaggregeerde rapportage.
Opslagbeperking: – persoonsgegevens in identificeerbare vorm alleen bewaren zolang dat nodig is voor die doeleinden. "Misschien hebben we het ooit nog nodig" is geen rechtmatig doel.
Recht op verwijdering: – in veel gevallen kunnen spelers je vragen om hun persoonlijke gegevens te wissen, met name wanneer ze hun toestemming intrekken of wanneer het oorspronkelijke doel niet langer van toepassing is.

Voor een gamebedrijf zijn deze principes van toepassing op:

Account- en profielgegevens.
Betalings- en transactiegegevens.
Chat- en sociale gegevens.
Telemetrie en analyse.
Anti-cheat- en fraudelogboeken.
Supporttickets en geschilgeschiedenis.

Voor elk van deze categorieën zijn expliciete beslissingen nodig: hoe lang u identificeerbare gegevens bewaart, wanneer u overschakelt naar geanonimiseerde of geaggregeerde formulieren en hoe u geldige verzoeken tot verwijdering honoreert. Belasting- en boekhoudwetten gaan vaak samen met deze privacyprincipes en kunnen het verzoek van een speler om specifieke gegevens te verwijderen, overschrijven. U moet die interacties dus duidelijk kunnen uitleggen.

Deze informatie is algemeen en vormt geen juridisch advies. U dient altijd specifiek juridisch advies in te winnen voor uw rechtsgebieden en productmix.

Principes en rechten omzetten in concrete bewaartermijnen

Het omzetten van abstracte privacyrechten in duidelijke regels is essentieel als u wilt dat engineers en operationele teams consistent handelen. Ze moeten voor elke gegevenscategorie weten wat het doel is, hoe lang de gegevens bewaard worden en wat er aan het einde van die periode gebeurt, zodat ze het juiste gedrag kunnen implementeren.

Privacy- en beveiligingsteams zijn het vaak eens over de principes, maar er ontstaat wrijving wanneer engineers om specifieke details vragen. Ze hebben cijfers en gedrag nodig, geen abstracte zinnen. Een praktische aanpak is om een bewaar- en verwijderingsschema op te stellen dat voor elke categorie spelergegevens het volgende vermeldt:

Doel: – waarom u deze gegevens bewaart, zoals het leveren van het spel, het voorkomen van fraude of het voldoen aan de belastingwetgeving.
Wettelijke basis of verplichting: – toestemming, contract, gerechtvaardigd belang, wettelijke verplichting.
Standaard bewaartermijn: – hoe lang u identificeerbare gegevens onder normale omstandigheden bewaart.
Uitzonderingen: – situaties waarin u gegevens langer moet bewaren, zoals bij openstaande geschillen of juridische verplichtingen.
Eindtoestand: – of u deze aan het einde van de periode verwijdert, anonimiseert of samenvoegt.
Verwijderingsmethode: – de technische aanpak die u gebruikt, zoals het verwijderen van rijen, vernietigen van sleutels of anonimiseren.

Wanneer een speler een beroep doet op zijn recht op wissen, kun je systematisch redeneren:

Welke categorieën vallen onder het verzoek?
Zijn er wettelijke verplichtingen waardoor u bepaalde gegevens moet bewaren, bijvoorbeeld vanwege belastingwetgeving of regelgeving ter bestrijding van witwassen?
In welke systemen bevinden de relevante gegevens zich?
Welke technische maatregelen worden er genomen om gegevens te verwijderen of te anonimiseren waar dat is toegestaan?

Uw ISO 27001-documentatie en uw privacy-impactbeoordelingen moeten naar ditzelfde schema verwijzen. Zo voorkomt u dat u parallelle sets regels probeert te handhaven die onvermijdelijk afwijken en moeilijker te verdedigen zijn.

Omgaan met lastige categorieën: fraude, minderjarigen en geschillen

Enkele van de moeilijkste vragen rijzen rond de gegevens die u gebruikt om uw bedrijf en andere spelers te beschermen, omdat deze categorieën vragen oproepen over privacy en eerlijkheid, terwijl ze een langere bewaartermijn rechtvaardigen. U hebt mogelijk een langere bewaartermijn nodig voor fraude en anti-cheat, of om juridische claims te verdedigen, maar u wilt ook de hoeveelheid gegevens die u over personen in de loop der tijd bewaart, minimaliseren.

Enkele van de moeilijkste vragen die rijzen rondom de gegevens die u gebruikt om uw bedrijf en andere spelers te beschermen:

Fraude- en anti-cheatlogs: – het kan zijn dat je langer moet vasthouden om patronen te herkennen en de integriteit van het spel te beschermen.
Betalings- en belastinggegevens: – financiële wetten vereisen vaak dat u bepaalde gegevens een vast aantal jaren bewaart.
Geschillen- en ondersteuningslogboeken: – Mogelijk hebt u nog gegevens nodig totdat de verjaringstermijnen voor rechtsvorderingen zijn verstreken.
Gegevens van minderjarigen en zelfuitgesloten spelers: – Mogelijk hebt u aanvullende verplichtingen om kwetsbare groepen te beschermen of bepaalde verwerkingen te beperken.

Het is verstandig om duidelijke, gedocumenteerde regels voor deze gevallen op te stellen in plaats van ad-hocbeslissingen toe te staan. Vervolgens kunt u controlemechanismen ontwerpen die zowel het beschermende doel als het privacyrisico erkennen.

Stap 1 – Documenteer de spanning

Schrijf op waarom u in specifieke gebieden langere retentie nodig hebt, inclusief verwijzingen naar juridische, wettelijke of platformverwachtingen, zodat de afweging transparant is.

Stap 2 – Scheid gegevens met een hoog risico

Bewaar logboeken en profielen met een hoog risico op een overzichtelijke, afgeschermde locatie met sterke toegangscontroles en aparte bewaarregels, zodat ze niet opgaan in algemene systemen.

Stap 3 – Verminder de herkenbaarheid in de loop van de tijd

Ga zo snel mogelijk van volledige identificatiegegevens over op pseudoniemen, en van pseudoniemen op samengevoegde of volledig geanonimiseerde gegevens, terwijl u nog steeds aan uw beschermingsbehoeften voldoet.

Stap 4 – Controleer de verlengde retentie regelmatig

Zorg ervoor dat er in het bestuur sprake is van periodieke evaluatie van deze bijzondere gevallen, zodat ‘tijdelijke’ retentie niet permanent wordt door nalatigheid of gemak.

Concrete voorbeelden maken het eenvoudiger om deze ideeën toe te passen. Fraudelogs kunnen worden opgeslagen in een speciale database waar alleen gehashte identificatiegegevens na een bepaalde leeftijd worden bewaard, waardoor patronen zichtbaar blijven, maar mensen minder kwetsbaar zijn. Betalingsgegevens kunnen worden opgesplitst, zodat alleen de minimale transactiereferenties en bedragen die vereist zijn voor belastingregels, worden bewaard in een financieel systeem, los van gameplayprofielen. Accounts van minderjarigen en spelers die zichzelf hebben uitgesloten, kunnen worden gemarkeerd, zodat sommige veiligheidsgerelateerde gegevens gedurende een bepaalde periode worden bewaard, terwijl marketingtelemetrie en profileringsgegevens veel eerder worden verwijderd.

A.8.10 doet geen afbreuk aan uw wettelijke plichten, en de privacywetgeving verhindert u niet om gegevens te bewaren die u daadwerkelijk nodig hebt voor juridische verdediging of naleving. Het punt is dat een langere bewaartermijn gerechtvaardigd, gedocumenteerd en technisch gehandhaafd moet zijn, en niet zomaar aangenomen, zodat toezichthouders en spelers kunnen zien dat u eerlijk handelt.

De spelergegevens en de levenscyclus van het logboek toewijzen aan A.8.10

Om A.8.10 in de praktijk te laten werken, moet je denken in termen van een levenscyclus. Spelersgegevens verschijnen en verdwijnen niet zomaar; ze verplaatsen zich van verzameling naar actief gebruik en vervolgens naar verschillende opslaglagen voordat ze uiteindelijk worden verwijderd of geanonimiseerd. A.8.10 koppelt controles aan elke fase van die reis. Veilig verwijderen wordt veel eenvoudiger wanneer je voor elke fase weet waar de gegevens zich bevinden en wat er vervolgens moet gebeuren, en wanneer iedereen in beveiliging, privacy, engineering en LiveOps dezelfde map deelt.

Veel studio's hebben informele mentale modellen van deze stroom, maar slechts weinigen hebben dit op een manier uitgewerkt waarop verschillende teams kunnen vertrouwen bij het ontwerpen van systemen, functies en operationele processen.

Visueel: eenvoudig levenscyclusdiagram van verzameling → actief gebruik → warme archivering → koude archivering → verwijdering/anonimisering.

Een typische levenscyclus in moderne games

De meeste moderne gamestacks volgen een vergelijkbaar patroon, ook al verschillen de labels. Spelers genereren gebeurtenissen, jij verwerkt die gebeurtenissen om ervaringen te leveren en vervolgens verplaats je oudere data langzaam naar koudere, goedkopere of meer beperkte opslagplaatsen. Verwijderings- en anonimiseringsbeslissingen werken alleen als ze deze echte stroom respecteren in plaats van te doen alsof alle data in één overzichtelijke database staat.

Hoewel elke titel anders is, zijn de grote lijnen van het proces herkenbaar:

Verzameling en inname: – spelers melden zich aan, authenticeren zich, spelen wedstrijden, chatten, geven geld uit en je verwerkt gebeurtenissen in backends, logs en analyses.
Actief gebruik: – gegevens worden gebruikt om het spel te leveren, LiveOps uit te voeren, matchmaking mogelijk te maken, inventarissen te beheren en klantenondersteuning te bieden.
Warm archief: – oudere gegevens worden verplaatst naar goedkopere opslag of tabellen met een lagere prioriteit, maar blijven nog enige tijd identificeerbaar, bijvoorbeeld voor accountherstel of langerlopende onderzoeken.
Koude archivering: – gegevens worden alleen bewaard voor verplichtingen zoals fiscale, wettelijke of ernstige fraudeonderzoeken, vaak in meer beperkte systemen.
Verwijdering of anonimisering: – gegevens worden verwijderd of getransformeerd, zodat ze niet langer aan een identificeerbare speler kunnen worden gekoppeld.

Deze levenscyclus is niet alleen van toepassing op accounttabellen, maar ook op observatie- en beveiligingslogs, telemetrie en datalakes, anti-cheat- en risicoscoresystemen, ondersteunings- en moderatietools, en integraties en exports van derden. Hoe duidelijker u kunt aangeven welke systemen en datasets zich in elke fase bevinden, hoe gemakkelijker het wordt om A.8.10-controles toe te wijzen en uit te leggen aan een auditor of een sceptische stakeholder.

A.8.10-bedieningselementen aan elke fase koppelen

Door A.8.10 aan de levenscyclus toe te voegen, definieert u wat waar moet zijn telkens wanneer gegevens een grens overschrijden, omdat die grenzen het risico veranderen. U verzamelt nieuwe gegevens, verplaatst deze naar een nieuwe opslaglocatie of besluit dat ze niet langer nodig zijn, en elke overgang biedt de mogelijkheid om verwijdering, minimalisatie of anonimisering af te dwingen.

Een nuttige manier om hierover na te denken, is om A.8.10 te beschouwen als een checklist die bij elke fasegrens wordt geactiveerd.

Wanneer gegevens van verzameling tot actief gebruik:

Controleer wat je verzamelt

Controleer of de velden beperkt zijn tot wat noodzakelijk is voor de gameplay, de handelingen en de verplichtingen, en niet alleen tot alles wat je uit nieuwsgierigheid kunt vastleggen.

Scheid identificatiegegevens van inhoud

Structureer schema's zodanig dat speler-ID's verwijderd of verwisseld kunnen worden zonder dat alle bruikbare analytische content of bedrijfsstatistieken verloren gaan.

Wanneer gegevens van actief gebruik om archief te verwarmen:

Bevestig de retentietrigger

Stel een duidelijke tijd of gebeurtenis in waarna gegevens uit actieve winkels worden verplaatst en documenteer hoe die trigger wordt geïmplementeerd in relevante pijplijnen of services.

Beperk de toegang en pas de controles aan

Zorg voor betere toegang tot gearchiveerde gegevens en configureer bewaartermijnen in overeenstemming met uw schema, zodat oudere gegevens zich niet ongemerkt opstapelen.

Wanneer gegevens van warm naar koud archief:

Rechtvaardig wat overblijft

Zorg ervoor dat alleen gegevens die daadwerkelijk nodig zijn voor juridische, regelgevende of beveiligingsdoeleinden, in de cold storage worden opgeslagen en dat deze rechtvaardiging wordt gedocumenteerd.

Pas sterkere waarborgen toe

Pas strengere toegangscontroles, monitoring en, waar nodig, encryptie toe voor koude archieven, zodat minder gebruikte gegevens geen gemakkelijke prooi worden.

Wanneer gegevens van van koude archivering tot verwijdering of anonimisering:

Automatiseer de eindtoestand

Definieer een geautomatiseerde taak of proces dat gegevens verwijdert of anonimiseert wanneer de bewaartermijn verloopt, in plaats van te vertrouwen op ad-hoc opschoningen.

Verzamel bewijs en fouten

Registreer succesvolle uitvoeringen en uitzonderingen, zodat u kunt aantonen dat de controle werkt, fouten kunt onderzoeken en uw aanpak in de loop van de tijd kunt verfijnen.

Bij elke grens zou u de volgende vraag moeten kunnen beantwoorden: "Als we zeggen dat gegevens na X naar deze fase gaan, hoe weten we dan dat dit daadwerkelijk het geval is en wat gebeurt er dan?" Deze antwoorden vormen de ruggengraat van uw A.8.10-controles en helpen u toezichthouders en partners te laten zien dat u de volledige levenscyclus serieus neemt.

Inclusief back-ups, testgegevens en donkere hoeken

Back-ups, testomgevingen en exports vallen vaak buiten het dagelijkse denken over de levenscyclus, maar bevatten grote hoeveelheden spelergegevens die je verwijderingsstrategie stilletjes kunnen ondermijnen. Je hoeft je back-upontwerp hier niet helemaal opnieuw te formuleren, maar je moet deze gebieden wel in dezelfde map verwerken en vervolgens vertrouwen op je technische standaarden om te bepalen hoe verwijdering daadwerkelijk plaatsvindt.

Het is gemakkelijk om je te concentreren op primaire systemen en te vergeten waar de data zich bevindt. Back-ups en replica's verdienen een eigen plan. Als je back-ups met een lange levensduur gebruikt, kun je de data van individuele spelers mogelijk niet rigoureus verwijderen. In dat geval kun je het volgende doen:

Versleutel back-ups met sterke, goed beheerde sleutels.
Stel bewaartermijnen in en zorg ervoor dat verlopen sets worden verwijderd.
Zorg ervoor dat oude back-ups verlopen of niet-herstelbaar zijn, bijvoorbeeld door sleutels te vernietigen of media te saneren.

Test- en stagingomgevingen kunnen grote hoeveelheden productiegegevens bevatten. Als u deze van live records voorziet, moeten ze binnen het bereik van uw levenscyclus- en verwijderingsregels vallen. U kunt ook de gegevens anonimiseren voordat u ze gebruikt, zodat ontwikkelaars met realistische maar niet-identificeerbare informatie kunnen werken.

Exports en rapporten – csv-bestanden, data-extracten en screenshots die worden gebruikt voor analyse of rapportage – moeten worden beheerd of vermeden. Wanneer exports noodzakelijk zijn, bewaar ze dan op gecontroleerde locaties met duidelijke bewaartermijnen en geef waar mogelijk de voorkeur aan gecentraliseerde rapportage of dashboards.

Een eenvoudige tabel kan hierbij helpen, met kolommen zoals 'Opslag of systeem', 'Levenscyclusfase' en 'Bewaar- en verwijdergedrag', en niet meer dan een handvol rijen per titel. Zodra deze mapping bestaat, kunnen tools en platforms hierop worden afgestemd. Een geïntegreerde ISMS-oplossing zoals ISMS.online biedt u één centrale plek voor de levenscyclus, het beleid dat ernaar verwijst en het bewijs dat deze wordt gevolgd, zodat u net zo bewust om kunt gaan met donkere hoeken als met primaire systemen.

Integreer, breid uit en schaal uw compliance, zonder rommel. IO geeft u de veerkracht en het vertrouwen om veilig te groeien.

Boek uw demo

Technische patronen voor veilig verwijderen van gegevens in databases, logs, back-ups en telemetrie

Veilig verwijderen werkt alleen als de onderliggende architectuur het praktisch en veilig maakt voor uw teams om toe te passen. U hebt een kleine set standaardpatronen nodig die engineers begrijpen, die goedkoop in gebruik zijn en die auditors kunnen volgen, zodat u het verwijderen niet voor elke game en service opnieuw hoeft uit te vinden.

Zelfs het beste beleid heeft weinig zin als uw architectuur verwijdering moeilijk of gevaarlijk maakt. Het goede nieuws is dat er herhaalbare patronen zijn die u op meerdere technologieën kunt toepassen. Het doel is niet perfectie vanaf dag één, maar een kleine set standaardbenaderingen die engineers begrijpen, die meeschalen met uw stack en die auditors kunnen volgen.

Een belangrijk ontwerpdoel is om verwijdering veiliger en goedkoper te maken dan het probleem te negeren. Dit betekent doorgaans dat verwijdering op schema- en pijplijnniveau moet worden gepland in plaats van dat het later moet worden toegevoegd.

Veilig verwijderen in productiedatabases en -services

Veilig verwijderen uit live databases betekent het verwijderen of anonimiseren van spelergegevens zonder de spelfunctionaliteit te verstoren, terwijl u er zeker van bent dat records niet stilletjes in vergeten tabellen blijven hangen. U kunt kiezen uit een paar hoofdpatronen en standaardiseer de patronen die passen bij uw risicobereidheid en operationele volwassenheid.

Voor databases met spelersaccounts, profielen, inventarissen en andere kerngegevens hebt u verschillende opties:

Fysieke rijverwijdering: – eenvoudige verwijderingsbewerkingen met passende cascadering, gevolgd door onderhoudstaken zoals vacuümzuigen of verdichten om indien nodig opslag terug te winnen.
Zacht verwijderen plus periodiek hard verwijderen: – records voor een korte periode als verwijderd markeren ter ondersteuning van accountherstel of operationele veiligheid, en vervolgens definitief verwijderen na een bepaald interval.
Indeling op tijd of huurder: – het structureren van tabellen of verzamelingen, zodat grote hoeveelheden oude gegevens in bulk kunnen worden verwijderd of gearchiveerd.

Welk patroon u ook kiest, u moet:

Scheid identificatoren waar mogelijk van minder gevoelige inhoud, zodat u met het verwijderen van een kleine koppeltabel effectief grote hoeveelheden gameplay-gegevens kunt anonimiseren.
Zorg ervoor dat de applicatielogica geen verwijderde gegevens uit caches, zoekindexen of afgeleide archieven 'ophaalt'.
Implementeer idempotente verwijderingsroutines, zodat het opnieuw proberen van een mislukte taak de integriteit niet verstoort of de status niet gedeeltelijk weergeeft.
Test cascade-delete- en referentiële-integriteitsgedrag grondig in niet-productieomgevingen, zodat voorzichtige databasebeheerders de impact kunnen zien voordat ze de live-gegevens aanpassen.

Documenteer deze patronen als onderdeel van je technische standaarden voor A.8.10 en koppel ze terug aan de retentieregels in je planning. Zo weten engineers bij de lancering van een nieuwe game of feature welk patroon ze moeten toepassen en hoe ze kunnen bewijzen dat het werkt.

Het ontwerpen van retentiegevoelige logs en telemetrie

Logs en telemetrie zijn essentieel voor het uitvoeren en verbeteren van games, maar ze vormen ook een van de meest onoverzichtelijke bronnen van persoonsgegevens en een veelvoorkomende bron van overmatige retentie die uw risico stilletjes vergroot. Het doel is niet om het loggen te stoppen of systemen uit te schakelen, maar om alleen vast te leggen wat u nodig hebt, dit zo lang mogelijk te bewaren en het vervolgens te verwijderen of directe links naar personen te verwijderen. Retentie en verwijdering moeten vanaf het begin in het ontwerp worden opgenomen.

Nuttige principes zijn onder meer:

Classificeer logs op doel: – beveiliging, fraude, gameplay-analyse en crashdiagnostiek kunnen elk verschillende bewaartermijnen rechtvaardigen.
Zorg ervoor dat u niet meer gegevens registreert dan nodig is: – neem geen volledige identificatiegegevens of payloads op als hashes, tokens of geaggregeerde statistieken voldoende zouden zijn.
Gebruik ingebouwde bewaarmaatregelen: – Bij de meeste logging- en telemetrieplatforms kunt u tijdgebaseerde bewaring en automatische verwijdering instellen; configureer deze in overeenstemming met uw planning.
Overweeg anonimisering: – voor oudere gegevens die alleen in geaggregeerde analyses worden gebruikt, vervangt u de identificatiegegevens door tokens of verwijdert u ze volledig na een bepaalde periode.

In de praktijk kan dit betekenen dat gedetailleerde beveiligingslogs gedurende een bepaalde periode worden bijgehouden, waarna grovere aggregaten worden bewaard voor trendanalyse, of dat fijnmazige gameplay-gebeurtenissen op spelerniveau gedurende een korte periode worden bewaard om functies te verfijnen en deze vervolgens worden samengevoegd tot geanonimiseerde cohorten. De sleutel is dat dit gedrag centraal wordt geconfigureerd en kan worden aangetoond, en niet aan individuele teams wordt overgelaten om ad hoc te beslissen.

Back-ups, archieven en cryptografische verwijdering

Back-ups en archieven zijn bedoeld om gegevens te bewaren. Veilig verwijderen gaat hier dus om het beheren van complete back-upsets in plaats van te proberen individuele spelers te wissen, terwijl u toch een geloofwaardig verhaal krijgt over wat er gebeurt wanneer de bewaartermijn verloopt. U vertrouwt op encryptie, tijdsgelimiteerde bewaartermijnen en gecontroleerde vernietiging van sleutels of media om aan te tonen dat verlopen gegevens in de praktijk niet langer toegankelijk zijn.

Back-ups vormen een bijzondere uitdaging, omdat ze specifiek ontworpen zijn om gegevens te bewaren, vaak in grote, ondoorzichtige blokken. Je kunt zelden de gegevens van één speler verwijderen uit een decennium aan volledige back-ups. In plaats daarvan beheer je het verwijderen op back-upsetsniveau.

Praktische stappen zijn onder meer:

Back-ups en archieven versleutelen: met sterke sleutels die apart van de gegevens worden beheerd.
Definieer back-upbewaartermijnen: die passen bij uw risicobereidheid en wettelijke verplichtingen. Ook voorkomt u dat u back-ups onbeperkt bewaart.
Zorg ervoor dat oude back-ups niet meer kunnen worden hersteld: door de relevante sleutels of media op een gecontroleerde, gedocumenteerde manier te vernietigen wanneer de bewaartermijn verloopt.
Vermijd het gebruik van back-ups als archieven: door langetermijngegevens te bewaren in speciaal gebouwde, toegangsgecontroleerde archieven met een duidelijke retentie in plaats van algemene herstelback-ups.

Cryptografische verwijdering – het onleesbaar maken van data door sleutels te verwijderen of in te trekken – is vaak de enige praktische manier om te voldoen aan A.8.10 voor grootschalige back-ups en gedistribueerde object stores. Dit is afhankelijk van robuust sleutelbeheer; als sleutels in meerdere datasets worden hergebruikt of slecht worden beveiligd, zijn uw garanties zwakker. Cryptografische verwijdering, mits zorgvuldig toegepast, combineert operationele veerkracht met sterke garanties dat verlopen data daadwerkelijk verdwenen zijn, wat zowel spelers als uw studio beschermt bij incidenten.

Bestuur, rollen en uitzonderingen: verwijdering laten werken in een live-gamesbedrijf

Veilig verwijderen werkt alleen als iedereen weet wie wat beslist, wie het werk doet en hoe uitzonderingen worden afgehandeld. Anders stapelen oude spelersgegevens zich ongemerkt op terwijl moeilijke gesprekken worden uitgesteld. Duidelijk beheer maakt van A.8.10 een normaal onderdeel van de werking van je games en services.

Verwijderen is geen een-team-oefening. Beveiliging kan het niet alleen, engineering kan het niet alleen, en privacy of LiveOps evenmin. Om A.8.10 zonder voortdurende frictie te laten werken, is duidelijke governance nodig: wie neemt welke beslissingen, wie implementeert ze, wie controleert of ze werken en hoe uitzonderingen worden afgehandeld.

Zonder die duidelijkheid wordt verwijdering een reeks ongemakkelijke gesprekken en vastgelopen tickets, wat mensen ertoe aanzet het onderwerp helemaal niet meer aan te kaarten. Voor teams die net beginnen met hun ISO 27001-traject, voorkomt het vroegtijdig vastleggen van deze verantwoordelijkheden dat een of twee mensen al het werk rustig kunnen verwerken.

Bepalen wie wat bezit

Het definiëren van eigenaarschap voor beslissingen over bewaren en verwijderen voorkomt verwarring en vingerwijzen, omdat iedereen kan zien wie verantwoordelijk is en wie verantwoordelijk is. Een eenvoudige RACI-matrix die aangeeft wie verantwoordelijk, aansprakelijk, geraadpleegd en geïnformeerd is, maakt duidelijk wie regels moet ondertekenen en wie de technische controles moet uitvoeren.

Een eenvoudige RACI-matrix (Responsible, Accountable, Consulted, Informed) voor verwijdering kan veel verwarring voorkomen. Typische patronen zijn onder andere:

Beveiliging of de CISO-functie: – verantwoordelijk voor het waarborgen dat A.8.10 wordt geïmplementeerd als onderdeel van het ISMS; geraadpleegd over de gevolgen van risico’s.
Privacy of de DPO: – verantwoordelijk voor het waarborgen dat het bewaren en verwijderen van gegevens in overeenstemming is met de wetgeving en de rechten van spelers.
Data- en platformengineering: – verantwoordelijk voor de implementatie en uitvoering van technische verwijdering of anonimisering.
LiveOps en product: – advies gegeven over de impact van behoud en verwijdering op spelactiviteiten en analyses.
Spelerondersteunings- en communityteams: – verantwoordelijk voor het afhandelen van communicatie met spelers en het doorverwijzen van complexe gevallen.

Zodra deze rollen zijn overeengekomen, kunt u ze inbouwen in secties voor beleidsverantwoordelijkheid, workflows voor wijzigingsbeheer en onboarding voor nieuwe systemen en leveranciers. Op die manier is er, wanneer iemand vraagt "wie bepaalt hoe lang chatlogs bewaard moeten blijven?", een ander antwoord dan "het hangt ervan af met wie je praat", en kunnen beslissingen over verwijdering in hetzelfde tempo verlopen als de gameontwikkeling.

Uitzonderingen ontwerpen zonder de controle te verliezen

Vrijwel elke studio heeft uitzonderingen op de standaard bewaartermijnen nodig om fraude-, veiligheids- of juridische redenen. Het gevaar is echter dat deze uitzonderingen uit gewoonte permanent worden. Een soepel maar gedisciplineerd uitzonderingsproces stelt u in staat om belangrijke gegevens te bewaren wanneer dat nodig is, bijvoorbeeld tijdens onderzoeken naar fraude of toezichthoudende instanties, zonder uw volledige verwijderingsstrategie stilletjes te ondermijnen.

Vrijwel elke studio heeft uitzonderingen op de standaard bewaartermijnen nodig. Fraude, vals spelen, ernstige veiligheidsincidenten en onderzoeken door toezichthouders vereisen soms dat u gegevens langer bewaart dan normaal. Het risico is dat uitzonderingen zich informeel opstapelen en niemand er ooit op terugkomt.

Een robuuste aanpak is om:

Vraag om een gedocumenteerde rechtvaardiging voor een verlengde bewaartermijn, inclusief juridische of wettelijke verwijzingen indien van toepassing.
Stel voor elke uitzondering een beoordelingsdatum of -voorwaarde in, bijvoorbeeld ‘totdat onderzoek X is afgesloten plus twee jaar’.
Beperk de toegang tot de opslag met verlengde retentie tot de kleinste groep die deze daadwerkelijk nodig heeft.
Beoordeel openstaande uitzonderingen op een regulier bestuursforum en sluit ze wanneer ze niet langer nodig zijn.

Een goed uitzonderingsrapport zou er bijvoorbeeld zo uit kunnen zien: "Fraudegeval F-123 – bewaar gerelateerde transactie-, apparaat- en netwerklogboeken tot 31 december 2028; eigenaar: Hoofd Fraude; controleer elk kwartaal de risicocommissie." Deze mate van specificiteit zorgt ervoor dat iedereen op één lijn zit en biedt u een duidelijk audittraject, dat zowel ISO 27001-audits als wettelijke controles ondersteunt.

Het trainen van frontlinieteams en het afstemmen van LiveOps

Frontlineteams vertalen je verwijderingsbeleid naar beloftes voor spelers. Als support- en communityteams 'accountverwijdering' anders omschrijven dan hoe je systemen zich gedragen, creëer je zowel vertrouwens- als complianceproblemen. Door training, scripts en LiveOps-planning af te stemmen op je A.8.10-controles, voorkom je deze hiaten.

Spelers, ouders en zelfs partners nemen vaak als eerste contact op met de frontlinieteams: support, communitymanagers, LiveOps. Als die teams niet duidelijk kunnen uitleggen wat "account verwijderen" inhoudt, of erger nog, dingen beloven die technisch gezien niet kloppen, creëer je zowel vertrouwens- als complianceproblemen.

Daarom moet u:

Zorg voor eenvoudige uitleg en interne FAQ's waarin in begrijpelijke taal wordt beschreven wat er wordt verwijderd, wat om juridische redenen kan worden bewaard en hoe lang dat moet duren.
Train medewerkers om te herkennen wanneer een verzoek juridische beperkingen of complexe uitzonderingen tot gevolg kan hebben en hoe ze dit op de juiste manier kunnen escaleren.
Stem de LiveOps-planning af op aankomende wijzigingen in behoud of verwijdering, zodat telemetrie- of segmentatiestrategieën tijdig worden aangepast.

Wanneer iedereen begrijpt dat veilig verwijderen er is om spelers en de studio te beschermen, niet om goede ideeën te blokkeren, krijg je minder last-minute conflicten tussen product en compliance – en meer doordachte ontwerpen die beide ondersteunen. Dat verlaagt op zijn beurt de kosten van incidenten, beperkt de blootstelling aan regelgeving en bouwt vertrouwen op de lange termijn op bij spelers.

ISMS.online ondersteunt meer dan 100 normen en voorschriften, waardoor u één platform krijgt voor al uw compliancebehoeften.

Boek uw demo

Cloud, leveranciers en gedeelde verantwoordelijkheid voor verwijdering

Moderne games zijn sterk afhankelijk van cloud- en software-as-a-serviceproviders, maar je blijft verantwoordelijk voor hoe spelergegevens in je stack worden opgeslagen en verwijderd. A.8.10 moet daarom verder reiken dan je eigen systemen en ook contracten, configuraties en risicobeoordelingen van leveranciers bevatten, zodat gegevens niet langer dan nodig worden bewaard, alleen omdat ze op het platform van iemand anders staan.

Een klein deel van een moderne gamestack bevindt zich uitsluitend in uw eigen datacenter. Identiteit, betalingen, analyses, marketing, community, support en zelfs core backends kunnen allemaal afhankelijk zijn van cloud- en software-as-a-serviceproviders. ISO 27001 A.8.10 is nog steeds van toepassing; het betekent alleen dat uw verwijderingsstrategie ook die providers moet omvatten.

U kunt er niet zomaar op vertrouwen dat "de leverancier het afhandelt". U moet begrijpen, documenteren en, waar nodig, contractueel vastleggen wie wat, waar en wanneer verwijdert. Dit is vooral belangrijk wanneer aanbieders verwijzen naar hun eigen certificeringen; afstemming op één framework garandeert niet dat hun bewaartermijnen overeenkomen met die van u of dat ze uw tijdschema's voor verwijdering ondersteunen.

Het model van gedeelde verantwoordelijkheid begrijpen

Door het model van gedeelde verantwoordelijkheid te begrijpen, kunt u zien welke verwijderingsmechanismen u zelf beheert en welke bij de provider liggen, zodat u realistische controles kunt ontwerpen in plaats van aannames. U bepaalt welke spelergegevens naar een service stromen, hoe lang deze blijven en wanneer u verwijdering aanvraagt, terwijl de provider verantwoordelijk is voor hoe zijn eigen infrastructuur wordt gewist of gerecycled.

Cloudproviders hebben het vaak over gedeelde verantwoordelijkheid: zij beveiligen de infrastructuur, u beveiligt hoe u deze gebruikt. Voor verwijdering is dit vaak ongeveer als volgt verdeeld:

Infrastructuur als een service: – u beheert de besturingssystemen, databases en applicatiegegevens; de provider beheert de fysieke media en de laagdrempelige sanering.
Platform als een service: – U beheert uw gegevens en configuraties binnen beheerde services; de provider beheert de back-ups en onderliggende systemen.
Software als een service: – u beheert doorgaans de configuratie en gebruikspatronen, terwijl de leverancier vrijwel alles anders beheert.

Voor elke belangrijke dienst moet u het volgende kunnen beantwoorden:

Welke gegevens over uw spelers worden hier opgeslagen?
Wie kan behoud en verwijdering configureren?
Wat gebeurt er met uw gegevens als u een account of record verwijdert?
Hoe gaat de provider om met back-ups en met het retourneren of vernietigen van gegevens na afloop van het contract?

Het documenteren van deze antwoorden maakt deel uit van zowel A.8.10 als andere ISO 27001-maatregelen rondom cloudgebruik. Het geeft u een duidelijkere basis voor leveranciersselectie en -onderhandelingen.

Het contractueel vastleggen van het verwijderen

Verwijdering is veel betrouwbaarder wanneer dit in contracten is vastgelegd in plaats van informeel te worden afgehandeld, omdat u een duidelijke basis hebt om uw verwachtingen kenbaar te maken. Uw gegevensverwerkingsovereenkomsten en beveiligingsschema's moeten de bewaartermijnen, ondersteuning voor verzoeken tot verwijdering en hoe gegevens aan het einde van de relatie worden behandeld, specificeren.

Beleid en goede bedoelingen zijn niet voldoende wanneer andere organisaties uw gegevens beheren. Uw contracten, gegevensverwerkingsovereenkomsten en beveiligingsschema's moeten het volgende bevatten:

Maximale bewaartermijnen voor gegevens nadat deze uw systemen verlaten.
Verplichtingen om te helpen bij verzoeken tot verwijdering van spelers binnen de overeengekomen termijnen.
Hoe back-ups, logs en archieven worden behandeld aan het einde van de bewaartermijn of bij beëindiging van het contract.
Welke bewijsstukken de provider u verstrekt, zoals verwijderingslogboeken of certificaten, en onder welke omstandigheden.

Zorg er ook voor dat uw leveranciersrisicobeoordelingen verwijdering expliciet behandelen. Als een leverancier zijn eigen datalevenscyclus en verwijderingspraktijken niet kan beschrijven, of als hij uitsluitend vertrouwt op generieke certificeringen zonder gedetailleerde retentie, is dat een belangrijk signaal om voorzichtig te zijn of om sterkere voorwaarden te onderhandelen. De verwachtingen van de sector zijn steeds meer gericht op duidelijke, schriftelijke verwijderingsafspraken in contracten.

De export van derde partijen onder controle houden

Exports van derden creëren vaak onbeheerde kopieën van spelergegevens die buiten de normale controle vallen, wat zelfs een goed ontworpen verwijderingsstrategie stilletjes kan ondermijnen. Dashboards, csv-exporten en gesynchroniseerde datasets zijn handig, maar als je ze geen expliciete bewaartermijnen geeft, kunnen ze jarenlang onopgemerkt blijven.

Zelfs als de kernservices goed functioneren, kunnen er gegevens in onbeheerde hoeken lekken via:

Handmatige export van dashboards naar spreadsheets.
Gegevenssynchronisatie met business intelligence-tools.
Bijlagen en bestanden in ticketing- of samenwerkingssystemen.

Deze kopieën zijn gemakkelijk te vergeten en moeilijk gericht te verwijderen. Om het risico te verkleinen:

Minimaliseer ad-hoc-exporten waar mogelijk en geef de voorkeur aan in-place analysetools.
Indien export noodzakelijk is, sla deze dan op in gecontroleerde locaties met bewaartermijnen.
Neem deze patronen op in uw levenscyclusdiagram en de training van uw personeel, zodat ze niet over het hoofd worden gezien.

In veel studio's wordt het probleem al aanzienlijk verminderd door teams bewust te maken van het risico en een beter alternatief te bieden – zoals gecentraliseerde rapporten of dashboards. Dat verkleint op zijn beurt de kans dat een onderzoek of inbreuk gegevens aan het licht brengt waarvan niemand wist dat ze bestonden.

Boek vandaag nog een demo met ISMS.online

ISMS.online helpt u ISO 27001 A.8.10 om te zetten van een vage verwijderingsregel naar een duidelijke, controleerbare set controles die de risico's van niet-verwijderde spelergegevens en retentiegevoelige logs voor al uw titels en diensten verminderen. Door uw beleid, gegevensinventarissen, bewaartermijnen, technische normen en bewijsmateriaal te centraliseren, geeft het platform u één betrouwbaar overzicht van hoe informatie wordt beheerd door studio's en leveranciers.

Bekijk uw A.8.10-verdieping op één plek

Wanneer u uw ISO 27001-werkzaamheden beheert in een speciale omgeving zoals ISMS.online, profiteert u van verschillende voordelen:

Uw retentie- en verwijderingsmatrices worden gecombineerd met risicobeoordelingen en toepasbaarheidsverklaringen, zodat u precies kunt laten zien hoe A.8.10 en A.5.32 samenwerken om de geïdentificeerde risico's te beperken.
Levenscyclusdiagrammen, systeeminventarissen en leveranciersgegevens worden levende artefacten die worden bijgewerkt naarmate uw games en stack evolueren, in plaats van dat ze vastzitten in vergeten diapresentaties.
Bewijs van verwijderingen – van configuratie-exporten tot interne auditnotities – kan rechtstreeks worden gekoppeld aan de controles die ze ondersteunen, waardoor audits minder snel op het laatste moment hoeven te worden uitgevoerd.

Voor teams die de coördinatie verzorgen op het gebied van beveiliging, privacy, data, engineering en LiveOps, zorgt deze gedeelde visie ervoor dat verwijdering van een vaag idee verandert in een concreet, traceerbaar werkprogramma. Het biedt ook minder ervaren studio's een structuur om te volgen wanneer ze voor het eerst controles formaliseren. Een ISMS-platform kan ook uw levenscyclusoverzichten, bewaarschema's en leveranciersrecords op één plek bewaren, zodat u niet hoeft te proberen het A.8.10-verhaal samen te stellen uit verspreide documenten en individuele herinneringen.

Volgende stappen voor uw studio

Als u zich in uw eigen omgeving herkent in de hierboven beschreven uitdagingen, kan een kort, gericht gesprek voldoende zijn om te zien hoe het er beter uit kan zien. U kunt ervoor kiezen om:

Loop door de levenscyclus van spelergegevens van één titel en ontdek waar de huidige verwijderings- en bewaarmaatregelen tekortschieten.
Bekijk hoe uw bestaande ISO 27001-documentatie opnieuw kan worden gebruikt en versterkt om A.8.10 dieper te behandelen.
Ontdek hoe workflows, taaktoewijzingen en dashboards ervoor kunnen zorgen dat verschillende teams op één lijn zitten over wie wat moet doen en wanneer, zodat het verwijderen op schema blijft.

Boek een demo bij ISMS.online en zie hoe alle onderdelen van Bijlage A.8.10 – van wettelijke bewaartermijnen en levenscyclusmapping tot technische verwijderingspatronen en auditbewijs – kunnen worden samengebracht in één beheersbaar systeem. Zo behoudt u de gegevens van spelers, vermindert u de impact van incidenten, bent u tevreden met auditors en toezichthouders en kunt u vol vertrouwen geweldige games blijven leveren.

Demo boeken

Veelgestelde Vragen / FAQ

Hoe moet een gamestudio het verwijderen van spelergegevens heroverwegen onder ISO 27001 A.8.10?

U moet het verwijderen van spelergegevens als een ontworpen, bewezen fase in de levenscyclus, en niet een ad-hoc gunst die u verleent via supporttickets.

Hoe verandert A.8.10 de alledaagse aannames over ‘verwijdering’?

Onder ISO 27001 A.8.10 wordt "we verwijderen accounts wanneer spelers daarom vragen" het absolute minimum, niet het operationele model. De clausule verwacht van u dat u:

Behandel elke categorie spelersgegevens (accounts, betalingen, chat, telemetrie, anti-cheat, ondersteuning) als een beheerd vermogen met een doel, een eigenaar en een gedefinieerde eindtoestand.
Bepaal vooraf wanneer elke categorie van plaats verandert actief gebruik (nodig om het spel te runnen of te beschermen) om gerechtvaardigde retentie (belasting, geschillen, fraude, veiligheid) en tenslotte naar verwijdering of anonimisering.
Verander die beslissingen in herhaalbare technische patronen: vaste soft-delete-vensters, geplande harde verwijderingen, anonimiseringstaken en levenscyclusregels in opslag- en logplatforms.
vangen bewijs dat deze patronen doorlopen: taaklogboeken, wijzigingsrecords, configuratie-exporten en voorbeeldcontroles die uw ISMS naast de A.8.10-besturing kan bijhouden.

De echte verschuiving is van improvisatie naar voorspelbaarheidEen studio die precies weet waar nog identificeerbare spelers zijn, waar alleen nog geanonimiseerde cohorten over zijn en wat volledig verouderd is, heeft een kleinere reikwijdte als er iets misgaat en een duidelijker verhaal als het gaat om de uitleg aan auditors of platforms.

Hoe kan een ISMS deze denkwijze in de praktijk brengen?

Met een informatiebeveiligingsbeheersysteem hebt u één plek waar u al uw informatie kunt koppelen beleid, risico en implementatie:

U bewaart gegevenscategorie-inventarissen, bewaartermijnen en verwijderingsnormen in één werkruimte.
Elke A.8.10-controle is gekoppeld aan specifieke risico's, systemen en operationele procedures, en bestaat niet uit abstracte bewoordingen.
Interne audits, goedkeuringen van wijzigingen en incidentbeoordelingen kunnen allemaal naar dezelfde artefacten verwijzen, dus verwijdering wordt hoe je games bouwt en bedient, geen eenmalige opruimactie vóór de certificering.

Wanneer je een auditor rustig kunt begeleiden van risicoregister → retentieregels → technische patronen → bewijs, lijkt het erop dat je studio het vertrouwen van spelers op de lange termijn begrijpt, niet alleen de levering van functies op de korte termijn. Een ISMS zoals ISMS.online maakt die begeleiding veel eenvoudiger door controles, registraties en verantwoordelijkheden nauw met elkaar te verbinden en altijd up-to-date te houden.

Hoe kunnen we schema's voor het bewaren van spelergegevens opstellen die fraude, beveiliging en analytische waarde beschermen?

Je ontwerpt retentie rondom waarom u elke categorie aanhoudt en welke wet of welk contract dit toestaat, niet rond welke database of welk dashboard het belangrijkst lijkt.

Hoe bouwen we een retentiematrix die voor alle games werkt?

De meeste studio's hebben baat bij een enkele retentiematrix die het volledige scala aan spelergegevenstypen bestrijkt:

Account en identiteit (inloggegevens, contactgegevens, leeftijdsmarkeringen)
Betalingen en factureringsgegevens
Chatten en sociale interacties
Beveiligings- en infrastructuurlogboeken
Anti-cheat- en fraude-indicatoren
Gameplay-telemetrie en UX-analyse
Support- en communitytickets

Voor elke rij legt u vier dingen vast:

Doel: – waarom u deze verzamelt (om het spel te bedienen, spelers te factureren, de veiligheid te waarborgen, fraude te bestrijden, het ontwerp te verbeteren).
Wettelijke / contractuele basis: – consumentenrecht, belastingregels, PCI DSS, platformvoorwaarden, privacywetgeving enzovoort.
Minimale retentie: – wat u moet bijhouden om te blijven voldoen aan de wetgeving (bijvoorbeeld belastinggegevens of terugboekingstermijnen).
Maximale retentie voor identificeerbare gegevens: – het moment waarop u personen verwijdert of anonimiseert, zelfs als u samengevoegde patronen behoudt.

Fraude en beveiliging zijn zaken waar teams vaak de neiging hebben om alles voor altijd te bewaren. A.8.10 voorkomt geen langere periodes waarin het risico dit echt rechtvaardigt, maar verwacht wel dat u:

Geef die categorieën expliciete, beredeneerde tijdsduren (bijvoorbeeld een geschilperiode plus een bepaalde buffer).
Scheid ruwe, identificeerbare gegevens van afgeleide signalen (risicoscores, gehashte identificatoren, geanonimiseerde cohorten), zodat u signalen langer kunt bewaren dan identiteit.
Behandel ongebruikelijke onderzoeken als tijdgebonden uitzonderingen, elk met een eigenaar en een beoordelingsdatum, in plaats van onuitgesproken permanente uitzonderingen.

Op het gebied van analyse hangen de meeste ontwerpbeslissingen af van patronen in plaats van specifieke spelersHiermee kunt u de retentie voor telemetrie met volledige betrouwbaarheid verkorten en oudere gegevens naar geaggregeerde of geanonimiseerde weergaven die product- en datateams nog steeds kunnen raadplegen. Het dwingt je ook om exports (BI-extracten, CSV-dumps, sandbox-datasets) in dezelfde levenscyclus op te nemen in plaats van ze als onzichtbare langetermijnkopieën te laten staan.

Waar moeten deze regels gelden zodat ze realistisch blijven?

Bewaartermijnen vervallen snel als ze verborgen zitten in e-mailthreads of geïsoleerde spreadsheets. Wanneer u ze beheert in een ISMS:

Privacy, beveiliging, analyse en techniek kunnen allemaal hun goedkeuring geven aan een enkele, gedeelde matrix.
Beoordelingen kunnen worden gekoppeld aan uw risico-register en de managementbeoordelingscyclus.
Bewijsstukken zoals configuratieschermafbeeldingen, beleidsbevestigingen en steekproefresultaten worden naast de regels weergegeven, zodat u auditors beide kunt laten zien de beslissing en hoe deze in de praktijk verloopt.

Als u A.8.10 wilt omzetten van een zorg naar een ontwerptool, maakt het centraliseren van die matrix in een platform zoals ISMS.online een groot verschil. U krijgt een eenduidig beeld van retentie dat aansluit bij ISO 27001, privacyverplichtingen en uw live-operationele realiteit.

Wat houdt veilig verwijderen van gamedatabases, logs, telemetrie en back-ups eigenlijk in?

Veilige verwijdering betekent dat zodra gegevens het vastgestelde einde van hun levensduur bereiken, ze worden verwijderd. niet meer praktisch met redelijke inspanning te verhalen, over live systemen, analyse stacks en back-ups.

Hoe gaan we om met live services en databases?

Voor kerndiensten die accounts, rechten, inventarissen en vergelijkbare spelersgegevens bevatten, combineert veilig verwijderen doorgaans het volgende:

Acties op applicatieniveau: , zoals het verwijderen of anonimiseren van records op rijniveau zodra aan een bewaartermijn is voldaan of een verzoek tot wissen is gevalideerd.
Tijdgebaseerde partitionering: , zodat hele tabelpartities of shards (bijvoorbeeld per maand of seizoen) kunnen worden verwijderd, waardoor dure opruimacties per rij worden vermeden.
Routinematig onderhoud van de opslag – verdichten of stofzuigen – zodat ‘verwijderde’ records niet voor onbepaalde tijd in niet-toegewezen ruimte blijven liggen.

De sleutel is om deze als volgt uit te drukken: huispatronen, geen individuele keuzes van ontwikkelaars. Een eenvoudige interne standaard zoals "accounts gebruiken patroon A; transactiegeschiedenis gebruikt patroon B; inventarissen gebruiken patroon C" maakt gedrag voorspelbaar over titels heen en veel gemakkelijker te documenteren volgens A.8.10.

Hoe zit het met logs, telemetrie en langetermijnopslag?

Logstreams en telemetrie bevatten vaak rijkere spelercontext dan de primaire gamedatabase. In die systemen is veilig verwijderen sterk afhankelijk van de configuratie:

Ingebouwd retentie- en rotatiecontroles in logging- en observatietools, verschillend afgestemd op gameplay, prestatie- en beveiligingsstromen.
Vroegtijdige minimalisatie – het hashen, afkappen of tokeniseren van identificatoren dicht bij de bron – zodat niet elke logregel de volledige identiteit blootlegt, gevolgd door anonimisering of downsampling naarmate de gegevens ouder worden.
Levenscyclusregels in objectopslag of datalakes die datasets laten verlopen of archiveren en coördineren met sleutelbeheer, waarmee u encryptiesleutels kunt verwijderen wanneer gegevens effectief verloren moeten gaan.

Back-ups zijn het moment waarop het fysiek wissen van elke kopie niet meer realistisch is. Veel volwassen studio's maken gebruik van cryptografische uitwissing In plaats daarvan: versleutel discrete datasets met sleutels met een bepaald bereik en behandel de geplande sleutelverwijdering als de verwijderingsgebeurtenis. In combinatie met levenscyclusbeleid en sleutelbeheerlogboeken wordt dit door auditors en toezichthouders algemeen geaccepteerd als een praktische manier om te voorkomen dat leesbare geschiedenis wordt bewaard.

De werkende test is eenvoudig: voor elke belangrijke opslagplaats van spelergegevens kunt u drie vragen beantwoorden: wat er gebeurt als de retentie eindigt, wie deze activeert en hoe u dit bewijstMet een ISMS zoals ISMS.online kunt u ervoor zorgen dat deze antwoorden consistent zijn en in meerdere databases, logplatforms en back-upregimes worden weergegeven.

Hoe kan een gamestudio de levenscyclus van spelergegevens zo in kaart brengen dat ISO 27001 A.8.10 voor iedereen logisch is?

Je brengt de levenscyclus in kaart, zodat mensen A.8.10 zien als een gedeelde foto van hoe spelergegevens stromen, niet als een paragraaf in een norm.

Hoe ziet een praktische levenscycluskaart eruit?

Voor een belangrijke titel zou een levenscycluskaart die mensen daadwerkelijk helpt, het volgende kunnen doen:

Begin waar de gegevens verschijnen: account aanmaken, aanmelden, aankopen, gameplay-gebeurtenissen, chat, anti-cheat-tests, ondersteuningscontacten, marketinginvoerpunten.
Laat zien waar gegevens als volgende terechtkomen: accountservice, matchmaking, anti-cheat, telemetrieverzamelaars, datawarehouse, logplatforms, CRM en communitytools.
Onderscheiden actieve systemen, warme opslag, archief en verwijdering/anonimisering stadia.
Markeer de gebeurtenissen die de bewaartermijnen starten (laatste activiteit, einde abonnement, einde terugboekingsvenster) en de processen of taken die in actie komen als die punten bereikt zijn.
Neem minder voor de hand liggende schaduwen op: testomgevingen die zijn gevuld vanuit de productieomgeving, sandboxes voor datawetenschap, CSV-exporten en lokale kopieën voor ontwikkelaars.

Zodra die visie voor één game bestaat, kun je het patroon standaardiseren en aanpassen voor andere titels, in plaats van telkens opnieuw retentie te moeten ontwerpen. Nieuwe systemen of leveranciers moeten dan aangeven waar ze zich in de levenscyclus bevinden en hoe ze dezelfde overgangen eren.

Hoe verhoudt dit zich tot A.8.10 en uw ISMS?

Met het levenscyclusartefact waarnaar in uw ISMS wordt verwezen, kunt u:

Link A.8.10 direct naar benoemde overgangspunten: waar gegevens niet meer actief worden gebruikt, wanneer timers starten en waar verwijdering of anonimisering van toepassing is.
Wijs op elk punt verantwoordelijkheden toe, zodat duidelijk is wie de retentie instelt, wie taken uitvoert en wie het bewijsmateriaal controleert.
Hergebruik de kaart in ontwerpbeoordelingen, goedkeuringen van wijzigingen en leveranciersbeoordelingen, dus de teams voor beveiliging, privacy en engineering gaan uit van hetzelfde diagram in plaats van concurrerende aannames.

Door die kaart, de bijbehorende regels en de bijbehorende procedures in ISMS.online te bewaren, wordt levenscyclusdenken onderdeel van je normale governance. Managementbeoordelingen en interne audits kunnen na incidenten de vraag stellen "waar bevonden deze gegevens zich in de levenscyclus?", en zo begint A.8.10 te voelen als onderdeel van goed gamedesign, in plaats van als een vinkje.

Wie zou in de livegamesindustrie verantwoordelijk moeten zijn voor beslissingen over het bewaren en verwijderen van gegevens, en hoe voorkomen we dat uitzonderingen zich verspreiden?

Bewaring en verwijdering worden betrouwbaar wanneer ze duidelijk eigenaarschap, een eenvoudige beslissingslus en zichtbare tracking van uitzonderingen.

Hoe wijzen we rollen toe zonder bureaucratie te creëren?

In de praktijk kiezen de meeste livestudio's voor een lichtgewicht RACI-stijl verdeling:

Een beveiligings- of CISO-functie is verantwoordelijk voor het voldoen aan A.8.10 voor alle titels en gedeelde services.
Een privacy- of juridische functie is verantwoordelijk om ervoor te zorgen dat het bewaren en verwijderen van gegevens in overeenstemming is met de wet, de verplichtingen van het platform en wat u aan uw spelers vertelt.
Data- en platformengineeringteams zijn verantwoordelijk voor het implementeren en bedienen van verwijderings- en anonimiseringspatronen in code, infrastructuur en gegevenspijplijnen.
LiveOps, product en analyse zijn geraadpleegd zodat retentieperiodes niet stilletjes fraudebestrijding, experimentontwerp of de spelerservaring ondermijnen.
Ondersteunings- en gemeenschapsteams zijn verantwoordelijk voor het verwerken van verzoeken van spelers, het beheren van verwachtingen en het signaleren van ongebruikelijke gevallen die tot tijdelijke verlengingen kunnen leiden.

Om te voorkomen dat uitzonderingen uw model langzaam uithollen, voegt u een lichte governance-lus toe in plaats van een nieuw comité:

Eventuele verlengde bewaartermijnen voor onderzoeken, fraudegevallen of veiligheidsredenen worden vastgelegd met een reden, een eigenaar en een beoordelingsdatum.
Deze gegevens worden beoordeeld in hetzelfde ritme als uw andere risico- en compliance-onderwerpen, bijvoorbeeld in kwartaallijkse ISMS-managementbeoordelingen.
Een kleine set A.8.10-metrieken, zoals tijdige afhandeling van verzoeken tot wissen, aantal te laat ingediende uitzonderingenen systemen missen nog steeds gedefinieerde regels – in de reguliere berichtgeving voorkomt.

Wanneer je dit beheert in een ISMS-platform zoals ISMS.online, kunnen dezelfde workflows die incidenten, wijzigingen en risico's afhandelen, ook beslissingen over retentie en verwijdering bevatten. Zo blijft wat je daadwerkelijk met spelersgegevens doet, afgestemd op wat je spelers, partners en toezichthouders vertelt, zelfs wanneer de studio nog in de lanceringsfase zit of brandjes aan het blussen is.

Hoe veranderen cloudservices en -leveranciers onze aanpak voor A.8.10, en wat moeten we opnemen in contracten en configuraties?

Cloud- en SaaS-diensten veranderen waar en hoe spelergegevens worden opgeslagen en verwijderd, maar ze veranderen niets aan de realiteit dat jouw studio is nog steeds verantwoordelijk om te bepalen wat er bewaard wordt, hoe lang en wanneer het verwijderd of geanonimiseerd moet worden.

Wat moeten we vastleggen voor elke dienst die met spelergegevens te maken heeft?

Voor elke aanbieder die speler-ID's of gedragsgegevens bewaart, moeten uw ISMS-records het volgende vermelden:

Welke spelergegevenscategorieën het opslaat (ID's, contactgegevens, betalingstokens, chatlogs, telemetrie, ondersteuningsrecords) en voor welke titels, regio's of platforms.
Welke opties voor behoud en verwijdering U kunt het volgende beheren: schuifregelaars voor logboekbewaring, regels voor de levenscyclus van objectopslag, ingebouwde hulpmiddelen voor het wissen van gegevens en gedrag bij het sluiten van accounts.
Hoe verwijdering in de praktijk wordt geactiveerd – door configuratie, geplande processen, API-aanroepen of supporttickets – en wat dat betekent voor back-ups, replica's en analyse-exporten.
Wat bewijzen U kunt het volgende verzamelen en bewaren: configuratie-exporten, auditlogs, SOC 2- of ISO 27001-rapporten, leveranciersverklaringen over back-upverwerking en het opschonen van media aan het einde van het contract.

Deze details vormen twee belangrijke artefacten:

Jouw interne levenscyclus- en retentiematrix, waar externe opslagplaatsen naast interne databases en logplatforms verschijnen.
Uw contracten en gegevensverwerkingsovereenkomsten, die verwachtingen moet scheppen voor maximale retentie, ondersteuning bij wissen, back-upbehandeling en gedrag bij beëindiging of migratie.

Leveranciersrisicobeoordelingen moeten verwijdering en retentie behandelen als vragen op hetzelfde niveau als encryptie en toegangscontrole. Als een leverancier niet kan voldoen aan de levenscyclus die u voor de gegevens van uw spelers hebt gedefinieerd, wordt dat een bewuste risicobeslissing voor uw beveiligings- en privacymanagers in plaats van een onbedoelde inbreuk onder druk van de release.

Wanneer u deze verwachtingen, configuraties en bewijsstukken binnen ISMS.online beheert, behoudt u een consistente A.8.10-laag, zelfs als uw leveranciersmix evolueert. U kunt laten zien welke services welke categorieën spelergegevens bewaren, hoe lang ze deze bewaren, hoe u verwijdering of anonimisering activeert en waar u het bewijs daarvan opslaat – precies de duidelijkheid die platforms, toezichthouders en spelers zoeken bij het bepalen of ze een gamestudio op de lange termijn vertrouwen.

Wij zijn een leider in ons vakgebied

Regionale leider - Winter 2026 Middenmarkt EU

Regionale leider - Winter 2026 Middenmarkt EMEA

"ISMS.Online, uitstekende tool voor naleving van regelgeving"
— Jim M.

"Maakt externe audits een fluitje van een cent en koppelt alle aspecten van uw ISMS naadloos aan elkaar"
— Karen C.

"Innovatieve oplossing voor het beheer van ISO en andere accreditaties"
— Ben H.

ISO 27001 A.8.10 – Veilige verwijdering van spelergegevens en logs met gevoelige retentie