China Privacy Law App minimum necessary personal information by category
App category mapping page for common mobile app necessary personal information scope, using only categories supported by the official source.
The 2021 provisions define the basic function and necessary consumer-side personal information for 39 app types. Match the real function first; the list does not authorize unrelated or optional collection.
Use the 2021 provisions to test what is indispensable to an app's stated basic function. The official list covers 39 app types, including installed, preinstalled, and qualifying mini programs. A listed field is within the category's necessary-information scope only for the stated basic function; the rule does not require collection, authorize another purpose, or replace the PIPL duties that apply to the field.
1
Section 1
How to use the 39-category list
First identify the service the user is trying to use, then match that service to the exact basic function in the official list. means consumer-side information without which that basic function cannot operate normally. Information about merchants, drivers, couriers, teachers, or other supply-side users is outside this definition and needs its own legal analysis. The provisions took effect on 1 May 2021.
For a multi-function app, map each function separately. A field listed for ride hailing does not become necessary for news browsing or a loyalty feature merely because both appear in one app.
Record the app version, user journey, selected category, exact basic function, field or permission, collection point, purpose, and why the function fails without it.
Treat fields outside the listed scope as non-necessary for that basic function. The app may not refuse the basic function because a user declines those fields.
Do not extend a category rationale to analytics, advertising, personalization, account enrichment, or convenience features without a separate PIPL purpose and processing analysis.
Apply PIPL legality, purpose limitation, minimum-impact, notice, processing-basis, sensitive-information, retention, security, and rights duties in addition to the category list.
Selected category examples from the official table
These examples show how category, function, and field stay linked. Use the official Chinese table for the exact result across all 39 categories and check whether the app's implementation genuinely needs each field.
Map and navigation - positioning and navigation: location, departure point, and destination.
Ride hailing - booking a taxi or hailing a cruising taxi: registered-user mobile number; passenger departure point, destination, location, and travel trace; and, for online booking, payment time, amount, and channel.
Instant messaging - text, image, voice, and video communications: registered-user mobile number, account, and instant-messaging contact account list.
Online shopping and food delivery - purchasing goods or food delivery: registered-user mobile number; recipient name, address, and contact number; and payment time, amount, and channel.
Medical consultation and registration - online consultation or appointment booking: registered-user mobile number; patient name, identity-document type and number, hospital, and department for registration; or a description of the condition for consultation.
The table says the basic function can operate without personal information for 13 categories: women's health, live streaming, online audio or video, short video, news, fitness, browser, input method, security management, e-books, camera and editing, app store, and utility tools.
The category list answers whether a field is necessary to a listed basic function. It does not decide every PIPL question, validate a bundled permission request, or cover supply-side users. Where no category fits, do not force the app into the nearest label; document the function-specific necessity analysis under the binding PIPL rules. Sorena's testing and evidence steps below explain how to demonstrate that analysis; they are not a separate statutory checklist.
Test a new user with every non-necessary field and permission declined. The listed basic function should remain available.
Map software development kits, device permissions, inferred data, and background events as well as visible form fields; the collection mechanism does not change the necessity test.
Where one permission exposes more data than the function needs, record how the implementation limits collection, access, frequency, precision, transmission, and retention.
Retain the category decision, screen and data-flow evidence, field and permission inventory, refusal test, PIPL notice and basis analysis, owner, approval, and change triggers.
Reopen the decision when the basic function, user type, field, SDK, permission, purpose, collection timing, or technical dependency changes.
Sorena AI helps turn the China Privacy Law App minimum necessary personal information by category decision into owners, controls, and reviewer-ready records.
Articles 10-12 require app security and data controls, compliance with the necessary-information scope, and no forced consent or refusal of basic service for non-necessary information.
Articles 3-4 support the indispensable-to-basic-function test, its consumer-side boundary, and the requirement not to block basic functionality for refusal of non-necessary information.