Data Security Technology — Personal Information Security Specification (2026 Draft for Comment).

DCC archive. This is the public-consultation draft of the revised GB/T 35273, released by the National Cybersecurity Standardization Technical Committee (TC260) for public comment on June 17, 2026 to replace GB/T 35273-2020. The archived standard text below is the working-group draft (本草案完成时间 2026-06-01); the accompanying drafting explanation is dated 2026-05-20. It is a recommended-standard draft — non-binding and non-final; clause numbers may change before release (expected after 2027). DCC’s structural read of what changed against the 2020 edition is in the brief From Consent to Governance.

Source documents

• Draft standard (full text, Chinese): download PDF ↓
• Drafting explanation (编制说明, Chinese): download PDF ↓
• Official consultation post: 网安标委 / WeChat

A DCC working English translation of the full draft follows. The Chinese source text is in the downloadable PDF above. The English is a working translation for overseas counsel, with terminology aligned to DCC’s standing glossary and the informative annex tables (A, B, D) reconstructed from the source layout. Where the translation differs from the source PDF, the Chinese / PDF governs.

Provenance and process (from the drafting explanation)

The revision was filed with TC260 on August 22, 2025 (project No. 20260700-T-469) to support implementation of the Personal Information Protection Law, the Regulation on Network Data Security Management, and the Measures for Personal Information Protection Compliance Audits. CESI leads drafting, joined by Beijing Institute of Technology, the CAC Data and Technology Support Center, and a large industry cohort (Huawei, Honor, ZTE, Ant Group, ByteDance/Douyin, Tencent, Meituan, Kuaishou, Alibaba, DiDi, China Unicom, Ezviz, Vipshop, Alibaba Cloud, Tencent Cloud, and others). It cleared WG8 review and was turned into a consultation draft on April 1, 2026, and passed the expert-review meeting on April 29, 2026 before opening for public comment.

Main technical changes against GB/T 35273-2020 (official list)

The draft’s own preface and drafting explanation list the principal changes versus the 2020 edition:

* The preface and drafting explanation cite “separate consent” at 3.8, while the draft body places the definition at 3.7 — a cross-reference to be reconciled in the final text.

English translation (DCC)

DCC working translation of the consultation draft, for overseas counsel. Not official. Article/clause numbers track the Chinese source; where this translation and the source PDF differ, the Chinese governs. Informative annexes are translated in summary table form. Terminology follows DCC’s standing Chinese→English glossary: “handler” = personal information handler (个人信息处理者), “PIPIA” = personal information protection impact assessment (个人信息保护影响评估), “person in charge” = person in charge of personal information protection (个人信息保护负责人), and “PI” abbreviates personal information.

Foreword

This document is drafted in accordance with GB/T 1.1—2020. It replaces GB/T 35273-2020 Information Security Technology — Personal Information Security Specification. Compared with GB/T 35273-2020, the principal technical changes are:

• revised “sensitive personal information” (see 3.2);
• added “separate consent” (see 3.8);
• added the “quality-assurance principle” (see 4);
• added “lawful basis for personal information processing” (see 5);
• added “collection of sensitive personal information” (see 6.6);
• added “collection by AI products or services” (see 6.7);
• added “collection by terminal products or services” (see 6.8);
• added “use of a unified account system” (see 8.6);
• added “overseas legal-jurisdiction determination and conflict handling” (see 11);
• added “person in charge of personal information protection” (see 13.1);
• added “personal information-protection working body and personnel” (see 13.2);
• added “personal information-protection compliance audit” (see 13.8).

This document is proposed by and under the centralized management of the National Cybersecurity Standardization Technical Committee (SAC/TC260). Drafting lead: China Electronics Standardization Institute (CESI), with a large group of co-drafting universities, research bodies and enterprises.

Introduction

In recent years, with the wide application of new technologies, personal- information processing has become multi-scenario, multi-business, complex in its chains and frequent in cross-border interaction, and personal information protection faces new risks. Global data-governance rules are tightening, outbound-data demand keeps growing, and problems of illegal collection, misuse and leakage are more acute — posing potential threats to individuals’ lawful rights, the public interest and even national security. Pursuant to the Cybersecurity Law, the Data Security Law, the Personal Information Protection Law and the Regulation on Network Data Security Management, this standard focuses on the full personal information lifecycle, refines processing rules, details security requirements and strengthens handler accountability. Where laws or regulations provide otherwise for a requirement in this standard, those provisions are to be followed.

1　Scope

This document specifies the principles and security requirements to be followed in carrying out personal information processing activities — collection, storage, use, processing, transmission, provision, public disclosure, deletion and the like. It applies to regulating the personal- information processing activities of organizations of all kinds, and also to the supervision, management and assessment of such activities by competent authorities, third-party assessment institutions and others.

2　Normative references

The following documents are indispensable to the application of this document through normative reference. Dated references: only the cited version applies; undated references: the latest version (including all amendments) applies.

• GB/T 25069—2022 Information security technology — Terminology
• GB/T 39335—2020 Information security technology — Guidance for personal information security impact assessment
• GB/T 37988—2019 Information security technology — Data security capability maturity model
• GB/T 42574—2024 Information security technology — Implementation guide for notification and consent in personal information processing
• GB/T 45574—2025 Data security technology — Security requirements for processing sensitive personal information
• GB 46864—2025 Data security technology — Technical requirements for information erasure of electronic products
• GB/T 46903—2025 Data security technology — Requirements for personal information protection compliance audit
• GB/T AAAA—AAAA Data security technology — Personal information protection requirements for products and services for minors (forthcoming)
• GB/T AAAA—AAAA Data security technology — Security guide for data provision, entrusted processing and joint processing (forthcoming)

3　Terms and definitions

The terms defined in GB/T 25069—2022 and the following apply.

3.1 personal information — various information, recorded electronically or otherwise, relating to an identified or identifiable natural person, excluding information that has been anonymized. NOTE 1: includes name, date of birth, ID-document number, biometric information, address, contact details, communication records and content, account passwords, property information, credit information, whereabouts, accommodation, health/physiological information, transaction information, etc. NOTE 2: see Annex A for determination methods and types. NOTE 3: information formed by a handler’s processing of personal or other information (e.g., a user profile or feature label) that, alone or combined with other information, can identify a specific natural person or reflect their activities, is personal information.

3.2 sensitive personal information — personal information that, once leaked or unlawfully used, is liable to harm the dignity of a natural person or endanger personal or property safety. NOTE 1: includes biometric, religious-belief, specific-identity, medical- health, financial-account, and whereabouts information, and the personal information of minors under 14. NOTE 2: see Annex B and GB/T 45574-2025 for identification. NOTE 3: where multiple items of personal information, once aggregated, meet the definition, the aggregated personal information as a whole shall be identified and protected as sensitive personal information.

