Warum nicht gelöschte Spielerdaten zu einem strategischen Risiko geworden sind
Spielerdaten, die nicht rechtzeitig gelöscht werden, entwickeln sich schnell zu einem Sicherheits-, Datenschutz- und Regulierungsrisiko für Ihr Studio. Wenn Telemetriedaten, Chatprotokolle und Supporthistorien nicht endgültig gelöscht werden, zieht jeder Verstoß oder jede Anfrage unnötige Mehrarbeit, zusätzliche Systeme und Beweise nach sich. Die Behandlung von Daten am Ende ihres Lebenszyklus als kontrollierbares Risiko ermöglicht es Ihnen, die Auswirkungen von Vorfällen zu minimieren, Untersuchungen zu vereinfachen und den Missbrauch von Informationen einzuschränken.
Spielerdaten stehen heute im Spannungsfeld von Umsatz, Regulierung und Reputation. Unkontrollierte Datenspeicherung erhöht daher unbemerkt Ihr Risiko. Anhang A.8.10 der ISO 27001:2022 schreibt ausdrücklich vor, dass Informationen gelöscht werden müssen, sobald sie nicht mehr benötigt werden. Die Löschung muss so erfolgen, dass eine Wiederherstellung ausgeschlossen ist und alle rechtlichen, regulatorischen, vertraglichen und internen Anforderungen erfüllt werden. Diese Formulierung trägt sowohl dem Datenschutz als auch der klassischen Informationssicherheit Rechnung.
Die meisten Studios wissen bereits, wie sie Live-Systeme schützen; weitaus weniger können jedoch verlässlich nachweisen, was mit Daten geschieht, wenn diese „nicht mehr benötigt“ werden. Genau diese Lücke schließt A.8.10. Es fordert Sie auf, alte Playerdaten und Protokolle nicht länger als harmlose Archive zu behandeln, sondern als Assets, die gezielt gelöscht werden müssen. Ob Sie ISO 27001 zum ersten Mal implementieren oder ein ausgereiftes ISMS stärken – diese Kontrollmaßnahme verbindet Aufbewahrungsfristen mit der tatsächlichen Löschung.
Daten, die Sie nie erhoben oder rechtzeitig gelöscht haben, können niemals gestohlen, beschlagnahmt oder gegen Sie verwendet werden.
Die versteckten Kosten des Hortens von Spielerdaten
Gehorte Spielerdaten verbergen sich an mehr Orten, als die meisten Teams vermuten – von alten Telemetrie-Pipelines bis hin zu vergessenen Testdatenbanken. Jede zusätzliche Kopie vergrößert das Risiko eines Datenlecks oder von Fragen zur Speicherdauer der Daten, da mehr Systeme betroffen sind und mehr Beweismaterial geprüft werden muss als ursprünglich geplant.
Wenn Sie ehrlich angeben, wo Spielerdaten gespeichert sind, finden Sie in der Regel weit mehr als nur Kontotabellen und Zahlungsaufzeichnungen. Typische Beispiele sind:
- Legacy-Telemetrie-Pipelines, die weiterhin Ereignisse empfangen, obwohl Dashboards nicht verwendet werden.
- Alte Crash-Dumps mit Rohgerätekennungen und Stack-Traces.
- Chatprotokolle wurden „nur für den Fall“ zur Moderation aufbewahrt, aber nie überprüft.
- Kopien von Produktionsdatenbanken in Testumgebungen und Sandboxes.
Jede einzelne dieser Kopien erweitert den potenziellen Umfang eines Sicherheitsvorfalls. Wenn ein Angreifer in Ihren Analyse-Cluster eindringt oder eine Aufsichtsbehörde nach der Aufbewahrung von Daten Minderjähriger fragt, reicht es nicht aus, einfach auf Ihre Hauptdatenbank zu verweisen. Sie müssen alle Orte berücksichtigen, an die Daten im Laufe der Jahre durch Produkteinführungen, Updates und Experimente gelangt sind.
Es geht hier nicht nur um Sicherheit. Übermäßige Datenspeicherung untergräbt auch die Glaubwürdigkeit Ihrer Darstellung von Datenminimierung in Datenschutz-Folgenabschätzungen, Partnerfragebögen und Plattformbewertungen. Wenn Richtlinien die Aufbewahrung von Protokollen für ein Jahr vorschreiben, Systeme diese aber stillschweigend fünf Jahre lang speichern, entsteht ein Glaubwürdigkeitsproblem, noch bevor ein Problem auftritt. Für Teams, die ihr ISMS formalisieren, ist die Visualisierung dieses Inventars oft der wichtigste Schritt zur Risikominderung.
Wie nicht gelöschte Protokolle Vorfälle verschlimmern
Nicht gelöschte Protokolle verlangsamen, verteuern und erschweren die Aufklärung von Vorfällen, da sie die Menge potenziell gefährdeter Daten vergrößern und den Aufwand zur Ermittlung der Auswirkungen erhöhen. Wenn die Aufbewahrung nicht nach Zweck segmentiert ist, werden weitaus mehr sensible Informationen weitaus länger aufbewahrt, als das Risiko eigentlich rechtfertigt.
Bei der Reaktion auf einen Sicherheitsvorfall sind zwei Dinge sofort entscheidend: Wie schnell lässt sich das Ausmaß der Offenlegung ermitteln und wie überzeugend kann dieses Ausmaß Führungskräften, Partnern und Aufsichtsbehörden erläutert werden. Langlebige, schlecht verwaltete Protokolle und Telemetrie-Pipelines stehen beiden Zielen entgegen, da sie Routinedaten mit hochsensiblen Informationen vermischen und alles jahrelang speichern.
Es hilft dabei, die verschiedenen Arten von Protokollen, die Sie aufbewahren, zu unterscheiden:
- Betriebsprotokolle: – für Leistung, Stabilität und Fehlersuche.
- Sicherheitsprotokolle: – für Zugriffskontrolle, Anomalieerkennung und Reaktion auf Sicherheitsvorfälle.
- Betrugs- und Anti-Cheat-Protokolle: – zur langfristigen Musteranalyse und Durchsetzung.
Sicherheits-, Betrugsbekämpfungs- und Anti-Cheat-Teams plädieren häufig für eine lange Aufbewahrungsdauer, und in manchen Fällen haben sie Recht. Das Problem ist jedoch, dass die Aufbewahrung selten segmentiert wird. Routinemäßige Authentifizierungsprotokolle und hochsensible Indikatoren für Betrugsringe werden letztendlich gleich behandelt und beide auf unbestimmte Zeit aufbewahrt.
In der Praxis bedeutet dies, dass Forensikteams riesige Datenmengen durchforsten müssen, um festzustellen, welche Daten manipuliert wurden, Rechtsteams prüfen müssen, ob sehr alte Datensätze offengelegt werden müssen, und operative Teams mit den Leistungseinbußen durch überdimensionierte Protokollspeicher zurechtkommen müssen. ISO 27001 A.8.10 zwingt dazu, diese Datenflut durch explizite Grenzwerte, Automatisierung und Überwachung einzudämmen.
Warum Spielestudios in einzigartiger Weise exponiert sind
Spielestudios sind in besonderem Maße gefährdet, da sie detaillierte Verhaltensdaten darüber sammeln, wie Nutzer spielen, Geld ausgeben und interagieren – oft auch Daten von Minderjährigen und schutzbedürftigen Spielern. Werden diese Informationen länger als nötig gespeichert, stellen sie ein sensibles Risiko statt eines nützlichen Guts dar und erschweren den Umgang mit Vorfällen oder Kritik erheblich.
Spieleunternehmen sammeln einige der umfangreichsten Verhaltensdaten aller Konsumgüterbranchen. Sie erfassen oft nicht nur Ausgaben und Anmeldevorgänge, sondern auch sekundengenaues Gameplay, Chats, soziale Netzwerke, Geräteprofile, Standortinformationen und Anti-Cheat-Signale. Unter Umständen verarbeiten sie auch Daten von Minderjährigen, selbstausgeschlossenen Spielern oder Personen in Ländern mit strengen Datenschutzbestimmungen.
All das macht nicht gelöschte Daten sensibler:
- Spielverläufe und Chatprotokolle können Spielmuster, Beziehungen und in manchen Fällen auch gesundheitliche oder finanzielle Belastungen offenlegen.
- Daten zur Monetarisierung von Lootboxen und Mikrotransaktionen stehen in engem Zusammenhang mit aktuellen Debatten über den Verbraucherschutz.
- Betrugsbekämpfungssysteme können sensible Risikoprofile von Einzelpersonen ableiten oder speichern.
Nehmen wir ein einfaches Beispiel mit Minderjährigen. Ein Teenager spielt mit elterlicher Erlaubnis, unterhält sich über Schule und Familie, gibt Geld mit der Karte der Eltern aus und schließt anschließend sein Konto. Jahre später, wenn detaillierte Spiel- und Chatprotokolle noch existieren, speichern Sie unnötigerweise hochsensible Verhaltensdaten einer inzwischen erwachsenen Person – ohne erkennbaren Zweck. Dasselbe gilt für selbstausgeschlossene oder gefährdete Spieler, deren Daten Sie sorgsam behandeln müssen.
Wenn Datensätze lange nach ihrem Bedarf erhalten bleiben, bergen sie unnötige Risiken für Ihre Privatsphäre und Ihren Ruf. Die Einhaltung von A.8.10 ermöglicht es Ihnen, dieses Risiko kontrolliert zu reduzieren, anstatt auf einen Datenverstoß, eine Beschwerde oder behördliche Maßnahmen zu warten. Eine Plattform wie ISMS.online hilft Ihnen dabei, sich einen klaren Überblick zu verschaffen, indem sie Richtlinien, Datenbestände und Kontrollen in einer einzigen Ansicht zusammenführt. So können Sie entscheiden, welche Daten unbedingt erhalten bleiben müssen, welche anonymisiert und welche endgültig gelöscht werden müssen. Anschließend können Sie Prüfern die Umsetzung dieser Entscheidungen nachweisen.
KontaktWas ISO 27001:2022 A.8.10 wirklich von Spielestudios verlangt
ISO 27001:2022 Anhang A.8.10 erwartet, dass Sie das Löschen von Daten als normalen Bestandteil des Lebenszyklus von Spielerdaten behandeln und nicht als nachträgliche Überlegung. Sie legen fest, wann die einzelnen Informationstypen nicht mehr benötigt werden, wählen eine geeignete Lösch- oder Anonymisierungsmethode und stellen anschließend sicher, dass diese Methoden tatsächlich auf den Systemen, die diese Daten speichern, angewendet werden.
A.8.10 mag auf dem Papier kurz erscheinen, hat aber weitreichende Konsequenzen. Es verpflichtet dazu, Informationen endgültig zu löschen, sobald sie nicht mehr benötigt werden, sodass eine Wiederherstellung ausgeschlossen ist und alle rechtlichen, regulatorischen, vertraglichen und internen Anforderungen erfüllt werden. Für ein Spieleunternehmen bedeutet das, das Löschen als festen Bestandteil des Prozesses zu implementieren und nicht als einmalige Aktion, die ausgeführt werden muss, wenn sich jemand daran erinnert.
Konkret bedeutet dies, dass Sie entscheiden müssen, wann die einzelnen Spielerdaten und Protokolle nicht mehr benötigt werden, geeignete Lösch- oder Anonymisierungsverfahren auswählen und deren Wirksamkeit nachweisen können. Abschnitt A.8.10 steht in Verbindung mit Anhang A.5.32 zur Aufbewahrung und Ihrem Risikobehandlungsverfahren gemäß Klausel 6: Sie entscheiden, welche Daten wie lange aufbewahrt werden und welche Bedrohungen durch sicheres Löschen bewältigt werden können.
Eine allgemeinverständliche Darstellung von Anhang A.8.10
A.8.10 lässt sich am besten als fünf einfache Fragen zu Ihren Daten und Ihren Entscheidungen verstehen. Dabei geht es nicht um die Beschreibung bestimmter Produkte, sondern darum, in einfachen Worten erklären zu können, was Sie aufbewahren, warum Sie es aufbewahren und was Sie tun, wenn es nicht mehr benötigt wird.
Man kann sich A.8.10 als auf fünf Fragen aufgebaut vorstellen:
-
Um welche Informationen geht es?
Nicht nur „personenbezogene Daten“ im Sinne des Datenschutzes, sondern jegliche Informationen in Systemen, Geräten oder Medien: Kontotabellen, Spielereignisse, Betrugsprotokolle, Telemetriedaten, Backups, Exporte und mehr. -
Ab wann ist es nicht mehr erforderlich?
Hier greifen die Bestimmungen A.8.10 und A.5.32 zur Aufbewahrung und Ihren rechtlichen Verpflichtungen. „Nicht mehr erforderlich“ muss zweckgebunden und rechtlich begründet sein, nicht nur aus Bequemlichkeit. -
Wie werden Sie die Daten löschen oder anonymisieren?
Logisches Löschen, kryptografisches Löschen, Speicherbereinigung, Aggregation und Anonymisierung können alle gültig sein, müssen aber bewusst gewählt werden. -
Wer ist verantwortlich?
Richtlinien und Verfahren müssen die Verantwortlichkeiten für die Definition von Regeln, die Bedienung von Löschmechanismen und die Überprüfung ihrer Funktionsfähigkeit festlegen. -
Wie beweisen Sie es?
Sie benötigen Nachweise: Konfigurationsdaten, Protokolle, Tickets und Ergebnisse interner Prüfungen, die belegen, dass die Löschung oder Anonymisierung tatsächlich stattfindet.
So betrachtet ist A.8.10 weniger eine „technologische“ Kontrollmaßnahme, sondern vielmehr eine Brücke zwischen Ihrer Informationsgovernance – was Sie aufbewahren und warum – und Ihrer technischen Umsetzung – wie Sie Daten verschwinden lassen oder unschädlich machen.
Wie A.8.10 in Ihr ISMS passt
A.8.10 funktioniert nur, wenn es in Ihr bestehendes Informationssicherheitsmanagementsystem integriert ist. Es basiert auf Ihren Risikobewertungen und Aufbewahrungsentscheidungen und bietet konkrete Kontrollmechanismen, auf die Sie verweisen können, um zu beschreiben, wie Sie die Auswirkungen von Vorfällen, Audits und Datenschutzbeschwerden reduzieren.
Wenn Sie bereits ein Informationssicherheitsmanagementsystem betreiben, sollte A.8.10 nicht isoliert betrieben werden. Es ist mit folgenden Systemen verbunden:
- A.5.32 – Aufbewahrung: Darin heißt es, dass Sie festlegen müssen, wie lange Informationen aufbewahrt werden. A.8.10 ist der Ausführungsarm: Was geschieht nach Ablauf dieser Zeit?
- Klausel 6 – Risikobehandlung: Sie entscheiden hier, welche Bedrohungen durch sicheres Löschen, Anonymisieren oder Minimieren reduziert werden.
- Steuerungsmöglichkeiten für Protokollierung und Überwachung: weil die Regeln zur Protokollaufbewahrung und die Löschvorgänge mit den Anforderungen an Sicherheit, Betrugsprävention und Datenschutz in Einklang stehen müssen.
- Cloud- und Lieferantenkontrollen: weil Ihre Löschliste auch Infrastruktur und Dienste umfassen muss, die Sie nicht direkt betreiben.
- Zugriffskontrolle und Verschlüsselung: Denn eine effektive Löschung ist einfacher, wenn sensible Daten getrennt und mit gut verwalteten Schlüsseln verschlüsselt werden.
Bei der Dokumentation Ihrer Kontrollen ist es hilfreich, diesen Zusammenhang explizit aufzuzeigen: beispielsweise durch Verweise auf Aufbewahrungsregeln in Ihren Löschverfahren und durch Aufzeichnung in Ihrem Risikobehandlungsplan, wie A.8.10 spezifische Bedrohungen wie Datenreste oder übermäßige Aufbewahrung mindert.
Der Unterschied zwischen dem Ignorieren von Löschungen und der Ausrichtung an A.8.10 ist oft eklatant:
| Ohne Aufbewahrungs- und Löschdisziplin | Ausgerichtet auf A.8.10 |
|---|---|
| Umfang des Vorfalls schwer zu definieren | Umfang basierend auf bekannten, zugeordneten Datenspeichern |
| Audits sind reaktiv und schmerzhaft | Audits folgen einem dokumentierten Lebenszyklus |
| Die Datenschutzfunktion wirkt inkonsistent. | Aufbewahrungsregeln und Systemverhalten stimmen eindeutig überein |
| Das Vertrauen zwischen Spielern und Partnern ist fragil. | Sie können die Minimierungs- und Aufbewahrungsgrenzen nachweisen. |
Eine ISMS-Plattform wie ISMS.online erleichtert diese Verknüpfungen, indem sie es Ihnen ermöglicht, Richtlinien, Risiken, Kontrollen und Nachweise miteinander in Beziehung zu setzen, sodass ein Auditor – und Ihre eigene Führungsebene – eine direkte Linie von den übergeordneten Anforderungen bis hin zu konkreten Maßnahmen in Ihren Systemen nachvollziehen kann.
Worauf Wirtschaftsprüfer tatsächlich achten
Prüfer interessieren sich nicht nur für die einzelnen Richtlinien, sondern auch dafür, wie Sie die Datenlöschung konzipieren, implementieren und betreiben. Sie müssen darauf vertrauen können, dass Ihre Zusicherungen der Realität entsprechen. Sie wollen sehen, dass Aufbewahrungsregeln existieren, technisch durchgesetzt werden und bei Fehlern überwacht werden, damit sie Ihren Aussagen zu Spielerdaten und Protokollen vertrauen können.
Prüfer geben sich niemals mit einem einzelnen Satz in ihren Richtlinien zufrieden, der besagt: „Wir löschen Daten, wenn sie nicht mehr benötigt werden.“ Sie suchen in der Regel nach drei Ebenen von Beweisen:
- Design: – dokumentierte Richtlinien, Standards und Verfahren, die Aufbewahrungsfristen, Löschmethoden und Verantwortlichkeiten für verschiedene Datentypen definieren.
- Implementierung: – Systemkonfigurationen, Automatisierungsaufträge und Prozessartefakte wie geplante Aufgaben, Objektspeicher-Lebenszyklusregeln oder Datenbankroutinen, die dem entsprechen, was die Dokumente versprechen.
- Bedienung und Überwachung: – Protokolle, Tickets und interne Prüfberichte, die belegen, dass Löschungen oder Anonymisierungen tatsächlich stattgefunden haben, dass Fehler erkannt und behoben werden und dass Ausnahmen erfasst und überprüft werden.
Für Spielerdaten und Protokolle könnte dies bedeuten, dass diese angezeigt werden:
- Eine Aufbewahrungs- und Löschmatrix für die wichtigsten Datenkategorien.
- Ein Verfahren zur Bearbeitung von Spielerlöschungsanträgen.
- Bildschirmdarstellungen oder Exporte aus Datenbank-, Protokollierungs- und Speichersystemen, in denen Aufbewahrung und Löschung konfiguriert sind.
- Ein Beispiel für Löschprotokolle und Ergebnisse interner Prüfungen.
Wenn Sie einfache Fragen wie „Wo kann ich überprüfen, ob Chatprotokolle, die älter als achtzehn Monate sind, entfernt oder anonymisiert wurden?“ ohne langes Suchen beantworten können, sind Sie schon einen großen Schritt weiter, um die Anforderungen von A.8.10 zu erfüllen und Ihre nächste Prüfung deutlich zu erleichtern.
ISO 27001 leicht gemacht
Ein Vorsprung von 81 % vom ersten Tag an
Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.
Vom „Recht auf Vergessenwerden“ bis zu Aufbewahrungsfristen: Die Angleichung von Artikel 8.10 an die DSGVO und den globalen Datenschutz.
Sicheres Löschen ist nicht nur ein Sicherheitsthema, sondern auch ein Beweis gegenüber Spielern und Aufsichtsbehörden, dass Sie Datenschutzrechte respektieren. Datenschutzgesetze wie die Datenschutz-Grundverordnung (DSGVO) fordern, dass Sie Ihre Datenmenge minimieren, nicht mehr benötigte Daten löschen und Rechte wie Datenminimierung, Speicherbegrenzung und das Recht auf Löschung wahren. Diese Prinzipien decken sich weitgehend mit Abschnitt A.8.10, der Ihnen die praktischen, operativen Instrumente an die Hand gibt, um diese Erwartungen in realen Systemen durchzusetzen.
Man muss kein Datenschutzanwalt werden, um gute Löschkontrollen zu entwickeln, aber man muss verstehen, wie sich rechtliche Verpflichtungen in Aufbewahrungsregeln und technisches Verhalten in den Systemen umsetzen lassen.
Grundlegende Datenschutzprinzipien, auf denen Sie aufbauen müssen
Drei allgemein anerkannte Prinzipien legen fest, wie lange Spielerdaten gespeichert werden dürfen und was mit ihnen geschehen muss. Sie finden sich in vielen Datenschutzrahmenwerken wieder und dienen Aufsichtsbehörden als gängige Bezugspunkte bei der Bewertung Ihrer Praktiken.
Diese drei Ideen sind:
- Datenminimierung: – Erfassen und verarbeiten Sie nur die Daten, die für Ihre Zwecke angemessen, relevant und notwendig sind. Falls Sie keine detaillierten Telemetriedaten auf Spielerebene benötigen, sollten Sie stattdessen aggregierte Berichte in Betracht ziehen.
- Speicherbeschränkung: Personenbezogene Daten dürfen nur so lange in identifizierbarer Form gespeichert werden, wie es für die jeweiligen Zwecke erforderlich ist. „Wir könnten sie eines Tages brauchen“ ist kein rechtmäßiger Zweck.
- Recht auf Löschung: – In vielen Fällen können Spieler Sie bitten, ihre personenbezogenen Daten zu löschen, insbesondere wenn sie ihre Einwilligung widerrufen oder der ursprüngliche Zweck nicht mehr zutrifft.
Für ein Spieleunternehmen gelten diese Grundsätze für:
- Konto- und Profildaten.
- Zahlungs- und Transaktionsaufzeichnungen.
- Chat- und soziale Daten.
- Telemetrie und Analytik.
- Protokolle zur Betrugsbekämpfung und zum Schutz vor Betrug.
- Support-Tickets und Konfliktverläufe.
Für jede dieser Kategorien sind klare Entscheidungen erforderlich: Wie lange werden personenbezogene Daten gespeichert, wann werden sie anonymisiert oder aggregiert und wie werden berechtigte Löschanträge bearbeitet? Steuer- und Rechnungslegungsvorschriften stehen oft im Zusammenhang mit diesen Datenschutzgrundsätzen und können den Löschantrag eines Spielers für bestimmte Datensätze außer Kraft setzen. Daher müssen diese Zusammenhänge klar erläutert werden können.
Diese Informationen sind allgemeiner Natur und stellen keine Rechtsberatung dar. Sie sollten sich stets spezifisch rechtlich beraten lassen, insbesondere im Hinblick auf Ihre Rechtsordnung und Ihr Produktportfolio.
Prinzipien und Rechte in konkrete Aufbewahrungsregeln umsetzen
Abstrakte Datenschutzrechte in klare Regeln zu übersetzen ist unerlässlich, damit Entwickler und Betriebsteams einheitlich handeln. Sie müssen für jede Datenkategorie wissen, welchem Zweck sie dient, wie lange sie gespeichert werden und was nach Ablauf dieser Frist geschieht, um die richtigen Verhaltensweisen umzusetzen.
Datenschutz- und Sicherheitsteams sind sich oft über die Grundsätze einig, doch es entstehen Reibungspunkte, wenn Entwickler nach konkreten Details fragen. Sie benötigen Zahlen und Verhaltensdaten, keine abstrakten Formulierungen. Ein praktischer Ansatz ist die Erstellung eines Aufbewahrungs- und Löschplans, der für jede Kategorie von Spielerdaten Folgendes auflistet:
- Zweck: – warum Sie es halten, beispielsweise um das Spiel auszuliefern, Betrug zu verhindern oder Steuergesetze einzuhalten.
- Rechtsgrundlage oder Verpflichtung: – Einwilligung, Vertrag, berechtigtes Interesse, gesetzliche Verpflichtung.
- Standardaufbewahrungsfrist: – wie lange Sie personenbezogene Daten unter normalen Umständen aufbewahren.
- Ausnahmen: – Situationen, in denen Daten länger aufbewahrt werden müssen, z. B. bei offenen Streitigkeiten oder aufgrund gesetzlicher Aufbewahrungspflichten.
- Endzustand: – unabhängig davon, ob Sie die Daten am Ende des Zeitraums löschen, anonymisieren oder aggregieren.
- Löschmethode: – die von Ihnen angewandte technische Vorgehensweise, wie z. B. Zeilenlöschung, Schlüsselvernichtung oder Anonymisierung.
Wenn ein Spieler sein Recht auf Löschung geltend macht, kann man dann systematisch argumentieren:
- Welche Kategorien sind von der Anfrage abgedeckt?
- Gibt es rechtliche Verpflichtungen, die Sie zur Aufbewahrung bestimmter Aufzeichnungen verpflichten, beispielsweise Steuer- oder Geldwäschebekämpfungsvorschriften?
- In welchen Systemen befinden sich die relevanten Daten?
- Welche technischen Kontrollen setzen Sie ein, um die Daten gegebenenfalls zu löschen oder zu anonymisieren?
Ihre ISO 27001-Dokumentation und Ihre Datenschutz-Folgenabschätzungen sollten auf denselben Zeitplan verweisen, damit Sie nicht versuchen, parallele Regelwerke aufrechtzuerhalten, die sich zwangsläufig verändern und immer schwieriger zu verteidigen sind.
Umgang mit heiklen Kategorien: Betrug, Minderjährige und Streitigkeiten
Besonders schwierige Fragen ergeben sich im Zusammenhang mit Daten, die Sie zum Schutz Ihres Unternehmens und anderer Marktteilnehmer verwenden, da diese Kategorien Fragen des Datenschutzes und der Fairness aufwerfen, obwohl sie eine längere Aufbewahrung rechtfertigen. Eine längere Aufbewahrung kann beispielsweise zur Betrugsbekämpfung oder zur Abwehr von Rechtsansprüchen erforderlich sein, gleichzeitig möchten Sie aber die Menge der über Einzelpersonen gespeicherten Daten im Laufe der Zeit minimieren.
Einige der schwierigsten Fragen betreffen Daten, die Sie zum Schutz Ihres Unternehmens und anderer Marktteilnehmer verwenden:
- Betrugs- und Anti-Cheat-Protokolle: – Um Muster zu erkennen und die Integrität des Spiels zu verteidigen, benötigen Sie möglicherweise eine längere Merkzeit.
- Zahlungs- und Steuerdaten: – Finanzgesetze schreiben häufig vor, dass bestimmte Unterlagen für eine festgelegte Anzahl von Jahren aufbewahrt werden müssen.
- Streit- und Supportprotokolle: – Möglicherweise benötigen Sie die Unterlagen noch bis zum Ablauf der Verjährungsfristen für Rechtsansprüche.
- Daten von Minderjährigen und selbstausgeschlossenen Spielern: – Möglicherweise bestehen zusätzliche Verpflichtungen zum Schutz gefährdeter Gruppen oder zur Einschränkung bestimmter Verarbeitungsvorgänge.
Es empfiehlt sich, für solche Fälle klare, dokumentierte Regeln festzulegen, anstatt Ad-hoc-Entscheidungen zuzulassen. So lassen sich Kontrollmechanismen entwickeln, die sowohl dem Schutzzweck als auch dem Datenschutzrisiko Rechnung tragen.
Schritt 1 – Die Spannung dokumentieren
Begründen Sie schriftlich, warum Sie in bestimmten Bereichen eine verlängerte Aufbewahrung benötigen, und verweisen Sie dabei auf rechtliche, regulatorische oder plattformspezifische Erwartungen, damit der Kompromiss transparent wird.
Schritt 2 – Hochrisikodaten aussortieren
Hochriskante Protokolle und Profile sollten an klar abgegrenzten Orten mit strengen Zugriffskontrollen und eindeutigen Aufbewahrungsregeln aufbewahrt werden, damit sie nicht mit allgemeinen Systemen verschmelzen.
Schritt 3 – Verringerung der Identifizierbarkeit im Laufe der Zeit
Wechseln Sie so bald wie möglich von vollständigen Identifikatoren zu Pseudonymen und von Pseudonymen zu aggregierten oder vollständig anonymisierten Daten, solange Ihre Schutzanforderungen noch erfüllt werden.
Schritt 4 – Überprüfen Sie regelmäßig die verlängerte Aufbewahrungsdauer.
Die regelmäßige Überprüfung dieser Sonderfälle sollte in die Governance integriert werden, damit eine „vorübergehende“ Beibehaltung nicht aus Nachlässigkeit oder Bequemlichkeit zu einer dauerhaften wird.
Konkrete Beispiele erleichtern die Umsetzung dieser Ideen. Betrugsprotokolle könnten in einer separaten Datenbank gespeichert werden, in der nach einer gewissen Zeit nur noch gehashte Kennungen aufbewahrt werden. So bleiben Muster sichtbar, während die einzelnen Personen weniger gefährdet sind. Zahlungsdaten könnten so aufgeteilt werden, dass in einem Finanzsystem, getrennt von den Spielprofilen, nur die für die Steuervorschriften erforderlichen minimalen Transaktionsreferenzen und -beträge gespeichert werden. Die Konten von Minderjährigen und selbst ausgeschlossenen Spielern könnten gekennzeichnet werden, sodass bestimmte sicherheitsrelevante Daten für festgelegte Zeiträume gespeichert werden, während Marketing-Telemetrie- und Profiling-Daten deutlich früher gelöscht werden.
A.8.10 hebt Ihre gesetzlichen Pflichten nicht auf, und das Datenschutzrecht hindert Sie nicht daran, Daten zu speichern, die Sie zur Rechtsverteidigung oder zur Einhaltung gesetzlicher Bestimmungen benötigen. Wichtig ist, dass jede längere Aufbewahrung begründet, dokumentiert und technisch durchgesetzt werden muss und nicht einfach vorausgesetzt werden darf, damit Aufsichtsbehörden und Marktteilnehmer sehen können, dass Sie fair handeln.
Zuordnung der Spielerdaten und des Protokolllebenszyklus zu A.8.10
Damit A.8.10 in der Praxis funktioniert, muss man in Lebenszykluskategorien denken. Spielerdaten erscheinen und verschwinden nicht einfach; sie durchlaufen den Prozess von der Erfassung über die aktive Nutzung bis hin zu verschiedenen Speicherebenen, bevor sie schließlich gelöscht oder anonymisiert werden. A.8.10 integriert Kontrollmechanismen in jede Phase dieses Prozesses. Die sichere Löschung wird deutlich einfacher, wenn für jede Phase bekannt ist, wo sich die Daten befinden und was als Nächstes geschehen soll, und wenn alle Beteiligten aus den Bereichen Sicherheit, Datenschutz, Entwicklung und LiveOps denselben Überblick haben.
Viele Studios verfügen über informelle mentale Modelle dieses Ablaufs, aber nur wenige haben ihn so detailliert dargestellt, dass sich verschiedene Teams bei der Entwicklung von Systemen, Funktionen und Betriebsprozessen darauf verlassen können.
Visuell: einfaches Lebenszyklusdiagramm von der Sammlung → aktive Nutzung → Warmarchivierung → Kaltarchivierung → Löschung/Anonymisierung.
Ein typischer Lebenszyklus in modernen Spielen
Die meisten modernen Spiele-Stacks folgen einem ähnlichen Muster, auch wenn die Bezeichnungen variieren: Spieler generieren Ereignisse, diese werden verarbeitet, um Spielerlebnisse zu ermöglichen, und ältere Daten werden anschließend schrittweise in weniger frequentierte, kostengünstigere oder restriktivere Speicher verschoben. Entscheidungen zur Löschung und Anonymisierung funktionieren nur, wenn sie diesen realen Datenfluss berücksichtigen und nicht so tun, als befänden sich alle Daten in einer einzigen, übersichtlichen Datenbank.
Obwohl sich die einzelnen Titel unterscheiden, sind die grundlegenden Phasen bekannt:
- Sammlung und Aufnahme: – Spieler melden sich an, authentifizieren sich, spielen Matches, chatten, geben Geld aus, und Sie erfassen diese Ereignisse in Backends, Protokollen und Analysen.
- Aktive Nutzung: – Die Daten werden verwendet, um das Spiel bereitzustellen, LiveOps zu betreiben, das Matchmaking zu ermöglichen, Inventare zu verwalten und Kundensupport zu leisten.
- Warmes Archiv: – Ältere Daten werden auf kostengünstigere Speichermedien oder in Tabellen mit niedrigerer Priorität verschoben, bleiben aber für eine gewisse Zeit identifizierbar, beispielsweise zur Kontowiederherstellung oder für längerfristige Untersuchungen.
- Kaltarchiv: Die Daten werden nur zur Erfüllung von Verpflichtungen wie Steuer-, Regulierungs- oder Betrugsermittlungen gespeichert, oft in stärker eingeschränkten Systemen.
- Löschung oder Anonymisierung: – Die Daten werden entfernt oder so verändert, dass sie keinen Bezug mehr zu einem identifizierbaren Spieler haben.
Dieser Lebenszyklus gilt nicht nur für Kontentabellen, sondern auch für Observability- und Sicherheitsprotokolle, Telemetrie- und Data-Lake-Systeme, Anti-Cheat- und Risikobewertungssysteme, Support- und Moderationstools sowie Drittanbieterintegrationen und -exporte. Je klarer Sie darstellen können, welche Systeme und Datensätze in welcher Phase angesiedelt sind, desto einfacher wird es, die Kontrollen gemäß A.8.10 zuzuordnen und sie einem Auditor oder einem skeptischen Stakeholder zu erläutern.
Anbringen der A.8.10-Steuerelemente an jede Phase
Die Einbindung von A.8.10 in den Lebenszyklus bedeutet, festzulegen, welche Bedingungen jedes Mal erfüllt sein müssen, wenn Daten eine Grenze überschreiten, da sich an diesen Grenzen das Risiko ändert. Sie erfassen neue Daten, verschieben sie in einen neuen Speicherort oder entscheiden, dass sie nicht mehr benötigt werden – jeder Übergang bietet die Möglichkeit, Löschung, Minimierung oder Anonymisierung durchzusetzen.
Eine hilfreiche Herangehensweise ist es, A.8.10 als Checkliste zu betrachten, die an jeder Phasengrenze ausgelöst wird.
Wenn Daten verschoben werden von Sammlung zur aktiven Nutzung:
Prüfen Sie, was Sie sammeln
Stellen Sie sicher, dass die Felder auf das beschränkt sind, was für das Gameplay, den Betrieb und die Verpflichtungen notwendig ist, und nicht einfach alles, was Sie aus Neugier erfassen können.
Trennen Sie Kennungen vom Inhalt.
Strukturschemata so gestalten, dass Spielerkennungen entfernt oder ausgetauscht werden können, ohne dass dabei alle nützlichen Analysedaten oder Geschäftskennzahlen verloren gehen.
Wenn Daten verschoben werden von aktive Nutzung zur Erwärmung von Archivmaterialien:
Bestätigen Sie den Retention-Trigger.
Legen Sie einen eindeutigen Zeitpunkt oder ein Ereignis fest, nach dem Daten aus aktiven Speichern entfernt werden, und dokumentieren Sie, wie dieser Auslöser in den relevanten Pipelines oder Diensten implementiert wird.
Zugriffe einschränken und Kontrollen anpassen
Verschärfen Sie den Zugriff auf archivierte Daten und konfigurieren Sie Aufbewahrungsfristen entsprechend Ihrem Zeitplan, damit sich ältere Datensätze nicht unbemerkt ansammeln.
Wenn Daten verschoben werden von warm bis kalt archiviert:
Begründen Sie, was übrig bleibt.
Stellen Sie sicher, dass nur Daten, die tatsächlich für rechtliche, regulatorische oder sicherheitsrelevante Zwecke benötigt werden, in die Kaltlagerung übernommen werden und dass diese Begründung dokumentiert wird.
Stärkere Sicherheitsvorkehrungen anwenden
Für selten genutzte Datenarchive sollten strengere Zugriffskontrollen, Überwachungsmaßnahmen und gegebenenfalls Verschlüsselung eingeführt werden, damit diese nicht zu einem leichten Ziel werden.
Wenn Daten verschoben werden von kalte Archivierung bis hin zur Löschung oder Anonymisierung:
Automatisiere den Endzustand
Definieren Sie einen automatisierten Job oder Prozess, der Daten löscht oder anonymisiert, wenn die Aufbewahrungsfrist abläuft, anstatt sich auf Ad-hoc-Bereinigungen zu verlassen.
Beweise und Fehler erfassen
Protokollieren Sie erfolgreiche Testläufe und Ausnahmen, um nachzuweisen, dass die Steuerung funktioniert, Fehler zu untersuchen und Ihren Ansatz im Laufe der Zeit zu verfeinern.
An jedem Übergang sollten Sie folgende Fragen beantworten können: „Wenn wir sagen, dass Daten nach Phase X in diese Phase gelangen, woher wissen wir, dass dies tatsächlich der Fall ist, und was passiert dann?“ Diese Antworten bilden das Rückgrat Ihrer A.8.10-Kontrollen und helfen Ihnen, Aufsichtsbehörden und Partnern zu zeigen, dass Sie den gesamten Lebenszyklus ernst nehmen.
Einschließlich Backups, Testdaten und dunklen Ecken
Backups, Testumgebungen und Exporte werden im alltäglichen Lebenszyklusmanagement oft vernachlässigt, enthalten aber große Mengen an Spielerdaten, die Ihre Löschstrategie untergraben können. Sie müssen hier nicht Ihr gesamtes Backup-Konzept neu darstellen, aber Sie müssen diese Bereiche in eine gemeinsame Übersicht integrieren und Ihre technischen Standards anwenden, um den tatsächlichen Löschvorgang abzudecken.
Man konzentriert sich leicht auf die primären Systeme und vergisst dabei, wo Daten gespeichert bleiben. Backups und Replikate verdienen eine eigene Planung. Bei der Verwendung von Langzeit-Backups ist es unter Umständen nicht möglich, die Daten einzelner Spieler gezielt zu löschen. In diesem Fall sollten Sie Folgendes beachten:
- Verschlüsseln Sie Backups mit starken, gut verwalteten Schlüsseln.
- Legen Sie Aufbewahrungsfristen fest und stellen Sie sicher, dass abgelaufene Datensätze entfernt werden.
- Stellen Sie sicher, dass alte Backups abgelaufen oder nicht mehr wiederherstellbar sind, beispielsweise durch Schlüsselvernichtung oder Datenträgerbereinigung.
Test- und Staging-Umgebungen können große Mengen an Produktionsdaten enthalten. Wenn Sie diese mit Live-Datensätzen befüllen, müssen diese Ihren Lebenszyklus- und Löschregeln entsprechen. Alternativ sollten Sie die Daten vor der Verwendung anonymisieren, damit Entwickler mit realistischen, aber nicht identifizierbaren Informationen arbeiten.
Exporte und Berichte – CSV-Dateien, Datenextrakte und Screenshots für Analysen oder Berichte – müssen entweder kontrolliert oder vermieden werden. Sind Exporte unumgänglich, sollten sie an kontrollierten Orten mit klaren Aufbewahrungsregeln gespeichert und nach Möglichkeit zentralisierte Berichte oder Dashboards bevorzugt werden.
Eine einfache Tabelle mit Spalten wie „Speicher oder System“, „Lebenszyklusphase“ und „Aufbewahrungs- und Löschverhalten“ und maximal wenigen Zeilen pro Spalte kann hilfreich sein. Sobald diese Zuordnung existiert, lassen sich Tools und Plattformen darauf ausrichten. Eine integrierte ISMS-Lösung wie ISMS.online bietet Ihnen eine zentrale Plattform für den Lebenszyklus, die zugehörigen Richtlinien und die Nachweise ihrer Einhaltung. So können Sie auch schwer zugängliche Bereiche genauso sorgfältig verwalten wie primäre Systeme.
Befreien Sie sich von einem Berg an Tabellenkalkulationen
Integrieren, erweitern und skalieren Sie Ihre Compliance, ohne dass es zu Problemen kommt. IO gibt Ihnen die Widerstandsfähigkeit und das Vertrauen, um sicher zu wachsen.
Technische Muster für die sichere Löschung von Daten in Datenbanken, Protokollen, Backups und Telemetrie
Sicheres Löschen funktioniert nur, wenn die zugrundeliegende Architektur die praktische und sichere Anwendung durch Ihre Teams ermöglicht. Sie benötigen wenige Standardmuster, die Entwickler verstehen, die kostengünstig zu betreiben sind und die von Prüfern befolgt werden können, damit Sie das Löschen nicht für jedes Spiel und jeden Dienst neu erfinden müssen.
Selbst die besten Richtlinien nützen wenig, wenn Ihre Architektur das Löschen erschwert oder riskant macht. Die gute Nachricht: Es gibt wiederholbare Muster, die sich technologieübergreifend anwenden lassen. Ziel ist nicht Perfektion vom ersten Tag an, sondern ein kleiner Satz standardisierter Vorgehensweisen, die Entwickler verstehen, die mit Ihrer Systemarchitektur skalieren und die auch von Auditoren nachvollzogen werden können.
Ein zentrales Designziel ist es, das Löschen sicherer und kostengünstiger zu gestalten, als das Problem zu ignorieren. Das bedeutet in der Regel, das Löschen auf Schema- und Pipeline-Ebene einzuplanen, anstatt es nachträglich hinzuzufügen.
Sicheres Löschen in Produktionsdatenbanken und -diensten
Sicheres Löschen in Live-Datenbanken bedeutet, Spielerdaten zu entfernen oder zu anonymisieren, ohne die Spielfunktionen zu beeinträchtigen. Gleichzeitig erhalten Sie die Gewissheit, dass Datensätze nicht unbemerkt in vergessenen Tabellen verbleiben. Es stehen Ihnen einige Hauptmuster zur Auswahl, und Sie sollten diejenigen standardisieren, die Ihrer Risikobereitschaft und Ihrem Reifegrad entsprechen.
Für Datenbanken, die Spielerkonten, Profile, Inventare und andere wichtige Daten enthalten, haben Sie mehrere Möglichkeiten:
- Physische Zeilenlöschung: – unkomplizierte Löschvorgänge mit entsprechender Kaskadierung, gefolgt von Wartungsarbeiten wie Vakuumieren oder Verdichten, um gegebenenfalls Speicherplatz zurückzugewinnen.
- Soft-Löschung plus periodische Hard-Löschung: – Datensätze werden für einen kurzen Zeitraum als gelöscht markiert, um die Wiederherstellung des Kontos oder die Betriebssicherheit zu gewährleisten, und anschließend nach einem festgelegten Intervall endgültig gelöscht.
- Partitionierung nach Zeit oder Mieter: – Strukturierung von Tabellen oder Sammlungen, sodass große Mengen veralteter Daten gesammelt gelöscht oder archiviert werden können.
Für welches Muster Sie sich auch entscheiden, Sie sollten Folgendes beachten:
- Trennen Sie nach Möglichkeit Identifikatoren von weniger sensiblen Inhalten, sodass durch das Löschen einer kleinen Verknüpfungstabelle große Mengen an Spieldaten effektiv anonymisiert werden können.
- Stellen Sie sicher, dass die Anwendungslogik gelöschte Daten nicht aus Caches, Suchindizes oder abgeleiteten Speichern „wiederbelebt“.
- Implementieren Sie idempotente Löschroutinen, damit das Wiederholen eines fehlgeschlagenen Vorgangs die Integrität nicht beeinträchtigt oder einen Teilzustand hinterlässt.
- Testen Sie das Verhalten von Kaskadenlöschung und referenzieller Integrität gründlich in Nicht-Produktionsumgebungen, damit vorsichtige Datenbankadministratoren die Auswirkungen erkennen können, bevor sie Live-Daten berühren.
Dokumentieren Sie diese Muster als Teil Ihrer technischen Standards für A.8.10 und verknüpfen Sie sie mit den Aufbewahrungsregeln in Ihrem Zeitplan. So wissen die Entwickler bei der Veröffentlichung eines neuen Spiels oder einer neuen Funktion, welches Muster anzuwenden ist und wie dessen Funktionsfähigkeit nachgewiesen werden kann.
Entwicklung von speicherzeitkritischen Protokollen und Telemetrie
Protokolle und Telemetriedaten sind für den Betrieb und die Verbesserung von Spielen unerlässlich, stellen aber gleichzeitig eine der größten Quellen personenbezogener Daten dar und führen häufig zu übermäßiger Datenspeicherung, wodurch das Risiko schleichend steigt. Ziel ist es nicht, die Protokollierung zu unterbinden oder Systeme abzuschalten, sondern nur die benötigten Daten zu erfassen, diese so lange wie nötig zu speichern und sie anschließend entweder zu löschen oder direkte Verbindungen zu einzelnen Personen zu entfernen. Die Speicherung und Löschung sollte von Anfang an in die Planung einbezogen werden.
Zu den nützlichen Prinzipien gehören:
- Protokolle nach Zweck klassifizieren: – Sicherheit, Betrugsbekämpfung, Spielanalyse und Absturzdiagnose können jeweils unterschiedliche Aufbewahrungsfristen rechtfertigen.
- Vermeiden Sie es, mehr Protokolle zu führen als nötig: – Verzichten Sie auf die Angabe vollständiger Kennungen oder Nutzdaten, wenn Hashes, Token oder aggregierte Metriken ausreichen.
- Nutzen Sie die integrierten Rückhaltefunktionen: – Die meisten Protokollierungs- und Telemetrieplattformen ermöglichen die Einstellung einer zeitbasierten Aufbewahrung und einer automatischen Löschung; konfigurieren Sie diese entsprechend Ihrem Zeitplan.
- Erwägen Sie die Anonymisierung: – Bei älteren Daten, die nur in aggregierten Analysen verwendet werden, werden die Kennungen nach einer gewissen Zeit durch Token ersetzt oder vollständig entfernt.
In der Praxis könnte dies bedeuten, detaillierte Sicherheitsprotokolle für einen definierten Zeitraum zu führen und anschließend nur gröbere Aggregationen für Trendanalysen zu speichern. Alternativ könnten detaillierte Spielereignisse auf Spielerebene für einen kurzen Zeitraum erfasst werden, um Funktionen zu optimieren, und anschließend zu anonymisierten Kohorten zusammengefasst werden. Entscheidend ist, dass diese Verhaltensweisen zentral konfiguriert und nachweisbar sind und nicht von einzelnen Teams ad hoc entschieden werden.
Datensicherungen, Archive und kryptografische Löschung
Backups und Archive dienen der Datensicherung. Sicheres Löschen bedeutet hier die Verwaltung ganzer Backup-Sätze, nicht das Löschen einzelner Datenträger. Gleichzeitig wird eine glaubwürdige Dokumentation darüber erstellt, was nach Ablauf der Aufbewahrungsfrist geschieht. Verschlüsselung, zeitlich begrenzte Aufbewahrung und die kontrollierte Vernichtung von Schlüsseln oder Datenträgern gewährleisten, dass abgelaufene Daten in der Praxis nicht mehr zugänglich sind.
Backups stellen eine besondere Herausforderung dar, da sie speziell für die Datensicherung entwickelt wurden, oft in großen, undurchsichtigen Datenblöcken. Es ist selten möglich, die Daten eines einzelnen Spielers aus zehn vollständigen Backups zu löschen. Stattdessen erfolgt die Löschung auf Ebene der Backup-Sets.
Zu den praktischen Schritten gehören:
- Backups und Archive verschlüsseln: mit starken Schlüsseln, die getrennt von den Daten verwaltet werden.
- Aufbewahrungszeiträume für Backups festlegen: die Ihrem Risikoprofil und Ihren rechtlichen Verpflichtungen entsprechen, und vermeiden Sie es, Backups auf unbestimmte Zeit aufzubewahren.
- Stellen Sie sicher, dass alte Backups nicht mehr wiederherstellbar sind: durch kontrollierte und dokumentierte Vernichtung der entsprechenden Schlüssel oder Datenträger nach Ablauf der Aufbewahrungsfrist.
- Vermeiden Sie es, Backups als Archive zu verwenden: durch die Aufbewahrung langfristiger Aufzeichnungen in eigens dafür errichteten, zugangskontrollierten Speichern mit klaren Aufbewahrungsfristen anstelle allgemeiner Wiederherstellungssicherungen.
Kryptografisches Löschen – also das Unlesbarmachen von Daten durch Löschen oder Widerrufen von Schlüsseln – ist oft die einzige praktikable Möglichkeit, die Anforderungen von A.8.10 für groß angelegte Backups und verteilte Objektspeicher zu erfüllen. Es setzt ein robustes Schlüsselmanagement voraus; werden Schlüssel für viele Datensätze wiederverwendet oder unzureichend geschützt, sinkt die Sicherheit. Bei sorgfältiger Implementierung ermöglicht kryptografisches Löschen jedoch die Kombination von Ausfallsicherheit und der Gewissheit, dass abgelaufene Daten tatsächlich gelöscht sind. Dies schützt sowohl die Spieler als auch Ihr Studio im Falle von Vorfällen.
Governance, Rollen und Ausnahmen: Wie Löschvorgänge in einem Live-Spieleunternehmen funktionieren
Sicheres Löschen funktioniert nur dann dauerhaft, wenn alle wissen, wer welche Entscheidungen trifft, wer die Aufgaben übernimmt und wie Ausnahmen gehandhabt werden. Andernfalls sammeln sich alte Spielerdaten unbemerkt an, da schwierige Gespräche aufgeschoben werden. Klare Richtlinien machen A.8.10 von einem Nebenprojekt zu einem festen Bestandteil des Betriebs Ihrer Spiele und Dienste.
Das Löschen von Daten ist keine Aufgabe für ein einzelnes Team. Weder die Sicherheitsabteilung noch die Entwicklungsabteilung, der Datenschutz oder LiveOps können dies allein bewältigen. Damit A.8.10 reibungslos funktioniert, ist eine klare Governance erforderlich: Wer trifft welche Entscheidungen, wer setzt sie um, wer überprüft ihre Wirksamkeit und wie werden Ausnahmen behandelt?
Ohne diese Klarheit wird das Löschen zu einer Reihe unangenehmer Gespräche und unbeantworteter Tickets, was wiederum dazu führt, dass das Thema gar nicht erst angesprochen wird. Für Teams, die gerade erst mit der ISO 27001-Einführung beginnen, verhindert die frühzeitige schriftliche Festlegung dieser Verantwortlichkeiten, dass ein oder zwei Personen stillschweigend die gesamte Arbeit übernehmen.
Festlegen, wem was gehört
Die klare Definition der Zuständigkeiten für Aufbewahrungs- und Löschentscheidungen vermeidet Missverständnisse und Schuldzuweisungen, da jeder nachvollziehen kann, wer verantwortlich ist. Eine einfache RACI-Matrix, die festlegt, wer verantwortlich, rechenschaftspflichtig, zu konsultieren und zu informieren ist, macht deutlich, wer Regeln genehmigen und die technischen Kontrollen aufrechterhalten muss.
Eine einfache RACI-Matrix (Verantwortlich, Rechenschaftspflichtig, Beratend, Informiert) für Löschvorgänge kann viel Verwirrung beseitigen. Typische Muster sind:
- Sicherheit oder die CISO-Funktion: – verantwortlich für die Sicherstellung der Umsetzung von A.8.10 als Teil des ISMS; wird zu Risikoauswirkungen konsultiert.
- Datenschutz oder der Datenschutzbeauftragte: – verantwortlich dafür, sicherzustellen, dass Aufbewahrung und Löschung mit den Gesetzen und Spielerrechten übereinstimmen.
- Daten- und Plattformentwicklung: – verantwortlich für die Implementierung und den Betrieb der technischen Löschung oder Anonymisierung.
- LiveOps und Produkt: – Beratung hinsichtlich der Auswirkungen von Datenaufbewahrung und -löschung auf den Spielbetrieb und die Spielanalyse.
- Spielersupport- und Community-Teams: – zuständig für die Kommunikation mit den Spielern und die Weiterleitung komplexer Fälle.
Sobald diese Rollen festgelegt sind, können Sie sie in die Richtlinienbereiche für Verantwortlichkeiten, Änderungsmanagement-Workflows und das Onboarding neuer Systeme und Anbieter integrieren. So gibt es auf die Frage „Wer entscheidet, wie lange Chatprotokolle aufbewahrt werden?“ eine klarere Antwort als „Das hängt davon ab, mit wem man spricht“, und Löschentscheidungen können genauso schnell getroffen werden wie die Spieleentwicklung.
Ausnahmen entwerfen, ohne die Kontrolle zu verlieren
Fast jedes Studio benötigt Ausnahmen von seinen Standardaufbewahrungsregeln aus Betrugs-, Sicherheits- oder Rechtsgründen. Die Gefahr besteht jedoch darin, dass diese Ausnahmen aus Gewohnheit zur Gewohnheit werden. Ein unkomplizierter, aber disziplinierter Ausnahmeprozess ermöglicht es Ihnen, wichtige Daten bei Bedarf aufzubewahren, beispielsweise im Rahmen von Betrugsermittlungen oder behördlichen Anfragen, ohne Ihre gesamte Löschstrategie stillschweigend zu untergraben.
Fast jedes Studio benötigt Ausnahmen von seinen Standardaufbewahrungsregeln. Betrug, Täuschung, schwerwiegende Sicherheitsvorfälle und behördliche Ermittlungen erfordern mitunter eine längere Datenspeicherung als üblich. Die Gefahr besteht darin, dass sich solche Ausnahmen informell anhäufen und nie wieder überprüft werden.
Ein solider Ansatz ist:
- Verlangen Sie eine dokumentierte Begründung für jede verlängerte Aufbewahrungsfrist, gegebenenfalls einschließlich rechtlicher oder behördlicher Verweise.
- Legen Sie für jede Ausnahme ein Überprüfungsdatum oder eine Überprüfungsbedingung fest, z. B. „bis zum Abschluss der Untersuchung X plus zwei Jahre“.
- Der Zugang zum Langzeitarchiv sollte auf die kleinste Gruppe beschränkt werden, die ihn tatsächlich benötigt.
- Offene Ausnahmen sind in einem regelmäßigen Gremium der Unternehmensführung zu überprüfen und zu schließen, sobald sie nicht mehr benötigt werden.
Ein guter Ausnahmedatensatz könnte beispielsweise so aussehen: „Betrugsfall F-123 – zugehörige Transaktions-, Geräte- und Netzwerkprotokolle bis zum 31. Dezember 2028 aufbewahren; Verantwortlicher: Leiter der Betrugsabteilung; vierteljährliche Überprüfung durch den Risikoausschuss.“ Diese Detailgenauigkeit sorgt für einheitliche Vorgehensweisen und eine lückenlose Nachvollziehbarkeit, die sowohl ISO-27001-Audits als auch behördliche Prüfungen unterstützt.
Schulung der Frontline-Teams und Ausrichtung von LiveOps
Die Teams im direkten Kundenkontakt setzen Ihre Löschrichtlinien in konkrete Zusagen an die Spieler um. Wenn Support- und Community-Teams die „Kontolöschung“ anders beschreiben als Ihre Systeme sich verhalten, entstehen Vertrauens- und Compliance-Probleme. Durch die Abstimmung von Schulungen, Skripten und LiveOps-Planung auf Ihre A.8.10-Kontrollen lassen sich diese Lücken vermeiden.
Spieler, Eltern und sogar Partner wenden sich oft zuerst an die Teams im direkten Kundenkontakt: Support, Community-Manager, LiveOps. Wenn diese Teams nicht klar erklären können, was „Kontolöschung“ bedeutet, oder schlimmer noch, Dinge versprechen, die nicht der Wahrheit entsprechen, entstehen Vertrauensprobleme und Probleme mit der Einhaltung von Richtlinien.
Sie sollten daher:
- Stellen Sie einfache Erklärungen und interne FAQs bereit, die in verständlicher Sprache beschreiben, was gelöscht wird, was aus rechtlichen Gründen aufbewahrt werden kann und über welchen Zeitraum.
- Schulen Sie die Mitarbeiter darin, zu erkennen, wann eine Anfrage rechtliche Sperren oder komplexe Ausnahmen auslösen könnte und wie sie in solchen Fällen angemessen eskalieren können.
- Richten Sie die LiveOps-Planung an den bevorstehenden Änderungen der Aufbewahrungs- oder Löschrichtlinien aus, damit Telemetrie- oder Segmentierungsstrategien rechtzeitig angepasst werden können.
Wenn alle verstehen, dass sicheres Löschen dem Schutz der Spieler und des Studios dient und nicht gute Ideen verhindern soll, gibt es weniger Konflikte zwischen Produktentwicklung und Compliance in letzter Minute – und durchdachtere Designs, die beides unterstützen. Das wiederum reduziert die Kosten von Vorfällen, minimiert das Risiko regulatorischer Verstöße und stärkt das langfristige Vertrauen der Spieler.
Verwalten Sie Ihre gesamte Compliance an einem Ort
ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.
Cloud, Anbieter und gemeinsame Verantwortung für die Löschung
Moderne Spiele sind stark von Cloud- und Software-as-a-Service-Anbietern abhängig, dennoch bleiben Sie für die Speicherung und Löschung von Spielerdaten in Ihrer gesamten Infrastruktur verantwortlich. A.8.10 muss daher über Ihre eigenen Systeme hinaus Verträge, Konfigurationen und Risikobewertungen von Anbietern einbeziehen, damit Daten nicht länger als nötig aufbewahrt werden, nur weil sie sich auf der Plattform eines anderen Anbieters befinden.
Nur noch ein kleiner Teil der modernen Spiele-Technologie befindet sich ausschließlich im eigenen Rechenzentrum. Identitätsmanagement, Zahlungsabwicklung, Analysen, Marketing, Community-Management, Support und sogar die Kern-Backends können von Cloud- und Software-as-a-Service-Anbietern abhängig sein. ISO 27001 A.8.10 gilt weiterhin; dies bedeutet lediglich, dass Ihre Löschprotokolle auch diese Anbieter umfassen müssen.
Sie können sich nicht einfach darauf verlassen, dass „der Anbieter sich darum kümmert“. Sie müssen verstehen, dokumentieren und gegebenenfalls vertraglich festlegen, wer was, wo und wann löscht. Dies ist besonders wichtig, wenn Anbieter auf ihre eigenen Zertifizierungen verweisen; die Einhaltung eines bestimmten Rahmenwerks garantiert nicht, dass deren Aufbewahrungsfristen mit Ihren übereinstimmen oder dass sie Ihre Löschfristen unterstützen.
Das Modell der geteilten Verantwortung verstehen
Das Verständnis des Modells der geteilten Verantwortung hilft Ihnen zu erkennen, welche Löschmechanismen Sie kontrollieren und welche beim Anbieter liegen. So können Sie realistische Kontrollmechanismen anstelle von Annahmen entwickeln. Sie entscheiden, welche Spielerdaten in einen Dienst fließen, wie lange sie gespeichert werden und wann Sie die Löschung anfordern. Der Anbieter hingegen ist dafür verantwortlich, wie seine Infrastruktur gelöscht oder wiederverwendet wird.
Cloud-Anbieter sprechen häufig von geteilter Verantwortung: Sie sichern die Infrastruktur, Sie die Art und Weise ihrer Nutzung. Im Bereich der Löschung lässt sich diese Verantwortung oft grob wie folgt aufteilen:
- Infrastruktur als Dienstleistung: – Sie haben die Kontrolle über Betriebssysteme, Datenbanken und Anwendungsdaten; der Anbieter kontrolliert die physischen Datenträger und die Datenbereinigung auf niedriger Ebene.
- Platform‐as‐a‐Service: – Sie behalten die Kontrolle über Ihre Daten und Konfigurationen innerhalb der Managed Services; der Anbieter kümmert sich um Backups und die zugrunde liegenden Systeme.
- Software‐as‐a‐Service: – Sie haben in der Regel die Kontrolle über Konfiguration und Nutzungsmuster; der Anbieter kontrolliert fast alles andere.
Für jede wichtige Dienstleistung sollten Sie folgende Fragen beantworten können:
- Welche Daten über Ihre Spieler werden hier gespeichert?
- Wer kann die Aufbewahrung und Löschung konfigurieren?
- Was geschieht mit den Daten, wenn man ein Konto oder einen Datensatz löscht?
- Wie handhabt der Anbieter Datensicherungen und die Rückgabe oder Vernichtung von Daten am Vertragsende?
Die Dokumentation dieser Antworten ist Bestandteil sowohl von A.8.10 als auch anderer ISO 27001-Kontrollen im Zusammenhang mit der Cloud-Nutzung und bietet Ihnen eine klarere Grundlage für die Auswahl und Verhandlung von Anbietern.
Die Löschung vertraglich zu gestalten
Die Löschung von Daten ist wesentlich zuverlässiger, wenn sie vertraglich geregelt ist, anstatt informell behandelt zu werden, da Sie so eine klare Grundlage haben, Ihre Erwartungen zu formulieren. Ihre Datenverarbeitungsvereinbarungen und Sicherheitsrichtlinien sollten Aufbewahrungsfristen, die Unterstützung von Löschanträgen und die Behandlung der Daten nach Beendigung der Geschäftsbeziehung genau festlegen.
Richtlinien und gute Absichten reichen nicht aus, wenn andere Organisationen Ihre Daten speichern. Ihre Verträge, Datenverarbeitungsvereinbarungen und Sicherheitsrichtlinien sollten Folgendes regeln:
- Maximale Aufbewahrungsfristen für Daten, nachdem diese Ihre Systeme verlassen haben.
- Verpflichtung zur Unterstützung bei Anträgen auf Spielerlöschung innerhalb vereinbarter Fristen.
- Wie mit Backups, Protokollen und Archiven am Ende der Aufbewahrungsfrist oder bei Vertragsbeendigung umgegangen wird.
- Welche Nachweise Ihnen der Anbieter zur Verfügung stellt, wie z. B. Löschprotokolle oder Zertifikate, und unter welchen Umständen.
Sie sollten außerdem sicherstellen, dass Ihre Lieferantenrisikobewertungen die Datenlöschung explizit umfassen. Kann ein Anbieter seinen eigenen Datenlebenszyklus und seine Löschpraktiken nicht beschreiben oder stützt er sich ausschließlich auf allgemeine Zertifizierungen ohne Angaben zur Aufbewahrung, ist dies ein wichtiges Warnsignal, ihm mit Vorsicht zu begegnen oder strengere Vertragsbedingungen auszuhandeln. Die Branche erwartet zunehmend klare, schriftliche Löschzusagen in Verträgen.
Kontrolle der Exporte von Drittländern
Exporte von Drittanbietern erzeugen oft unkontrollierte Kopien von Spielerdaten, die außerhalb der üblichen Kontrollen liegen und selbst eine gut durchdachte Löschstrategie unbemerkt untergraben können. Dashboards, CSV-Exporte und synchronisierte Datensätze sind zwar praktisch, aber ohne explizite Aufbewahrungsregeln können sie jahrelang unbemerkt im System verbleiben.
Selbst wenn die Kerndienste einwandfrei funktionieren, können Daten durch folgende Wege in unkontrollierte Bereiche gelangen:
- Manuelle Exporte von Dashboards in Tabellenkalkulationen.
- Datensynchronisation in Business-Intelligence-Tools.
- Anhänge und Dateien in Ticket- oder Kollaborationssystemen.
Diese Kopien geraten leicht in Vergessenheit und lassen sich nur schwer gezielt löschen. Um das Risiko zu minimieren:
- Ad-hoc-Exporte sollten nach Möglichkeit minimiert und In-Place-Analysetools bevorzugt werden.
- Sofern Exporte notwendig sind, lagern Sie die Waren an regulierten Orten mit Aufbewahrungsfristen.
- Beziehen Sie diese Muster in Ihre Lebenszyklusanalyse und Mitarbeiterschulungen mit ein, damit sie nicht übersehen werden.
In vielen Studios reicht es schon aus, die Teams für das Risiko zu sensibilisieren und bessere Alternativen – wie zentralisierte Berichte oder Dashboards – anzubieten, um das Problem deutlich zu reduzieren. Dadurch sinkt wiederum die Wahrscheinlichkeit, dass bei einer Untersuchung oder einem Datenleck Daten aufgedeckt werden, deren Existenz bisher unbekannt war.
Buchen Sie noch heute eine Demo mit ISMS.online
ISMS.online unterstützt Sie dabei, ISO 27001 A.8.10 von einer vagen Löschregel in ein klares, auditierbares Kontrollsystem umzuwandeln, das Risiken durch nicht gelöschte Spielerdaten und sensible Protokolle für Ihre Titel und Dienste minimiert. Durch die Zentralisierung Ihrer Richtlinien, Dateninventare, Aufbewahrungsfristen, technischen Standards und Nachweise bietet Ihnen die Plattform einen einheitlichen und zuverlässigen Überblick darüber, wie Informationen studio- und anbieterübergreifend verwaltet werden.
Sehen Sie Ihr A.8.10-Geschoss an einem Ort
Wenn Sie Ihre ISO 27001-Arbeiten in einer dedizierten Umgebung wie ISMS.online verwalten, eröffnen sich Ihnen zahlreiche Vorteile:
- Ihre Aufbewahrungs- und Löschmatrizen stehen neben Risikobewertungen und Anwendbarkeitserklärungen, sodass Sie genau zeigen können, wie A.8.10 und A.5.32 zusammenwirken, um identifizierte Risiken zu mindern.
- Lebenszyklusdiagramme, Systeminventare und Lieferantenaufzeichnungen werden zu lebendigen Artefakten, die mit der Weiterentwicklung Ihrer Spiele und Ihres Technologie-Stacks aktualisiert werden, anstatt in vergessenen Präsentationen gefangen zu sein.
- Nachweise für Löschungen – von Konfigurationsexporten bis hin zu internen Prüfvermerken – können direkt mit den von ihnen unterstützten Kontrollen verknüpft werden, wodurch Prüfungen weniger zu einer hektischen Last-Minute-Aktion werden.
Für Teams, die in den Bereichen Sicherheit, Datenschutz, Daten, Engineering und LiveOps zusammenarbeiten, verwandelt diese gemeinsame Sicht die Löschung von einer vagen Idee in ein konkretes, nachvollziehbares Arbeitsprogramm. Sie bietet auch weniger erfahrenen Studios eine Struktur, an der sie sich orientieren können, wenn sie erstmals Kontrollmechanismen formalisieren. Eine ISMS-Plattform kann zudem Ihre Lebenszyklusdiagramme, Aufbewahrungsfristen und Lieferantendatensätze zentral verwalten, sodass Sie die Informationen nicht mühsam aus verstreuten Dokumenten und individuellen Erinnerungen zusammensetzen müssen.
Nächste Schritte für Ihr Studio
Wenn Sie die oben beschriebenen Herausforderungen in Ihrem eigenen Umfeld wiedererkennen, kann ein kurzes, zielgerichtetes Gespräch genügen, um zu sehen, wie eine Verbesserung aussehen könnte. Sie könnten beispielsweise Folgendes tun:
- Analysieren Sie den Lebenszyklus der Spielerdaten eines Titels und sehen Sie, wo die aktuellen Lösch- und Aufbewahrungsmechanismen ihre Grenzen haben.
- Prüfen Sie, inwiefern Ihre bestehende ISO 27001-Dokumentation wiederverwendet und erweitert werden kann, um A.8.10 ausführlicher abzudecken.
- Erfahren Sie, wie Workflows, Aufgabenzuweisungen und Dashboards dazu beitragen können, dass verschiedene Teams darüber abgestimmt sind, wer was wann zu tun hat, um den Löschvorgang planmäßig durchzuführen.
Vereinbaren Sie eine Demo mit ISMS.online und erleben Sie, wie sich alle Aspekte von Anhang A.8.10 – von gesetzlichen Aufbewahrungsfristen und Lebenszyklusabbildung bis hin zu technischen Löschmustern und Prüfnachweisen – in einem einzigen, übersichtlichen System vereinen lassen. So können Sie Spielerdaten schützen, die Auswirkungen von Vorfällen minimieren, Prüfer und Aufsichtsbehörden zufriedenstellen und weiterhin mit Zuversicht großartige Spiele veröffentlichen.
KontaktHäufig gestellte Fragen (FAQ)
Wie sollte ein Spielestudio die Löschung von Spielerdaten gemäß ISO 27001 A.8.10 überdenken?
Sie sollten das Löschen von Spielerdaten als eine entworfene, nachgewiesene Phase im Lebenszyklus, keine spontane Gefälligkeit, die man über Support-Tickets erweist.
Wie verändert A.8.10 unsere alltäglichen Annahmen über „Löschen“?
Gemäß ISO 27001 A.8.10 ist die Löschung von Konten auf Anfrage von Spielern lediglich das absolute Minimum und nicht mehr das operative Modell. Die Klausel erwartet von Ihnen Folgendes:
- Behandeln Sie jede Spielerdatenkategorie (Konten, Zahlungen, Chat, Telemetrie, Anti-Cheat, Support) als eine verwaltete Vermögenswerte mit einem Zweck, einem Eigentümer und einem definierten Endzustand.
- Legen Sie im Voraus fest, wann jede Kategorie wechselt von aktive Nutzung (wird benötigt, um das Spiel auszuführen oder zu schützen) gerechtfertigte Beibehaltung (Steuern, Streitigkeiten, Betrug, Sicherheit) und schließlich zu Entfernung oder Anonymisierung.
- Verwandle diese Entscheidungen in wiederholbare technische Muster: Feste Zeitfenster für das Soft-Delete, geplante Hard-Deletes, Anonymisierungsaufträge und Lebenszyklusregeln in Speicher- und Protokollplattformen.
- Erfassung Beweise dafür, dass diese Muster laufen: Jobprotokolle, Änderungsdatensätze, Konfigurationsexporte und Stichprobenprüfungen, die Ihr ISMS zusammen mit der A.8.10-Steuerung verwalten kann.
Der eigentliche Wandel findet von der Improvisation zur VorhersagbarkeitEin Studio, das genau weiß, wo es noch identifizierbare Spieler gibt, wo nur noch anonymisierte Gruppen existieren und wer komplett aus dem Spiel genommen wurde, hat einen geringeren Gefahrenradius, wenn etwas schiefgeht, und eine klarere Geschichte, wenn es sich gegenüber Prüfern oder Plattformen erklären muss.
Wie lässt sich diese Denkweise in der Praxis umsetzen?
Ein Informationssicherheitsmanagementsystem bietet Ihnen eine zentrale Stelle zur Verknüpfung von Daten. Politik, Risiko und Umsetzung:
- Sie verwalten Datenkategorieinventare, Aufbewahrungsregeln und Löschstandards in einem einzigen Arbeitsbereich.
- Jede A.8.10-Kontrolle ist mit konkreten Risiken, Systemen und Arbeitsabläufen verknüpft und stellt keine abstrakte Formulierung dar.
- Interne Audits, Änderungsgenehmigungen und Vorfallanalysen können alle auf dieselben Artefakte verweisen, daher wird das Löschen zu wie man Spiele entwickelt und betreibt, keine einmalige Reinigung vor der Zertifizierung.
Wenn Sie einen Auditor ruhig und verständlich von der Risikoanalyse über Aufbewahrungsfristen und technische Muster bis hin zu den Nachweisen führen können, vermittelt Ihr Studio den Eindruck, dass es langfristiges Kundenvertrauen und nicht nur die kurzfristige Bereitstellung von Funktionen versteht. Ein ISMS wie ISMS.online erleichtert diesen Prozess erheblich, indem es Kontrollen, Aufzeichnungen und Verantwortlichkeiten eng miteinander verknüpft und stets aktuell hält.
Wie können wir Aufbewahrungsfristen für Spielerdaten entwerfen, die Betrug verhindern und gleichzeitig die Sicherheit und den Analysewert gewährleisten?
Sie gestalten Kundenbindung um warum Sie jede Kategorie halten und welches Gesetz oder welcher Vertrag dies erlaubt.nicht um die Datenbank oder das Dashboard herum, das gerade am wichtigsten erscheint.
Wie entwickeln wir eine Kundenbindungsmatrix, die für das gesamte Spieleportfolio funktioniert?
Die meisten Studios profitieren von einem einzigen Retentionsmatrix das die gesamte Bandbreite der Spielerdatentypen abdeckt:
- Konto und Identität (Logins, Kontaktdaten, Alterskennzeichnungen)
- Zahlungen und Abrechnungsunterlagen
- Chat und soziale Interaktionen
- Sicherheits- und Infrastrukturprotokolle
- Indikatoren zur Betrugsbekämpfung
- Gameplay-Telemetrie und UX-Analysen
- Support- und Community-Tickets
Für jede Zeile legen Sie vier Dinge fest:
- Zweck: – warum Sie es sammeln (Spielbetrieb, Abrechnung mit den Spielern, Aufrechterhaltung der Sicherheit, Betrugsbekämpfung, Verbesserung des Designs).
- Rechtliche / vertragliche Grundlage: – Verbraucherrecht, Steuervorschriften, PCI DSS, Plattformbedingungen, Datenschutzrecht usw.
- Mindestaufbewahrung: – was Sie aufbewahren müssen, um die Vorschriften einzuhalten (z. B. Steuerunterlagen oder Informationen zu Rückbuchungszeiträumen).
- Maximale Aufbewahrungsdauer für identifizierbare Daten: – der Zeitpunkt, an dem Sie einzelne Personen löschen oder anonymisieren, auch wenn Sie aggregierte Muster beibehalten.
Betrug und Sicherheit sind Bereiche, in denen Teams oft in die Falle tappen, alles für immer aufzubewahren. A.8.10 verhindert keine längeren Aufbewahrungsfristen, wenn das Risiko dies tatsächlich rechtfertigt, erwartet aber von Ihnen Folgendes:
- Geben Sie diese Kategorien an explizite, begründete Zeitdauern (zum Beispiel Streitzeitraum zuzüglich eines festgelegten Puffers).
- Trennen Sie Rohdatensätze, die auf identifizierbare Informationen hinweisen. abgeleitete Signale (Risikobewertungen, gehashte Kennungen, anonymisierte Kohorten), sodass Sie Signale länger speichern können als die Identität.
- Behandeln Sie ungewöhnliche Ermittlungen als zeitlich begrenzte Ausnahmenjeweils mit einem Eigentümer und einem Überprüfungsdatum anstelle von ungenannten permanenten Ausnahmen.
Im Bereich der Analytik hängen die meisten Designentscheidungen von Folgendem ab: Muster statt einzelner SpielerDadurch können Sie die Aufbewahrungsfrist für Telemetriedaten mit voller Genauigkeit verkürzen und ältere Daten verschieben in aggregierte oder anonymisierte Ansichten Produkt- und Datenteams können weiterhin Abfragen durchführen. Außerdem werden Exporte (BI-Extrakte, CSV-Dumps, Sandbox-Datensätze) in denselben Lebenszyklus integriert, anstatt sie als unsichtbare Langzeitkopien zu belassen.
Wo sollten diese Regeln verankert sein, damit sie ihre Gültigkeit behalten?
Aufbewahrungsregeln verlieren schnell ihre Gültigkeit, wenn sie in E-Mail-Verläufen oder isolierten Tabellenkalkulationen versteckt sind. Wenn Sie sie in einem ISMS verwalten:
- Datenschutz, Sicherheit, Analytik und Technik können alle ihr Okay geben einzelne, gemeinsam genutzte Matrix.
- Überprüfungen können in Ihr Risikoregister und Ihren Managementbewertungszyklus eingebunden werden.
- Nachweise wie Konfigurations-Screenshots, Richtlinienbestätigungen und Stichprobenergebnisse werden neben den Regeln abgelegt, sodass Sie den Prüfern beides zeigen können. die Entscheidung und ihre praktische Umsetzung.
Wenn Sie A.8.10 von einer Belastung in ein Gestaltungsinstrument verwandeln möchten, macht die zentrale Speicherung dieser Matrix auf einer Plattform wie ISMS.online einen großen Unterschied. Sie erhalten eine einheitliche Sicht auf die Aufbewahrungsdauer, die mit ISO 27001, Datenschutzbestimmungen und Ihren betrieblichen Abläufen übereinstimmt.
Was genau beinhaltet die sichere Löschung von Spieldatenbanken, Protokollen, Telemetriedaten und Backups?
Sicheres Löschen bedeutet, dass Daten, sobald sie ihr definiertes Lebensende erreicht haben, gelöscht werden. Mit zumutbarem Aufwand praktisch nicht mehr wiederherstellbar., über Live-Systeme, Analyse-Stacks und Backups hinweg.
Wie sollten wir mit Live-Diensten und Datenbanken umgehen?
Bei Kerndiensten, die Konten, Berechtigungen, Inventare und ähnliche Spielerdatensätze verwalten, kombiniert die sichere Löschung üblicherweise Folgendes:
- Aktionen auf Anwendungsebene: beispielsweise das Löschen oder Anonymisieren von Datensätzen auf Zeilenebene, sobald eine Aufbewahrungsregel erfüllt ist oder ein Löschantrag validiert wurde.
- Zeitbasierte Partitionierung: So können ganze Tabellenpartitionen oder Shards (zum Beispiel nach Monat oder Saison) gelöscht werden, wodurch aufwändige Bereinigungen Zeile für Zeile vermieden werden.
- Regelmäßige Speicherwartung – Verdichtung oder Absaugen – damit „gelöschte“ Datensätze nicht auf unbestimmte Zeit im nicht zugewiesenen Speicherplatz verbleiben.
Der Schlüssel liegt darin, diese auszudrücken als HausmusterEs geht nicht um individuelle Entwicklerentscheidungen. Ein einfacher interner Standard wie „Konten verwenden Muster A; Transaktionshistorie verwendet Muster B; Inventare verwenden Muster C“ macht das Verhalten titelübergreifend vorhersehbar und die Dokumentation gemäß A.8.10 deutlich einfacher.
Wie sieht es mit Protokollen, Telemetriedaten und Langzeitspeicherung aus?
Log-Streams und Telemetriedaten enthalten oft reichhaltigerer Spielerkontext als die primäre Spieledatenbank. In diesen Systemen hängt die sichere Löschung stark von der Konfiguration ab:
- Eingebaut Kontrollen der Aufbewahrung und Rotation in Protokollierungs- und Überwachungstools, die für Gameplay-, Leistungs- und Sicherheitsdatenströme unterschiedlich abgestimmt sind.
- Frühe Minimierung – Hashing, Abschneiden oder Tokenisieren von Kennungen nahe der Quelle – damit nicht jede Logzeile die vollständige Identität preisgibt, gefolgt von Anonymisierung oder Downsampling mit zunehmendem Alter der Daten.
- Lebenszyklusregeln in Objektspeichern oder Data Lakes, die Datensätze ablaufen lassen oder archivieren und mit diesen koordiniert werden SchlüsselverwaltungDadurch können Sie Verschlüsselungsschlüssel außer Betrieb nehmen, wenn die Daten effektiv verschwinden sollen.
Backups sind der Punkt, an dem das physische Löschen jeder einzelnen Kopie nicht mehr praktikabel ist. Viele etablierte Studios setzen daher auf Backups. kryptographische Löschung Stattdessen: Einzelne Datensätze mit bereichsspezifischen Schlüsseln verschlüsseln und die geplante Schlüsselabmeldung als Löschvorgang behandeln. In Kombination mit Lebenszyklusrichtlinien und Schlüsselverwaltungsprotokollen wird dies von Prüfern und Aufsichtsbehörden allgemein als praktikable Methode akzeptiert, um die Speicherung lesbarer Historien zu unterbinden.
Der Funktionstest ist unkompliziert: Für jeden wichtigen Speicherort von Spielerdaten können Sie drei Fragen beantworten – Was passiert nach Ablauf der Aufbewahrungsfrist, wer löst sie aus und wie lässt sich das nachweisen?Ein ISMS wie ISMS.online hilft Ihnen dabei, diese Antworten datenbankübergreifend, auf Protokollplattformen und in Backup-Systemen konsistent und nachvollziehbar zu halten.
Wie kann ein Spieleentwicklungsstudio den Lebenszyklus von Spielerdaten so abbilden, dass ISO 27001 A.8.10 für alle Beteiligten verständlich ist?
Sie bilden den Lebenszyklus ab, damit die Leute A.8.10 als ein gemeinsames Bild des Datenflusses der Spielernicht als Absatz in einer Norm.
Wie sollte eine praktische Lebenszykluskarte aussehen?
Für einen Vorzeigetitel könnte eine Lebenszykluskarte, die den Nutzern tatsächlich hilft, Folgendes beinhalten:
- Beginnen Sie dort, wo Daten auftreten: Kontoerstellung, Anmeldung, Käufe, Spielereignisse, Chat, Anti-Cheat-Prüfungen, Support-Kontakte, Marketing-Einstiegspunkte.
- Zeigen Sie, wo die Daten als Nächstes landen: Kontoverwaltung, Spielzusammenstellung, Anti-Cheat-Systeme, Telemetrie-Sammler, Data Warehouse, Protokollierungsplattformen, CRM und Community-Tools.
- Unterscheiden aktive Systeme, Warme Lagerung, Archiv und Löschung/Anonymisierung Stufen.
- Markieren Sie die Ereignisse, die die Aufbewahrungsfristen starten (letzte Aktivität, Ende des Abonnements, Ende des Rückbuchungszeitraums) und die Prozesse oder Jobs diese Handlung, wenn diese Punkte erreicht sind.
- Berücksichtigen Sie auch weniger offensichtliche Schatten: Staging-Umgebungen, die aus der Produktion befüllt werden, Data-Science-Sandboxes, CSV-Exporte und lokale Entwicklerkopien.
Sobald diese Ansicht für ein Spiel existiert, kann das Muster standardisiert und für andere Titel angepasst werden, anstatt die Kundenbindung jedes Mal von Grund auf neu zu gestalten. Neue Systeme oder Anbieter müssen dann erklären wo sie sich im Lebenszyklus befinden und wie sie dieselben Übergänge würdigen.
Wie hängt das mit A.8.10 und Ihrem ISMS zusammen?
Mit dem im ISMS referenzierten Lebenszyklusartefakt können Sie:
- Link A.8.10 direkt zu benannte Übergangspunkte: wenn Daten nicht mehr aktiv genutzt werden, wenn Zeitstempel gesetzt werden und wenn Löschung oder Anonymisierung Anwendung findet.
- Weisen Sie an jedem Punkt Verantwortlichkeiten zu, sodass klar ist, wer die Aufbewahrung konfiguriert, wer die Jobs ausführt und wer die Nachweise überprüft.
- Verwenden Sie die Karte wieder in Designprüfungen, Änderungsgenehmigungen und LieferantenbewertungenSo argumentieren Sicherheits-, Datenschutz- und Entwicklungsteams anhand desselben Diagramms anstatt anhand konkurrierender Annahmen.
Die Speicherung dieser Karte, der zugehörigen Regeln und Verfahren in ISMS.online ermöglicht es, den Lebenszyklus von Daten in Ihre reguläre Governance zu integrieren. Managementbewertungen und interne Audits können nach Vorfällen die Frage stellen: „Wo befanden sich diese Daten in ihrem Lebenszyklus?“ Genau dadurch wird A.8.10 zu einem integralen Bestandteil eines guten Systemdesigns und nicht nur zu einer Pflichtübung.
Wer sollte in einem Live-Games-Unternehmen die Verantwortung für Aufbewahrungs- und Löschentscheidungen tragen, und wie können wir die Ausbreitung von Ausnahmen verhindern?
Aufbewahrung und Löschung werden zuverlässig, wenn sie klare Zuständigkeiten, ein einfacher Entscheidungsprozess und eine transparente Nachverfolgung von Ausnahmen.
Wie können wir Aufgaben verteilen, ohne eine Bürokratie aufzubauen?
In der Praxis begnügen sich die meisten Live-Studios mit einer einfachen RACI-artigen Aufteilung:
- Eine Sicherheits- oder CISO-Funktion ist verantwortlich zur Erfüllung von A.8.10 über verschiedene Titel und Shared Services hinweg.
- Eine Datenschutz- oder Rechtsfunktion ist für ihren Verlust verantwortlich. um sicherzustellen, dass Aufbewahrung und Löschung mit dem Gesetz, den Plattformverpflichtungen und den Anweisungen an die Spieler übereinstimmen.
- Daten- und Plattformentwicklungsteams sind für ihren Verlust verantwortlich. zur Implementierung und zum Betrieb von Lösch- und Anonymisierungsmustern in Code, Infrastruktur und Datenpipelines.
- LiveOps, Produkt und Analytik sind konsultiert damit Aufbewahrungsfristen nicht stillschweigend Betrugskontrollen, Versuchsdesign oder das Spielerlebnis untergraben.
- Support- und Community-Teams sind für ihren Verlust verantwortlich. zur Bearbeitung von Spieleranfragen, zum Erwartungsmanagement und zum Kennzeichnen von Sonderfällen, die vorübergehende Verlängerungen auslösen könnten.
Um zu verhindern, dass Ausnahmen Ihr Modell langsam untergraben, fügen Sie einen schlanken Steuerungsmechanismus anstelle eines neuen Komitees hinzu:
- Jede verlängerte Aufbewahrung aufgrund von Ermittlungen, Betrugsfällen oder Sicherheitsgründen wird mit Angabe des Grundes, des Verantwortlichen und des Überprüfungsdatums protokolliert.
- Diese Aufzeichnungen werden im gleichen Rhythmus wie Ihre anderen Risiko- und Compliance-Themen überprüft – zum Beispiel im Rahmen vierteljährlicher ISMS-Management-Reviews.
- Eine kleine Auswahl an A.8.10-Metriken – wie zum Beispiel Pünktliche Bearbeitung von LöschanträgenAnzahl Ausnahmen für überfällige Zahlungen und Systeme, denen noch definierte Regeln fehlen – erscheint in der regulären Berichterstattung.
Wenn Sie dies in einer ISMS-Plattform wie ISMS.online verwalten, können dieselben Workflows, die Vorfälle, Änderungen und Risiken bearbeiten, auch Entscheidungen über Aufbewahrung und Löschung umfassen. Dadurch bleibt die tatsächliche Verwendung von Spielerdaten im Einklang mit den Informationen, die Sie Spielern, Partnern und Aufsichtsbehörden mitteilen – selbst wenn sich das Studio in der Launch-Phase befindet oder dringende Probleme behebt.
Wie verändern Cloud-Dienste und -Anbieter unsere Herangehensweise an A.8.10, und was sollten wir in Verträge und Konfigurationen einbeziehen?
Cloud- und SaaS-Dienste verändern sich wo und wie Spielerdaten werden gespeichert und gelöscht, aber das ändert nichts an der Tatsache, dass Ihr Studio ist weiterhin verantwortlich um festzulegen, was wie lange aufbewahrt wird und wann es entfernt oder anonymisiert werden muss.
Welche Daten sollten wir für jeden Dienst erfassen, der Spielerdaten verarbeitet?
Für jeden Anbieter, der Spieler-IDs oder Verhaltensdaten speichert, sollten Ihre ISMS-Aufzeichnungen Folgendes enthalten:
- Welche Spielerdatenkategorien Es speichert (IDs, Kontaktdaten, Zahlungstoken, Chatprotokolle, Telemetriedaten, Supportaufzeichnungen) und für welche Titel, Regionen oder Plattformen.
- Welche Aufbewahrungs- und Löschoptionen Sie können Folgendes steuern: Schieberegler für die Protokollaufbewahrung, Lebenszyklusregeln für Objektspeicher, integrierte Löschwerkzeuge, Verhalten bei Kontoschließung.
- Wie die Löschung in der Praxis ausgelöst wird – durch Konfiguration, geplante Prozesse, API-Aufrufe oder Support-Tickets – und was das für Backups, Replikate und Analysenexporte.
- Was Beweis Sie können Folgendes erfassen und aufbewahren: Konfigurationsexporte, Audit-Protokolle, SOC 2- oder ISO 27001-Berichte, Herstellererklärungen zur Datensicherung und Datenträgerbereinigung zum Vertragsende.
Diese Details prägen zwei wichtige Artefakte:
- Ihre internen Lebenszyklus- und Retentionsmatrix, wo Drittanbieter-Shops neben hauseigenen Datenbanken und Protokollierungsplattformen erscheinen.
- Ihr Verträge und Datenverarbeitungsvereinbarungen, wodurch Erwartungen hinsichtlich maximaler Aufbewahrung, Unterstützung beim Löschen, Behandlung von Backups und Verhalten bei Beendigung oder Migration festgelegt werden sollten.
Bei der Risikobewertung von Anbietern sollten Löschung und Aufbewahrung genauso wichtig genommen werden wie Verschlüsselung und Zugriffskontrolle. Kann ein Anbieter den von Ihnen definierten Lebenszyklus für die Daten Ihrer Spieler nicht einhalten, ist dies eine bewusste Risikoentscheidung für Ihre Sicherheits- und Datenschutzbeauftragten und kein versehentliches Sicherheitsrisiko unter dem Druck der Veröffentlichung.
Wenn Sie diese Erwartungen, Konfigurationen und Nachweise in ISMS.online verwalten, gewährleisten Sie eine konsistente Darstellung gemäß A.8.10, auch wenn sich Ihr Anbietermix ändert. Sie können nachweisen, welche Dienste welche Kategorien von Spielerdaten speichern, wie lange diese aufbewahrt werden, wie die Löschung oder Anonymisierung ausgelöst wird und wo die entsprechenden Nachweise gespeichert werden – genau die Transparenz, die Plattformen, Regulierungsbehörden und Spieler erwarten, um langfristig Vertrauen in ein Spielestudio zu fassen.
