一、ISO/IEC 27701:2019 6.5.2.1 标准原文
原文摘要：ISO/IEC 27002:2013 8.2.1 中规定的控制、实施指南和其他信息以及补充实施指南适用。组织的信息分类系统应明确将 PII 视为其实施方案的一部分，并通过分类体系理解组织处理了什么样的 PII、包括何种类别和特殊类别、存储在何处以及可以通过哪些系统流通。也就是说，信息分级应直接服务于对 PII 类型、位置和流向的掌握。
二、条款解读说明
6.5.2.1 是 2019 版在 8.2.1 基础上的一个实质性增强。27002:2013 原本要求根据信息的法律要求、价值、重要性以及对未授权泄露或修改的敏感性进行分级，而 27701 进一步指出，组织的信息分类系统必须把 PII 明确纳入其中。这意味着分类体系不应只围绕业务秘密、财务敏感度或一般保密等级展开，还要能反映个人信息的存在、类型和相应保护要求。
在 PIMS 中，把 PII 纳入分级体系有三个直接作用。第一，它帮助组织知道自己到底处理了哪些种类的个人信息，而不仅是抽象地知道“有一些客户数据”。第二，它帮助组织识别这些信息位于哪些系统、文件、介质和流转路径中。第三，它为后续访问控制、标记、导出限制、备份、保留和删除提供一致的判断基础。没有这一层，很多与 PII 相关的保护动作都会因为缺少统一判断标准而碎片化。
| 分级要素 | 一般信息安全视角 | PIMS 额外要关注什么 |
|---|---|---|
| 保密性与敏感度 | 泄露对组织的影响 | 泄露对 PII 主体的影响和法律后果 |
| 法律和合同要求 | 遵守监管、合同和保密约束 | 不同类型 PII 的特别规则和特殊类别要求 |
| 位置与流向 | 信息在哪些系统中使用 | PII 在哪些系统、报表和介质之间流转 |
| 生命周期变化 | 信息随时间可能降级或失效 | PII 在保留、去标识化、删除前是否仍属高风险 |
标准特别提到“什么样的 PII”“特殊类别”“存储位置”和“通过哪些系统流通”。这说明 6.5.2.1 的目标并不只是给信息打一个等级，而是借分类体系形成一张高层次的数据认知图。组织若无法通过分类回答这些问题，说明分级体系还没有真正支持 PIMS。尤其在数据分散于多系统、多团队、多地区的环境中，这一条可以成为重新梳理 PII 视图的重要抓手。
同时，分类不应等于一刀切地把所有 PII 都归入最高级别。成熟体系通常会根据 PII 类型、数量、处理目的、法律要求和主体影响进行更细的设计。比如一般联系方式、账户认证信息、健康或生物特征信息、儿童信息和投诉调查材料，其风险和处理要求显然不同。组织可以在总体分级方案中体现这种差异，但前提是分类逻辑对使用者足够清晰，不至于复杂到无法执行。
6.5.2.1 还要求分级结果随着资产价值、敏感性和重要性的变化而更新。对 PII 来说，这一点同样重要。例如某些信息在收集初期风险较高，在去标识化后风险下降；某些日志在最初只被认为是技术数据，但当其中包含身份标识和行为轨迹时，就应被重新评估。分类若不能动态反映这种变化，就会要么保护不足，要么长期过度控制。
因此，6.5.2.1 的本质，是让分级体系成为组织理解和管理 PII 的主框架之一。它既服务于风险识别，也服务于日常执行。只要这层框架清楚，很多具体控制才不会失去共同依据。
三、实施要点
- 在分类制度中明确写出 PII 及其不同类型的识别和分级原则。
- 让分级结果能够映射到 PII 的位置、流向和主要处理场景。
- 对特殊类别或高影响 PII 设置更高等级或更严格的处理要求。
- 定期评审分类结果，确保其反映信息生命周期和业务变化。
- 6.5.2.1的核心是让 PII 在分类体系中有明确位置，而不是被隐含在模糊的大类里。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| PII 分类框架 | 定义一般、敏感和特殊类别 PII 的级别逻辑 | 分类标准表 |
| 系统流向映射 | 把分类结果与系统、报表和接口对应起来 | PII 流向图 |
| 分级评审机制 | 在业务和法律变化时更新分类结果 | 评审记录 |
| 示例驱动培训 | 帮助人员理解不同 PII 属于何种等级 | 示例库和测试题 |
实践中，可以先用少量高频场景做分类示例，例如客户注册信息、员工薪酬信息、患者记录、日志中的身份标识等。让团队看到同样是“个人信息”，为什么保护要求会不同，比抽象讲原则更有效。
同时，也应避免把分级做成纯法务语言。分类体系最终是给业务、技术和运营人员共同使用的，因此必须既能反映法律要求，又能被执行者实际理解和操作。
五、典型案例
- PII 在分类体系中被“隐身”：某组织的分类方案强调商业秘密和财务敏感度，却没有单独体现 PII 类型，导致日志中的身份标识和行为数据长期被当作普通技术数据处理，访问和导出限制明显不足。
- 所有 PII 一刀切：另一家组织把所有个人信息都列为最高级，结果业务团队为绕开高强度流程，开始自发使用未授权副本和口头沟通。后来组织重新细分不同类型和影响程度后，规则才变得既有保护力又可执行。
这些案例说明，信息分级既不能看不见 PII，也不能把 PII 简化为一个无法操作的单一类别。真正有效的是能支撑差异化保护的清晰体系。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 信息分类标准 | PII 类别、等级划分、示例和评审原则 |
| 分类结果记录 | 资产或系统对应的分级结果和责任主体 |
| 位置与流向映射 | 不同等级 PII 存储位置和系统流转情况 |
| 评审和调整记录 | 分类升级、降级和原因说明 |
这些文件可以证明组织的分级不是抽象命名，而是确实帮助自己掌握了 PII 类型、位置和保护要求。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 分类体系只看组织价值 | 忽视 PII 主体风险和法律要求 | 把个人影响和监管义务纳入分级判断 |
| 所有 PII 同一等级 | 不是过度控制就是执行绕开 | 根据类型、场景和影响适度分层 |
| 分级结果长期不更新 | 位置和风险变化后分类失真 | 建立动态评审机制 |
分级动作最怕只在系统上线或制度发布时做一次。PII 类型、业务用途、接触人群和外部共享范围一旦变化，原本合理的等级就可能不再匹配现实风险。把分级和处理活动变化、客户要求、例外审批放到同一复核机制里，才能保证等级不是历史遗留标签，而是持续反映当前场景的管理判断。
6.5.2.1 在实务中还要求组织把“可识别性”和“聚合效应”纳入分级逻辑。单独看似普通的联系信息、设备标识、行为记录和位置片段，若能与其他字段组合起来识别特定个人，或者被用于画像、风控、身份校验和敏感推断，其风险就不应继续按低等级处理。很多分级体系失真，不是因为没有列出 PII 类别，而是因为仍在按字段孤立思考，忽略了数据组合后对主体可能产生的影响。对 27701 来说，真正有效的分级，必须能反映这种上下文变化。
检查这条控制是否成熟时，也不能只看分类制度文本，而应抽查具体系统和样本。比如某类健康信息是否在主系统、导出报表、备份副本和数据仓库里都被一致地视为高等级，某些“技术日志”是否因为包含主体标识和轨迹而被重新归类，某些看似普通的客服录音是否因为包含认证问答而应提高控制强度。只有当分类结果能够穿透系统边界、报表边界和用途边界时，6.5.2.1 才真正成为组织理解 PII 风险的工作工具，而不是停留在制度术语里。