3.3 personal information subject — the natural person identified by or associated with the personal information.

3.4 personal information handler (the draft’s own English gloss is “personal information processor”) — an organization or individual that independently determines the purpose and means of processing in personal information processing activities. NOTE 1: a natural person processing personal information for personal or household affairs need not bear a handler’s statutory obligations. NOTE 2: an individual processing on behalf of an organization is not a handler. NOTE 3: the handler is determined per specific processing activity; a provider may be a handler for some activities and an entrusted party for others. NOTE 4: roles may be fixed by agreement or effective rules; absent contrary evidence, those may determine each party’s characterization.

3.5 collect — the act of obtaining control over personal information, including direct collection (provided by the subject, or via interaction with or recording of the subject’s behavior) and indirect acquisition (receiving provision/transfer from other handlers, or gathering already-public information).

3.6 consent — a voluntary, clear authorizing act by the subject regarding their personal information. NOTE 1: includes authorization by an affirmative act (explicit consent) or inferred from a voluntary act. NOTE 2: explicit consent — an affirmative authorizing act in writing, orally, etc. (actively ticking or clicking “agree” / “register” / “send” / “dial”, actively filling in or providing, etc.). NOTE 3: inferred authorization — e.g., a subject who, after being notified of collection within a collection area, does not leave the area.

3.7 separate consent — an act by which an individual specifically gives concrete, explicit authorization for a particular processing of their personal information; it does not include a one-time consent given for multiple purposes or means of processing. NOTE: the notice content and the manner of obtaining separate consent must be distinguished from other processing activities.

3.8 user profiling — the process of analyzing or predicting a specific natural person’s characteristics (occupation, finances, health, education, preferences, credit, behavior, etc.) by collecting, aggregating and analyzing personal information, forming a feature model of that person. NOTE: using a specific person’s own information to form their model is “direct profiling”; using information from outside that person (e.g., their group’s data) is “indirect profiling.”

3.9 personal information protection impact assessment (PIPIA) — the process of examining whether a processing activity is lawful and compliant, analyzing the harm to the subject’s lawful rights and the corresponding security risks, and evaluating the effectiveness of protection measures.

3.10 delete — to remove personal information from all storage systems so that it cannot be retrieved, accessed or recovered.

3.11 publicize — releasing information to society or an unspecified group. NOTE: where information is released to an unspecified number of individuals on a social-media platform — even with visibility limits — if actual or potential recipients are numerous and beyond the publisher’s control, the public- disclosure attribute should be assessed by reference to this definition.

3.12 transfer (of control) — the transfer of control over personal information from one handler to another.

3.13 providing — a handler providing personal information to another handler, each holding independent control. NOTE: entrusting a third party to process is not “providing to another handler.”

3.14 anonymization — the process by which personal information is processed so that a specific natural person cannot be identified and cannot be restored.

3.15 de-identification — the process by which personal information is processed so that a specific natural person cannot be identified without additional information. NOTE: de-identification is on an individual basis, retaining individual granularity, using pseudonyms, encryption, hashing, etc.

3.16 personalized display — displaying content, search results for goods or services, etc., to a subject based on their browsing history, interests, consumption records and habits.

3.17 business function — a function meeting a subject’s specific use purpose (e.g., map navigation, ride-hailing, instant messaging, social, online payment, news, online shopping, delivery, ticketing).

3.18 device information — information describing a device’s basic attributes, unique identifiers and operating status, including hardware parameters, serial numbers and unique device identifiers written at the manufacturing stage.

3.19 unified account — a unified account system provided across different non-equity-affiliated entities within the same group, allowing a user to access all associated products with one account. EXAMPLE: companies A, B and C (no equity ties) under the same group run different products; one account logs into and uses all of them.

3.20 entrusted processing — processing carried out by an individual or organization entrusted by a handler, per agreed purpose and means.

4　Basic principles of personal information security

A handler shall observe the principles of lawfulness, legitimacy, necessity and good faith, specifically:

• a) Accountability — adopt technical and other necessary measures to safeguard security, and bear responsibility for harm to subjects’ lawful rights.
• b) Purpose specification — have an explicit, clear and specific purpose.
• c) Authorization and consent — disclose to the subject the purpose, means, scope and rules, and obtain consent or another lawful basis before processing.
• d) Minimum necessary — have a reasonable purpose directly related to it, using the least rights-intrusive means; save where law provides otherwise, the retention period shall be the shortest necessary to achieve the purpose.
• e) Openness and transparency — disclose the scope, purpose and rules clearly and reasonably, and accept external supervision.
• f) Quality assurance — through reminders, validation and verification, ensure the authenticity and accuracy of collected information; on discovering an error, promptly notify the subject and provide a correction channel; avoid decision bias or rights harm caused by inaccuracy.
• g) Security safeguards — have security capability matching the risks faced, and take sufficient management and technical measures to protect confidentiality, integrity and availability.
• h) Rights protection — provide methods to query, correct and delete personal information, and to withdraw consent, cancel an account and complain.

5　Lawful basis and compliance requirements for processing

5.1　General requirements

A handler shall:

• a) before processing begins, identify and record the lawful basis, forming a verifiable, traceable, auditable evidence chain; once fixed, the basis shall not be changed at will for the purpose of evading obligations;
• b) ensure the basis follows lawfulness, legitimacy, necessity and minimum- impact; where several bases are available, choose the one less intrusive on the individual’s rights, and keep it consistent with the notice;
• c) keep the basis consistent with the notice, the processing-activity record, the PIPIA and the compliance audit, and update them in sync on a material change of purpose, scope or circumstances;
• d) properly record the basis, including at least the applicable basis, an applicability explanation, the approval process and records, timestamps and evidence. NOTE: evidence typically includes contract clauses, statutory article numbers, system-configuration screenshots, etc.

5.2　Obtaining the individual’s consent

• a) collecting sensitive personal information requires the subject’s separate consent;
• b) collecting the personal information of a minor under 14 requires the separate consent of a parent/guardian;
• c) where law requires written consent, obtain written consent;
• d) notify the subject of the applicable processing rules before obtaining consent;
• e) consent must rest on clear notice and an explicit affirmative act; default, passive or continued-use-coerced consent is not valid consent (implement per GB/T 42574-2023, 9.1–9.4);
• f) provide a convenient way to withdraw; withdrawal does not affect processing already carried out before withdrawal; after withdrawal, promptly stop processing for that purpose except storage and necessary safeguards; NOTE: if the information was provided to a third party, the provision must cease immediately upon withdrawal.
• g) retain evidence of consent (content, time, means, carrier, evidence and withdrawal trace) per GB/T 42574-2023, 9.7;
• h) where guardian consent is legally required (minors under 14, persons with no/limited capacity), obtain it lawfully and keep records.

