ISO 27001 A.8.10 : Suppression sécurisée des données des joueurs pour les studios de jeux vidéo

Pourquoi les données de joueurs que vous ne supprimez pas sont devenues un handicap stratégique

Les données des joueurs que vous ne supprimez pas à temps deviennent rapidement un problème de sécurité, de confidentialité et de conformité réglementaire pour votre studio. Lorsque les données de télémétrie, les historiques de chat et les demandes d'assistance ne disparaissent jamais complètement, chaque violation de données ou enquête implique davantage de systèmes, de preuves et de travail que nécessaire. En traitant les données en fin de vie comme un risque géré, vous pouvez réduire l'impact des incidents, simplifier les enquêtes et limiter les risques d'utilisation abusive des informations.

Les données des joueurs se trouvent désormais au carrefour des revenus, de la réglementation et de la réputation ; leur conservation non maîtrisée accroît donc insidieusement les risques. L’annexe A.8.10 de la norme ISO 27001:2022 stipule clairement que les informations doivent être supprimées lorsqu’elles ne sont plus nécessaires, de manière à empêcher toute récupération et à respecter les exigences légales, réglementaires, contractuelles et internes. Cette formulation répond autant aux attentes en matière de confidentialité et de protection des données qu’à celles relatives à la sécurité de l’information classique.

La plupart des studios savent déjà comment protéger les systèmes en production ; en revanche, rares sont ceux qui peuvent démontrer avec certitude ce qu’il advient des données lorsqu’elles ne sont plus nécessaires. C’est précisément là que la norme A.8.10 intervient. Elle vous invite à ne plus considérer les anciennes données et journaux des joueurs comme de simples archives inoffensives, mais comme des actifs devant être délibérément supprimés. Que vous mettiez en œuvre la norme ISO 27001 pour la première fois ou que vous renforciez un système de gestion de la sécurité de l’information (SGSI) déjà établi, ce contrôle permet de concrétiser les politiques de conservation et de suppression effective.

Les données que vous n'avez jamais collectées ou que vous avez supprimées à temps ne peuvent jamais être volées, faire l'objet d'une citation à comparaître ou être utilisées contre vous.

Le coût caché de l'accumulation des données des joueurs

Les données des joueurs, souvent méconnues, se cachent à des endroits plus nombreux qu'on ne le pense, des anciens systèmes de télémétrie aux bases de données de test oubliées. Chaque copie supplémentaire augmente l'impact d'une fuite de données ou soulève des questions sur la durée de conservation, car le nombre de systèmes concernés et de preuves à examiner est plus important que prévu.

Si vous examinez attentivement l'emplacement des données des joueurs, vous constaterez généralement qu'elles contiennent bien plus que de simples tables de comptes et des enregistrements de paiement. Voici quelques exemples typiques :

Les anciens pipelines de télémétrie qui continuent de recevoir des événements même si les tableaux de bord ne sont plus utilisés.
Anciens fichiers de vidage mémoire contenant les identifiants bruts des périphériques et les traces de pile.
Les archives des conversations sont conservées « au cas où » pour la modération, mais ne sont jamais consultées.
Copies des bases de données de production dans des environnements de test et des bacs à sable.

Chacune de ces copies augmente le risque d'incident. Si un pirate informatique s'introduit dans votre système d'analyse, ou si une autorité de régulation vous interroge sur la conservation des données de mineurs, vous ne pouvez pas vous contenter de renvoyer les données vers votre base de données principale. Vous devez prendre en compte tous les emplacements où les données ont été stockées au fil des années, suite aux lancements, mises à jour et expérimentations.

Il ne s'agit pas uniquement de sécurité. La conservation excessive des données compromet également votre discours sur la minimisation des données dans les analyses d'impact relatives à la protection des données, les questionnaires destinés aux partenaires et les audits de plateforme. Si vos politiques exigent une durée de conservation d'un an, mais que vos systèmes en conservent discrètement cinq, votre crédibilité est mise à mal avant même qu'un problème ne survienne. Pour les équipes qui formalisent leur système de gestion de la sécurité de l'information (SGSI), la transparence de cet inventaire constitue souvent la mesure la plus efficace pour réduire les risques.

Comment les journaux non supprimés aggravent les incidents

Les journaux non supprimés ralentissent, renchérissent et compliquent la résolution des incidents, car ils augmentent le volume de données potentiellement exposées et l'effort nécessaire pour évaluer leur impact. Lorsque la conservation des données n'est pas segmentée par finalité, on finit par conserver beaucoup plus d'informations sensibles pendant une durée bien supérieure au risque réel.

Lorsqu'une violation de données survient, deux éléments sont cruciaux : la rapidité avec laquelle vous pouvez évaluer l'étendue des données compromises et la clarté avec laquelle vous pouvez expliquer cette étendue aux dirigeants, aux partenaires et aux autorités de réglementation. Des journaux et des pipelines de télémétrie persistants et mal gérés compromettent ces deux objectifs, car ils mélangent des traces routinières avec des informations hautement sensibles et conservent toutes les données pendant des années.

Il est utile de faire la distinction entre les différents types de bûches que vous détenez :

Journaux opérationnels : – pour les performances, la stabilité et le débogage.
Journaux de sécurité : – pour le contrôle d'accès, la détection des anomalies et la réponse aux incidents.
Journaux de fraude et de lutte contre la tricherie : – pour l’analyse et l’application des tendances à long terme.

Les équipes de sécurité, de lutte contre la tricherie et la fraude plaident souvent pour une conservation prolongée des données, et elles ont parfois raison. Le problème est que cette conservation est rarement segmentée. Les journaux d'authentification de routine et les indicateurs de réseaux de fraude, pourtant très sensibles, sont traités de la même manière et conservés indéfiniment.

Concrètement, cela signifie que les équipes d'investigation numérique doivent analyser d'énormes volumes de données pour comprendre ce qui a été consulté, que les services juridiques doivent déterminer si des enregistrements très anciens relèvent désormais du champ d'application de la divulgation, et que les équipes opérationnelles doivent gérer l'impact sur les performances des journaux de transactions volumineux. La norme ISO 27001 A.8.10 impose de structurer cette profusion de données grâce à des limites explicites, l'automatisation et la surveillance.

Pourquoi les studios de jeux vidéo sont particulièrement exposés

Les studios de jeux vidéo sont particulièrement vulnérables car ils collectent des données comportementales détaillées sur la façon dont les joueurs jouent, dépensent et interagissent, incluant souvent des mineurs et des joueurs fragiles. Lorsque ces informations sont conservées plus longtemps que nécessaire, elles deviennent un risque plutôt qu'un atout et compliquent considérablement la gestion de tout incident ou critique.

Les entreprises de jeux vidéo collectent certaines des données comportementales les plus riches de tous les secteurs de consommation. Elles suivent souvent non seulement les dépenses et les connexions, mais aussi le déroulement du jeu seconde par seconde, les conversations, les interactions sociales, les profils d'appareils, les indices de géolocalisation et les signaux anti-triche. Elles peuvent également être amenées à traiter des données concernant des mineurs, des joueurs auto-exclus ou des personnes résidant dans des territoires où la protection de la vie privée est strictement encadrée.

Tout cela rend les données non supprimées plus sensibles :

L'historique des matchs et les journaux de discussion peuvent révéler des habitudes de jeu, des relations et, dans certains cas, des problèmes de santé ou de stress financier.
Les données relatives à la monétisation des loot boxes et des microtransactions sont au cœur des débats actuels sur la protection des consommateurs.
Les systèmes anti-triche et anti-fraude peuvent déduire ou stocker des profils de risque sensibles concernant les individus.

Prenons un exemple simple concernant des mineurs. Un adolescent joue avec l'autorisation de ses parents, discute de l'école et de sa famille, effectue des achats avec la carte de ses parents, puis ferme son compte. Des années plus tard, si des historiques détaillés de parties et de conversations existent encore, vous détenez inutilement un historique comportemental très sensible d'une personne désormais majeure, sans raison apparente. Il en va de même pour les joueurs auto-exclus ou vulnérables dont vous avez le devoir de traiter les données avec soin.

Lorsque ces enregistrements sont conservés longtemps après avoir été inutiles, vous vous exposez à des risques inutiles pour la confidentialité et votre réputation. Se conformer à la norme A.8.10 vous permet de réduire ce risque de manière maîtrisée, sans attendre une violation de données, une plainte ou une intervention des autorités de réglementation. Une plateforme comme ISMS.online vous aide à y voir plus clair en centralisant les politiques, les inventaires de données et les contrôles. Vous pouvez ainsi déterminer ce qui doit être conservé, ce qui doit être anonymisé et ce qui doit être définitivement supprimé, puis démontrer aux auditeurs comment ces décisions sont appliquées.

Demander demo

Ce que la norme ISO 27001:2022 A.8.10 exige réellement des studios de jeux vidéo

La norme ISO 27001:2022, annexe A.8.10, exige que la suppression des données soit considérée comme une étape normale du cycle de vie des données des joueurs, et non comme une simple formalité. Il vous incombe de déterminer à quel moment chaque type d'information n'est plus nécessaire, de choisir une méthode de suppression ou d'anonymisation appropriée, puis de prouver que ces méthodes sont effectivement mises en œuvre sur les systèmes qui stockent ces données.

Sur le papier, la norme A.8.10 semble concise, mais ses implications sont profondes. Elle exige la suppression des informations lorsqu'elles ne sont plus nécessaires, de manière à empêcher toute récupération et en conformité avec les exigences légales, réglementaires, contractuelles et internes. Pour une entreprise de jeux vidéo, cela signifie concevoir la suppression comme une fonctionnalité intégrée, et non comme une action ponctuelle à effectuer lorsqu'un utilisateur s'en souvient.

