一、ISO/IEC 27701:2019 8.2.2 标准原文
原文摘要：标准要求组织确保代表客户处理 PII 仅按照客户书面说明中所述的目的进行。实施指南指出，合同应包括服务目标和时间范围；组织可能因技术原因选择适当处理方法，但应与客户的通用指令保持一致，并允许客户验证组织及其分包商未将 PII 用于其他目的。
二、条款解读说明
8.2.2 是处理者边界控制中的核心条款。它把一个非常朴素但经常被稀释的原则写得很清楚：处理者只能按照客户书面说明的目的处理 PII。标准允许处理者在技术实现层面做适当判断，例如如何分配资源、如何设计系统路径，但这种判断必须服务于既定目的，而不能演变成对目的本身的扩张、替换或再解释。
现实里，处理者越界往往并不是从明显的“擅自售卖数据”开始，而是从“顺手多做一点”开始。比如为了系统优化而长期留存更多字段，为了算法训练而把客户数据纳入内部模型，为了运营分析而把不同客户数据放到同一个数据池中重新利用。只要这些用途没有被客户书面说明覆盖，处理者就已经偏离了 8.2.2 的要求。
| 边界问题 | 8.2.2的判断标准 | 处理者应如何自检 |
|---|---|---|
| 目的是否明确 | 客户是否以书面方式说明处理目标 | 没有书面依据就不扩展处理 |
| 方法是否越线 | 技术实现是否改变了原有目的边界 | 区分方法优化和目的扩张 |
| 分包是否一致 | 分包商是否也只按原目的处理 | 把书面指示下沉到整个处理链 |
| 客户是否可验证 | 客户能否检查处理者是否按边界执行 | 准备可审查证据和解释材料 |
标准特别提到组织应允许客户验证其是否符合目的规范和限制原则，这意味着 8.2.2 并不是内部自我宣称即可。处理者需要能向客户证明：当前处理活动、日志、分包安排和系统配置确实没有把 PII 带向其他目的。对平台型和多租户型处理者来说，这尤为重要，因为内部资源共享和技术复用很容易让客户数据边界在后台被模糊化。
因此，8.2.2 的本质是把“按指示处理”从抽象口号变成处理者的运行纪律。技术选择可以灵活，但目的边界不能被技术团队自行重写。
从处理者边界控制看，8.2.2 的关键不在于处理者完全没有技术自主性，而在于这种自主性只能发生在“如何实现客户目的”层面，不能扩展到“是否增加新的目的”。现实中最容易发生的越界，并不是公开宣布把客户数据拿来做别的事，而是在产品优化、故障分析、模型训练、反欺诈联防和跨租户统计中，一点点把原本只为客户服务的处理扩大成处理者自己的持续用途。
这条控制还要求处理者让客户可验证自己和分包商没有超目的处理。也就是说，边界不是处理者自己心里清楚就够了，而要能够通过配置、日志、分包限制和审计证据体现出来。否则即便处理者主观上认为自己只是做技术优化，只要客户无法验证这些动作仍服务于原书面目的，信任边界就会迅速变弱。
三、实施要点
- 要求所有受托处理活动都能对应到客户书面说明、合同条款或正式变更记录。
- 对产品优化、模型训练、统一分析和内部复用设置专门目的越界检查。
- 将客户目的限制同步给分包商和内部多团队，避免后端复用超出原边界。
- 准备可供客户验证的证据，包括配置、日志、流程和分包说明。
- 8.2.2的核心是让处理者始终围绕客户书面目的运行，而不是让便利性逐步侵蚀受托边界。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 客户目的台账 | 统一记录客户书面指示和变更 | 目的描述、范围、版本和生效时间 |
| 越界用途审查表 | 检查内部新功能是否超出客户目的 | 评审结论和整改意见 |
| 分包目的下传机制 | 确保分包处理不偏离原边界 | 分包条款和验证记录 |
| 客户验证资料包 | 支持客户审查处理边界执行情况 | 配置说明、日志样例和控制描述 |
真正成熟的处理者不会把“客户目的”只放在合同里，而是会把它翻译成产品开关、租户配置、权限范围和分包约束。这样一来，边界才不会只存在于法务文件中。
在实施方法上，处理者最好为每类客户服务建立“目的约束清单”，把允许的处理操作、允许的配置差异、禁止的自用场景和分包可见性要求写成产品和运营规则。这样当团队准备把某项能力推广到所有租户时，能够先判断该能力是否仍在各客户书面说明覆盖范围内，而不是默认平台级优化天然正当。
五、典型案例
- 平台顺手拿客户数据训练模型：某处理者认为利用客户数据改进算法属于“服务提升”，但客户书面目的仅限订单处理，双方因此爆发严重信任危机。
- 分包商自作主张复用日志：另一家处理者的分包技术团队将客户日志用于内部性能分析，却没有把客户目的限制同步下去。
这些案例说明，8.2.2 不是限制技术进步，而是要求技术活动始终服从受托边界。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 客户书面指示记录 | 处理目的、范围、期限和变更历史 |
| 越界审查记录 | 新功能、新用途和内部复用的边界判断 |
| 分包目的限制条款 | 分包商处理范围和禁止事项 |
| 客户验证材料 | 证明仅按目的处理的配置和执行证据 |
这些材料能够帮助处理者证明，其受托处理始终围绕客户书面目的展开，没有借技术实现之名发生用途漂移。
成文信息管理上，8.2.2 应保留客户书面指示、目的说明版本、配置差异、目的变更确认和分包商遵循同一目的边界的证明。因为处理者最常见的风险不是完全没有目的说明，而是在客户需求变化、产品升级和模板合同复用中，原本清楚的目的逐渐被重新解释。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 技术优化可以顺便扩展目的 | 客户数据被带入内部用途 | 技术方法服从书面目的边界 |
| 客户大概知道就够了 | 缺少正式书面依据 | 坚持以书面说明和变更记录为准 |
| 只管自己不管分包 | 下游处理链偏离目的 | 把目的限制下沉到分包层 |
本条最容易失效的原因，是处理者把“提升平台能力”“改进客户体验”当成可以自动覆盖所有附加处理的万能理由。只要这种内部语言长期不被约束，客户书面目的就会被平台自我解释不断稀释，最终让受托边界名存实亡。
就 8.2 这一组处理者控制而言，最常见的失守模式是平台通用运营逻辑逐步压过客户边界。合同、书面指示和记录最初都在，但随着产品统一化、区域扩展、增长目标和供应商变化不断推进，团队开始默认“对所有客户都这么处理也没问题”。一旦这种默认形成，处理者就会在不知不觉中把受托处理做成自我决定的处理，最终既削弱客户控制，也削弱自身可证明性。
换个角度看，8.2 真正成熟的标志，是处理者能把客户边界转化成可被测试的产品与运营约束。客户问起某项功能是否会自用数据、某条路径是否受合同限制、某个变更是否超出书面指示时，处理者不需要再临时解释，而能直接指向既定规则、既定配置和既定记录。这种“边界可验证性”才是受托角色真正稳固的表现。
客户边界若不能被产品配置和审计证据共同证明，处理者最终仍会被平台惯性带着走。