5.3　Necessary for concluding/performing a contract

• a) applies only to realizing the contract’s core purpose, or to pre-contract measures necessary at the individual’s request or for objective reasons such as compliance with applicable law;
• b) shall not bring in activities with no direct connection to the core purpose — including personalized advertising for marketing, behavioral analysis beyond contractual necessity, and profiling not needed to perform the contract; risk assessment or quality improvement claimed as contractually necessary must be shown to be directly connected to the purpose;
• c) assess the connection and substitutability between the processing and core contractual obligations;
• d) annotate, in the processing record, the correspondence between contract/ offer elements and personal information fields;
• e) where a contract change alters the purpose or scope, re-assess the lawful basis before the change takes effect.

5.4　Necessary for human-resource management under a labor contract

Where HR management is carried out under lawfully formulated labor rules and a lawfully concluded collective contract:

• a) limited to processing necessary for employment, HR management, labor- discipline, pay/benefits, performance appraisal and labor-dispute handling;
• b) base it on lawfully formulated labor rules / collective or labor contract, noting the basis in the processing record;
• c) shall not bring in marketing, employee profiling or behavior monitoring unrelated to labor management;
• d) where it involves sensitive PI, automated decision-making, disclosure, external provision or outbound transfer, the corresponding chapters also apply.

5.5　Necessary to perform a statutory duty or obligation

• a) applies only where an explicit law, administrative regulation or legally effective normative document requires it and points to a specific obligation;
• b) limited to the minimum scope necessary, and not for unrelated purposes;
• c) note the explicit legal basis in the record;
• d) if information collected for legal compliance is used for another purpose, re-assess the lawful basis for that purpose.

5.6　Necessary to protect life, health and property in a public-health or emergency situation

• a) applies only in sudden, urgent scenarios to protect life, health or major property safety;
• b) processing required by a public-health authority for disease monitoring, reporting and intervention may proceed without authorization;
• c) assess urgency and irreplaceability, and retain the authorization/decision chain.

5.7　News reporting, public-opinion supervision and the like for the public interest

• a) only for news reporting, public-opinion supervision or other public- interest expression;
• b) shall not, in the name of “public interest,” carry out processing unrelated to the reporting purpose, excessive or insulting, and in particular shall not re-victimize minors, victims and other vulnerable groups;
• c) conduct a PIPIA weighing the public/newsworthy nature, impact on rights, means and scope, and substitutability, and apply de-identification and data minimization to balance public interest and rights;
• d) establish a review mechanism for the processing involved and the content to be disclosed, keeping editorial and legal-review records;
• e) promptly correct/update factually wrong, out-of-context or time-expired information.

5.8　Processing, within a reasonable scope, personal information that an individual has disclosed or that is otherwise lawfully public

• a) confirm a lawful basis for the source’s disclosure;
• b) use it for the original purpose of disclosure; do not use already-public information for profiling, marketing or other purposes;
• c) process only the public information necessary for the purpose; do not circumvent technical limits to scrape or aggregate;
• d) do not lower protection for public sensitive PI merely because it is public;
• e) maintain an inventory of processed public information (source, time of acquisition, basis of disclosure, restrictions, purpose/scope, necessity assessment, de-identification measures);
• f) before bulk scraping/aggregation, conduct a PIPIA, take reasonable measures and set up a rights-response channel.

5.9　Other circumstances provided by law or administrative regulation

• a) applies only where an explicit law/administrative regulation provides for the specific purpose, scope and conditions;
• b) shall not self-expand under “other circumstances,” nor substitute internal rules or industry self-discipline for a legal basis;
• c) record the legal basis’s name, article, applicable scenario and hierarchy;
• d) periodically review external-norm changes and, where needed, re-assess and re-notify.

6　Collection of personal information

6.1　Minimum necessary

• a) the type, fields, timing, granularity and scope collected shall be directly related to realizing the product/service’s business function, using the least rights-intrusive means; extended functions must show a reasonable connection to basic functions. NOTE 1: if only a particular type/field/scenario/granularity is needed, do not collect more; if only specified users or a specific scope is needed, do not collect from all users by default. NOTE 2: “directly related” means the basic/extended function cannot be realized without that information.
• b) the frequency of automatic collection shall be the lowest necessary;
• c) the quantity of indirect acquisition shall be the least necessary;
• d) information collected for AI data pre-processing or model training shall be limited to the minimum necessary, with effective security techniques to reduce leakage;
• e) an AI product/service should set up input-side reminders and a filter mechanism to achieve minimum collection and block non-essential sensitive PI; NOTE 3: on detecting a user entering sensitive PI, a prompt such as “mind the privacy risk; enter sensitive personal information with care” may be shown.
• f) an AI product/service shall not collect, in advance, information beyond what its function needs; it shall notify and request permissions when the user first enables the function;
• g) handlers should prefer privacy-enhancing technologies for minimization and, where used, inform the subject of the principle and impact;
• h) periodically assess the necessity of collection, re-validating on changes to business, technology or law.

6.2　Autonomous choice

Where a product/service offers multiple PI-collecting functions, a handler shall not coerce the subject into accepting them. Requirements:

• a) shall not bundle functions to force one-time acceptance of collection for functions the subject did not request; NOTE 1: for continuously-running tasks (e.g., an automated AI assistant), after a PIPIA and full notice, collection and permissions may be notified and consented once before the task begins.
• b) treat the subject’s affirmative act (clicking, ticking, filling in) as the trigger to enable a specific function, collecting only after the subject enables it; NOTE 2: see Annex C for implementation.
• c) closing/exiting a function shall be as convenient as enabling it; on exit, stop that function’s collection;
• d) do not frequently re-seek consent where the subject declines or exits a function;
• e) declining/exiting one function shall not suspend or degrade other functions the subject chose;
• f) shall not, on grounds of service improvement, experience, R&D or security, compel consent to collection;
• g) where an extended function uses AI, allow the subject to turn the AI feature off.

6.3　Notice and consent