Concrètement, il vous est demandé de déterminer à quel moment chaque type de données et de journal de joueurs cesse d'être nécessaire, de choisir des méthodes de suppression ou d'anonymisation adaptées au risque, et de pouvoir démontrer que ces méthodes sont effectivement mises en œuvre. Le point A.8.10 s'applique conjointement à l'annexe A.5.32 relative à la conservation des données et à votre processus de gestion des risques (article 6) : vous décidez quelles données conserver, pendant combien de temps et quelles menaces la suppression sécurisée vous aide à gérer.

Explication en langage clair de l'annexe A.8.10

Pour comprendre le point A.8.10, considérez-le comme cinq questions simples concernant vos données et vos décisions. Il ne s'agit pas de décrire des produits spécifiques, mais d'expliquer simplement ce que vous conservez, pourquoi vous le conservez et ce que vous faites lorsqu'il n'est plus nécessaire.

On peut considérer que la question A.8.10 repose sur cinq questions :

De quelles informations parlez-vous ?
Non seulement les « données personnelles » au sens de la protection de la vie privée, mais toute information contenue dans des systèmes, des appareils ou des supports : tableaux de comptes, événements de jeu, journaux de fraude, télémétrie, sauvegardes, exportations, etc.
Quand cela n'est-il plus nécessaire ?
C’est ici que les points A.8.10 et A.5.32 relatifs à la conservation des documents et à vos obligations légales se rejoignent. La mention « non requis » doit reposer sur un objectif précis et sur la loi, et non sur une simple commodité.
Comment allez-vous le supprimer ou l'anonymiser ?
La suppression logique, l'effacement cryptographique, la désinfection du stockage, l'agrégation et l'anonymisation peuvent toutes être valides, mais elles doivent être choisies délibérément.
Qui est responsable?
Les politiques et les procédures doivent attribuer la responsabilité de définir les règles, de mettre en œuvre les mécanismes de suppression et de vérifier leur bon fonctionnement.
Comment le prouver ?
Vous avez besoin de preuves : configurations, journaux, tickets et résultats d’audits internes qui démontrent que la suppression ou l’anonymisation a réellement lieu.

Vu sous cet angle, A.8.10 est moins un contrôle « technologique » qu’un pont entre votre gouvernance de l’information – ce que vous conservez et pourquoi – et votre mise en œuvre technique – comment vous faites disparaître les données ou les rendez inoffensives.

Comment la norme A.8.10 s'intègre à votre système de gestion de l'information (SGSI)

Le point A.8.10 n'est efficace que s'il est intégré à votre système de gestion de la sécurité de l'information. Il s'appuie sur vos évaluations des risques et vos décisions de conservation des données, et fournit des mesures concrètes que vous pouvez mettre en avant pour expliquer comment vous réduisez l'impact des incidents, des audits et des plaintes relatives à la protection de la vie privée.

Si vous utilisez déjà un système de gestion de la sécurité de l'information, la section A.8.10 ne doit pas être utilisée isolément. Elle est liée à :

A.5.32 – Rétention : qui stipule que vous devez définir la durée de conservation des informations. A.8.10 concerne l'exécution : que se passe-t-il à la fin de cette période ?
Article 6 – Traitement des risques : où vous décidez quelles menaces sont réduites par suppression sécurisée, anonymisation ou minimisation.
Contrôles relatifs à la journalisation et à la surveillance : car les règles de conservation des journaux et les tâches de suppression doivent être conformes aux exigences de sécurité, de lutte contre la fraude et de protection de la vie privée.
Contrôles du cloud et des fournisseurs : car votre plan de suppression doit couvrir les infrastructures et les services que vous n'exploitez pas directement.
Contrôle d'accès et chiffrement : car la suppression efficace est plus facile si les données sensibles sont séparées et chiffrées avec des clés bien gérées.

Lorsque vous documentez vos contrôles, il est utile de montrer explicitement ce lien : par exemple, en faisant référence aux règles de conservation dans vos procédures de suppression et en consignant dans votre plan de traitement des risques comment A.8.10 atténue des menaces spécifiques telles que la rémanence des données ou la surconservation.

La différence entre ignorer la suppression et s'aligner sur A.8.10 est souvent flagrante :

Sans discipline de rétention et de suppression	Conforme à la norme A.8.10
Il est difficile de définir la portée de l'incident.	Portée basée sur des magasins de données connus et cartographiés
Les audits sont réactifs et pénibles.	Les audits suivent un cycle de vie documenté
Le niveau de confidentialité semble incohérent.	Les règles de rétention et le comportement du système correspondent clairement.
La confiance entre joueurs et partenaires est fragile.	Vous pouvez démontrer les limites de minimisation et de rétention

Une plateforme ISMS telle que ISMS.online facilite ces liens en vous permettant de relier les politiques, les risques, les contrôles et les preuves, afin qu'un auditeur – et votre propre direction – puissent suivre une ligne directe depuis l'exigence de haut niveau jusqu'aux actions concrètes dans vos systèmes.

Ce que les auditeurs recherchent réellement

Les auditeurs s'intéressent à la manière dont vous concevez, mettez en œuvre et gérez la suppression des données, et pas seulement à une simple clause de politique, car ils doivent pouvoir s'assurer que vos affirmations correspondent à la réalité. Ils veulent vérifier que les règles de conservation existent, sont appliquées rigoureusement et font l'objet d'un suivi en cas de problème, afin de pouvoir se fier à vos déclarations concernant les données et les journaux des joueurs.

Les auditeurs ne se contentent jamais d'une simple phrase de politique générale affirmant « nous supprimons les données lorsqu'elles ne sont plus nécessaires ». Ils recherchent généralement trois niveaux de preuves :

Conception: – des politiques, normes et procédures documentées qui définissent les durées de conservation, les méthodes de suppression et les responsabilités pour différents types de données.
Mise en œuvre: – les configurations système, les tâches d’automatisation et les artefacts de processus tels que les tâches planifiées, les règles de cycle de vie du magasin d’objets ou les routines de base de données qui correspondent à ce que promettent les documents.
Exploitation et surveillance : – les journaux, les tickets et les contrôles d’audit interne démontrant que la suppression ou l’anonymisation a bien eu lieu, que les défaillances sont détectées et corrigées, et que les exceptions sont enregistrées et examinées.

Pour les données et les journaux des joueurs, cela pourrait impliquer de les afficher :

Une matrice de conservation et de suppression pour les principales catégories de données.
Procédure de traitement des demandes d'effacement de joueurs.
Captures d'écran ou exportations provenant de systèmes de base de données, de journalisation et de stockage où la conservation et la suppression sont configurées.
Un exemple de journaux de suppression et de conclusions d'audit interne.

Si vous pouvez répondre à des questions simples comme « où puis-je vérifier que les journaux de conversation datant de plus de dix-huit mois sont supprimés ou anonymisés ? » sans vous démener, vous êtes déjà bien avancé dans la satisfaction de l'exigence A.8.10 et vous rendrez votre prochain audit beaucoup moins pénible.

ISMS.online vous donne une longueur d'avance de 81 % dès votre connexion

La norme ISO 27001 simplifiée

Nous avons fait le plus gros du travail pour vous, en vous offrant une avance de 81 % dès votre connexion. Il ne vous reste plus qu'à remplir les champs.

Commencer

Du « droit à l’oubli » aux calendriers de conservation : harmonisation de l’article 8.10 avec le RGPD et la protection de la vie privée à l’échelle mondiale

La suppression sécurisée n'est pas seulement une question de sécurité ; c'est aussi la manière dont vous prouvez aux joueurs et aux autorités de régulation que vous respectez le droit à la vie privée. Les lois sur la protection des données, telles que le Règlement général sur la protection des données (RGPD), vous imposent de minimiser les données que vous conservez, d'effacer celles qui ne sont plus nécessaires et de respecter les droits tels que la minimisation des données, la limitation de leur conservation et le droit à l'effacement. Ces principes sont en parfaite adéquation avec la norme A.8.10, qui vous fournit les outils pratiques et opérationnels nécessaires pour garantir leur application dans vos systèmes.

Il n’est pas nécessaire de devenir un avocat spécialisé dans la protection de la vie privée pour concevoir de bons contrôles de suppression, mais il est indispensable de comprendre comment les obligations légales se traduisent en règles de conservation et en comportements techniques au sein de vos systèmes.

Principes fondamentaux de confidentialité sur lesquels vous devez vous appuyer

Trois principes largement reconnus déterminent la durée de conservation des données des joueurs et les obligations qui en découlent. Ils figurent dans de nombreux cadres de protection de la vie privée et servent de référence aux autorités de réglementation lors de l'évaluation des pratiques.

Ces trois idées sont :

Minimisation des données : Collectez et traitez uniquement les données adéquates, pertinentes et nécessaires à vos besoins. Si vous n'avez pas réellement besoin de données télémétriques détaillées au niveau du joueur, privilégiez plutôt les rapports agrégés.
Limitation de stockage: – Conserver les données personnelles sous une forme identifiable uniquement pendant la durée nécessaire aux fins pour lesquelles elles ont été collectées. « Nous pourrions en avoir besoin un jour » ne constitue pas un motif légitime.
Droit d'effacement: – Dans de nombreuses circonstances, les joueurs peuvent vous demander d’effacer leurs données personnelles, notamment lorsqu’ils retirent leur consentement ou lorsque la finalité initiale n’est plus applicable.

Pour une entreprise de jeux vidéo, ces principes s'appliquent à :

