一、GB/T 35273-2020 第4章 标准原文

二、条款解读说明

2.1 七项原则构成个人信息治理的底层逻辑

很多组织在做个人信息保护时，容易把工作拆成“写隐私政策、上权限、做培训、回用户请求”几个离散动作，但GB/T 35273-2020第4章强调的是一套完整的原则框架。它既要求组织在收集、使用、共享等环节有边界，也要求组织对自己的处理后果负责，并持续让个人信息主体能理解、能选择、能参与。换言之，第4章解决的是“为什么这么做”和“判断是否做对了”的问题。

2.2 七项原则的治理重点并不相同

2.3 第4章对组织提出的是“全生命周期一致性”要求

第4章的价值在于，它不是只约束某一个单点动作。例如，最小必要不仅约束收集环节，也约束展示、共享、导出和保留时间；公开透明不仅要求上线时展示隐私政策，也要求规则变化后及时更新；主体参与不仅要求能接受投诉，更要求组织具备在合理期限内完成核验、处理和答复的能力。真正成熟的组织，不会把这些原则写在制度首页后束之高阁，而会把它们嵌入产品需求、研发评审、合同管理、运营流程和审计机制中。

2.4 原则之间不能互相替代

实践中一个常见误区是“我已经征得同意，所以其他原则都可以弱化”。这是错误的。即便获得了同意，也不能无目的地收集、无上限地保留、无差别地共享，更不能以复杂条款掩盖实际处理行为。选择同意不是万能豁免，公开透明也不等于贴一份说明书，安全能力更不能被“用户已经同意”替代。第4章要求的是原则组合，而不是单一原则背书。

三、实施要点

3.1 建立原则到场景的映射清单

• 将收集、使用、共享、删除、投诉等主要处理场景逐一映射到七项原则。
• 每个场景都要回答目的是什么、依据是什么、最小边界在哪里、用户如何参与。
• 避免只有总制度，没有场景化控制标准。

3.2 把原则要求嵌入产品和流程评审

• 新功能上线前检查是否存在目的模糊、收集过量、默认同意或权利入口缺失的问题。
• 重大变更要复核原始告知和授权范围是否仍然适用。
• 对高风险业务建立个人信息安全影响评估机制。

3.3 建立从制度到系统的双层控制

• 制度层明确职责、审批、例外和问责。
• 系统层落实权限、脱敏、日志、留存周期和删除策略。
• 避免“制度写得很好，但系统默认全开放”。

3.4 让个人信息主体权利真正可达

• 在网站、App、小程序、客服和邮件等渠道提供清晰的权利入口。
• 告知内容要简洁、分层、易理解，避免只给复杂长文本。
• 对查询、更正、删除、投诉建立闭环工单和时限要求。

3.5 建立原则执行的持续监督机制

• 定期抽查隐私政策、同意记录、权限分配、数据导出和删除记录。
• 将审计、培训、事件复盘和投诉分析结果反哺制度更新。
• 对违反基本原则的业务场景及时叫停和整改。

四、常用工具与实施方法

五、典型案例

案例1：注册功能收集过多导致最小必要失效

1. 背景：某平台在用户注册时一次性要求提供姓名、生日、职业、通讯录权限和精确位置。
2. 问题：这些字段并非开户所必需，业务功能也没有逐项拆分，违反最小必要和选择同意原则。
3. 改进：企业将注册必填项缩减为手机号和验证码，其他字段改为用户主动开启特定功能后再单独申请。

案例2：隐私政策存在但用户看不懂

1. 背景：某应用提供了长篇隐私政策，但关键收集目的和共享对象埋在大量专业术语中。
2. 问题：形式上有公示，实质上不透明，用户无法做出真实选择。
3. 改进：改为分层告知，在申请权限、开启功能和对外共享前分别弹出简洁说明，并保留详细政策入口。

案例3：同意已取得却长期保留数据

1. 背景：某业务已结束，但历史个人信息长期留存在生产库和分析库中。
2. 问题：组织误以为“用户同意过”即可长期持有数据，忽视最小必要和确保安全原则。
3. 改进：重新梳理保留规则，对超期数据执行删除或匿名化，并将留存周期写入制度和系统策略。

六、成文信息管理要求

第4章虽然是原则性条款，但恰恰最需要组织留存证据，证明这些原则并非停留在口号，而是已经转化为具体的制度和操作要求。

1. 建议保留的成文信息
   • 个人信息保护总制度及七项原则适用说明
   • 数据分类分级清单、处理活动台账和用途登记表
   • 隐私政策、告知文本、同意记录及版本更新记录
   • 最小必要评审记录、删除和匿名化策略
   • 权利请求处理记录、投诉台账和整改闭环记录
   • 培训、审计、事件复盘和管理评审材料
2. 管理要求
   • 原则类制度应与具体业务规则、系统配置和审批流程保持一致。
   • 重要文档需要版本控制，确保隐私规则变化后可追溯。
   • 成文信息应能支撑外部检查、内部审计和责任追踪。

七、常见误区及踩坑提醒