---
title: "From Consent to Governance: What the 2026 Draft Revision of GB/T 35273 Changes Against the 2020 Standard"
author: "DCC Editorial"
published: 2026-06-23T06:00:00.000Z
url: https://datacompliancechina.com/posts/gbt-35273-2026-revision-from-consent-to-governance/
description: "On June 17, 2026 the National Cybersecurity Standardization Technical Committee (TC260), with CESI as drafting lead, released for public comment a systematic revision of GB/T 35273 — China's most-cited personal-information standard, the de-facto 'small PIPL.' The draft retitles the standard from 'Information Security Technology' to 'Data Security Technology' and expands its normative references from one standard to eight. DCC reads the revision as a role change, not a clause count: the standard moves from a consent-and-notice manual into a governance-capability framework. The substantive increments against GB/T 35273-2020: a new Chapter 5 importing PIPL Article 13's seven lawful bases as a standalone chapter with hard boundaries on each (contract-necessity, HR, public-disclosure) plus an evidence-chain duty; a sensitive-PI redefinition aligned to PIPL Article 28 with a new aggregation rule (multiple items that together meet the threshold are treated as sensitive as a whole); a formal 'separate consent' definition (3.7) with a negative list; a new eighth basic principle, 'quality assurance' (Chapter 4(f)); dedicated AI clauses on the collection side (6.7), in minimum-necessity (6.1 d–f), in aggregation/training (8.4), and a new generative-AI use clause (8.5.4) with output review and a 15-working-day deletion SLA; a unified-account-system clause (8.6) aimed at one-account-many-products groups; a terminal/IoT collection clause (6.8); a wholly new Chapter 11 on overseas-jurisdiction determination and conflict handling; and a systematized internal-control chapter (13) covering the person in charge of personal information protection, working body, processing-activity records, impact assessment, and a GB/T 46903-anchored compliance audit. Subject-rights response time tightens from 30 days to 15 working days. Clause numbers are from the comment draft and are not final; formal release is expected after 2027."
tags: ["gbt-35273", "personal-information", "pipl", "lawful-basis", "sensitive-pi", "separate-consent", "ai-governance", "generative-ai", "cross-border", "unified-account", "iot", "compliance-audit", "tc260", "draft-for-comment"]
laws_cited: ["gbt-35273-2026-draft-pi-security-specification", "gbt-35273-pi-security-specification", "pipl", "dsl", "network-data-security-regulations", "personal-info-audit-measures", "gbt-45574-sensitive-pi-processing-security", "gbt-42460-deidentification-evaluation-guide"]
domains: ["personal-information", "ai-governance", "cross-border", "app-compliance"]
original_title: "数据安全技术 个人信息安全规范（征求意见稿）"
original_author: "全国网络安全标准化技术委员会 (TC260); 中国电子技术标准化研究院 (CESI) — drafting lead"
original_publication: "TC260 public consultation (released June 17, 2026); DCC synthesis of four practitioner readings"
original_url: "https://mp.weixin.qq.com/s/_rWTtpMRTU-SA88NPhQyQQ"
source_language: "zh"
---

> **Source: Data Compliance China** — https://datacompliancechina.com/posts/gbt-35273-2026-revision-from-consent-to-governance/ · China data law, translated and annotated for overseas counsel. Cite as: Data Compliance China, "From Consent to Governance: What the 2026 Draft Revision of GB/T 35273 Changes Against the 2020 Standard", https://datacompliancechina.com/posts/gbt-35273-2026-revision-from-consent-to-governance/
> *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](/laws/gbt-35273-pi-security-specification/);
> the **full archived draft text** plus the drafting-explanation PDF is in
> the [draft entry](/laws/gbt-35273-2026-draft-pi-security-specification/).
> 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.

| Area | GB/T 35273-2020 | 2026 draft revision |
|---|---|---|
| Title / framing | "Information Security Technology" | **"Data Security Technology"**; references 1 → 8 standards |
| Lawful basis | Consent-centric, limited exceptions | **New Chapter 5**: PIPL Art. 13's seven bases as parallel tracks, each with hard boundaries + evidence-chain duty |
| Sensitive PI | "extremely likely to harm reputation / physical-mental health / cause discrimination" | **PIPL Art. 28 wording**; risk-feature categories; **aggregation rule** (3.2 note 3) |
| Consent granularity | Consent / explicit consent, undefined | **"Separate consent" defined (3.7)** + negative list + withdrawal-evidence duty |
| Basic principles | 7 principles | **8 principles** — new **"quality assurance"** (Ch.4(f)); two renamed |
| AI / generative AI | Not addressed | **6.7** (collection), **6.1 d–f** (min-necessity), **8.4** (training), **new 8.5.4** (generative-AI use) |
| Multi-product accounts | Not addressed | **New 8.6** unified-account-system clause (8 requirements) |
| Terminal / IoT | Not addressed | **New 6.8** terminal-collection clause + GB 46864 data-clearing (7.1c) |
| Cross-border | Outbound mechanisms only | **Wholly new Chapter 11** — jurisdiction determination + conflict handling |
| Organization | Person in charge + working body, general | **Ch.13 systematized**: person-in-charge thresholds, working body, records (13.4), PIPIA (13.5), **compliance audit (13.8)** |
| Subject-rights timing | 30 days | **15 working days** |

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](/laws/personal-info-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](/laws/gbt-35273-pi-security-specification/). This brief is a
DCC synthesis of four Chinese-language practitioner readings: He Yuan / DPOHUB
(数据法盟), ["国标35273《个人信息安全规范（征求意见稿）》主要修订了哪些内容？"](https://mp.weixin.qq.com/s/i6sY4yOMUgMyra1b5KkTwQ);
汉谟法喵, ["GB/T 35273《数据安全技术 个人信息安全规范》修订草案解读"](https://mp.weixin.qq.com/s/sJY2ppWf1t796Q0kmjsbVA);
中伦数据团队 (via TMT 法律论坛), ["35273修订：《数据安全技术 个人信息安全规范》（征求意见稿）变化解读"](https://mp.weixin.qq.com/s/n0MgKV-qQvmwPU3kJQ7V8w);
and HexCode / 数据何规, ["我的35273修订学习笔记（3）-个人信息存储、使用"](https://mp.weixin.qq.com/s/pWwSPJyzMo2_QtRJ3-SNgQ).
[Consultation draft (Chinese).](https://mp.weixin.qq.com/s/_rWTtpMRTU-SA88NPhQyQQ)*

*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.*