Données du compte et du profil.
Enregistrements des paiements et des transactions.
Données de chat et sociales.
Télémétrie et analyse.
Journaux anti-triche et anti-fraude.
Tickets d'assistance et historique des litiges.

Chacune de ces catégories exige des décisions explicites : la durée de conservation des données identifiables, le passage à l’anonymisation ou à l’agrégation des données, et la manière de traiter les demandes de suppression valides. Les lois fiscales et comptables s’ajoutent souvent à ces principes de confidentialité et peuvent prévaloir sur une demande d’effacement formulée par un joueur pour certains enregistrements ; vous devez donc être en mesure d’expliquer clairement ces interactions.

Ces informations sont d'ordre général et ne constituent pas un avis juridique. Vous devriez toujours obtenir des conseils juridiques spécifiques à votre juridiction et à votre gamme de produits.

Transformer les principes et les droits en règles de rétention concrètes

Transformer les droits abstraits en matière de protection de la vie privée en règles claires est essentiel pour garantir la cohérence des pratiques des ingénieurs et des équipes d'exploitation. Pour chaque catégorie de données, ils doivent connaître la finalité du traitement, la durée de conservation et les conséquences à l'issue de cette période afin d'adopter les comportements appropriés.

Les équipes chargées de la protection des données et de la sécurité s'accordent souvent sur les principes, mais des frictions apparaissent lorsque les ingénieurs demandent des précisions. Ils ont besoin de chiffres et de comportements concrets, pas de phrases abstraites. Une approche pratique consiste à élaborer un calendrier de conservation et de suppression des données qui, pour chaque catégorie de données de joueurs, répertorie :

Objectif : – pourquoi vous le détenez, par exemple pour livrer le jeu, prévenir la fraude ou vous conformer à la législation fiscale.
Base juridique ou obligation : – consentement, contrat, intérêt légitime, obligation légale.
Durée de conservation standard : – combien de temps vous conservez les données identifiables dans des circonstances normales.
Des exceptions: – les situations où vous devez conserver des données plus longtemps, comme les litiges en cours ou les obligations de conservation légale.
État final : – que vous supprimiez, anonymisiez ou agrégiez les données à la fin de la période.
Méthode de suppression : – l’approche technique que vous utilisez, comme la suppression de lignes, la destruction de clés ou l’anonymisation.

Lorsqu'un joueur invoque son droit à l'effacement, vous pouvez alors raisonner de manière systématique :

Quelles catégories sont concernées par la demande ?
Existe-t-il des obligations légales qui vous imposent de conserver certains documents, par exemple en matière de fiscalité ou de lutte contre le blanchiment d'argent ?
Dans quels systèmes résident les données pertinentes ?
Quels contrôles techniques mettez-vous en œuvre pour supprimer ou anonymiser le document lorsque cela est autorisé ?

Votre documentation ISO 27001 et vos analyses d'impact sur la protection des données doivent pointer vers le même calendrier, afin que vous n'essayiez pas de maintenir des ensembles de règles parallèles qui dérivent inévitablement et deviennent plus difficiles à défendre.

Gestion des catégories délicates : fraude, mineurs et litiges

Certaines des questions les plus complexes concernent les données utilisées pour protéger l'entreprise et les autres acteurs, car ces catégories soulèvent des questions de confidentialité et d'équité, même si elles justifient une conservation plus longue. Une conservation prolongée peut s'avérer nécessaire pour lutter contre la fraude et la tricherie, ou pour se défendre en justice, tout en minimisant les données personnelles conservées au fil du temps.

Certaines des questions les plus difficiles concernent les données que vous utilisez pour protéger votre entreprise et les autres acteurs :

Journaux de fraude et de lutte contre la tricherie : – Vous pourriez avoir besoin d'une durée de rétention plus longue pour repérer les schémas et préserver l'intégrité du jeu.
Données relatives aux paiements et aux taxes : – Les lois financières vous obligent souvent à conserver certains documents pendant un nombre d'années déterminé.
Journaux des litiges et du support : – Vous pourriez avoir besoin de documents jusqu’à l’expiration des délais de prescription pour les actions en justice.
Données des mineurs et des joueurs auto-exclus : – Vous pourriez avoir des obligations supplémentaires pour protéger les groupes vulnérables ou limiter certains traitements.

Il est judicieux d'établir des règles claires et documentées pour ces cas plutôt que de laisser place à des décisions ponctuelles. Vous pouvez ainsi concevoir des contrôles qui tiennent compte à la fois de l'objectif de protection et du risque pour la vie privée.

Étape 1 – Documenter la tension

Décrivez par écrit pourquoi vous avez besoin d'une conservation prolongée dans des domaines spécifiques, en incluant des références aux exigences légales, réglementaires ou de la plateforme afin que le compromis soit transparent.

Étape 2 – Isoler les données à haut risque

Conservez les journaux et profils à haut risque dans des emplacements clairs et limités, avec des contrôles d'accès stricts et des règles de conservation distinctes, afin qu'ils ne se fondent pas dans les systèmes généraux.

Étape 3 – Réduire l’identifiabilité au fil du temps

Passez des identifiants complets aux pseudonymes, puis des pseudonymes aux données agrégées ou entièrement anonymisées dès que possible, tout en répondant à vos besoins de protection.

Étape 4 – Examiner régulièrement la rétention prolongée

Intégrez un examen périodique de ces cas particuliers dans la gouvernance afin que le maintien « temporaire » ne devienne pas permanent par négligence ou par commodité.

Des exemples concrets facilitent la mise en œuvre de ces idées. Les journaux de fraude pourraient être stockés dans une base de données dédiée où seuls les identifiants hachés seraient conservés après un certain délai, permettant ainsi de détecter les schémas tout en protégeant les utilisateurs. Les données de paiement pourraient être segmentées afin que seules les références et les montants minimaux requis pour le calcul des taxes soient conservés dans un système financier, distinct des profils de jeu. Les comptes des mineurs et des joueurs auto-exclus pourraient être signalés afin que certains enregistrements liés à la sécurité soient conservés pendant des périodes définies, tandis que les données de télémétrie marketing et de profilage seraient supprimées beaucoup plus tôt.

L’article A.8.10 ne vous dispense pas de vos obligations légales, et la législation sur la protection des données ne vous empêche pas de conserver les données dont vous avez réellement besoin pour votre défense juridique ou pour vous conformer à la réglementation. L’important est que toute conservation prolongée soit justifiée, documentée et techniquement mise en œuvre, et non pas simplement présumée, afin que les autorités de régulation et les parties prenantes puissent constater que vous agissez de manière équitable.

Cartographie du cycle de vie des données du joueur et des journaux vers la version A.8.10

Pour que la mise en œuvre de la norme A.8.10 soit efficace, il est essentiel d'envisager son cycle de vie. Les données des joueurs n'apparaissent pas et ne disparaissent pas instantanément ; elles passent de la collecte à l'utilisation active, puis sont stockées à différents niveaux avant d'être finalement supprimées ou anonymisées. La norme A.8.10 associe des contrôles à chaque étape de ce processus. La suppression sécurisée est grandement facilitée lorsque l'on sait, pour chaque étape, où se trouvent les données et quelle est la prochaine étape, et lorsque tous les acteurs des services de sécurité, de confidentialité, d'ingénierie et d'exploitation en direct partagent la même vision d'ensemble.

De nombreux studios possèdent des représentations mentales informelles de ce flux, mais rares sont ceux qui l'ont schématisé de manière à ce que différentes équipes puissent s'appuyer dessus lors de la conception de systèmes, de fonctionnalités et de processus opérationnels.

Visuel : diagramme de cycle de vie simple depuis la collection → utilisation active → archivage à chaud → archivage à froid → suppression/anonymisation.

Un cycle de vie typique dans les jeux modernes

La plupart des architectures de jeux modernes suivent un schéma similaire, même si les intitulés diffèrent : les joueurs génèrent des événements, ces événements sont traités pour offrir des expériences de jeu, puis les données les plus anciennes sont progressivement déplacées vers des espaces de stockage moins coûteux, moins onéreux ou plus restrictifs. Les décisions de suppression et d’anonymisation ne sont efficaces que si elles respectent ce flux réel, au lieu de faire comme si toutes les données étaient stockées dans une seule et unique base de données.

Bien que chaque titre soit différent, les grandes étapes sont familières :

Collecte et ingestion : – Les joueurs s'inscrivent, s'authentifient, jouent des matchs, discutent, dépensent de l'argent, et vous intégrez ces événements dans vos systèmes backend, journaux et analyses.
Utilisation active : – Les données sont utilisées pour fournir le jeu, gérer les opérations en direct, optimiser le matchmaking, gérer les stocks et assurer le support client.
Archives chaudes : – les données plus anciennes sont déplacées vers un stockage moins coûteux ou des tables de priorité inférieure, mais restent identifiables pendant un certain temps, par exemple pour la récupération de comptes ou des enquêtes de longue durée.
Archives froides : – les données ne sont conservées que pour répondre à des obligations telles que les obligations fiscales, réglementaires ou les enquêtes pour fraude grave, souvent dans des systèmes plus restreints.
Suppression ou anonymisation : – les données sont supprimées ou transformées de manière à ne plus se rapporter à un joueur identifiable.

Ce cycle de vie s'applique non seulement aux tables de comptes, mais aussi aux journaux d'observabilité et de sécurité, à la télémétrie et aux lacs de données, aux systèmes anti-fraude et d'évaluation des risques, aux outils de support et de modération, ainsi qu'aux intégrations et exportations tierces. Plus vous pouvez clairement identifier les systèmes et les ensembles de données à chaque étape, plus il est facile d'attribuer les contrôles A.8.10 et de les expliquer à un auditeur ou à une partie prenante sceptique.

