一、ISO/IEC 27701:2019 6.1 标准原文
原文摘要：ISO/IEC 27002:2013 中提及“信息安全”的地方，应扩展到可能受 PII 处理影响的隐私保护。在实际使用中，27002 中的“信息安全”可理解为“信息安全和隐私”。所有控制目标和控制都应同时考虑信息安全风险以及与 PII 处理相关的隐私风险。除非第6章另有规定，或适用司法辖区另有要求，第6章相同指南同时适用于 PII 控制者和 PII 处理者。
二、条款解读说明
6.1是第6章最关键的解释性条款。它没有新增某一项具体控制，也没有给出长篇操作细则，但它重新定义了整章的阅读方法。ISO/IEC 27002:2013 原本是一套围绕信息安全目标和控制编写的实施指南，关注的核心是保密性、完整性和可用性。而 27701:2019 的第6章并不是另起炉灶再造一套控制，而是要求组织在既有 27002 控制体系上，加入 PII 处理的隐私视角。换句话说，控制本身大多还是那些控制，但控制要解决的问题已经变了，证明控制有效的方式也跟着变了。
很多组织在进入第6章时容易走向两个极端。第一个极端是把第6章理解成“没有写补充的控制就与隐私无关”，于是只盯着少量明确增补文字，而忽略大量原本就会作用于 PII 处理场景的安全控制。第二个极端则是把第6章机械理解为“所有控制都要再写一份隐私版”，结果写出一堆抽象而重复的说明，既没有帮助业务，也没有真正识别角色和场景差异。6.1 的意义，正是避免这两个极端。它告诉组织，凡是会接触、处理、传输、保留、删除、监测或共享 PII 的控制，都必须同时接受信息安全和隐私两种视角的检验。
| 6.1提出的核心判断 | 实际含义 | 如果忽略会发生什么 |
|---|---|---|
| “信息安全”扩展为“信息安全和隐私” | 控制不仅保护数据本身，也要控制处理行为对个人的影响 | 组织只看系统安全，不看主体权益和处理边界 |
| 所有控制要同时考虑两类风险 | 不仅考虑 CIA 风险，也考虑 PII 处理风险和主体后果 | 控制设计看似完整，但隐私风险长期不可见 |
| 第6章通用指南同时适用于控制者和处理者 | 无论角色不同，通用安全与隐私基础控制都不能缺 | 组织误以为只有第7章或第8章才与自己有关 |
从管理逻辑看，6.1把第6章定位为“通用 PIMS 指南层”。第7章和第8章分别提供控制者和处理者的特定补充，而第6章则提供所有处理 PII 的组织都必须考虑的基础控制扩展。这一点非常重要。因为许多最容易失控的地方，恰恰不是控制者或处理者特有义务，而是通用基础控制，例如访问控制、日志、备份、资产归还、供应商管理、远程工作、测试数据、事件响应和记录保护等。如果这些通用控制没有先被按隐私语境重读，后面的角色特定控制写得再细，体系也会出现明显短板。
6.1还指出，同一套指南通常同时适用于控制者和处理者，除非标准另有具体规定，或者某一司法辖区对两类角色施加了不同要求。这意味着组织在阅读第6章时，首先不应急着问“我是控制者还是处理者，所以这个控制跟我有没有关系”，而应先问“只要我处理 PII，这项基础控制会不会影响隐私结果”。例如移动设备策略、日志保护、外部服务控制、人员角色职责、信息分级和测试数据保护，这些都不因为角色不同而失去相关性。角色差异更多体现在义务细节和外部责任边界上，而不是通用控制是否存在。
另一个容易被低估的地方，是 6.1 把“与 PII 处理相关的隐私风险”放到了和信息安全风险同等位置。也就是说，组织不能把 27002 控制只当成技术或管理规范来执行，而要问这些控制在隐私场景里会如何影响个人。一个日志控制问题，也许不只会造成运维混乱，还可能导致大量 PII 在排障过程中被过度暴露；一个资产归还流程问题，也许不只会造成设备丢失，还可能让离职人员继续持有含有个人信息的介质；一个远程工作控制问题，也许不只涉及办公纪律，还可能直接改变家庭环境或公共环境下 PII 暴露的概率。6.1 的价值，就在于迫使组织在这些地方主动补上隐私后果视角。
因此，6.1并不是“本章总则”这样一句平铺直叙的目录说明，而是整个第6章最重要的方法论开关。读懂这一条，后面每一项控制的解读都会更准确；读不懂这一条，后面所有控制都可能退回到普通 ISMS 语境中去，失去 27701 真正的扩展意义。
三、实施要点
- 在阅读和实施第6章控制前，先统一组织内部理解: 27002 中的“信息安全”在第6章下应扩展为“信息安全和隐私”。
- 对每一项控制同时问两个问题: 它能否降低信息安全风险，以及它能否降低 PII 处理对个人和组织的不利后果。
- 不要把第6章看成控制者或处理者特定章节，它首先是所有处理 PII 组织都适用的通用基础控制层。
- 将第6章输出与第7章、第8章联动，先把通用控制做实，再叠加角色特定义务。
- 6.1的核心是统一解释口径，让第6章全部控制都进入隐私语境。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 第6章解释口径说明 | 统一“信息安全=信息安全和隐私”的应用方式 | 解释性说明文件 |
| 双视角控制检查表 | 同时检查安全风险和隐私风险 | 控制评估底稿 |
| 通用控制映射矩阵 | 识别哪些第6章控制作用于 PII 处理场景 | 适用性总表 |
| 角色补充衔接表 | 把第6章通用控制与第7章、第8章补充要求连接起来 | 控制衔接关系图 |
在实际工作中，一个很有效的做法是先选若干高风险场景做试读，例如主体请求处理、远程工作、测试数据、供应商接入和日志监控，然后用 6.1 的解释口径去逐项检查相关控制。组织通常会很快发现，原来很多看似“通用安全要求”的控制，实际上都直接影响隐私结果。通过这种场景化试读，团队对 6.1 的理解会比单纯宣讲更牢固。
若组织同时扮演控制者和处理者，还应在通用控制解释时明确“通用层先统一、角色层再区分”的原则。这样能避免团队一开始就陷入角色争论，反而忽略通用基础控制本身。
五、典型案例
- 只盯角色条款，忽略通用控制：某 SaaS 服务商在建设 PIMS 时把注意力几乎全部放在处理者义务上，合同和通知机制做得很细，但员工离职资产归还、远程访问、日志保护和测试数据管理都仍按旧习惯运行。后来客户尽调时发现问题集中在第6章通用控制没有隐私化，根源正是 6.1 没被真正理解。
- 把通用控制全都重新写成空话：另一家企业意识到“信息安全要扩展到隐私”，于是几乎把每个控制都附上一句“应保护个人信息”，但没有结合具体处理场景和风险解释实际差异。结果文件很多，执行帮助却很小。重新按 6.1 建立双视角分析后，控制说明才开始具备操作性。
这两个案例说明，6.1 最怕两种偏差: 一种是完全不扩展，另一种是无差别扩展。前者会漏掉大量隐私风险，后者会制造一堆无法执行的文字。只有回到“控制要同时面对安全风险和隐私风险”这一核心，解读才会准确。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 第6章通用适用性说明 | 如何理解“信息安全”扩展到隐私保护 |
| 双视角评估底稿 | 控制对应的安全风险与隐私风险分析 |
| 第6章与第7/8章衔接记录 | 通用控制与角色特定控制的关系说明 |
| 内部培训材料 | 用于统一不同团队对第6章控制的解释口径 |
这些文件的意义，在于把 6.1 从抽象解释原则变成组织内部真正共享的方法。只要方法没有被固化，后续第6章的大量条款就很容易被不同团队各自理解、各自执行，最终造成体系碎片化。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 认为只有写了补充指南的条款才涉及隐私 | 大量通用控制仍按纯 ISMS 口径运行 | 凡涉及 PII 处理的控制都应用 6.1 扩展解释 |
| 把所有控制都做成空泛隐私宣言 | 文件增加很多，执行价值很低 | 回到具体风险和具体场景解释控制含义 |
| 一开始就只讨论角色差异 | 忽略控制者和处理者共同需要的基础控制 | 先落实通用控制，再叠加角色特定要求 |