一、ISO/IEC 27701:2019 7.2.6 标准原文
原文摘要：标准要求组织与其使用的任何 PII 处理者签订书面合同，确保附录B中规定的适当控制得到实施。实施指南指出，合同应基于信息安全风险评估以及处理者所执行的 PII 处理范围来确定控制要求。默认情况下，附录B中的所有相关控制都应被考虑；若组织决定不要求处理者实施其中某些控制，应明确不实施的理由并形成文档化信息。
二、条款解读说明
7.2.6 是控制者将 PIMS 要求外化到处理链的重要条款。控制者即使自己不直接完成全部处理活动，仍然对处理的合法性和边界负有责任。因此，当外部处理者参与进来时，控制者不能只签一个普通服务合同，再默认对方会“按行业惯例做安全”。27701 的要求更明确：附录B 中针对处理者的控制，应作为合同治理的核心来源。
标准特别指出，应结合风险评估和处理范围来确定合同要求。这意味着合同不能一刀切。有的处理者只做托管存储，有的处理者会接触主体请求、跨境传输、分包安排和日志信息，不同场景对应的附录B控制要求也会不同。但无论如何，默认前提是先把所有相关控制都纳入考虑，而不是默认只写几条常见保密条款。
| 合同控制点 | 如果缺失会怎样 | 控制者应关注 |
|---|---|---|
| 处理范围 | 对方处理边界不清，后续扩张难以约束 | 写明数据、目的和操作类型 |
| 附录B控制要求 | 处理者责任停留在笼统“应安全处理” | 将相关控制逐条映射进合同 |
| 例外与不适用理由 | 省略控制却无人说明原因 | 记录排除依据和替代安排 |
| 监督与审查 | 合同签完后无法验证履行情况 | 约定报告、审计和整改要求 |
在实践中，控制者最容易犯的错误是把合同当成采购文件，而不是治理文件。只要价格、服务级别和交付时间谈妥，就以为控制已经足够。但 PII 处理合同的难点从来不在商业条款，而在责任边界是否具体可执行。例如谁负责主体请求、谁负责通知、是否允许分包、日志如何提供、终止后如何删除或返还数据。这些若没写清，出现问题时通常只能互相推责。
因此，7.2.6 的本质是通过合同把控制者的治理边界延伸到处理者。控制者不能把外部参与当成责任转移，而应通过附录B控制要求，把应有的行为、限制和证据义务明确写进可执行文件。
从审计和客户尽调角度看，最容易暴露问题的往往不是合同里完全没有隐私条款，而是条款写得过于抽象。比如只写“处理者应采取适当安全措施”“应按适用法律处理数据”，但没有具体到处理范围、分包限制、跨境安排、事件通知时限和删除返还要求。这类条款在签约阶段看上去已经覆盖了主题，真正到了争议场景却几乎不能指导执行，也很难追究责任。
标准要求默认考虑附录B全部相关控制，这一点对控制者很关键。它意味着合同起草逻辑应是“先逐条看哪些控制与该处理者相关，再说明不适用理由”，而不是“先写一份通用模板，剩下的以后再说”。二者差别很大。前者能形成经过风险判断的控制选择，后者则更容易把重要条款遗漏在模板之外，直到出现问题才发现合同没有给出真正边界。
三、实施要点
- 与所有参与处理 PII 的处理者签署书面合同，不以一般采购条款替代专门控制要求。
- 以附录B为基线逐项筛选相关控制，而不是只保留常见保密义务。
- 将不适用或排除的控制要求写明理由和替代措施，避免无声省略。
- 在合同中加入监督、报告、审计和终止处置机制，确保要求可验证。
- 7.2.6的核心是让控制者对外包处理链的控制要求具有合同约束力，而不是停留在内部期待。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 附录B映射模板 | 把处理者控制映射到合同条款 | 控制清单 |
| 处理范围描述模板 | 明确对方处理什么、为了什么 | 范围说明 |
| 供应商风险评估 | 确定合同控制强度 | 风险等级和附加条款 |
| 审计与报告机制 | 验证处理者履约情况 | 监督计划和整改要求 |
实践中，最有效的做法往往不是单独起草一份“隐私附件”了事，而是把关键控制要求融入主合同、数据处理附件、审计条款和终止条款之中，形成完整约束链。
在实施方法上，控制者还应把法务、采购、安全和业务负责人拉进同一份条款映射表。因为很多问题并非起草不到，而是起草后没有被正确落到供应商分级、上线门禁和履约检查上。只有当合同条款与供应商准入、年度复核、整改跟踪和退出机制联动时，这些条款才会从静态文本变成动态控制。
五、典型案例
- 只签保密协议没签处理控制：某控制者把客户数据交由外部平台处理，但合同只有笼统保密义务，没有附录B对应控制要求，后续在主体请求和分包问题上双方均称“合同没写清”。
- 不适用控制没有理由：另一组织认为某些处理者控制“不相关”而直接删去，但未记录原因，审查时无法证明其排除决定是基于风险判断而非疏忽。
这些案例说明，与处理者的合同若缺少控制映射，外部处理链条就很难真正纳入 PIMS。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| PII处理者合同 | 范围、责任、附录B控制和监督要求 |
| 控制映射记录 | 附录B条款与合同条款的一一对应 |
| 排除与例外说明 | 不适用控制的理由和替代措施 |
| 监督与审查记录 | 履约证明、整改和跟踪情况 |
这些记录能帮助控制者证明其已将处理者纳入正式控制边界，而不是将责任简单外包。
成文信息管理上，组织最好同时保存合同谈判中的关键判断痕迹，例如为什么某控制被排除、为什么接受处理者标准条款、为什么增加额外审计要求、为什么允许特定分包安排。因为在后续复盘里，真正难解释的往往不是合同最终长什么样，而是当初为什么接受了某种边界。没有这些判断记录，控制者很难证明自己的合同设计是基于风险选择而非随意妥协。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 有服务合同就等于有处理控制 | 附录B要求未进入可执行条款 | 将处理控制单独映射并固化 |
| 不适用控制可以直接删掉 | 后续无法解释为何排除 | 记录理由和替代安排 |
| 合同签完就结束 | 履约情况长期无人验证 | 保留监督、报告和审计机制 |
本条在真实项目中最容易失效的原因，是组织把合同签署当成终点，而不是治理起点。供应商能力会变，分包链会扩展，服务区域会调整，标准条款也可能更新。如果控制者没有建立版本跟踪和复核机制，当初写得还算完整的合同边界，几年后往往已经和实际处理状态脱节。
就 7.2 这一组控制的复核经验看，最常见的失守模式就是业务变化先发生，目的、依据、准许和记录随后才被动补记。短期内似乎还能自圆其说，时间一长就会形成大量“历史上到底为什么这样处理”的解释空白。因此，组织若想真正把 7.2 做实，就必须让用途变化、系统扩展、外部参与和合同变化自动触发前提条件复核，而不是依赖项目收尾时再统一补材料。
再往深一层看，7.2 组条款真正要防的并不是单次判断做错，而是组织失去对“起点条件”的持续记忆。一旦项目从立项进入运行，最初写下的目的、依据和合同边界很容易被迭代节奏冲淡，后续团队只看当前功能和数据是否可用，却不再回看这些条件最初为何成立。对控制者来说，真正成熟的做法不是偶尔复盘，而是让前提条件像代码和配置一样被持续维护、持续比对和持续更新。