Fixation des commandes A.8.10 à chaque phase

L'application du point A.8.10 au cycle de vie implique de définir les conditions requises à chaque franchissement d'une limite par les données, car c'est à ces limites que le risque évolue. Lors de la collecte de nouvelles données, de leur transfert vers un nouvel emplacement de stockage ou de la décision de les rendre inutiles, chaque transition est l'occasion d'appliquer la suppression, la minimisation ou l'anonymisation.

Une façon utile d'envisager cela est de considérer A.8.10 comme une liste de contrôle qui se déclenche à chaque limite d'étape.

Lorsque les données se déplacent depuis collection à utilisation active:

Vérifiez ce que vous collectez

Vérifiez que les champs sont limités à ce qui est nécessaire au jeu, aux opérations et aux obligations, et non pas à tout ce que vous pouvez capturer par simple curiosité.

Séparer les identifiants du contenu

Structurer les schémas de manière à ce que les identifiants des joueurs puissent être supprimés ou intervertis sans détruire tout le contenu analytique utile ni les indicateurs de performance de l'entreprise.

Lorsque les données se déplacent depuis utilisation active pour réchauffer les archives:

Confirmer le déclencheur de rétention

Définissez clairement une heure ou un événement après lequel les données sont déplacées hors des stockages actifs, et documentez la manière dont ce déclencheur est mis en œuvre dans les pipelines ou services concernés.

Réduire l'accès et ajuster les commandes

Limitez l'accès aux données archivées et configurez les limites de conservation en fonction de votre calendrier afin que les enregistrements les plus anciens ne s'accumulent pas silencieusement.

Lorsque les données se déplacent depuis archivage chaud à froid:

Justifiez ce qui reste

Veillez à ce que seules les données réellement nécessaires à des fins légales, réglementaires ou de sécurité soient conservées hors ligne et que cette justification soit documentée.

Mettre en place des mesures de protection plus strictes

Appliquez des contrôles d'accès plus stricts, une surveillance et, le cas échéant, un chiffrement pour les archives froides afin que les données les moins utilisées ne deviennent pas une cible facile.

Lorsque les données se déplacent depuis archivage à froid jusqu'à suppression ou anonymisation:

Automatiser l'état final

Définissez une tâche ou un processus automatisé qui supprime ou anonymise les données lorsque la période de conservation expire, plutôt que de vous fier à des nettoyages ponctuels.

Consigner les preuves et les défaillances

Consignez les exécutions réussies et les exceptions afin de pouvoir prouver que le contrôle fonctionne, enquêter sur les échecs et affiner votre approche au fil du temps.

À chaque étape, vous devriez pouvoir répondre à la question suivante : « Si nous disons que les données passent à cette étape après X, comment savons-nous que c’est réellement le cas, et que se passe-t-il ensuite ? » Ces réponses constituent la base de vos contrôles A.8.10 et vous aident à démontrer aux organismes de réglementation et à vos partenaires que vous prenez au sérieux l’intégralité du cycle de vie.

Y compris les sauvegardes, les données de test et les zones d'ombre

Les sauvegardes, les environnements de test et les exportations sont souvent négligés au quotidien dans la gestion du cycle de vie des jeux. Pourtant, ils contiennent d'importants volumes de données de joueurs susceptibles de compromettre votre stratégie de suppression. Il n'est pas nécessaire de détailler ici l'intégralité de votre architecture de sauvegarde, mais il est essentiel d'intégrer ces éléments et de vous appuyer sur vos normes techniques pour définir précisément le processus de suppression.

Il est facile de se concentrer sur les systèmes principaux et d'oublier où se trouvent les données. Les sauvegardes et les répliques méritent une attention particulière. Si vous utilisez des sauvegardes à longue durée de vie, il se peut que vous ne puissiez pas supprimer chirurgicalement les données de chaque joueur. Dans ce cas, vous devriez :

Chiffrez vos sauvegardes avec des clés robustes et bien gérées.
Définissez des périodes de conservation et assurez-vous que les ensembles expirés soient supprimés.
Assurez-vous que les anciennes sauvegardes sont expirées ou rendues irrécupérables, par exemple par destruction de la clé ou effacement sécurisé du support.

Les environnements de test et de préproduction peuvent contenir d'importants volumes de données de production. Si vous les alimentez avec des enregistrements réels, ces derniers doivent être inclus dans votre cycle de vie et vos règles de suppression, ou bien vous devez anonymiser les données avant utilisation afin que les développeurs travaillent avec des informations réalistes mais non identifiables.

Les exportations et les rapports (fichiers CSV, extraits de données et captures d'écran utilisés pour l'analyse ou la production de rapports) doivent être encadrés, voire évités. Lorsque des exportations sont nécessaires, stockez-les dans des emplacements sécurisés avec des règles de conservation claires et privilégiez, dans la mesure du possible, les rapports centralisés ou les tableaux de bord.

Un simple tableau peut s'avérer utile, avec des colonnes telles que « Magasin ou système », « Étape du cycle de vie » et « Comportement de conservation et de suppression », et quelques lignes maximum par intitulé. Une fois cette cartographie établie, les outils et les plateformes peuvent y être alignés. Une solution ISMS intégrée comme ISMS.online centralise le cycle de vie, les politiques qui y font référence et les preuves de son application, permettant ainsi une gestion aussi rigoureuse des systèmes non documentés que des systèmes principaux.

Intégrez, développez et faites évoluer votre conformité, sans complications. IO vous offre la résilience et la confiance nécessaires pour croître en toute sécurité.

Réservez votre démo

Modèles techniques pour la suppression sécurisée des données dans les bases de données, les journaux, les sauvegardes et la télémétrie

La suppression sécurisée n'est efficace que si l'architecture sous-jacente la rend pratique et sûre à mettre en œuvre par vos équipes. Il vous faut un petit ensemble de modèles standard que les ingénieurs comprennent, qui sont peu coûteux à exploiter et que les auditeurs peuvent suivre, afin de ne pas avoir à réinventer la suppression pour chaque jeu et service.

Même les meilleures politiques sont vaines si votre architecture rend la suppression difficile, voire dangereuse. Heureusement, il existe des modèles reproductibles applicables à de nombreuses technologies. L'objectif n'est pas la perfection dès le départ, mais un ensemble restreint de pratiques standardisées, compréhensibles par les ingénieurs, évolutives avec votre infrastructure et faciles à suivre pour les auditeurs.

Un objectif de conception essentiel est de rendre la suppression plus sûre et moins coûteuse que d'ignorer le problème. Cela implique généralement de planifier la suppression au niveau du schéma et du pipeline plutôt que de tenter de l'ajouter a posteriori.

Suppression sécurisée dans les bases de données et services de production

La suppression sécurisée dans les bases de données en production consiste à supprimer ou à anonymiser les données des joueurs sans perturber le fonctionnement du jeu, tout en vous assurant qu'aucun enregistrement ne subsiste dans des tables oubliées. Plusieurs modèles principaux s'offrent à vous ; il est recommandé de choisir celui qui correspond à votre tolérance au risque et à votre niveau de maturité opérationnelle.

Pour les bases de données contenant les comptes de joueurs, les profils, les inventaires et autres données essentielles, plusieurs options s'offrent à vous :

Suppression physique de la ligne : – opérations de suppression simples avec cascade appropriée, suivies de tâches de maintenance telles que le vide ou le compactage pour récupérer l'espace de stockage le cas échéant.
Suppression logicielle plus suppression physique périodique : – marquer les enregistrements comme supprimés pendant une courte période afin de faciliter la restauration du compte ou d’assurer la sécurité opérationnelle, puis les supprimer définitivement après un intervalle défini.
Partitionnement par période ou par locataire : – structurer les tables ou les collections de manière à pouvoir supprimer ou archiver en masse de grands volumes de données anciennes.

Quel que soit le modèle choisi, vous devez :

Séparez autant que possible les identifiants du contenu moins sensible, afin que la suppression d'une petite table de jointure puisse efficacement dépersonnaliser de grands volumes de données de jeu.
Veillez à ce que la logique applicative ne « ressuscite » pas les données supprimées des caches, des index de recherche ou des magasins dérivés.
Mettez en œuvre des routines de suppression idempotentes afin que la tentative de reprise d'une tâche ayant échoué ne compromette pas l'intégrité ni ne laisse d'état partiel.
Testez minutieusement le comportement de suppression en cascade et d'intégrité référentielle dans des environnements hors production afin que les administrateurs de bases de données prudents puissent en constater l'impact avant de toucher aux données en production.

Documentez ces modèles dans vos normes techniques pour A.8.10 et reliez-les aux règles de conservation de votre calendrier. Ainsi, lors du lancement d'un nouveau jeu ou d'une nouvelle fonctionnalité, les ingénieurs sauront quel modèle appliquer et comment en prouver l'efficacité.

Conception de journaux et de systèmes de télémétrie sensibles à la rétention

Les journaux d'activité et la télémétrie sont essentiels au fonctionnement et à l'amélioration des jeux, mais ils constituent également une source importante de données personnelles et une cause fréquente de sur-conservation qui accroît insidieusement les risques. L'objectif n'est pas d'arrêter la journalisation ni de désactiver les systèmes, mais de ne collecter que les données nécessaires, de les conserver aussi longtemps que cela est utile, puis de les supprimer ou de supprimer les liens directs avec les personnes, en intégrant les mécanismes de conservation et de suppression dès la conception.

Les principes utiles comprennent :

