一、GB/T 35273-2020 6.2 标准原文
条款原文：收集个人信息后，个人信息控制者宜立即进行去标识化处理，并采取技术和管理方面的措施，将可用于恢复识别个人的信息与去标识化后的信息分开存储并加强访问和使用的权限管理。
二、条款解读说明
2.1 去标识化是降低内部使用风险的重要缓冲层
在很多业务中，组织收集个人信息后并不总是需要在全流程中持续直接识别个人身份。例如，统计分析、推荐算法训练、运营监测、测试验证、审计抽样等场景，通常并不需要员工长期接触真实姓名、证件号、手机号等直接标识信息。GB/T 35273-2020第6.2条提出，收集个人信息后宜尽快去标识化，并将恢复识别的附加信息与去标识化结果分开存储。其核心目的，就是降低内部滥用、误操作和泄露后的直接识别风险。
2.2 去标识化不等于匿名化，仍属于个人信息治理范畴
| 处理方式 | 特点 | 是否仍属个人信息 | 管理要求 |
|---|---|---|---|
| 去标识化 | 在不借助额外信息情况下无法直接识别个人 | 通常仍属于个人信息 | 需要继续受控管理 |
| 匿名化 | 处理后无法复原且无法识别到个人 | 通常不再属于个人信息 | 重点在不可逆性证明 |
6.2明确讨论的是去标识化，而不是完全匿名化。这意味着去标识化后的数据并不是可以放任不管，它仍然可能在特定条件下与附加信息结合恢复识别。因此，组织不仅要做技术处理，还要做分离存储、权限控制和用途限制。
2.3 “尽早去标识化”反映的是风险前移治理思路
标准用“宜立即进行去标识化处理”表明，组织不应在数据进入多个系统、多个岗位、多个流程之后才想着降低可识别性。越早处理，就越能减少真实身份信息在系统中横向扩散的范围。特别是在开发测试、数据分析、报表使用、模型训练和外部协作场景中，去标识化越靠前，风险越可控。
2.4 分开存储和权限管理是6.2的关键落地点
很多组织做了字段掩码或替换，却把映射关系、原始标识和去标识化数据放在同一数据库、同一权限域甚至同一团队管理下，这会大幅削弱去标识化效果。标准特别强调将可用于恢复识别个人的信息与去标识化后的信息分开存储，并加强访问和使用权限管理。实践中，这通常意味着：映射表独立存放、访问审批更严格、运维和分析岗位隔离、查询行为留痕、敏感操作双人复核等。
2.5 去标识化的价值不仅在合规，也在治理效率
当组织能够在多数非识别性场景下使用去标识化数据，就可以减少真实身份数据在内部流转范围，降低权限复杂度，也更容易实现“按需可见”。这不仅有助于降低泄露风险，也能提升内部数据使用边界的清晰度。因此，6.2既是安全条款，也是数据治理能力条款。
三、实施要点
3.1 明确需要去标识化处理的场景
- 识别分析、测试、报表、模型训练、对外协作等不需要直接识别个人的场景。
- 对高敏感数据和大规模数据优先实施去标识化。
- 避免默认把全量原始数据直接提供给业务使用。
3.2 尽早在数据链路前段实施处理
- 在数据入湖、入仓、分析前或进入测试环境前进行去标识化。
- 减少明文身份信息在多个系统和岗位间扩散。
- 对需要临时恢复识别的场景设置专门审批和授权。
3.3 分离存储映射信息和去标识化数据
- 将姓名、手机号、证件号等可直接识别信息的映射关系独立保存。
- 对映射表设置更严格的权限、加密和访问审计。
- 避免一个岗位同时长期持有去标识化数据和复原钥匙。
3.4 建立用途和权限双重控制
- 按岗位和场景授予访问权限，而不是按部门整体开放。
- 对需要复原身份的操作设置审批、留痕和复核。
- 禁止在测试、培训、演示等场景随意使用可直接识别真实个人的数据。
3.5 定期验证去标识化有效性
- 检查是否可被轻易回识别、是否存在映射表泄露风险、是否存在权限绕过。
- 随着新字段、新算法和新关联数据加入，重新评估再识别风险。
- 将验证结果输入安全评估和审计机制。
四、常用工具与实施方法
| 工具/方法 | 适用场景 | 实施重点 | 关键输出 |
|---|---|---|---|
| 字段替换与令牌化 | 数据分析和应用隔离 | 降低真实身份信息暴露 | 去标识化数据集 |
| 映射表分离存储 | 可恢复识别场景 | 独立管理原始标识和映射关系 | 独立密钥/映射库 |
| 最小权限访问控制 | 内部数据使用 | 限制谁能看、谁能复原、谁能导出 | 权限策略 |
| 再识别风险评估 | 模型训练和多源融合 | 评估多数据集结合后的回识别风险 | 评估报告 |
| 测试数据脱敏流程 | 开发和测试环境 | 避免真实身份信息流入非生产环境 | 脱敏流程记录 |
五、典型案例
案例1：测试环境直接复制生产用户数据引发高风险
- 背景：某企业为方便测试，直接把生产数据库复制到测试环境。
- 问题：测试人员并不需要识别真实个人，但却能接触大量明文个人信息。
- 改进：上线测试数据去标识化流程，只保留业务验证所需结构和逻辑关系。
案例2：映射表与去标识化数据同库保存导致控制失效
- 背景：某系统已将用户ID替换为内部标识，但映射关系和分析数据保存在同一库中。
- 问题：只要拿到同一访问权限，就能轻易恢复真实身份。
- 改进：将映射表独立加密保存，并增加审批、审计和岗位隔离。
案例3：报表分析改用去标识化数据后降低暴露面
- 背景：运营团队长期使用带有真实手机号和姓名的报表做活跃度分析。
- 问题：分析目标并不需要直接识别个人，明文信息暴露没有必要。
- 改进：改为使用令牌化标识和分组标签，只有客服等极少数场景才允许复原身份。
六、成文信息管理要求
6.2要求组织能证明其已对适当场景实施去标识化，并对可恢复识别信息和使用权限进行有效管理，因此应保留完整的技术与管理证据。
- 建议保留的成文信息
- 去标识化适用场景清单和处理规则
- 字段替换、令牌化或其他处理方案说明
- 映射表分离存储和权限控制记录
- 再识别风险评估和整改记录
- 测试环境、分析环境脱敏实施记录
- 管理要求
- 应能说明哪些数据经过去标识化、哪些仍保留可识别信息以及理由。
- 映射表和复原权限应有单独、严格的控制和日志留痕。
- 文档和权限策略需随系统架构变化及时更新。
七、常见误区及踩坑提醒
| 误区 | 常见表现 | 正确做法 |
|---|---|---|
| 去标识化等于匿名化 | 误以为处理后无需再受控 | 把去标识化数据继续纳入个人信息治理 |
| 映射关系不分离 | 同库同权限可轻易复原 | 分库存储并强化权限控制 |
| 只做技术脱敏不做权限控制 | 大量岗位仍可接触复原信息 | 技术和管理措施同步实施 |
| 测试分析继续使用真实数据 | 非必要场景暴露真实身份 | 优先使用去标识化数据集 |
| 脱敏后长期不评估 | 新数据关联后再识别风险升高 | 定期开展再识别风险评估 |