Research cutoff: 22 July 2026
Scope: General research centred on Chinese law with selected EU, US and platform interfaces. It is not a legal opinion for a particular product or transfer.
Executive summary
Online-game data governance is not a question of how many fields a game collects. It is a question of how product functions, technical dependencies and global operations split a field into different processing activities. A phone number may register an account. Identity information may support real-name and anti-addiction controls. Telemetry may synchronise a game state, balance the economy and detect fraud. Voice may be social content, a moderation object and a customer-service attachment at the same time. A Chinese player’s account may be stored in China while an overseas publisher, support team, analytics SDK or cloud operator can query or download it.
The workable unit is field × purpose × decision-maker × region × age group. A privacy policy or SDK inventory is only a view of that unit. The team must know which entity decides the purpose, who receives the data, what legal basis applies, whether a child or sensitive attribute is involved, whether a remote query is a cross-border provision, how long the record remains and what happens when the player deletes an account or challenges a ban.
Chinese law does not provide a general “legitimate interests” basis that absorbs analytics, advertising and risk control. Contract necessity should be tested against a counterfactual: if the field is absent, can the promised core service still run? Real-name and anti-addiction checks usually point to statutory duties, not an unlimited consent. The 2024 cross-border rules adjust some procedural thresholds and exemptions; they do not remove notice, necessity, impact-assessment, security or rights duties.
For overseas operations, GDPR, COPPA and store policies are separate interfaces. A Chinese game should map data flows before selecting a transfer mechanism, use role analysis instead of company labels, stage children’s and biometric data separately, and retain operational evidence that the text actually matches the running client and SDK.
1. Start with the lifecycle, not a field list
A conventional privacy review begins with a list: phone, device ID, IP address, location, voice, payment, contacts. That list is useful but incomplete. The same field can have a different purpose, recipient and risk at each point of the lifecycle.
At registration, the service may need a phone number for account recovery, fraud prevention or a statutory real-name route. During a match, the game may process a pseudonymous identifier, device and network information, input events and anti-cheat signals. During customer support, a player may upload a receipt, identity document, voice recording or a screenshot containing a child’s name. During shutdown, the business may retain transaction evidence, chargeback records and a limited fraud-control record while deleting the player’s ordinary profile.
The review should therefore draw an actual data-flow diagram with product event, storage location, access route, recipient, purpose, retention and deletion task. “The database is in China” is a storage fact, not a complete transfer conclusion. “The vendor is only an SDK” is a technical description, not a legal role.
2. Chinese legal basis and necessity
The Personal Information Protection Law (PIPL) requires a clear, reasonable purpose, minimisation and a legal basis such as consent, contract necessity or a statutory obligation.[1] Chinese law has no universal legitimate-interest basis that can be used to absorb every useful analytics, advertising or fraud-prevention activity. A core account and game-state function may be necessary to perform the player contract. Cross-app advertising, optional social import, broad device profiling and indefinite telemetry need their own analysis.
The Necessary Personal Information Provisions for Common Types of Mobile Internet Applications describe a “network game” basic function and identify a registered user’s mobile number as the listed necessary information in that category.[2] The provision should not be reversed into a rule that every game must use a phone number as its only account method, nor into proof that an identity document, contacts, precise location or installed-app list is necessary for core play. Real-name and anti-addiction processing should be justified under the applicable game and minors rules, then kept separate from advertising and general analytics.
Consent is not a universal repair tool. A consent screen cannot make a non-necessary field necessary, and a player who withdraws consent may not be able to withdraw from a statutory identity check while remaining in a service that must enforce a statutory restriction. The product should distinguish general consent, separate consent for sensitive information or a transfer, guardian consent and a legal-duty route. Each should have a user-facing explanation and a back-end state.
The notice must describe real processing. If an overseas support team can search a Chinese database, saying “data remains in China” is incomplete. If a crash SDK sends device identifiers to an endpoint controlled by a group company, a vendor-only description is incomplete. If a voice-moderation supplier keeps clips for model training, “security review” is incomplete unless that use is actually necessary and disclosed.
3. Roles are determined by the activity
The operator, developer, publisher, cloud provider, SDK, support centre, payment platform and store may have different roles for different flows. A developer that determines the fields and purposes may be a personal-information processor even if a publisher signs the player contract. A publisher may decide customer-support purposes while acting as a recipient for game-state data. A cloud provider may process on instructions but become an independent decision-maker for its own security or billing records.
The role table should identify who decides purpose, essential means, recipients, retention and response to rights requests. It should also record the external contract and the internal owner. A data-processing agreement can allocate audit and indemnity duties, but it cannot rewrite a player’s statutory rights or turn an independent purpose into an instruction merely by using the word “processor”.
SDK governance should follow the lifecycle of an integration. Before inclusion, record the fields, endpoints, permissions, jurisdictions, children’s implications and contract. At release, test whether the SDK initialises before consent and whether it collects a field that the product never uses. During operation, record versions, configuration, access, incidents and deletion. On removal, revoke keys, stop collection, handle retained copies and update the notice.
The most common structural error is consent before the screen but SDK initialisation at app launch. Another is permission requested for a feature that has not been triggered. The remedy is not a longer policy; it is a client-state machine that starts optional collection when the feature is selected and proves that the permission or consent was obtained first.
4. Accounts, devices, behaviour and social content
Account and contact data should be separated from game state. A stable internal identifier can join systems without exposing a phone number as a universal lookup key. Recovery, anti-fraud and customer support may need a phone number, but the ordinary operations dashboard can use a pseudonymous identifier and a limited status.
Device and network information may be personal information when it can identify or single out a player, especially when combined with user ID, event sequences and account history. An IP address is not made harmless by calling it “technical”. The team should document the purpose of each device field, the minimum precision, the recipient and deletion date.
Telemetry has at least three possible purposes: synchronising state, improving balance and detecting cheating. These purposes can require different fields and retention. Anti-cheat may need a restricted evidence store and human review; product analytics may need aggregation; neither automatically justifies retaining raw input events forever. If a risk score affects a ban, match isolation or purchase access, the user needs an understandable explanation, a review route and evidence sufficient to revisit the specific decision.
Voice and chat should be split into original audio, transcription, voiceprint features, moderation labels and appeal clips. Ordinary voice chat is communication content; a voiceprint extracted to identify a person is biometric information. Content may reveal health, religion, location or a child’s identity. A single “voice data” row cannot support a meaningful purpose and retention decision.
Payment data should be separated from purchase history. A store may collect card details as its own controller; the game may receive transaction ID, product, price, currency, refund and account link. The game should not collect a full card number merely because it wants to reconcile a purchase. Support screenshots and chargeback files can contain more information than the original transaction and need a special intake rule.
5. Minors and biometric information
Minors protection begins with age design but age gating itself is processing. A reasonable architecture asks for the least information needed to put a user into an age band, then routes a user who needs real-name, parental-consent or anti-addiction controls to the relevant path. The team should not collect identity documents or faces from everyone just to support a claim that all players are adults.
The Regulations on the Protection of Minors Online require game providers to verify minors’ real identity through necessary means and implement time, duration and spending controls.[3] “Necessary means” should not be read as a universal facial-recognition mandate. A verified status, age band and parental-consent state can be stored separately from a full identity document, allowing ordinary operations, advertising and customer service to see only the status they need.
Facial recognition and voiceprint processing require a separate necessity and security assessment. If a face is used for anti-addiction verification, document why a less intrusive alternative cannot achieve the stated objective, limit the image and template lifecycle, restrict access and delete when the task ends. A biometric feature collected for identity should not silently become a training dataset or a marketing segment.
Under COPPA, the under-13 rule, mixed-audience treatment, actual knowledge and parental consent are distinct questions. The FTC’s 2025 amendments include separate parental consent for certain third-party disclosures and targeted advertising, retention limits and biometric identifiers.[4] The FTC’s 2026 age-verification policy statement also illustrates a principle relevant to game design: data collected solely for age determination should not be repurposed or kept longer than necessary.[5] These US rules do not replace Chinese real-name duties; they add a different product and disclosure interface.
The EU’s GDPR Articles 8 and 9, the DSA’s minors protection duties where the service is an accessible online platform, and store family policies may impose additional constraints. The team should implement a layered age state rather than one global “adult=true” flag.
6. Cross-border paths: draw the route before choosing a procedure
A Chinese player’s data written directly to an overseas server is an obvious transfer path. Less obvious paths include an overseas publisher querying a Chinese database over VPN, a foreign support desk viewing tickets, an analytics SDK sending device identifiers abroad, an overseas backup, a remote debugging session and a vendor downloading a limited export. Storage location is one fact; access, retrieval and provision are other facts.
The 2024 Provisions on Facilitating and Regulating Cross-Border Data Flows refine when an organisation must use a security assessment, standard contract or certification. The Cyberspace Administration of China states that certain situations may be exempt, including some contract-necessary transfers, cross-border human-resources management, emergencies, and transfers by non-CIIO processors involving fewer than 100,000 non-sensitive personal-information subjects from the beginning of the year.[6] The same official explanation also distinguishes thresholds for standard contract or certification and for security assessment. These procedural routes do not eliminate notice, applicable separate consent, impact assessment, necessity, security or data-subject rights.
The count must be based on actual de-duplicated individuals and the relevant period. Do not use registered accounts as a substitute for people, or player records as a substitute for transferred records. Sensitive personal information has a separate threshold. Important-data status, CIIO status, free-trade-zone negative lists and sector rules can change the route.
A path inventory should record source system, field class, subject count, recipient, country, access mode, transfer frequency, purpose, legal basis, impact assessment, contract, security control and deletion proof. Remote read-only access is still access. Encryption is a security measure, not a denial that data left the original control boundary.
7. Six common global-game paths
Global synchronisation. Separate Chinese account, gameplay state, chat, payment and risk data. Test whether a region-specific identifier or limited state can support the shared feature instead of sending a full profile.
Overseas publisher access. Apply field masking, ticket-based authorisation, session logs, export limits and emergency expiry. A person who can view a screen may still be querying personal information.
Analytics, crash and advertising SDKs. Confirm the contracting entity and endpoint. A Chinese domain can forward abroad; a global vendor can offer a Chinese instance. Test identifiers and event sequences together, not one field at a time.
Cross-border support. Tickets may contain identity documents, payment disputes, children’s information and audio. Route by region, hide real-name fields from ordinary agents and use temporary permission for attachments.
Stores and payments. Separate the store’s own collection from data actively sent by the game. The store’s controller role does not answer whether the game has made its own transfer or disclosed an order ID.
Overseas cloud and backup. Encryption does not eliminate transfer. Backups are personal information when they can be restored and linked to a player. Define restoration access, retention and deletion rather than treating cold storage as invisible.
8. Rights, automated decisions and security
A player’s access, copy, correction and deletion rights must reach the systems that hold account data, purchases, support, SDK records and backups. A front-end button works only if a back-end workflow can locate the stable identifier, route requests to independent recipients, verify the requester, exclude other users’ information and record completion. Deletion should distinguish the ordinary profile from transaction, fraud and legal-retention records; each exception needs a reason and expiry.
Automated anti-cheat or fraud decisions can materially affect access, matching and purchases. The operator should explain the relevant data categories, principal factors, likely consequences, retention and appeal route without publishing code or detection thresholds. Preserve enough evidence to review the particular action and limit indefinite retention of raw telemetry merely because a future dispute is possible.
Security controls must be tied to the data map: least privilege, individual accounts, strong authentication, key rotation, export alerts, separated production and analytics stores, secure vendor channels, incident response and tested deletion. A shared administrator account defeats both security and accountability. A security incident plan should identify who decides notification, who preserves logs and how a foreign publisher or local regulator receives only the necessary record.
9. A practical governance ledger
A small studio can maintain four linked ledgers.
- Field ledger: field, source, purpose, legal basis, sensitivity, age relevance, recipient and retention.
- Role ledger: decision maker, processor, independent recipient, contract, country and rights-request owner.
- Flow ledger: route, access method, frequency, subject count, transfer mechanism, security control and deletion proof.
- Lifecycle ledger: SDK version, consent state, age mode, incident, request, shutdown, export and deletion event.
Review the ledger at feature design, SDK addition, release candidate, major event, new publisher, new country and shutdown. A privacy policy should be generated from the ledger only after the running client, server and vendor configuration have been compared with it.
Three release questions expose weak governance quickly. First, disable every optional SDK in a clean installation and confirm that the core game still works; then enable one optional feature and observe exactly which fields leave the device. Second, create a child-mode account and follow the same path as an adult account: registration, first purchase, voice chat, targeted offer, support ticket, ban appeal and deletion. The team should be able to show where the path diverges and why. Third, revoke an overseas support agent’s access while a ticket is open and check that the session, export link, cache and backup permissions all expire. These exercises turn the data map into operational evidence.
Incident response should use the same vocabulary. “A vendor leak” is not a sufficient record. Capture the field, subjects, endpoint, purpose, role, countries, access window, encryption, containment action, notification decision and deletion or preservation result. If a publisher or SDK refuses to provide logs, the contract and technical architecture should make that refusal visible before launch. A documented inability to answer is itself a release risk.
The same discipline helps product teams resist false equivalences. A pseudonymous account ID is not automatically anonymous; a database replica is not automatically a new purpose; a read-only dashboard is not automatically outside the transfer analysis; and a consent checkbox is not automatically valid consent. Ask what the system can actually do, who can actually see the record, and which business decision follows from it. That three-part test usually finds the material issue faster than comparing policy paragraphs.
For a launch committee, the final sign-off should be a bounded statement: these fields, for these users, in these regions, for these purposes, through these recipients, with these controls and deletion dates. If a field, recipient or purpose falls outside that statement, the feature has not been approved merely because the privacy page is already published.
That bounded statement should travel with the release candidate. Product, engineering, security, legal and support should sign the same version rather than maintaining separate spreadsheets. When the next event adds a social feature, a new SDK or a foreign help desk, the delta is visible and the review can focus on the changed fields and routes. This is faster than restarting a generic privacy review and more reliable than assuming the old policy covers a new data flow.
10. Chinese, EU, US and platform interfaces
China’s regime asks whether the purpose is clear and necessary, whether sensitive information and minors are handled properly, and whether the cross-border route meets the relevant procedure. GDPR adds controller/processor and territorial questions, rights and children’s consent requirements. COPPA focuses on children under 13, parental consent, disclosure and retention. Apple and Google may require earlier or more visible permission, data-safety declarations and deletion mechanisms than a statute alone would suggest.
These interfaces should not be collapsed into a “strictest standard” slogan. A Chinese law duty to verify minors does not justify a global facial database. A US parental-consent path does not replace Chinese transfer documentation. A store data-safety form does not prove that a backend delete job completed. The team needs an interface table showing which requirement is mandatory, which is contractual, who owns it and what evidence proves completion.
11. Shutdown, deletion and disputes
A shutdown is a data event. Freeze only the transaction, fraud and dispute records that have a reason to survive. Delete or anonymise ordinary telemetry, voice and support attachments when the purpose ends. Notify players about account closure, remaining balances, export and appeal. If a publisher changes, migrate only what the new purpose and contract allow, and preserve the transfer record.
A dispute may require a temporary hold. The hold should identify the matter, fields, legal or contractual basis, reviewer and end date. It should not become a permanent archive of every player interaction. If a player requests a copy, distinguish the user’s data, game state, transaction, essential log and a third party’s information; do not disclose anti-cheat secrets merely because the user asks for every algorithmic record.
12. Conclusion and research limits
A defensible game data programme is a set of live maps, not a long policy. The field must be tied to a purpose, purpose to a decision maker, decision maker to a region and age group, and every important action to a retention and rights path. Cross-border compliance begins with the actual route: global service, foreign support, SDK, backup and remote access can each matter. Minors and biometric information need separate states and shorter, purpose-specific lifecycles.
The research is limited by the 22 July 2026 cutoff, the selected jurisdictions and the absence of a specific game’s architecture, subject counts, CIIO status, important-data determination and vendor contracts. Platform policies change. Thresholds and free-trade-zone lists require current factual review. Nothing here determines that a particular transfer is approved or that a specific game can collect a particular field.
Core sources
[1] Personal Information Protection Law of the People’s Republic of China, Articles 5–9 and 13, CAC official text: official source
[2] Provisions on the Necessary Personal Information for Common Types of Mobile Internet Applications, CAC: official source
[3] Regulations on the Protection of Minors Online, State Council / official Chinese government sources: official source
[4] FTC, 16 CFR Part 312: COPPA Final Rule Amendments, 22 April 2025: official source ; Federal Trade Register record: official source
[5] FTC, COPPA age-verification policy statement, 25 February 2026: official source
[6] CAC, Provisions on Facilitating and Regulating Cross-Border Data Flows, 22 March 2024: official source ; official Q&A: official source
[7] Measures on the Standard Contract for Cross-Border Transfer of Personal Information, CAC: official source
[8] Measures for Data Export Security Assessment, CAC: official source
[9] Regulation (EU) 2016/679 (GDPR), Articles 3, 4, 6, 8, 9, 26 and 28: official source
[10] EDPB Guidelines 07/2020 on controller and processor concepts: official source
[11] Regulation (EU) 2022/2065, Article 28, EUR-Lex: official source
[12] European Commission, minors protection guidelines, 2025: official source
[13] Apple, App Review Guidelines, sections 1.3, 5.1.1 and 5.1.2: official source
[14] Google Play User Data policy: official source
[15] Google Play Families Policy Requirements: official source
[16] FTC, Microsoft Xbox COPPA settlement, 5 June 2023: official source
[17] FTC, Epic Games enforcement and refunds, 19 December 2022: official source
[18] Ministry of Industry and Information Technology, 2025 APP and SDK enforcement notice: official source