Classer les journaux par finalité : – La sécurité, la fraude, l’analyse du gameplay et les diagnostics de plantage peuvent chacun justifier des périodes de conservation différentes.
Évitez de consigner plus de données que nécessaire : – N’incluez pas les identifiants complets ni les charges utiles si des hachages, des jetons ou des métriques agrégées suffisent.
Utilisez les commandes de rétention intégrées : – La plupart des plateformes de journalisation et de télémétrie vous permettent de définir une durée de conservation et une suppression automatique ; configurez-les en fonction de votre planning.
Envisagez l'anonymisation : – Pour les données plus anciennes utilisées uniquement dans des analyses agrégées, remplacez les identifiants par des jetons ou supprimez-les complètement après une certaine période.

Concrètement, cela pourrait se traduire par la conservation de journaux de sécurité détaillés pendant une période définie, puis par la conservation de données agrégées plus générales pour l'analyse des tendances, ou encore par la conservation d'événements de jeu précis au niveau du joueur pendant une courte période afin d'optimiser les fonctionnalités, puis leur regroupement en cohortes anonymisées. L'essentiel est que ces comportements soient configurés de manière centralisée et puissent être justifiés, et non laissés à la discrétion de chaque équipe.

Sauvegardes, archives et effacement cryptographique

Les sauvegardes et les archives sont conçues pour préserver les données. La suppression sécurisée consiste donc ici à gérer des ensembles de sauvegarde complets plutôt qu'à effacer des fichiers individuels, tout en fournissant une explication crédible quant au processus de suppression à l'expiration de la période de conservation. On s'appuie sur le chiffrement, une durée de conservation limitée et la destruction contrôlée des clés ou des supports pour démontrer que les données expirées ne sont plus accessibles.

Les sauvegardes présentent un défi particulier car elles sont conçues spécifiquement pour préserver les données, souvent sous forme de blocs volumineux et opaques. Il est rare de pouvoir supprimer les données d'un seul joueur à partir de dix ans de sauvegardes complètes. La suppression se fait donc au niveau des ensembles de sauvegarde.

Les étapes pratiques comprennent :

Chiffrez les sauvegardes et les archives : avec des clés fortes gérées séparément des données.
Définir les périodes de conservation des sauvegardes : qui correspondent à votre tolérance au risque et à vos obligations légales, et évitez de conserver des sauvegardes indéfiniment.
S'assurer que les anciennes sauvegardes deviennent irrécupérables : en détruisant les clés ou supports concernés de manière contrôlée et documentée lorsque la période de conservation expire.
Évitez d'utiliser les sauvegardes comme archives : en conservant des archives à long terme dans des espaces de stockage spécialement conçus à cet effet et à accès contrôlé, avec des règles de conservation claires plutôt que des sauvegardes de récupération générales.

L’effacement cryptographique – qui consiste à rendre les données illisibles en supprimant ou en révoquant les clés – est souvent la seule solution pratique pour satisfaire à l’exigence A.8.10 pour les sauvegardes à grande échelle et les systèmes de stockage d’objets distribués. Il repose sur une gestion rigoureuse des clés ; si ces dernières sont réutilisées pour de nombreux ensembles de données ou mal protégées, les garanties sont moindres. Déployée avec soin, l’effacement cryptographique permet toutefois d’allier résilience opérationnelle et forte assurance que les données expirées sont définitivement supprimées, protégeant ainsi les joueurs et votre studio en cas d’incident.

Gouvernance, rôles et exceptions : comment faire fonctionner la suppression dans un secteur d’activité de jeux en direct

La suppression sécurisée n'est efficace que si chacun sait qui décide de quoi, qui effectue le travail et comment les exceptions sont gérées. Sans cela, les anciennes données des joueurs s'accumulent discrètement, les discussions difficiles étant sans cesse repoussées. Une gouvernance claire transforme la version A.8.10, d'un projet secondaire, en une composante essentielle du fonctionnement de vos jeux et services.

La suppression n'est pas une tâche qui incombe à une seule équipe. La sécurité, l'ingénierie, la confidentialité et les opérations en direct ne peuvent y parvenir seules. Pour que la version A.8.10 fonctionne sans heurts constants, une gouvernance claire est indispensable : qui prend quelles décisions, qui les met en œuvre, qui vérifie leur bon fonctionnement et comment les exceptions sont gérées.

Sans cette clarté, la suppression se transforme en une série de conversations délicates et de tickets bloqués, ce qui, en retour, incite à éviter complètement le sujet. Pour les équipes qui débutent leur démarche ISO 27001, formaliser ces responsabilités dès le départ évite qu'une ou deux personnes ne s'accaparent discrètement tout le travail.

Définir qui possède quoi

Définir clairement les responsabilités en matière de décisions de conservation et de suppression évite toute confusion et tout rejet de responsabilité, car chacun peut identifier les personnes responsables. Une matrice RACI simple, indiquant les personnes responsables, redevables, consultées et informées, permet de déterminer clairement qui doit valider les règles et qui doit assurer le bon fonctionnement des contrôles techniques.

Une simple matrice RACI (Responsable, Autorité, Consulté, Informé) pour la suppression peut éviter bien des confusions. Voici quelques exemples typiques :

La sécurité ou la fonction de RSSI : – responsable de veiller à ce que le point A.8.10 soit mis en œuvre dans le cadre du SMSI ; consulté sur les impacts des risques.
Confidentialité ou DPO : – chargé de veiller à ce que la conservation et la suppression des données soient conformes aux lois et aux droits des joueurs.
Ingénierie des données et des plateformes : – responsable de la mise en œuvre et de l’exploitation des procédures techniques de suppression ou d’anonymisation.
LiveOps et produit : – consulté sur l'impact de la conservation et de la suppression des données sur les opérations et l'analyse des jeux.
Équipes de soutien aux joueurs et à la communauté : – chargé de gérer les communications avec les joueurs et d’acheminer les cas complexes.

Une fois ces rôles définis, vous pouvez les intégrer aux sections relatives à la responsabilité des politiques, aux processus de gestion du changement et à l'intégration des nouveaux systèmes et fournisseurs. Ainsi, lorsqu'on vous demande « qui décide de la durée de conservation des historiques de conversation ? », il y aura une réponse autre que « cela dépend de votre interlocuteur », et les décisions de suppression pourront être prises au même rythme que le développement du jeu.

Concevoir des exceptions sans perdre le contrôle

Presque tous les studios doivent prévoir des dérogations à leurs règles de conservation standard pour des raisons de fraude, de sécurité ou légales. Le risque est que ces dérogations deviennent permanentes par habitude. Une procédure de dérogation souple mais rigoureuse permet de conserver des données importantes lorsque cela s'avère nécessaire, par exemple lors d'enquêtes pour fraude ou de contrôles réglementaires, sans pour autant compromettre votre stratégie de suppression globale.

Presque tous les studios ont besoin de dérogations à leurs règles de conservation standard. Fraude, tricherie, incidents graves de sécurité et enquêtes réglementaires peuvent exiger une conservation des données plus longue que d'habitude. Le risque est que ces dérogations s'accumulent de manière informelle et ne soient jamais réexaminées.

Une approche robuste consiste à :

Exiger une justification documentée pour toute conservation prolongée, y compris les références juridiques ou réglementaires le cas échéant.
Définir une date ou une condition de révision pour chaque exception, par exemple « jusqu’à la clôture de l’enquête X plus deux ans ».
Limiter l'accès au stockage à conservation étendue au groupe le plus restreint qui en a réellement besoin.
Examiner les exceptions ouvertes lors d'un forum de gouvernance régulier et les clôturer lorsqu'elles ne sont plus nécessaires.

Un bon enregistrement d'exception pourrait ressembler à ceci : « Cas de fraude F‑123 – conserver les journaux de transactions, d'appareils et de réseau associés jusqu'au 31 décembre 2028 ; responsable : Responsable de la lutte contre la fraude ; examen trimestriel par le comité des risques. » Ce niveau de précision permet de maintenir l'alignement de tous et offre une piste d'audit claire, ce qui facilite les audits ISO 27001 et les contrôles réglementaires.

Former les équipes de première ligne et harmoniser les opérations en direct

Les équipes de première ligne traduisent vos politiques de suppression de compte en engagements concrets pour les joueurs. Par conséquent, si les équipes de support et de communauté décrivent la « suppression de compte » différemment du fonctionnement de vos systèmes, cela crée des problèmes de confiance et de conformité. Aligner la formation, les scripts et la planification des opérations en direct avec vos contrôles A.8.10 permet d'éviter ces écarts.

Les joueurs, les parents et même les partenaires sont souvent les premiers à s'adresser aux équipes de première ligne : assistance, gestionnaires de communauté, LiveOps. Si ces équipes ne peuvent pas expliquer clairement ce que signifie la « suppression de compte », ou pire, font des promesses qui ne sont pas techniquement vraies, cela crée des problèmes de confiance et de conformité.

Vous devriez donc :

Fournissez des explications simples et une FAQ interne qui décrivent, en langage clair, ce qui est supprimé, ce qui peut être conservé pour des raisons légales et pendant quelles périodes.
Former le personnel à reconnaître les situations où une demande peut déclencher des blocages légaux ou des exceptions complexes, et à savoir comment procéder à une remontée d'information appropriée.
Alignez la planification LiveOps avec les changements à venir en matière de conservation ou de suppression, afin que les stratégies de télémétrie ou de segmentation soient ajustées en temps voulu.