• a) on collection, inform the subject of the handler’s name and contact, the purpose and means, the categories and retention period, and the ways and procedures to exercise rights, and obtain consent; NOTE 1: a single-function product may notify via the processing rules; a multi-function product should, in addition, notify purpose/means/scope when it actually begins to collect a particular item. NOTE 2: implement per GB/T 42574-2023, Clauses 8 and 9.
• a’) where on-site collection by automated devices occurs without prior consent, use devices with conspicuous form, or voice prompts, signage, indicator lights, etc., so the subject is aware;
• b) biometric-capable devices shall limit the recognition scope to the use scenario, recognizing only authorized users within limits;
• c) before collecting sensitive PI, obtain separate consent, fully informed, specific and clear;
• d) before collecting a minor’s PI: aged 14+, consent of the minor or guardian; under 14, separate consent of a parent/guardian;
• e) for indirect acquisition:
  1. for public-channel collection, follow the provider’s public-information rules;
  2. when buying third-party services, require by contract that the provider be responsible for the source’s lawfulness and for the lawfulness of onward provision; the handler is responsible only for the lawfulness of post- receipt use;
  3. confirm with the provider the lawfulness of the source and of provision;
  4. the provider should pass a third-party legal-compliance assessment or self-assessment before providing.

6.4　Processing rules

• a) formulate processing rules including at least: (1) the handler’s basic details and valid contact; (2) the collecting/using functions and, per function, the purpose, means and categories, permissions called and their frequency, the necessity and impact of sensitive PI (clearly marked/ highlighted); (3) means of collection, retention period, outbound-transfer status; (4) the purpose, categories, third-party types and respective responsibilities for external provision/transfer/disclosure; (5) for embedded SDKs, a structured list of third-party services/SDK name (package), version, main function, operator, categories collected, and a link to the SDK’s PI rules; (6) the subject’s rights and mechanisms (query, correct, delete, cancel account, withdraw consent, obtain a copy, complain about automated decisions); (7) security risks of providing, and effects of not providing; (8) the principles followed, security capability and protection measures, with compliance proof where appropriate; (9) channels for inquiries/complaints and external dispute resolution.
• b) the rules shall be true, accurate and complete;
• c) clear, plain and standardized, avoiding ambiguity;
• d) published and easily accessible (e.g., prominent links on the homepage, app install page, interface);
• e) delivered to each subject; where cost is excessive or there is significant difficulty, may be published by announcement; NOTE 1: a consumer internet app should, on first launch, notify collection/use rules prominently (e.g., pop-up) and obtain the user’s clear agreement.
• f) update promptly and re-notify when items in (a) change; NOTE 2–5: omitted (naming, cross-references to GB/T 44588-2024, multi-product consistency).
• g) a smart terminal’s rules shall be conveniently queryable online or via the manual;
• h) keep historical versions of the rules available.

6.5　Exceptions to consent

Where another lawful basis under 5.3–5.8 exists, a handler need not obtain the subject’s consent to collect.

6.6　Collection of sensitive personal information

Before collecting sensitive PI, in addition to the above, comply with the sensitive-PI collection requirements in GB/T 45574-2025, Clauses 5 and 6.

6.7　Collection by AI products or services

• a) where an AI product/service offers deep-synthesis features that edit biometrics such as face/voice, prominently prompt the subject and obtain separate consent;
• b) where it uses PI for pre-training/optimization training, prominently notify the purpose, means and scope of impact and obtain consent; where law requires separate consent, obtain it; refusal shall not affect the basic function’s normal use; provide a way to withdraw consent;
• c) where it calls other services:
  1. same provider: consent may be obtained directly via the AI interface;
  2. third-party provider: determine the processing relationship and each party’s liability by scenario (see the forthcoming “Security guide for data provision, entrusted processing and joint processing”); the other-service handler shall obtain the subject’s consent when first providing.

6.8　Collection by terminal products or services

• a) for products with no/limited UI (smart cameras, locks, speakers, watches, bands, etc.): if there is a companion app/web page, present the processing rules prominently (e.g., pop-up) before first use and guide the user to read; if not, present them offline via the user manual;
• b) set prominent signage in public areas with image-collection devices, informing subjects that video/image collection is underway;
• c) where, in using a smart terminal, non-essential PI is collected or consent is not obtained, promptly delete or anonymize it.

7　Storage of personal information

7.1　Minimizing storage time

• a) the retention period shall be the shortest necessary; dynamically assess and adjust it on changes to purpose, business need or law; on achievement or impossibility of the purpose, promptly delete or anonymize;
• b) beyond the 7.1(a) period, delete or anonymize;
• c) electronic products storing PI shall support cyclic overwrite, formatting and controlled deletion, meeting GB 46864-2025.

7.2　De-identification

After collection, before statistics, academic research, disclosure or use beyond the original purpose, de-identify in time to reduce direct/indirect re- identification risk:

• a) establish a standard process (set the target, identify identifiers, choose techniques, implement, validate);
• b) choose appropriate techniques by data type, scenario and security need;
• c) weigh impact on usability/analytical value and resistance to attack;
• d) systematically evaluate the result against the de-identification target;
• e) judge whether re-identification risk is acceptable; if it exceeds the threshold, re-select/combine techniques and re-evaluate until acceptable; document the process and result;
• f) store recovery information (keys, mapping tables) separately from de- identified data, with strict, minimum-necessary access control and full logging/audit;
• g) keep complete records (datasets, techniques and parameters, time, operator, evaluation report, changes);
• h) periodically internally audit effectiveness and rectify findings, retaining records.

7.3　Transmission and storage of sensitive personal information

On the basis of GB/T 45574-2025, 5.5:

• a) use encryption and other security measures when transmitting/storing sensitive PI;
• b) when storing biometrics, secure them first — e.g., store the raw biometric and its digest separately, or collect/store/use only the digest.

7.4　Cessation of operations

On ceasing a product/service: a) stop further collection; b) notify subjects individually or by announcement; c) delete or anonymize the PI held; d) follow law where it provides otherwise.

8　Use of personal information

8.1　Purpose limitation

• a) do not use PI beyond a scope directly or reasonably related to the stated collection purpose; where business genuinely requires going beyond the original purpose/means/scope, re-establish a lawful basis and re-notify; where consent is the basis, re-obtain consent (separate/written where law requires);
• b) information produced by processing that, alone or combined, identifies a person or reflects their activities, is personal information, and its processing follows the consent obtained at collection. NOTE: if such produced information is sensitive PI, comply with GB/T 45574.

8.2　Access controls

• a) least-privilege access — staff access only the minimum PI and operations their duties require;
• b) internal approval for important operations (bulk modify/copy/download);
• c) separation of roles (security manager, data operator, auditor);
• d) over-privilege access for genuine work needs requires approval by the person in charge or working body and recording;
• e) for sensitive-PI access/modification, trigger operation authorization by workflow (e.g., a complaint handler may access only on receiving a complaint).

8.3　Display restrictions

