From Consent to Governance: What the 2026 Draft Revision of GB/T 35273 Changes Against the 2020 Standard

Editor’s Note — DCC.

On June 17, 2026 the National Cybersecurity Standardization Technical Committee (全国网络安全标准化技术委员会, “TC260”), with the China Electronics Standardization Institute (中国电子技术标准化研究院, CESI) as drafting lead, released for public comment a systematic revision of GB/T 35273 — the recommended national standard that has functioned for years as China’s operational benchmark for personal-information protection, and in the pre-PIPL era as a de-facto “small PIPL.” The 2020 edition is in DCC’s law-catalogue entry; the full archived draft text plus the drafting-explanation PDF is in the draft entry. This brief is the structural read of what the draft changes. It is a DCC synthesis of four Chinese-language practitioner readings — He Yuan / DPOHUB (数据法盟), 汉谟法喵, the Zhong Lun data team (中伦数据团队, via TMT 法律论坛), and HexCode (数据何规) — cross-checked against the consultation text and its drafting explanation. Clause numbers are from the comment draft and are not final (the commentators already flag at least one cross-reference slip, on “separate consent”); formal release is expected after 2027.

The one-line thesis

The headline is not how many articles were added. It is that the standard’s role changed. GB/T 35273-2020 gave personal-information handlers an operable manual centered on the privacy policy and notice-and-consent. The 2026 draft tries to wire law, business process, algorithmic products, cross-border scenarios, management responsibility and audit evidence into a single net.

The 2020 standard answered “how do I collect and notify properly?” The 2026 draft answers “can you prove, on demand, why every processing activity is lawful — and who is accountable when it is not?”

Three vectors run through every change:

• From consent management to governance capability. A privacy policy plus a ticked box is no longer a processing basis. Each activity must state why it may be processed, on a verifiable, traceable, auditable evidence chain.
• From point-in-time compliance to a continuous, provable system. Processing records, impact assessment, compliance audit and incident response are expected to form a standing loop, not a one-off remediation project produced the week before an inspection.
• From domestic governance to global compliance coordination. A wholly new chapter asks outbound operators to map foreign extraterritorial reach and to have a conflict-handling mechanism ready.

Two surface signals telegraph the shift before you reach a single requirement: the title moves from “Information Security Technology” (信息安全技术) to “Data Security Technology” (数据安全技术), and the normative-reference list grows from one referenced standard to six published plus two forthcoming.

What changed against the 2020 standard — the annotated map

The increments sit in nine columns. The right-hand column is the draft’s new position; treat it as the change to highlight, not the settled rule.

The sections below annotate each increment.

1. A new Chapter 5 — lawful basis becomes the spine (新增专章)

The single most structural change. The 2020 edition treated consent as the absolute core with a short list of exceptions. The draft adds Chapter 5, “Lawful Basis and Compliance Requirements for Personal-Information Processing” (个人信息处理的合法性基础与合规要求, nine clauses), importing PIPL Article 13’s seven bases as parallel tracks — consent is now just one of them — and giving each track an explicit prohibition boundary:

• Consent (5.2) — pre-processing notice, affirmative act. Prohibits pre-ticking, default consent, passive consent, and consent forced as the price of continued use.
• Contract necessity (5.3) — limited to the core contract purpose. Expressly excludes personalized advertising, out-of-scope behavioral analysis, and non-essential profiling. The commentators read this as close to the GDPR strict reading of “necessary for performance of a contract,” and as materially shrinking the room to use “contract necessity” to escape consent.
• HR / labor management (5.4) — only attendance, performance, pay, benefits and labor-dispute handling. Excludes employee profiling, marketing, and monitoring unrelated to labor management.
• Legal duty (5.5) — must point to a specific obligation in law, an administrative regulation, or a normative document; a handler may not self-expand under “other circumstances.”
• Public health / emergency (5.6) — only genuine emergencies protecting life, health or major property; routine processing may not borrow it.
• Processing already-public information within a reasonable scope (5.8) — tied to the original purpose of disclosure. Prohibits profiling, marketing, and bulk scraping that bypasses technical limits.

Two cross-cutting duties anchor the chapter. Under 5.1, a handler must identify and record the lawful basis before processing, forming a verifiable, traceable, auditable evidence chain; a basis, once chosen, may not be changed to evade obligations; the basis must stay consistent with the notice, the processing-activity record, the impact assessment and the audit; and where multiple bases are available, the handler should pick the one less intrusive on individual rights. A new Annex D supplies worked lawful-basis scenarios — e-commerce, flight booking, online medical, employee attendance, cybersecurity obligations, epidemic control, news reporting, academic research, and large-model training.