Lorsque chacun comprend que la suppression sécurisée vise à protéger les joueurs et le studio, et non à bloquer les bonnes idées, on constate moins de conflits de dernière minute entre le développement et la conformité, et l'on obtient des conceptions plus réfléchies qui prennent en compte les deux. Cela permet, à son tour, de réduire les coûts liés aux incidents, de limiter les risques réglementaires et de bâtir une confiance durable des joueurs.

ISMS.online prend en charge plus de 100 normes et réglementations, vous offrant une plate-forme unique pour tous vos besoins de conformité.

Réservez votre démo

Cloud, fournisseurs et responsabilité partagée en matière de suppression

Les jeux modernes s'appuient fortement sur les fournisseurs de services cloud et SaaS, mais vous restez responsable du stockage et de la suppression des données des joueurs au sein de votre infrastructure. L'exigence A.8.10 doit donc s'étendre au-delà de vos propres systèmes et englober les contrats, les configurations et les évaluations des risques liés aux fournisseurs, afin que les données ne soient pas conservées plus longtemps que nécessaire simplement parce qu'elles sont hébergées sur la plateforme d'un tiers.

Dans un jeu moderne, très peu d'éléments résident exclusivement dans votre centre de données. L'identité, les paiements, l'analyse, le marketing, la communauté, le support et même les systèmes backend principaux peuvent tous dépendre de fournisseurs de cloud et de SaaS. La norme ISO 27001 A.8.10 reste applicable ; cela signifie simplement que votre processus de suppression doit également s'étendre à ces fournisseurs.

Il est impossible de se fier aveuglément au prestataire. Il est impératif de comprendre, de documenter et, le cas échéant, de définir contractuellement qui supprime quoi, où et quand. Ceci est d'autant plus important que les prestataires mettent en avant leurs certifications ; l'adhésion à un référentiel ne garantit ni que leurs calendriers de conservation correspondent aux vôtres, ni qu'ils respectent vos délais d'effacement.

Comprendre le modèle de responsabilité partagée

Comprendre le modèle de responsabilité partagée vous permet d'identifier les leviers de suppression que vous contrôlez et ceux qui relèvent du fournisseur, afin de concevoir des contrôles réalistes plutôt que de vous baser sur des suppositions. Vous décidez quelles données de joueurs sont transmises à un service, combien de temps elles y restent et quand vous demandez leur suppression, tandis que le fournisseur est responsable de la manière dont sa propre infrastructure est effacée ou recyclée.

Les fournisseurs de services cloud parlent souvent de responsabilité partagée : ils sécurisent l’infrastructure, vous sécurisez son utilisation. En matière de suppression, cela se traduit généralement comme suit :

Infrastructure en tant que service : – vous contrôlez les systèmes d’exploitation, les bases de données et les données d’application ; le fournisseur contrôle les supports physiques et le nettoyage de bas niveau.
Plateforme en tant que service : – vous contrôlez vos données et vos configurations au sein des services gérés ; le fournisseur s’occupe des sauvegardes et des systèmes sous-jacents.
Logiciel en tant que service : – vous contrôlez généralement la configuration et les modes d'utilisation ; le fournisseur contrôle presque tout le reste.

Pour chaque service important, vous devriez être en mesure de répondre à la question suivante :

Quelles données concernant vos joueurs sont stockées ici ?
Qui peut configurer la conservation et la suppression des données ?
Que deviennent les données lorsque vous supprimez un compte ou un enregistrement ?
Comment le fournisseur gère-t-il les sauvegardes et la restitution ou la destruction des données en fin de contrat ?

La documentation de ces réponses fait partie à la fois du point A.8.10 et d'autres contrôles de la norme ISO 27001 relatifs à l'utilisation du cloud, et elle vous donne une base plus claire pour la sélection et la négociation avec les fournisseurs.

Rendre la suppression contractuelle

La suppression des données est bien plus fiable lorsqu'elle est formalisée par contrat plutôt que gérée de manière informelle, car vous disposez ainsi d'une base claire pour faire valoir vos attentes. Vos accords de traitement des données et vos politiques de sécurité doivent préciser les durées de conservation, les modalités de traitement des demandes d'effacement et le traitement des données à la fin de la relation contractuelle.

Les politiques et les bonnes intentions ne suffisent pas lorsque d'autres organisations détiennent vos données. Vos contrats, accords de traitement des données et plans de sécurité doivent aborder les points suivants :

Durées maximales de conservation des données après leur sortie de vos systèmes.
Obligation de répondre aux demandes d'effacement des données des joueurs dans les délais convenus.
Comment les sauvegardes, les journaux et les archives sont traités à la fin de la période de conservation ou à la résiliation du contrat.
Quelles preuves le fournisseur vous fournira-t-il, telles que des journaux de suppression ou des certificats, et dans quelles circonstances ?

Vous devez également vous assurer que vos évaluations des risques liés aux fournisseurs couvrent explicitement la suppression des données. Si un fournisseur est incapable de décrire son propre cycle de vie des données et ses pratiques de suppression, ou s'il se contente de certifications génériques sans précisions sur la conservation, cela constitue un signal important incitant à la prudence ou à la négociation de conditions plus strictes. Le secteur privilégie de plus en plus des engagements clairs et écrits en matière de suppression des données dans les contrats.

Garder les exportations de tiers sous contrôle

Les exportations tierces créent souvent des copies non gérées des données des joueurs, échappant ainsi aux contrôles habituels et pouvant compromettre même une stratégie de suppression bien conçue. Les tableaux de bord, les exportations CSV et les ensembles de données synchronisés sont pratiques, mais sans règles de conservation explicites, ils peuvent persister inaperçus pendant des années.

Même lorsque les services essentiels fonctionnent correctement, des données peuvent fuiter vers des zones non gérées via :

Exportation manuelle des tableaux de bord vers des feuilles de calcul.
Synchronisation des données avec les outils de veille stratégique.
Pièces jointes et fichiers dans les systèmes de billetterie ou de collaboration.

Ces copies sont faciles à oublier et difficiles à supprimer de manière ciblée. Pour réduire les risques :

Réduisez autant que possible les exportations ponctuelles et privilégiez les outils d'analyse intégrés.
Lorsque des exportations sont nécessaires, stockez-les dans des lieux réglementés avec des limites de conservation.
Intégrez ces modèles dans votre cartographie du cycle de vie et dans la formation de votre personnel afin qu'ils ne soient pas négligés.

Dans de nombreux studios, le simple fait de sensibiliser les équipes au risque et de leur proposer une meilleure alternative – comme des rapports ou des tableaux de bord centralisés – permet de réduire considérablement le problème. Cela diminue d'autant plus le risque qu'une enquête ou une violation de données révèle l'existence de données dont personne ne soupçonnait l'existence.

Réservez une démo avec ISMS.online dès aujourd'hui

ISMS.online vous aide à transformer la norme ISO 27001 A.8.10, actuellement vague, en un ensemble de contrôles clairs et auditables, réduisant ainsi les risques liés aux données de joueurs non supprimées et aux journaux sensibles à conserver pour l'ensemble de vos jeux et services. En centralisant vos politiques, inventaires de données, calendriers de conservation, normes techniques et preuves, la plateforme vous offre une vision unique et fiable de la gouvernance de l'information au sein de vos studios et fournisseurs.

Visualisez votre étage A.8.10 en un seul endroit

Lorsque vous gérez votre travail relatif à la norme ISO 27001 dans un environnement dédié tel que ISMS.online, vous bénéficiez de plusieurs avantages :

Vos matrices de conservation et de suppression côtoient les évaluations des risques et les déclarations d'applicabilité, ce qui vous permet de montrer exactement comment les points A.8.10 et A.5.32 fonctionnent ensemble pour atténuer les risques identifiés.
Les diagrammes de cycle de vie, les inventaires système et les enregistrements des fournisseurs deviennent des artefacts vivants, mis à jour au fur et à mesure que vos jeux et votre infrastructure évoluent, au lieu d'être figés dans des présentations PowerPoint oubliées.
Les preuves de suppression – qu’il s’agisse d’exportations de configuration ou de notes d’audit interne – peuvent être directement liées aux contrôles qu’elles prennent en charge, ce qui permet de réduire le temps consacré aux audits à la dernière minute.

Pour les équipes de sécurité, de confidentialité, de données, d'ingénierie et d'exploitation en direct, cette vision partagée transforme la suppression, d'une idée vague, en un programme de travail concret et traçable. Elle offre également aux studios moins expérimentés un cadre à suivre lors de la mise en place de leurs premiers contrôles. Une plateforme de gestion de la sécurité de l'information (SGSI) centralise vos cartographies de cycle de vie, vos calendriers de conservation et vos enregistrements fournisseurs, vous évitant ainsi de reconstituer l'histoire de la sécurité à partir de documents épars et de souvenirs isolés.

Prochaines étapes pour votre studio

Si vous vous reconnaissez dans les défis décrits ci-dessus, une brève conversation ciblée peut suffire à entrevoir des solutions plus efficaces. Vous pourriez par exemple :

Analysez le cycle de vie des données des joueurs d'un jeu et identifiez les lacunes des contrôles actuels de suppression et de conservation.
Examinez comment votre documentation ISO 27001 existante pourrait être réutilisée et renforcée pour couvrir plus en détail le point A.8.10.
Découvrez comment les flux de travail, l'attribution des tâches et les tableaux de bord peuvent permettre aux différentes équipes de s'aligner sur qui doit faire quoi et quand, afin de garantir le bon déroulement des suppressions.

Réservez une démonstration avec ISMS.online et découvrez comment tous les éléments de l'Annexe A.8.10 – des délais légaux de conservation et de la cartographie du cycle de vie aux modèles de suppression technique et aux preuves d'audit – peuvent être intégrés dans un système unique et facile à gérer. Vous pourrez ainsi respecter les données des joueurs, réduire l'impact des incidents, satisfaire aux exigences des auditeurs et des organismes de réglementation, et continuer à proposer d'excellents jeux en toute sérénité.

