一、ISO/IEC 27701:2019 6.10 标准原文
原文摘要：本条对应 ISO/IEC 27002:2013 第13章，包括 6.10.1 网络安全管理与 6.10.2 信息传输。2019版在 6.10.2.1 信息传输策略和规程中补充提出，组织应考虑在适用情况下，在系统内外强制执行与 PII 处理相关的规则；在 6.10.2.4 保密或不泄漏协议中补充提出，凡接触 PII 的人员都应承担保密义务，保密义务持续时间应被明确规定；当组织是 PII 处理者时，其与员工、代理之间的保密安排还应确保这些人员遵守与数据处理和保护有关的策略和规程。整体上，6.10要求组织把网络和传输中的 PII 保护做成一条连续、可落实、可追责的控制链。
二、条款解读说明
6.10 是第6章中最容易被技术团队“自动化理解”的一组条款，因为网络、传输协议、邮件和保密协议看上去都属于经典信息安全主题。但在 PIMS 语境中，通信安全的重点并不只是保障网络可用和防止攻击，更在于确保 PII 在离开原始存储位置后，仍然沿着受控路径传输、被正确对象接收、在需要时受到加密和隔离，并且所有接触者都知道自己承担何种保密义务。
6.10.1 处理的是网络安全管理，关注网络本身是否有足够边界、服务是否按要求提供、不同网络域是否按信任等级隔离。6.10.2 则把视角推向信息传输，关注邮件、消息、接口、文件交换和合同安排这些更贴近业务流的场景。对 PII 来说，这两个部分其实是一体的。网络负责“路”是否安全，传输负责“货”怎么送、送给谁、出了问题谁承担责任。
| 子条款 | 核心问题 | 在PIMS中的直接价值 |
|---|---|---|
| 6.10.1 网络安全管理 | 网络边界和连接条件是否被明确定义 | 防止 PII 通过弱网络入口被接触、篡改或绕行 |
| 6.10.2 信息传输 | 信息如何通过邮件、文件、接口和协议安全流动 | 防止传输中的 PII 被误发、截取、错误解释或不当保存 |
| 补充要求 | PII 规则能否在系统内外被强制执行、接触者是否承担保密义务 | 把隐私要求嵌入真实传输链路和人员责任链 |
2019 版在 6.10.2.1 的补充非常关键。它不是要求组织额外再写一份“隐私传输制度”，而是提醒组织，凡是与 PII 处理相关的规则，不能只停留在业务说明或员工培训中，而要在适用时被系统、流程和外部协作机制真正执行出来。例如，某些字段只能通过特定接口发送、某类数据不能转发到个人邮箱、某类主体信息只能在指定国家或指定承包方之间传输，这些都需要被真正强制，而不是依赖操作者临场记忆。
在 6.10.2.4 中，标准又把责任拉回到“人”。因为再严密的网络和协议，也无法取代接触者的保密义务。尤其在处理者场景中，组织的员工、外包人员、驻场支持、代理服务商乃至分包链条中的操作人员，都可能在故障排查、文件交付、业务协同或客户支持中接触 PII。若这些人没有清楚、可执行、可追责的保密义务，通信安全就会在最后一步从技术问题退化为人员风险。
6.10 还需要和上一章、下一章一起理解。它与 6.6 访问控制共同决定“谁能看”，与 6.7 密码控制共同决定“链路如何上锁”，与 6.12 供应商关系共同决定“跨组织传输时谁承担什么责任”。因此，通信安全不是孤立章节，而是连接内部控制和外部协作的一道关键桥梁。
对很多组织而言，真正的薄弱点并不在主链路，而在旁路和例外。正式接口也许有 TLS、专线和日志，真正出问题的往往是临时导出、邮件转发、即时消息传文件、故障时用个人工具传日志、供应商临时收样本、客户要求通过特殊渠道回传材料等。这些场景共同说明，6.10 管的不是“标准通信方式”本身，而是所有能让 PII 在人与系统、系统与系统、组织与组织之间移动的通道。
因此，6.10 的本质，是围绕 PII 建立“网络可控、传输可控、接收可控、保密义务可控”的全链路通信安全体系。只有这四层同时成立，组织才能说自己不仅保护了静态数据，也保护了流动中的个人信息。
三、实施要点
- 把 6.10 当作 PII 流动控制章节，而不是只当作网络基础设施章节。
- 同时管理网络边界、传输渠道、接收对象和接触者保密义务，避免只重技术不重责任。
- 对正式接口、邮件、消息工具、文件交换、物理传输和临时例外分别建立边界要求。
- 在系统和流程中尽可能强制执行与 PII 传输有关的规则，而不是只靠制度提醒。
- 6.10的核心是让 PII 在流动中仍保持原有保护强度，不因为离开主系统就失去控制。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 网络域与连接矩阵 | 明确哪些系统和区域可以互通、如何互通 | 网络边界和允许连接清单 |
| 传输渠道分级规则 | 区分接口、邮件、即时消息、文件交换和物理介质的适用边界 | 渠道使用标准 |
| 协议与保密条款模板 | 规范外部接收方和接触者的责任安排 | 合同附件、保密义务条款 |
| 传输留痕与例外审批 | 记录特殊传输、外发和临时绕行的依据与责任 | 审批记录和审计日志 |
实践中，最有效的动作通常不是再增加一套抽象制度，而是先回答四个问题：哪些 PII 可以通过电子渠道发送，哪些必须通过受控接口；哪些外部方可以接收明文，哪些必须加密；哪些人员能够执行传输动作，哪些只能审批；哪些场景一旦偏离标准通道就必须额外留痕。把这四件事写清楚，6.10 就有了真正的执行基础。
对服务型平台和处理者而言，还应把客户说明做到位。客户往往并不真正关心组织内部网络拓扑，但一定关心自己的 PII 经由哪些通道被传输、在什么情况下会共享给第三方、出现异常时谁会通知、自己的日志和记录能否被区分。通信安全若不能对客户问题形成稳定答案，说明它还停留在纯技术视角。
五、典型案例
- 主链路安全，旁路失守：某组织为正式接口部署了加密和访问控制，但客服部门长期用邮件回传包含主体资料的截图和表格，且没有统一加密要求。最终问题出在看似“方便沟通”的旁路，而不是核心系统。
- 合同里没写清保密义务：某处理者将部分支持工作交给代理团队，技术通道虽已受控，但代理人员对处理 PII 的限制、保密持续期限和违规报告义务写得很模糊，后续发生样本误传时，组织发现自己很难追责。
这些案例说明，通信安全一旦被分裂成“网络是技术的、协议是法务的、邮件是业务自己的”，最终就没有人能对 PII 流动的整体安全负责。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 通信安全制度 | 网络管理原则、传输边界、例外规则和责任分工 |
| 传输策略与渠道清单 | 不同类型 PII 的允许渠道、加密要求和禁止场景 |
| 协议与保密安排 | 外部传输责任、保密持续时间、违规报告和销毁要求 |
| 例外审批和审计记录 | 临时传输、绕行处理、异常事件和整改结果 |
这些文件能帮助组织证明，6.10并不是分散在网络团队、法务团队和业务团队手中的零碎要求，而是一套围绕 PII 流动建立起来的正式治理机制。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 通信安全等于链路加密 | 接收对象、传输场景和保密责任无人管 | 同时管理通道、对象、责任和留痕 |
| 正式接口安全就足够 | 邮件、截图、即时消息和临时导出成为旁路 | 覆盖所有真实传输通道 |
| 保密协议只是HR文件 | 接触 PII 的外包、代理和支持人员责任模糊 | 按处理场景明确保密义务和持续期限 |
通信安全最容易被误判的地方，在于组织会高估“主链路”的成熟度，低估“协作链”的风险。专线、VPN、网关和正式接口通常最先被建设，但真正频繁承载 PII 的，往往是工单附件、共享文件夹、聊天工具、审批流中的截图和跨团队转发。若没有把这些协作型通道一起纳入 6.10，组织就等于在最常用的路径上放弃了统一保护强度。
6.10 做得成熟时，组织应能做到两件事。第一，随机抽一种 PII，说明它允许通过哪些网络和传输渠道移动、哪些渠道绝对禁止、例外如何审批。第二，随机抽一类接触者，说明他为什么有权接触、承担什么保密义务、离岗或合作终止后义务持续多久。能同时回答这两类问题，才说明通信安全不只是设备配置，而是真正进入了 PIMS 的流动边界治理。
所以，读者理解本章时不要把它看成“第13章的普通复述”。在 PII 场景下，通信安全实质上是在回答一个更尖锐的问题：个人信息一旦开始流动，组织靠什么保证它不会在网络边界、共享边界和责任边界上逐步失真。能把这个问题回答清楚，6.10 才算真正落地。