DCC read. The operational artifact this forces is not a better consent log but a lawful-basis matrix: for every data category × purpose × method × recipient × cross-border leg, what is the basis, why is it necessary, is it still valid, and does a business change require re-assessment.

2. Sensitive PI redefined + an aggregation rule

The 3.2 definition is realigned to PIPL Article 28 — “liable to harm the dignity of a natural person or endanger personal or property safety” (容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害), replacing the 2020 “extremely likely to harm reputation, physical-mental health, or cause discriminatory treatment.” The enumeration shifts from named fields (bank account, communication records) to risk-feature categories — biometrics, religious belief, specific identity, medical health, financial account, whereabouts/location track — plus under-14 minors; religious belief and specific identity are added.

The rule to highlight is 3.2 note 3: where multiple PI items, once aggregated, meet the sensitive-PI threshold, the aggregated whole must be identified and protected as sensitive PI. This breaks the old field-by-field test. A device ID, a location trail, a set of browsing or transaction fragments may each be low-risk alone, yet cross-referenced may infer health, occupation, household structure or financial capacity. Annex B is expanded with “specific-identity information” and “other sensitive PI” categories and footnotes (a–g) referencing the biometric special standards (GB/T 41806, 41819, 41807, 41773), precise-location data, criminal records, and ID-card photographs.

A formal “separate consent” (单独同意) term enters at 3.7 — specific, concrete, affirmative; not a one-time authorization spanning multiple purposes or methods — with a negative list (default, passive, pre-ticked, forced-via-continued-use are all invalid) and a strengthened withdrawal duty (convenient withdrawal path; immediate cessation; synchronized termination of any third-party provision; retain evidence of content, time, method, and the withdrawal trace). Scenarios requiring separate consent include: collecting sensitive PI (5.2a, 6.3c); under-14 minors via guardian (5.2b); providing PI to a third party (10.2b); public disclosure (10.4b); AI face/voice deep-synthesis (6.7a); and PI used for AI pre-training/optimization where law requires it (6.7b).

Draft caveat. He Yuan flags a cross-reference slip — the preface’s revision list labels “separate consent” as 3.8 while the body places it at 3.7. A reminder that this is a comment draft to be reconciled, not a finished text.

3. A new eighth principle — “quality assurance” (保证质量)

Chapter 4’s basic principles go from seven to eight. The new item 4(f), “quality assurance,” sits alongside minimum-necessity and security: through prompting, verification and checking, ensure the authenticity and accuracy of collected PI; on discovering an error, timely notify the subject and provide a correction channel; and avoid decision bias or rights harm caused by inaccurate data (two other principles are renamed — “choice consent” → “authorization consent,” “subject participation” → “rights protection”). It echoes PIPL Article 8, and pairs with 9.2’s subject correction right (now a 15-working-day completion window).

DCC read. This quietly promotes data quality from an operations/ML concern to a personal-information-protection obligation. In credit scoring, hiring screens, insurance pricing and fraud control, “inaccurate,” “incomplete” or “stale” data can cause real rights harm — so the standard now puts a verifiable correction loop on the protection side of the ledger.

4. AI and generative AI — the most current-affairs-driven additions

The draft builds an end-to-end AI lane across four locations:

• Collection (6.7). Deep-synthesis features that edit face/voice → separate consent (6.7a). Using PI for pre-training / optimization training → prominent notice + consent, separate consent where law requires it; refusal must not disable basic functions; provide a withdrawal path (6.7b). AI extension functions must be switchable off (6.2g).
• Minimum-necessity (6.1 d–f). Training-data pre-processing and model training are held to the minimum necessary with effective security measures (6.1d); an input-side reminder/filter mechanism should screen out non-essential sensitive PI (6.1e) — e.g., prompting “mind the privacy risk; enter sensitive personal information with care” (6.1 note 3).
• Aggregation / training (8.4). Before aggregating already-public data for training, review the source and content, run a risk assessment, and de-identify (8.4c); build a model-output review mechanism to reduce the risk that the model is induced to output real, identifiable PI (8.4e). HexCode reads 8.4e as a direct response to the Kimi incident — a user translating a slide deck reportedly received a stranger’s complete résumé (name, phone, work history), explained away as “AI hallucination.”
• Generative-AI use (new 8.5.4). Where an information system accesses an LLM or uses an agent to process PI and may materially affect subject rights (e.g., outputs PI): run a personal information protection impact assessment (PIPIA) in advance and periodically; provide a convenient feedback channel and, on a deletion/restriction request, complete within 15 working days; build output-content review and risk monitoring; and (recommended) an identify-and-filter mechanism for unauthorized or expressly-refused PI, tuning parameters to prevent its output (8.5.4 a–d). Practitioners note the overlap with LLM and algorithm-filing practice.