Demander demo

Foire aux questions

Comment un studio de jeux vidéo devrait-il repenser la suppression des données des joueurs selon la norme ISO 27001 A.8.10 ?

Vous devez traiter la suppression des données des joueurs comme une étape conçue et démontrée du cycle de vie, et non une faveur ponctuelle que vous rendez via des tickets d'assistance.

Comment la norme A.8.10 modifie-t-elle les conceptions courantes de la « suppression » ?

Conformément à la norme ISO 27001 A.8.10, la suppression des comptes à la demande des joueurs constitue le strict minimum, et non le modèle opérationnel. Cette clause exige de vous que :

Traitez chaque catégorie de données de joueur (comptes, paiements, chat, télémétrie, anti-triche, assistance) comme une actifs gérés avec un objectif, un propriétaire et un état final défini.
Décidez à l'avance du moment où chaque catégorie passe de manière intense (nécessaire pour exécuter ou protéger le jeu) à rétention justifiée (fiscalité, litiges, fraude, sécurité) et enfin à suppression ou anonymisation.
Transformez ces décisions en modèles techniques répétables: fenêtres de suppression logicielle fixes, suppressions permanentes planifiées, tâches d'anonymisation et règles de cycle de vie dans les plateformes de stockage et de journalisation.
Capture preuves que ces schémas se produisent: journaux de travaux, enregistrements de modifications, exportations de configuration et exemples de contrôles que votre SMSI peut conserver en parallèle du contrôle A.8.10.

Le véritable changement s'opère du passage de l'improvisation à prévisibilitéUn studio qui sait précisément où se trouvent encore des joueurs identifiables, où ne subsistent que des groupes anonymisés et ce qui a complètement disparu a un rayon d'action plus restreint en cas de problème et une version des faits plus claire à présenter aux auditeurs ou aux plateformes.

Comment un système de gestion de l'information (SGSI) rend-il cet état d'esprit concret ?

Un système de gestion de la sécurité de l'information vous offre un point d'accès unique pour la liaison politique, risque et mise en œuvre:

Vous conservez les inventaires des catégories de données, les règles de conservation et les normes de suppression dans un seul espace de travail.
Chaque contrôle A.8.10 est lié à des risques, des systèmes et des procédures opérationnelles spécifiques plutôt que de rester sous forme de formulation abstraite.
Les audits internes, les approbations de changement et les revues d'incidents peuvent tous faire référence aux mêmes éléments, la suppression devient donc comment vous créez et exploitez des jeux, et non un simple nettoyage ponctuel avant la certification.

Lorsque vous pouvez guider un auditeur sereinement, du registre des risques aux règles de conservation, en passant par les modèles techniques et les preuves, votre studio démontre qu'il comprend l'importance de la confiance à long terme avec les utilisateurs, et pas seulement la livraison de fonctionnalités à court terme. Un système de gestion de la sécurité de l'information (SGSI) comme ISMS.online facilite grandement cette présentation en assurant une cohérence et une mise à jour constantes des contrôles, des enregistrements et des responsabilités.

Comment concevoir des calendriers de conservation des données des joueurs qui protègent contre la fraude, la sécurité et la valeur analytique ?

Vous concevez la fidélisation autour Pourquoi détenez-vous chaque catégorie et quelle loi ou quel contrat vous y autorise ?, et non pas en fonction de la base de données ou du tableau de bord que vous jugez le plus important.

Comment construire une matrice de fidélisation qui fonctionne pour l'ensemble du parc de jeux ?

La plupart des studios bénéficient d'un seul matrice de rétention qui couvre l'ensemble des types de données des joueurs :