Where PI is displayed via an interface, de-identify to reduce leakage:

• a) public display — show only the minimum fields; de-identify direct identifiers (name, ID number, phone);
• b) display to the subject — de-identify sensitive PI; show the full record only after the subject chooses; by default disable screenshot/screen-recording and copy/print of sensitive data;
• c) internal display — apply de-identification per scenario and PIPIA result.

8.4　Aggregation/fusion of PI collected for different purposes

• a) comply with 8.1;
• b) conduct a PIPIA per the post-aggregation purpose and take effective measures;
• c) before aggregating self-disclosed or lawfully-public PI for model training, review the source and content, assess risk and de-identify;
• d) de-identify directly-identifying PI;
• e) establish a model-output review mechanism to reduce the model outputting — or being induced to output — real, identifiable PI.

8.5　Automated decision-making and AI

8.5.1　Limits on user profiling

• a) feature descriptions shall not: 1) contain obscene, pornographic, gambling, superstitious, terrorist or violent content; 2) express discrimination by ethnicity, race, religion, disability or disease;
• b) in operations or external cooperation, profiling shall not: 1) infringe the lawful rights of citizens, legal persons or others; 2) endanger national security/honor/interests, incite subversion or secession, promote terrorism/ extremism/ethnic hatred, spread violent or pornographic information, or fabricate/spread false information disrupting economic and social order;
• c) except as necessary for the consented purpose, eliminate explicit identity- pointing to avoid precise targeting (e.g., direct profiling for credit evaluation, but indirect profiling for advertising).

8.5.2　Personalized display

• a) where used, clearly distinguish personalized from non-personalized content; NOTE 1: e.g., label it “推荐/定推” (“recommended” / “targeted push”) or use separate columns/sections/pages.
• b) in e-commerce, when showing personalized results by interests/habits, also offer an option not targeted to the consumer’s characteristics; NOTE 2: results based on a chosen location, identical regardless of identity, count as a non-targeted option.
• a’) for news-information push using personalized display: 1) provide a simple, intuitive option to exit/turn off personalization; 2) on exit, offer to delete or anonymize the PI underlying targeted push;
• b’) establish a mechanism for the subject to manage the PI (labels, profile dimensions) on which personalization relies, allowing them to adjust its degree.

8.5.3　Information-system automated decision mechanisms

Where the system has an automated-decision mechanism that can significantly affect the subject (e.g., auto-deciding credit and loan limits, or screening interviewees), comply with GB/T 45392 and:

• a) ensure decision transparency and fairness; no unreasonable differential treatment on price or other terms;
• b) conduct a PIPIA at the design stage or before first use, and take effective protective measures;
• c) conduct periodic PIPIAs during use and improve measures;
• d) provide a complaint channel for automated-decision results and conduct human review of them.

8.5.4　Use of generative AI

Where the system accesses an LLM, or uses an LLM-powered agent to process PI, and may materially affect the subject’s rights (e.g., outputting PI):

• a) conduct a PIPIA in advance and periodically, ensuring measures match the risk level;
• b) provide a convenient feedback channel for affected subjects to request deletion or restriction of output; complete verification and deletion within 15 working days of the request;
• c) establish output-content review and risk-monitoring to reduce improper output;
• d) (recommended) establish an identify-and-filter mechanism for unauthorized or expressly-refused PI in training data, and tune parameters to prevent its output.

8.6　Use of a unified account system

• a) formulate dedicated processing rules, and in each product’s rules inform the subject of the categories, purposes and means of the linked PI; clearly mark/ highlight sensitive PI and inter-account provision;
• b) PI collected by each product under the unified account should be stored separately;
• c) provide per-product query/copy/modify capability or entry;
• d) reasonably explain on a subject’s challenge to the linked display/processing;
• e) besides cancelling the unified account, provide ways to delete a single product’s data or cancel a single product’s account;
• f) deleting one product’s data shall not affect retention of other data under the unified account;
• g) providing PI between two or more accounts follows the Clause 4 principles; beyond the original scope or with a changed purpose, obtain consent per 6.3;
• h) periodically review inter-account provision and adjust the use strategy.

9　Rights of the personal information subject

9.1　Access (query)

Provide methods for the subject to query: a) the PI (or its types) held about them; b) its source and purpose; c) the identity/type of third parties that have obtained it. NOTE: for queries about PI the subject did not actively provide, the handler may decide whether to respond after weighing risk/harm, technical feasibility and cost, with an explanation.

9.2　Correction

A subject finding their PI inaccurate/incomplete may request correction. On request, verify the source; if an error/incompleteness is confirmed, correct/ supplement promptly; if unable to verify, inform the reason. The subject shall provide accurate correction information and proof; the handler shall complete correction within 15 working days and inform the result.

9.3　Deletion

• a) promptly delete on request where: 1) the purpose is achieved/unachievable/no longer necessary; 2) the product/service ceases, or the period expires; 3) consent is withdrawn; 4) collection/use violated law; 5) collection/use breached the agreement with the subject;
• b) where PI was provided/transferred to a third party in violation of law/ agreement, immediately stop and notify the third party to delete;
• c) where PI was disclosed in violation, immediately stop and notify recipients to delete;
• d) where PI is still needed to serve the subject, explain on a deletion request; if the subject insists, guide them to cancel the product/service;
• e) when deleting, use one or more methods ensuring irrecoverability: 1) clear storage media per GB 46864-2025; 2) for backup/DR/archive data, ensure non- reuse via backup-cycle overwrite, isolation or de-identification; 3) anonymize and evaluate the result.

9.4　Withdrawal of consent

• a) provide a method to withdraw; after withdrawal, do not process the PI until a lawful basis is obtained;
• b) the withdrawal path shall be as convenient as the collection path;
• c) safeguard the right to refuse PI-based advertising; for external provision/ transfer/disclosure, provide a way to withdraw or delete. NOTE: withdrawal does not affect processing carried out before withdrawal.

9.5　Account cancellation

• a) provide a simple cancellation method; b) a convenient interactive cancellation page responding promptly; c) where manual handling is needed, complete within a committed period (≤15 working days); d) identity-verification on cancellation shall not require more PI than registration/use; e) no unreasonable conditions (e.g., cancelling one account forcing cancellation of others, or requiring exact historical records); f) where sensitive PI is collected to verify identity, delete/anonymize it once the purpose is met; g) promptly delete/anonymize PI after cancellation; h)–i) for unified-account integrated management, identify the account provider and its processing purpose/means/scope, and allow cancelling the unified account or closing its use/deleting product-only data to equivalent effect; j) follow law where retention is required.

9.6　Obtaining a copy