5. A unified-account clause (8.6) aimed at one-account-many-products groups

New 8.6, “Use of a unified account system,” targets a specific structure: a unified account offered across non-equity-affiliated entities within the same group (defined at 3.19) — the “one login, many products” ecosystem. Eight requirements, the load-bearing ones being: a dedicated processing rule that discloses, in each product’s rules, the linked information types, purposes and methods, with sensitive PI and inter-account data provision marked or highlighted (8.6a); PI collected by each product should be stored separately (8.6b); a per-product query/copy/modify entry (8.6c); a path to delete one product’s data or cancel one product’s account without affecting the others (8.6e–f); providing PI between two or more accounts follows the basic principles, and going beyond the original scope or changing the purpose requires fresh consent (8.6g); and a periodic review of inter-account data flows (8.6h).

DCC read. Group-wide membership systems, loyalty/points programs, and the group “data mid-platform” become flagged high-risk zones. One account logging into many services is not, by itself, a justification for different legal entities to share, analyze and reuse the same individual’s PI. HexCode notes the draft stops short of banning unified accounts but insists on clear disclosure and single-product cancellation.

6. A terminal / IoT collection clause (6.8)

New 6.8, “Collection by terminal products or services,” addresses devices with no or limited UI — smart cameras, locks, speakers, watches, bands — and public-area image capture. Where a companion app or web page exists, the processing rules must be shown before first use via a prominent pop-up; absent one, via the user manual or other offline means (6.8a). Public-area image-collection devices need prominent notice signage (6.8b). Non-essential PI collected, or PI collected without consent, must be deleted or anonymized promptly (6.8c). Relatedly, electronic products that store PI must support cyclic-overwrite / format / controlled-delete clearing per GB 46864-2025 (7.1c).

7. A wholly new Chapter 11 — overseas jurisdiction and conflict handling

The most forward-looking addition, and the one outbound operators should read first. Chapter 11 sets out jurisdiction determination (11.1), conflict identification and layered handling (11.2), compliance process and proof (11.3), and organization and responsibility (11.4). Its design:

• A four-factor jurisdiction framework — territorial / effects / personal / sector-specific (11.1.1).
• A layered conflict-handling priority (11.2.2): under the premise of not violating PRC law, administrative regulations, or competent-authority requirements, prioritize local mandatory norms; then norms posing a significant penalty/injunction risk; then resolve via contract or industry self-discipline; and finally reference international standards or best practice.
• A caution that extraterritorial reach may not be denied solely because there is “no local entity” or “no direct consideration charged” (11.1.3).
• Guidance on government data-request response, transparency, and third-party risk, with structured, versioned records, re-assessment when target-country law or enforcement shifts, and at least annual assessment for high-risk cross-border processing.

DCC read. Outbound compliance moves from “can the data leave China?” to “who will regulate it abroad, and what do we do when regimes conflict?” — i.e., from a filing exercise to a standing governance function. The connecting factors the draft lists (operating locale, local entity and staff, where compute/cloud is billed, use of local language/currency, local advertising and after-sales, continuous local tracking) are the same factors overseas counsel already use to assess GDPR-style extraterritorial exposure.

8. A systematized internal-control chapter (13)

The draft hardens organizational accountability:

• Person in charge of personal information protection — four appointment triggers: a large network platform; a business centered on PI processing with >200 relevant staff; processing >1,000,000 persons’ PI (with a new “expected to within 12 months” limb); or processing >100,000 persons’ sensitive PI. The officer gets qualification, duty, power and independence detail (participate in major decisions, report directly to top management, propose rectification / cessation of unlawful processing), aligned to PIPL Article 52 and the Network Data Regulation. The same thresholds trigger a dedicated working body.
• Compliance audit (13.8) — conducted per GB/T 46903-2025 across five stages (prepare, implement, report, rectify, archive); for important internet platforms, an independent body composed mainly of external members supervises the audit — pairing with the PI Protection Compliance Audit Measures.
• Processing-activity records (13.4) — seven trigger circumstances, fifteen content items, ≥3-year retention, kept electronic, structured and machine-readable, and producible to regulators on demand.
• Impact assessment (13.5) — a pre-condition for launch, major change and termination; eight scenarios require a prior PIPIA; and quantitative thresholds mark an “important processing activity” for which a third-party PIPIA is recommended (processing 10M persons’ PI; providing 100k to a third party; processing 100k sensitive PI; processing 10k minors’ PI; or providing 10k abroad).