Compte et identité (identifiants, coordonnées, indicateurs d'âge)
Paiements et enregistrements de facturation
Discussions et interactions sociales
Journaux de sécurité et d'infrastructure
Indicateurs anti-triche et anti-fraude
Télémétrie de jeu et analyse de l'expérience utilisateur
Billets d'assistance et communautaires

Pour chaque rangée, vous épinglez quatre éléments :

Objectif : – pourquoi vous collectez ces données (gestion du jeu, facturation des joueurs, maintien de la sécurité, lutte contre la fraude, amélioration du design).
Base juridique/contractuelle : – droit de la consommation, règles fiscales, PCI DSS, conditions d'utilisation des plateformes, droit de la protection des données, etc.
Rétention minimale : – ce que vous devez conserver pour rester en conformité (par exemple, les documents fiscaux ou les délais de remboursement).
Durée de conservation maximale des données identifiables : – le moment où vous supprimez ou anonymisez les individus, même si vous conservez les tendances agrégées.

En matière de fraude et de sécurité, les équipes ont souvent tendance à adopter une approche empirique du « tout conserver, indéfiniment ». La norme A.8.10 n'interdit pas d'allonger les périodes de conservation lorsque le risque le justifie réellement, mais elle exige de vous que :

Donnez ces catégories durées explicites et raisonnées (par exemple, période de litige plus une marge de sécurité définie).
Séparer les enregistrements bruts et identifiables des signaux dérivés (scores de risque, identifiants hachés, cohortes anonymisées), vous pouvez donc conserver les signaux plus longtemps que l'identité.
Considérez les enquêtes inhabituelles comme exceptions limitées dans le temps, chacune avec un propriétaire et une date de révision, au lieu de délimitations permanentes non précisées.

Du point de vue analytique, la plupart des décisions de conception reposent sur des schémas plutôt que des joueurs spécifiquesCela vous permet de réduire la durée de conservation des données télémétriques complètes et de déplacer les données plus anciennes vers vues agrégées ou anonymisées Les équipes produit et données peuvent toujours interroger ces données. Cela vous oblige également à intégrer les exportations (extraits BI, fichiers CSV, jeux de données de test) dans le même cycle de vie au lieu de les laisser comme des copies invisibles à long terme.

Où ces règles devraient-elles être inscrites pour qu'elles restent pertinentes ?

Les règles de conservation se dégradent rapidement si elles sont dissimulées dans des fils de discussion par courriel ou des feuilles de calcul isolées. En les gérant dans un système de gestion de la sécurité de l'information (SGSI) :

La confidentialité, la sécurité, l'analyse et l'ingénierie peuvent toutes donner leur accord pour un matrice unique et partagée.
Les évaluations peuvent être intégrées à votre registre des risques et à votre cycle de gestion et d'évaluation.
Des éléments de preuve tels que des captures d'écran de la configuration, des accusés de réception de politiques et des résultats de contrôles ponctuels sont placés à côté des règles, ce qui vous permet de les présenter aux auditeurs. la décision et sa mise en œuvre pratique.

Si vous souhaitez transformer le point A.8.10 d'une source d'inquiétude en un outil de conception, centraliser cette matrice sur une plateforme comme ISMS.online fait toute la différence. Vous obtenez ainsi une vision unifiée de la conservation des données, conforme à la norme ISO 27001, aux obligations de confidentialité et à la réalité de vos opérations.

En quoi consiste concrètement la suppression sécurisée des bases de données, des journaux, des données de télémétrie et des sauvegardes de jeux ?

La suppression sécurisée signifie que, une fois que les données atteignent leur fin de vie définie, elles sont Il n'est plus possible de le récupérer en pratique avec un effort raisonnable., à travers les systèmes en production, les piles analytiques et les sauvegardes.

Comment devons-nous gérer les services et bases de données en production ?

Pour les services essentiels qui gèrent les comptes, les droits d'accès, les inventaires et autres données similaires relatives aux joueurs, la suppression sécurisée combine généralement :

Actions au niveau de l'application : , par exemple en supprimant ou en anonymisant les enregistrements au niveau des lignes une fois qu'une règle de conservation est respectée ou qu'une demande d'effacement est validée.
Partitionnement temporel : , de sorte que des partitions ou des fragments de table entiers (par exemple, par mois ou par saison) peuvent être supprimés, évitant ainsi des nettoyages coûteux ligne par ligne.
Maintenance régulière du stockage – compactage ou aspiration – afin que les documents « supprimés » ne restent pas indéfiniment dans un espace non alloué.

L'essentiel est de les exprimer comme modèles de maisonsIl ne s'agit pas de choix individuels de développeurs. Une norme interne simple, telle que « les comptes utilisent le modèle A ; l'historique des transactions utilise le modèle B ; les stocks utilisent le modèle C », permet de prévoir le comportement d'un logiciel à l'autre et facilite grandement la documentation par rapport à la norme A.8.10.

Qu’en est-il des journaux d’activité, de la télémétrie et du stockage à long terme ?

Les flux de journaux et de télémétrie contiennent souvent contexte de joueur plus riche que la base de données principale du jeu. Dans ces systèmes, la suppression sécurisée dépend fortement de la configuration :

Intégré commandes de rétention et de rotation dans les outils de journalisation et d'observabilité, paramétrés différemment pour les flux de jeu, de performance et de sécurité.
Minimisation précoce – hachage, troncature ou tokenisation des identifiants près de la source – afin que chaque ligne de journal ne révèle pas l'identité complète, suivie de anonymisation ou sous-échantillonnage à mesure que les données vieillissent.
Les règles de cycle de vie dans le stockage d'objets ou les lacs de données qui expirent ou archivent les ensembles de données et se coordonnent avec gestion des clés, vous permettant de mettre hors service les clés de chiffrement lorsque les données doivent effectivement disparaître.

Les sauvegardes sont le cas où l'effacement physique de chaque copie n'est plus envisageable. De nombreux studios établis adoptent cette méthode. effacement cryptographique Il est plutôt recommandé de chiffrer les ensembles de données discrets avec des clés à portée limitée et de considérer la suppression programmée des clés comme un événement de suppression. Associée à des politiques de cycle de vie et à des journaux de gestion des clés, cette méthode est largement reconnue par les auditeurs et les organismes de réglementation comme un moyen pratique de ne plus conserver d'historique lisible.

Le test pratique est simple : pour chaque grand magasin de données de joueurs, vous pouvez répondre à trois questions – Que se passe-t-il lorsque la fidélisation prend fin, qui en est à l'origine et comment le prouver ?Un système de gestion de la sécurité de l'information (SGSI) tel que ISMS.online vous aide à garantir la cohérence et la traçabilité de ces réponses dans l'ensemble des bases de données, des plateformes de journalisation et des systèmes de sauvegarde.

Comment un studio de jeux peut-il cartographier le cycle de vie des données des joueurs afin que la norme ISO 27001 A.8.10 soit compréhensible par tous ?

Vous cartographiez le cycle de vie pour que les gens voient A.8.10 comme un image partagée du flux de données des joueurs, et non pas comme un paragraphe dans une norme.

À quoi devrait ressembler une carte de cycle de vie pratique ?

Pour un titre phare, une cartographie du cycle de vie qui aide réellement les utilisateurs pourrait :

Commencez là où les données apparaissent : création de compte, connexion, achats, événements de jeu, chat, sondages anti-triche, contacts d’assistance, points d’entrée marketing.
Indiquez où les données seront ensuite utilisées : service de compte, mise en relation, système anti-triche, collecteurs de données télémétriques, entrepôt de données, plateformes de journalisation, CRM et outils communautaires.
Distinguer systèmes actifs, stockage au chaud, les archives et suppression/anonymisation étapes.
Marquez les événements qui déclenchent les compteurs de rétention (dernière activité, fin de l'abonnement, fin de la période de remboursement) et le processus ou emplois qui agissent lorsque ces points sont atteints.
Incluez les zones d'ombre moins évidentes : environnements de test alimentés par la production, bacs à sable de science des données, exportations CSV et copies locales pour les développeurs.

Une fois cette vue établie pour un jeu, vous pouvez standardiser le modèle et l'adapter à d'autres titres au lieu de concevoir la rétention à partir de zéro à chaque fois. Les nouveaux systèmes ou fournisseurs doivent ensuite le déclarer. où ils se situent dans le cycle de vie et comment ils honorent ces mêmes transitions.

Quel est le lien avec le point A.8.10 et votre SMSI ?

Grâce à l'artefact de cycle de vie référencé dans votre SMSI, vous pouvez :

Lien A.8.10 directement vers points de transition nommés: là où les données cessent d'être utilisées, lorsque les minuteurs démarrent et là où la suppression ou l'anonymisation s'applique.
Attribuez les responsabilités à chaque étape afin de bien définir qui configure la conservation des données, qui exécute les tâches et qui examine les preuves.
Réutiliser la carte dans revues de conception, approbations de modifications et évaluations des fournisseursAinsi, les équipes de sécurité, de confidentialité et d'ingénierie argumentent à partir du même schéma au lieu de se baser sur des hypothèses contradictoires.

En conservant cette cartographie, ses règles de fonctionnement et les procédures associées dans ISMS.online, la gestion du cycle de vie des données devient une composante essentielle de votre gouvernance. Après un incident, les revues de direction et les audits internes peuvent interroger la base de données sur son cycle de vie, ce qui permet à l'étape A.8.10 de s'intégrer pleinement à la conception du système et de devenir une simple formalité.

Qui devrait être responsable des décisions de conservation et de suppression dans le secteur des jeux en ligne, et comment empêcher la propagation des exceptions ?

La conservation et la suppression deviennent fiables lorsqu'elles ont Une responsabilité clairement définie, un cycle de décision simple et un suivi visible des exceptions.

Comment attribuer les rôles sans créer de bureaucratie ?

En pratique, la plupart des studios d'enregistrement en direct optent pour une répartition légère de type RACI :

Une fonction de sécurité ou de RSSI est responsable pour répondre à la question A.8.10 dans tous les titres et services partagés.
Une fonction de confidentialité ou juridique est Voyages pour garantir que la conservation et la suppression des données soient conformes à la loi, aux obligations de la plateforme et aux informations communiquées aux joueurs.
Les équipes d'ingénierie des données et des plateformes sont Voyages pour la mise en œuvre et l'exploitation de modèles de suppression et d'anonymisation dans le code, l'infrastructure et les pipelines de données.
LiveOps, produit et analytique sont consulté afin que les fenêtres de conservation ne compromettent pas discrètement les contrôles anti-fraude, la conception des expériences ou l'expérience des joueurs.
Les équipes de soutien et communautaires sont Voyages pour traiter les demandes des joueurs, gérer leurs attentes et signaler les cas inhabituels pouvant entraîner des prolongations temporaires.

Pour éviter que les exceptions n'érodent progressivement votre modèle, il est préférable d'ajouter une boucle de gouvernance légère plutôt qu'un nouveau comité :

Toute conservation prolongée à des fins d'enquêtes, de cas de fraude ou pour des raisons de sécurité est consignée avec le motif, le responsable et la date de révision.
Ces documents sont examinés au même rythme que vos autres sujets liés aux risques et à la conformité – par exemple, lors des revues trimestrielles de la direction du SMSI.
Un petit ensemble de métriques A.8.10 – telles que traitement en temps voulu des demandes d'effacement, nombre de exceptions en retardbauen des systèmes qui ne disposent toujours pas de règles définies – apparaît dans les reportages réguliers.

Lorsque vous gérez cela sur une plateforme ISMS comme ISMS.online, les mêmes flux de travail qui gèrent les incidents, les modifications et les risques peuvent également prendre en charge les décisions de conservation et de suppression des données. Ainsi, vos pratiques en matière de données des joueurs restent cohérentes avec vos communications avec les joueurs, les partenaires et les autorités de réglementation, même lorsque le studio est en phase de lancement ou en situation d'urgence.

Comment les services cloud et les fournisseurs modifient-ils notre approche de l'A.8.10, et que devons-nous intégrer dans les contrats et les configurations ?

Les services cloud et SaaS évoluent ou et comment Les données des joueurs sont stockées et supprimées, mais cela ne change rien au fait que Votre studio est toujours responsable pour décider ce qui doit être conservé, pendant combien de temps et quand cela doit être supprimé ou anonymisé.

Quelles données devons-nous collecter pour chaque service qui accède aux données des joueurs ?

Pour chaque fournisseur détenant des identifiants de joueurs ou des données comportementales, vos enregistrements ISMS doivent préciser :

Laquelle catégories de données des joueurs il stocke (identifiants, coordonnées, jetons de paiement, journaux de chat, données de télémétrie, enregistrements d'assistance) et pour quels titres, régions ou plateformes.
Laquelle options de conservation et de suppression Vous pouvez contrôler : les curseurs de conservation des journaux, les règles de cycle de vie du stockage des objets, les outils d’effacement intégrés, le comportement de fermeture des comptes.
Comment la suppression est déclenchée en pratique – par la configuration, les processus planifiés, les appels d'API ou les tickets de support – et quelles sont les conséquences pour exportations de sauvegardes, de réplicas et d'analyses.
Organisateur Ce que preuve Vous pouvez collecter et conserver : les exportations de configuration, les journaux d'audit, les rapports SOC 2 ou ISO 27001, les déclarations des fournisseurs sur la gestion des sauvegardes et la désinfection des supports en fin de contrat.

Ces détails façonnent deux artefacts clés :

Votre interne matrice de cycle de vie et de rétention, où les magasins tiers apparaissent aux côtés des bases de données internes et des plateformes de journalisation.
Votre contrats et accords de traitement des données, ce qui devrait définir les attentes en matière de conservation maximale, de prise en charge de l'effacement, de traitement des sauvegardes et de comportement lors de la résiliation ou de la migration.

Les évaluations des risques liés aux fournisseurs doivent considérer la suppression et la conservation des données au même titre que le chiffrement et le contrôle d'accès. Si un fournisseur ne peut respecter le cycle de vie que vous avez défini pour les données de vos joueurs, cela devient une décision de gestion des risques délibérée pour vos responsables de la sécurité et de la confidentialité, et non une compromission accidentelle due à la pression des mises en production.

En gérant ces attentes, configurations et preuves au sein d'ISMS.online, vous garantissez une conformité A.8.10 optimale, même en cas d'évolution de votre portefeuille de fournisseurs. Vous pouvez ainsi indiquer quels services détiennent quelles catégories de données de joueurs, pendant combien de temps, comment vous déclenchez leur suppression ou leur anonymisation, et où sont stockées les preuves de ces actions. C'est précisément la transparence que recherchent les plateformes, les organismes de réglementation et les joueurs pour décider de faire confiance à un studio de jeux vidéo sur le long terme.

Nous sommes un leader dans notre domaine

Responsable régional - Hiver 2026 Royaume-Uni

Responsable régional - Hiver 2026 Marché intermédiaire UE

Responsable régional - Hiver 2026 Marché intermédiaire EMEA

« ISMS.Online, outil exceptionnel pour la conformité réglementaire »
— Jim M.

« Facilite les audits externes et relie de manière transparente tous les aspects de votre SMSI »
— Karen C.

« Solution innovante pour la gestion des accréditations ISO et autres »
— Ben H.

ISO 27001 A.8.10 – Suppression sécurisée des données des joueurs et conservation des journaux sensibles