一、ISO/IEC 29100:2024 5.4 标准原文
条款要义：本条从标识符、可区分特征、可链接信息、假名化数据、元数据、非请求PII和敏感PII等多个角度说明，组织如何识别什么信息属于或可能属于PII。
理解重点：5.4的关键不是死记几种数据类型，而是理解可识别性是情境性的，某些信息单独看似乎普通，但一旦与其他信息结合，就可能形成PII。
二、条款解读说明
2.1 识别PII是隐私治理的入口工作
如果组织连什么是PII都识别不清，后续最小化、通知、访问、删除和安全保护就无从谈起。5.4的重要性在于，它要求组织放弃“只有姓名和身份证号才算个人信息”的狭窄认识，转而从识别可能性的角度理解PII。账号、设备标识、位置数据、行为轨迹、浏览记录、订单偏好、音视频特征、工号、组合字段、系统日志中的关联信息，都可能在具体情境下指向某个可识别的人。
这也是为什么许多隐私项目一开始就会出错。团队把PII名单写得过窄，结果部分高风险信息被遗漏；或者把所有数据一概视为高敏信息，导致治理失去重点。5.4真正要求的是建立一套既不过度简化、也不过度泛化的识别框架，让组织可以合理判断哪些信息直接识别、哪些间接识别、哪些经过关联后仍然可能识别，以及哪些应被视为更高风险的敏感PII。
2.2 29100对PII的识别强调“单独识别”与“组合识别”并重
| 类别 | 说明 | 典型示例 | 治理启示 |
|---|---|---|---|
| 直接标识符 | 单独即可识别个人 | 姓名、身份证号、手机号、邮箱、账号 | 通常需要较强控制 |
| 可区分特征 | 描述某人独特特征 | 生物特征、声音、影像、设备指纹 | 识别风险常被低估 |
| 可链接信息 | 需与其他数据关联后识别 | 订单号、地址片段、工单编号、位置轨迹 | 不能因“单独看不出”而忽视 |
| 假名化数据 | 去除直接标识后保留可回链能力 | 用户ID、加盐标识、代号化记录 | 仍可能属于PII，不可误判为完全匿名 |
| 元数据 | 与处理活动相关的伴生信息 | 访问时间、设备、IP、位置、日志信息 | 在安全和分析场景中特别关键 |
| 敏感PII | 一旦滥用影响更大 | 健康、财务、儿童、精准位置、生物识别 | 应提高治理等级 |
2.3 假名化、元数据和非请求PII是最容易被忽视的三类
第一类容易被误判的是假名化数据。很多团队看到用户ID、哈希值、代号或token，就本能认为“已经不是个人信息了”。但只要组织仍然能够通过映射表、后台系统、日志关联或其他合理方式回溯到具体个人，这类数据就仍然可能构成PII。5.4对此提醒非常重要，因为它纠正了“去掉姓名就等于匿名”的常见误解。
第二类是元数据。访问记录、设备信息、地理位置、时间戳、点击路径、接口调用日志，看起来像技术数据，但一旦与账号、行为或上下文关联，同样可能识别个人，甚至比传统静态字段更能暴露行为模式。第三类是非请求PII，也就是组织原本并不打算收集，但在上传附件、自由文本、客服留言、邮件往来或日志中被意外带入的PII。这些数据最容易因为“不在正式字段里”而逃离治理视野。
2.4 识别PII不是一次性分类，而是持续判断能力
随着技术能力提升，原本难以识别的信息可能变得更容易被关联；随着业务扩展，原本分散的信息组合起来也可能具备更强识别性。因此，5.4并不支持“做一张字段清单后永不更新”的管理方式。真正成熟的组织会把PII识别能力嵌入到需求评审、架构设计、字段治理、日志设计、数据分析和供应商接入流程中，让识别判断成为持续能力，而不是年审时临时补课。
三、实施要点
3.1 建立PII识别规则库
- 将直接标识符、间接标识符、可链接信息、元数据和敏感PII分别列出并定义判断规则。
- 对假名化数据单独建立识别口径，避免误当匿名数据。
- 引入场景判断，说明相同字段在不同业务中可能具有不同风险等级。
3.2 将识别工作嵌入设计与变更流程
- 新增字段、日志、埋点、接口和供应商接入时，先判断是否涉及PII及其敏感性。
- 对自由文本、附件上传和客服工单等非结构化场景建立专项识别规则。
- 定期抽查历史系统，识别被漏标或误分类的PII。
3.3 根据识别结果分层治理
- 不是所有PII都一刀切管理，应按识别性、敏感性和使用场景分层。
- 对敏感PII、可回链假名化数据和高价值元数据实施更强保护。
- 将识别结果与最小化、访问控制、保留和通知要求联动。
四、常用工具与实施方法
| 工具或方法 | 适用场景 | 实施重点 | 关键输出 |
|---|---|---|---|
| PII分类分级表 | 字段治理 | 区分直接、间接、敏感和假名化数据 | 分类目录 |
| 字段与日志审查 | 系统设计 | 检查是否存在漏标PII和过度记录 | 审查记录 |
| 数据发现与扫描 | 存量治理 | 发现数据库、附件和对象存储中的PII | 发现报告 |
| 可链接性评估 | 假名化场景 | 判断数据是否仍可合理回链到个人 | 评估结论 |
五、典型案例
案例一：日志中的PII被长期忽略
某互联网平台长期认为应用日志只是技术信息，未按PII管理。后续复盘发现，日志中包含账号、IP、设备标识、地址片段和错误回显内容，足以关联到具体主体。企业依据5.4重新定义日志识别规则，并将相关日志纳入分级和访问管理，补上了长期盲区。
案例二：假名化用户ID被误判为匿名数据
某产品团队把内部用户编号视为匿名标识，允许广泛共享给分析团队。后来审查发现，只要结合主数据映射表，编号就能快速回到具体个人。依据5.4的识别思路，组织将其改判为仍可识别的PII，并对共享、导出和保留方式做出调整。
六、成文信息管理要求
- PII识别标准、分类分级规则和示例库。
- 字段、日志、附件和非结构化数据识别记录。
- 敏感PII和假名化数据的判定记录。
- 识别结果与控制要求的映射文件。
- 历史复核和误分类整改记录。
七、常见误区及踩坑提醒
| 常见误区 | 风险表现 | 正确做法 |
|---|---|---|
| 只有直接身份字段才算PII | 大量间接识别信息被遗漏 | 从可识别性和关联能力角度识别PII |
| 假名化就等于匿名 | 可回链数据被过度共享 | 单独评估假名化数据的回链可能性 |
| 日志和元数据不算PII | 技术系统形成长期治理盲区 | 将元数据纳入PII识别范围 |
| 识别做一次就结束 | 新技术和新组合导致判断过时 | 把PII识别嵌入持续变更流程 |
八、审核关注点与成熟度判断
审核人员通常不会只看一份分类表，而会抽查真实字段、日志、报表、附件上传、客服工单和分析样本，确认组织是否真能识别各种形态的PII。如果团队在常见边界问题上回答前后不一，或者对假名化、元数据、自由文本中的PII缺乏稳定口径，说明5.4还不成熟。成熟组织则能展示统一的识别标准、判定记录和实际样本。
成熟度更高的标志是：PII识别已经进入设计前置阶段，而不是等数据落地后再补标。做到这一点，组织才真正具备以框架驱动治理的能力。
九、发布级补强建议
5.4这篇文章要写出深度，关键在于把“PII识别”从简单列举字段，提升到“理解可识别性”的层面。只要文章能讲清楚直接识别、组合识别、假名化、元数据和敏感PII之间的关系，并结合真实场景说明为何识别是持续能力而非静态清单，就已经具备较强的发表价值。