On request and after identity verification, provide a copy of, or transmit where technically feasible to a designated third party, in a readable format: a) basic and identity information; b) health/physiological and education/work information.

9.7　Responding to requests

• a) after verifying identity, respond to 9.1–9.6 requests within 15 working days (or the statutory period), with a reasonable explanation, and inform of external dispute resolution;
• b) set dedicated functions in the interface for online exercise of rights;
• c) where direct fulfillment is costly or difficult, provide an alternative;
• d) a request under 9.1–9.6 need not be honored where it: 1) relates to the handler’s statutory obligations; 2) directly concerns national/defense security; 3) directly concerns public security/health or major public interest; 4) directly concerns criminal investigation/prosecution/trial/ enforcement; 5) the subject is shown to be acting in bad faith or abusing rights; 6) protects life/property of the subject or others where consent is hard to obtain; 7) would seriously harm the lawful rights of the subject or others; 8) the information’s scope/setting is private;
• e) if declining, inform the reason and provide a complaint channel;
• f) on a natural person’s death, close relatives may, for their lawful interests, exercise access/copy/correction/deletion over the deceased’s PI (unless the deceased arranged otherwise), providing death and kinship proof; respond within 15 working days or inform of the delay.

9.8　Complaint management

Establish a complaint-management mechanism and tracking process, responding within a reasonable time.

10　Entrusted processing, provision, transfer and disclosure

10.1　Entrusted processing

• a) entrustment shall not exceed the consented scope (or comply with 6.5);
• b) conduct a PIPIA and ensure the entrusted party meets the 13.6 data-security capability;
• c) the entrusted party shall: 1) process strictly as required, feeding back if unable for special reasons; 2) not sub-entrust without prior authorization, and notify on changes; 3) assist in responding to 9.1–9.6 requests; 4) feed back inability to protect or any incident; 5) delete/anonymize on termination;
• d) supervise the entrusted party (by contract; by inspection);
• e) accurately record and store the entrustment;
• f) on discovering non-compliant processing or failure to protect, immediately require cessation and remediation (change passwords, revoke permissions, disconnect), terminating the relationship and requiring deletion if needed.

10.2　Provision

Provision (other than for M&A/bankruptcy) requires: a) prior PIPIA and effective measures; b) where consent is the basis, inform the purpose, recipient, contact, means, categories and consequences, and obtain separate consent (unless de-identified so the recipient cannot re-identify); c) the recipient processes only within that scope and re-obtains consent per 6.3 on change; d) fix the recipient’s duties by contract; e) accurately record provision (date, scale, purpose, recipient); f) bear liability for harm from an incident; g) on the recipient’s violation, require cessation/remediation and, if needed, terminate and require deletion.

10.3　Transfer on M&A/reorganization/bankruptcy

a) inform subjects; b) the successor continues the original duties, re-obtaining explicit consent on a purpose change; c) on bankruptcy with no successor, delete or anonymize.

10.4　Public disclosure

PI should not, in principle, be disclosed. Where lawful or with reasonable grounds: a) prior PIPIA and measures; b) inform purpose and categories and obtain separate consent; c) for sensitive PI, additionally give a prominent notice of the sensitive content; d) record disclosure (date, scale, purpose, scope); e) bear liability for harm; f) do not disclose biometrics; g) do not disclose analysis results of PRC citizens’ race, ethnicity, political views, religion, etc.

10.5　Other lawful grounds for provision/transfer/disclosure

No prior consent is needed where it: a) relates to statutory obligations; b) directly concerns national/defense security; c) directly concerns public security/health/major public interest; d) directly concerns criminal justice; e) protects major life/property interests where consent is hard to obtain; f) concerns PI the subject disclosed to the public themselves; g) is collected from lawfully-public sources (lawful news reporting, government disclosure).

10.6　Joint handlers

a) state joint processing in the processing rules; b) where the handler and a third party are joint handlers, jointly fix the security requirements and respective duties by contract and clearly inform subjects; c) failing clear notice of the third party’s identity and respective duties, the handler bears the security liability arising from the third party. NOTE: where a handler deploys a third-party PI-collecting plugin (analytics, SDK, map API) and that third party did not separately obtain consent, they are joint handlers at the collection stage.

10.7　Third-party access management

Where a third-party PI-collecting product/service is integrated and 10.1/10.5/ 10.6 do not apply: a) establish access management and workflow, with security assessment/access conditions as needed; b) fix security duties by contract; c) clearly mark that the third party provides it; d) keep access contracts and records available; e) require the third party to obtain consent per this standard and verify how; f) require the third party to have a rights-response/ complaint mechanism and keep it updated; g) urge the third party to strengthen security, rectifying or cutting off access on failure; h) for embedded/accessed automated tools (code, scripts, interfaces, models, SDKs, mini-programs):

1. technically test that collection meets the agreement; 2) inspect collection and cut off access on out-of-scope behavior.

10.8　Cross-border transmission

Where PI collected/produced in PRC operations is provided abroad, comply with relevant laws, administrative regulations, departmental rules and mandatory national standards, strengthen outbound technical/management measures, and guard against and dispose of unlawful-outbound risks.

11　Overseas legal-jurisdiction determination and conflict handling

11.1　Jurisdiction determination

11.1.1　Determination factors

Where processing involves overseas subjects, overseas entities, overseas storage/compute, overseas placement/monitoring, provision abroad, or may trigger foreign extraterritorial application, the handler shall determine the target jurisdiction, with factors including at least:

• a) territorial — where key processing occurs (collection, storage, use, provision), local entity/employees, the billing locale of the data center/ cloud;
• b) effects — whether it intentionally targets the jurisdiction’s subjects (local language, currency, delivery promises, local advertising/after-sales, continuous tracking);
• c) personal — the establishment/operation links between the handler (or its controlled overseas entity) and companies in the jurisdiction;
• d) sector-specific rules — extraterritorial provisions for finance, telecom, commercial transactions, etc.

11.1.2　Comprehensive determination and recording

Where territorial, effects and personal factors coexist, identify the relevant factors per local law, weigh them as needed, and produce a written analysis as a precondition to the processing record and PIPIA and a go-live gate.

11.1.3　Exclusions

Unless local law expressly provides, do not deny a target jurisdiction’s extraterritorial application solely on the ground of “no local entity” or “no direct consideration charged.”

11.2　Conflict identification and layered handling

11.2.1　Conflict types

Identify at least: a) direct-opposition (one jurisdiction compels transfer/ provision while another bans outbound/restricts it); b) standard-inconsistency (differences in sensitive-data definition, consent threshold, cross-border mechanism, evidencing); c) procedural-difference (reporting deadlines, local representative/agent, filing/registration).