9. Subject-rights timing and storage-chapter detail

Response time tightens from 30 days to 15 working days across the rights and AI-deletion provisions. The storage chapter (Ch.7) also gets more operational: de-identification now expects a systematic re-identification risk assessment plus a complete process record; derived personal information is itself PI, subject to notice-and-consent; and access controls get granular (mask name/ID/phone; default-off screenshot/screen-recording). HexCode — annotating from practice — flags several of these as hard to implement (e.g., an app cannot truly prevent screen capture; a “technically-hard-to-delete” carve-out from PIPL should arguably be restated to avoid a one-size-fits-all “you can only delete” reading) — useful texture on which clauses may move before the standard is finalized.

What overseas counsel should do with the comment window

The draft is non-binding and not final, which is exactly why it is the low-cost window to rebuild the base before AI training, unified accounts, terminal collection, cross-border operation and automated decisioning are deeper in the product. Concretely:

• Build the processing-activity panorama first. By product line, user group, data type, purpose, method, recipient, retention, storage location and cross-border leg. Without this map, lawful basis, PIPIA, audit and cross-border management have nothing to attach to.
• Stand up a lawful-basis matrix, not a better consent log. Re-classify each activity to its best basis; reserve consent for what genuinely needs it; and isolate every separate-consent trigger (sensitive PI, minors, third-party provision, public disclosure, deep-synthesis, qualifying AI training) into its own interaction with retained evidence.
• Re-identify sensitive PI by scenario, not by field. Move from a “sensitive-field list” to a “sensitive-processing-scenario list,” focused on profiling, model training and risk-scoring where aggregation can tip an otherwise-ordinary dataset over the line.
• Give AI its own data-governance rulebook. Training-source whitelist, pre-training de-identification standard, input collection/retention rules, optimization boundaries, human review, third-party model calls, input-filtering, output review, and the user’s off-switch — written down as an input to the PIPIA.
• Map unified-account and terminal/SDK data flows. Confirm which group products share which data, on what basis, with what notice; verify that requested device permissions match actual use; and that single-product cancellation truly leaves the rest intact.
• Treat cross-border as conflict management. Maintain a cross-border matrix (subject locale, processor locale, storage/compute locale, foreign recipients, mechanism, supplementary measures, and a documented government- request response protocol), and re-assess on foreign legal/enforcement change.
• Close the loop on records, PIPIA, audit and incident response. For sensitive PI, automated decisions, entrusted processing, external provision, disclosure, cross-border and major function changes — assess before, log during, review after — and keep it producible on demand.

The 2026 draft does not rewrite what personal-information protection requires so much as it rebuilds how the duty runs — moving the benchmark from a description of good practice into a system a regulator expects you to operate, prove, and be audited against.

— 全国网络安全标准化技术委员会 (TC260), 数据安全技术 个人信息安全规范 （征求意见稿） (Data Security Technology — Personal Information Security Specification, draft for comment), released for public consultation June 17, 2026; drafting lead 中国电子技术标准化研究院 (CESI). Revises GB/T 35273-2020. This brief is a DCC synthesis of four Chinese-language practitioner readings: He Yuan / DPOHUB (数据法盟), “国标35273《个人信息安全规范（征求意见稿）》主要修订了哪些内容？”; 汉谟法喵, “GB/T 35273《数据安全技术 个人信息安全规范》修订草案解读”; 中伦数据团队 (via TMT 法律论坛), “35273修订：《数据安全技术 个人信息安全规范》（征求意见稿）变化解读”; and HexCode / 数据何规, “我的35273修订学习笔记（3）-个人信息存储、使用”. Consultation draft (Chinese).

Not legal advice. The above is DCC’s structural analysis of a draft standard out for public comment. All clause numbers refer to the June 2026 comment draft and are subject to change before formal release (expected after 2027); where the draft and the final text differ, the final text governs.