11.2.2　Priority and measures

After identifying a conflict: a) without violating PRC law, administrative regulations or competent-authority requirements, follow this order: prioritize local mandatory norms; where local norms are unclear, prioritize norms posing a significant penalty/injunction risk; if neither applies, resolve via contract or industry self-discipline; if still unclear, reference international standards or best practice. b) consider measures: 1) regional differentiation/isolation (localize processing, aggregate after local processing, avoid unnecessary transfer); 2) minimization/de-identification; 3) mechanism substitution and multi-track (select applicable cross-border mechanisms per jurisdiction with supplementary measures); 4) government-request response (legality review, scope minimization, partner/subject notice, remedies); 5) third-party risk management (assess SDK/API providers, audit and monitor); 6) transparency (publish transparency reports); 7) compliance-evidence retention (a cross-border compliance ledger recording the full identification/assessment/handling process).

11.3　Compliance process and proof

• 11.3.1 Special assessment — for first entry to a jurisdiction, a material change, or new external provision/monitoring, complete an integrated assessment of jurisdiction, conflict identification and a cross-border adaptation plan before go-live, included in the PIPIA report.
• 11.3.2 Records and consistency — keep the lawful basis, jurisdiction determination, cross-border mechanism, supplementary measures and government- request strategy structured and versioned in the processing record, consistent with the rules and contracts.
• 11.3.3 Assessment and monitoring — periodically assess key activities; assess high-risk cross-border activities at least annually, and re-assess/rectify on changes to the jurisdiction’s rules or enforcement.

11.4　Organization and responsibilities

a) designate a cross-border compliance lead, fixing legal/data/security duties and a processing record (jurisdiction, business, data, mechanism, evidence); b) for third parties/SDKs/ad networks, implement access management, contractual control and audit, terminating access on out-of-scope processing; c) establish a government-request response mechanism and transparency reporting, retaining legal basis, request scope, response decision and technical-handling evidence.

12　Handling personal information security incidents

12.1　Emergency handling and reporting

a) formulate an incident contingency plan; b) train and drill at least annually; c) on an incident, per the plan: 1) record the incident (discoverer, time, place; PI and number of people; system; impact on connected systems; whether authorities were contacted); 2) assess impact and take control measures; 3) report timely per cybersecurity-incident law (types/number/content/nature of subjects; impact; measures taken/planned; contacts); 4) where it may seriously harm subjects (e.g., sensitive-PI leakage), notify per 12.2; d) update the plan per legal changes and incident experience.

12.2　Notification

a) promptly notify affected subjects by email, letter, phone, push, etc.; where individual notice is hard, issue an effective public warning; b) notify at least: 1) the incident’s content and impact; 2) measures taken/planned; 3) self- protection advice; 4) remedies offered; 5) the person in charge’s / working body’s contacts.

13　Organizational management requirements

13.1　Person in charge of personal information protection

• a) an organization meeting any of the following shall designate a person in charge to supervise processing and protection: 1) it is a large network platform; 2) its main business involves PI processing with >200 relevant staff; 3) it processes

  1,000,000 persons’ PI; 4) it processes >100,000 persons’ sensitive PI. NOTE 1: a “large network platform” has ≥50 million registered or ≥10 million monthly-active users, complex business, and data activities significantly affecting national security, the economy or livelihood. NOTE 2: simple processing (e.g., HR-archive keeping) may be excluded.

• b) a large platform’s person in charge must meet legal/regulatory conditions; other handlers’ person in charge should be the legal representative or principal, with expertise, experience, coordination ability and independence;
• c) qualifications include: PRC nationality; no criminal/serious-dishonesty record affecting independence; a legally effective employment/appointment agreement; PI expertise and management experience; familiarity with the handler’s structure, equity, core business and PI systems; strong analysis, writing and coordination skills;
• d) duties include: overall implementation and direct responsibility for PI protection; making and implementing the protection plan; formulating/issuing the processing rules and protocols; responsibility for PIPIA and compliance audit; communication/reporting; confidentiality; supporting investigations and proposing improvements;
• e) powers/duties include: participate in major decisions and report directly to the principal; authority to coordinate departments; the right to give opinions before major decisions; the right to stop non-compliant operations and take corrective measures; propose suggestions; provide training resources; attend training;
• f) no fixed term; on replacement, fill the role within 30 working days with a person meeting 13.1(a)–(d);
• g) the handler shall guarantee resources for the person in charge (leadership responsibility of the legal rep/principal; resources for independent performance; timely involvement in all PI matters; direct reporting);
• h) ensure independence: no instruction/interference in duties; no dismissal/ penalty for lawful performance; direct accountability to the top body; no conflicting concurrent posts;
• i) organizations not required to appoint a person in charge may follow 13.1(b)–(h).

13.2　personal information protection working body and personnel

• a) the legal rep/principal bears overall leadership responsibility, providing resources;
• b) establish a personal information protection management structure and working body; allocate per-department staff reasonably and encourage specialized training;
• c) an organization meeting any of the following shall set up a dedicated working body: 1) large network platform; 2) main business involves PI processing with >200 staff; 3) processes >1,000,000 persons’ PI, or is expected to within 12 months; 4) processes >100,000 persons’ sensitive PI;
• d) duties include: making/implementing/updating rules; maintaining the PI inventory and access policy; conducting PIPIAs and urging rectification; training; pre-launch testing to avoid unknown collection/use/provision; publishing and handling complaints; periodic compliance audit; communicating with authorities;
• e) personnel receive periodic training.

13.3　PI-security engineering

When developing PI-processing products/services, follow GB/T 41817 to consider protection across requirements, design, development, testing and release — planning, building and using protection measures in step.

13.4　Records of processing activities

• 13.4.1 General — records cover the full lifecycle and are true, accurate, complete and timely, achieving traceability, auditability and provability.
• 13.4.2 Scope — maintain records where: a) processing sensitive PI; b) automated decision-making; c) entrusting, providing to other handlers, or disclosing; d) providing abroad; e) material change of purpose/means/type/scenario; f) internal access/copying; g) other activities with major impact on rights.
• 13.4.3 Content — at least: a) handler name/contact; b) categories, purpose, means, lawful basis and retention; c) for external provision, recipient name/ contact/purpose; d) for outbound, categories/purpose/means, recipient country, recipient name/contact, mechanism (assessment/certification/SCC) and filing; e) summary of security measures; f) for sensitive PI, the specific categories and necessity result; g) for automated decisions/profiling, the logic, algorithm/model type and version, fairness/transparency safeguards and appeal channel; h) for entrustment, party name/contact, contract no., supervision/ audit arrangements and deletion; i) for disclosure, date/scale/purpose/scope/ channel/frequency; j) rights-exercise channels and complaint records; k) PIPIA report, conclusion and risk measures; l) incidents and handling; m) approval records; n) operator name/role/contact; o) historical versions of the rules.
• 13.4.4 Maintenance — assign a responsible person; update before changes take effect; review at least annually (semi-annually for high-risk activities).
• 13.4.5 Retention — keep current and historical versions at least three years (or as law provides).
• 13.4.6 Availability — keep records electronic, structured and machine-readable, producible on regulatory inspection or subject request.

13.5　Personal information protection impact assessment

• 13.5.1 General — establish a PIPIA system based on 13.4 records, making the PIPIA a precondition for launch, material change and termination, forming a verifiable, traceable, auditable evidence chain.
• 13.5.2 Content — at least: a) lawfulness (basis under Clause 5); b) legitimacy (clear purpose, no misleading/inducement, value to the subject, consistency with public order/morals, no conflict of legitimate interests with rights); c) necessity (direct relation, only necessary PI, least-impact means); d) risk- source analysis (environment, technical measures, process compliance, personnel, third parties, management, business features/scale/posture); e) rights-impact analysis (autonomy, differential treatment, reputation/mental distress, personal/property safety); f) comprehensive risk analysis.
• 13.5.3 Scenarios requiring a prior PIPIA: a) sensitive PI; b) automated decision- making; c) entrusting/providing/disclosing; d) providing abroad; e) before a product launch or major function change; f) on legal/regulatory change; g) on major change to business model/system/environment; h) on a major incident or warning. Where (a)–(d) already exist without a prior PIPIA, assess promptly.
• 13.5.4 Management — a) the person in charge or working body identifies activities to assess, plans assessments, and supervises; b) plan and assess per GB/T 39335; c) ensure independence/objectivity/expertise — large platforms and important activities should commission a third-party PIPIA; NOTE 1: “important processing activities” include processing 10,000,000 persons’ PI, providing 100,000 persons’ PI to a third party, processing 100,000 persons’ sensitive PI, processing 10,000 minors’ PI, or providing 10,000 persons’ PI abroad. d) on serious/high risk, propose targeted improvements and urge them; e) produce a PIPIA report — the person in charge or working body may approve launch/change/continuation only where measures match the risk (low, or medium with a clear improvement/ supervision plan); f) review effective conclusions at least annually, and immediately on 13.5.3(f)–(g); g) conclusions take effect on person in charge / authorized approval; h) keep the report and evidence at least three years, available, and publish in suitable form for wide-impact/high-attention activities; i) file the sealed report where required; j) use tooling and keep materials electronic/ structured for timely retrieval.

13.6　Data-security capability

Per relevant national standards, build appropriate data-security capability to prevent leakage, damage, loss and tampering. Handlers processing sensitive PI should meet GB/T 37988 level-3 or above.

13.7　Personnel management and training

a) sign confidentiality agreements with PI-processing staff, and background- check those with extensive sensitive-PI access; b) define security duties per post and a penalty mechanism; c) require continued confidentiality on transfer/termination; d) define requirements for external service personnel who may access PI, with confidentiality agreements and supervision; e) establish guidance for special posts (person in charge, legal, compliance, product, R&D, testing) on launch; f) train and assess PI-processing staff at least annually or on major legal change.

13.8　Personal information protection compliance audit

Conduct compliance audits per GB/T 46903-2025, across five stages (preparation, implementation, reporting, rectification, archiving):

• a) periodically audit compliance per law (frequency per GB/T 46903-2025);
• b) ensure audit evidence is true, complete and valid;
• c) handlers providing important Internet platform services, with huge user numbers and complex business, shall set up an independent body composed mainly of external members to supervise the audit;
• d) establish an audit management system (personnel, methods, basis, scope, frequency; auditor duties/powers);
• e) ensure necessary resources and authority (budget, staffing, facilities);
• f) ensure independence — auditors do not manage/decide on the audited object; the report should go directly to the board or security-compliance committee; self-audits via an independent unit or virtual team of non-involved professionals;
• g) build an audit-evidence system (management system, technical measures, processing records, operation logs, supervision records, test reports);
• h) (recommended) build an audit management system to find and close gaps with continuous supervision;
• i) (recommended) use audit tooling to improve efficiency and quality.

Annex A (informative)　Examples of personal information

Annex B (informative)　Determination of sensitive personal information

Footnotes: a — see GB/T 41806. b — see GB/T 41819. c — see GB/T 41807. d — see GB/T 41773. e — basic physique info (weight, height, blood type, blood pressure, lung capacity) may be deemed non-sensitive if unrelated to disease/medical visits. f — location via a device’s precise-location permission is precise location; coarse location estimated from network address is not; continuous precise location can generate whereabouts. g — criminal record means a state organ’s objective record of an offender (charge, sentence).

Annex C (informative)　Methods for realizing the subject’s autonomous will

Realizing the subject’s autonomous will has two aspects: not coercing the subject into multiple functions; and safeguarding the subject’s right to know and to authorize. Handlers — especially app operators — may use:

C.1 Distinguishing basic and extended functions. a) define basic functions by the subject’s fundamental expectation and primary need; b) do not treat service improvement, experience or R&D alone as a basic function; c) treat other functions as extended.

C.2 Notice and explicit consent for basic functions. a) before enabling a basic function (install, first use, registration), notify via the interface the categories of PI necessary and the effect of refusal, and obtain explicit consent by an affirmative act; b) if the subject refuses, the handler may decline that function; c) the interface should allow re-access and change of consent scope.

C.3 Notice and explicit consent for extended functions. a) before first use of an extended function, notify each function and the PI necessary, allowing item- by-item consent; b) on refusal, do not repeatedly seek consent (≤ once per 24h unless the subject actively enables it); c) refusal shall not deny or degrade the basic function; d) the interface should allow re-access and change of scope.

Annex D (informative)　Example scenarios of lawful basis

References

The draft cites GB/T 32921—2016, GB/Z 28828—2012, the Cybersecurity Law, NPC Standing Committee decisions on internet security (2000) and network-information protection (2012), the E-Commerce Law, the Telecom-and-Internet PI Protection Provisions (MIIT Order No. 24, 2013), Criminal Law Amendments (VII) and (IX), and international references including ISO/IEC 29100/29101/29134/29151/29184, the EU GDPR, CWA 16113-2012, the EU-U.S. Data Privacy Framework (2023), the OECD Privacy Framework (2013), the APEC Privacy Framework (2005) and the U.S. Consumer Privacy Bill of Rights Act discussion draft (2015).