一、ISO/IEC 27701:2019 6.11.2 标准原文
原文摘要：本条对应 ISO/IEC 27002:2013 14.2，包括安全的开发策略、系统变更控制规程、运行平台变更后的技术评审、软件包变更限制、系统安全工程原则、安全的开发环境、外包开发、系统安全测试和系统验收测试。2019版在 6.11.2.1 中补充提出，系统开发和设计策略应基于 PII 原则、适用法律义务和组织的处理类型，并在里程碑中设置 PII 保护检查点，默认最小化 PII 处理；在 6.11.2.5 中补充提出，与 PII 处理有关的系统和组件应采用设计中的隐私原则和默认隐私原则构建，并能支持如按期删除等控制；在 6.11.2.7 中补充提出，这些隐私设计原则同样适用于外包信息系统。整体上，6.11.2要求组织把 PII 保护从单个功能点提升为研发和支持过程的长期约束。
二、条款解读说明
6.11.2 是 6.11 中最具有工程实践色彩的一组条款。它关注的是系统在开发、维护、升级、外包、测试和验收过程中，如何持续保持安全和隐私保护能力不被削弱。对 PIMS 而言，这一组条款的意义非常直接：即使需求阶段想清楚了，如果后续开发和支持过程没有足够纪律，系统同样会在版本迭代、组件替换、平台升级和供应商交付中逐步偏离原来的 PII 边界。
27002 的 14.2 原本就强调开发规则、变更控制、平台评审、软件包修改限制、安全工程原则、安全开发环境、外包、测试和验收。27701 的补充则把这些要求与隐私原则更紧密地绑定起来。也就是说，标准不满足于“开发要安全”，它还要求开发要内生最小化、隐私设计、默认保护、定期删除和对外包同样有效的约束。
| 子条款群 | 主要解决的问题 | PIMS中的核心价值 |
|---|---|---|
| 6.11.2.1-2.5 | 开发策略、变更、平台评审、工程原则是否守住 PII 边界 | 防止系统在设计和演进中偏离隐私目标 |
| 6.11.2.6-2.7 | 开发环境和外包开发是否扩大 PII 暴露面 | 防止支持性环境成为真实数据风险源 |
| 6.11.2.8-2.9 | 安全测试和验收是否真正验证隐私能力 | 确保交付的是“能用且守边界”的系统 |
2019 版在 6.11.2.1 和 6.11.2.5 中反复强调“设计的隐私原则”和“默认的隐私原则”，这说明 27701 很关注一个现实问题：很多系统即使表面支持某些隐私流程，也只是靠人工操作、项目例外或补充脚本维持，而不是在设计上天然倾向于最小化、最少披露和可退出。标准希望开发策略和工程原则能把这种倾向变成默认值，而不是把保护建立在“有人记得去额外处理”上。
对 PII 处理系统来说，6.11.2 最容易暴露问题的地方通常是系统演进。新模块上线时可能还能比较完整地考虑隐私要求，真正被忽略的往往是版本小改、依赖库替换、平台迁移、补丁更新、紧急修复、外包重构和上线前最后一轮配置修改。若这些过程没有统一纪律，再好的初始设计也会被一点点磨损。
这组条款还反映出一个成熟研发组织的基本特征：隐私和安全要求不是“审计来时再补的材料”，而是版本控制、代码评审、工程规范、交付验收和供应商管理的一部分。只要组织仍把这些要求当成研发之外的附加任务，6.11.2 就很难真正落地。
因此，6.11.2 的本质，是把 PII 保护固化到研发和支持过程本身，让每次设计、每次修改、每次交付都在同一套边界下进行。只有过程被治理，结果才可能持续稳定。
三、实施要点
- 把隐私原则和最小化处理要求写进开发策略、工程原则和交付准则，而不是只放在制度文件里。
- 用正式的变更和平台评审机制保护原有 PII 边界不被版本演进悄悄侵蚀。
- 对软件包改动、开发环境、外包开发和测试验收建立与内部开发同等强度的要求。
- 让研发、架构、安全、隐私和供应商管理在同一流程中协同，而不是各自补充要求。
- 6.11.2的核心是让开发和支持过程本身具备守住 PII 保护目标的能力，而不是靠少数人额外补位。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 开发策略与工程规范 | 把隐私原则、最小化和删除能力写进研发规则 | 研发基线和设计标准 |
| 变更与平台评审流程 | 避免升级和修复破坏既有控制 | 评审记录和回退要求 |
| 外包与环境控制 | 规范开发环境和第三方交付质量 | 合同条款、环境要求和审计证据 |
| 安全测试与验收准则 | 验证系统是否按要求保护 PII | 测试报告和验收结论 |
实践中，最有效的方法通常是把 PII 检查点嵌进现有研发里程碑，而不是另起一套完全独立流程。例如在方案评审时确认最小化和删除能力，在变更评审时确认日志和展示边界，在上线前确认测试环境和外包交付是否带入真实数据风险。
对已经上线多年的系统，也应重新用 6.11.2 的视角检查“历史上哪些开发和支持习惯已经变成结构性风险”，例如默认共享测试环境、库升级无隐私回归验证、紧急补丁长期绕过标准评审等。
五、典型案例
- 功能迭代压过隐私原则：某平台为了提升转化率不断增加字段采集与行为记录，但开发策略中没有最小化处理和里程碑检查点，结果系统逐渐变成“能收都收、以后再说”的状态。
- 外包交付只验功能：某外包项目按期交付且功能完整，但默认日志过度、测试数据治理薄弱、删除能力缺失，说明开发和支持过程并未真正吸收 PII 保护要求。
这些案例说明，6.11.2 的问题往往不在某个点，而在整个过程长期缺少对 PII 边界的持续约束。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 开发安全与隐私策略 | 设计原则、最小化要求、里程碑检查点和角色职责 |
| 变更与评审记录 | 版本变更、平台升级、风险评估和批准结果 |
| 外包与环境控制文件 | 供应商要求、开发环境边界和审计证据 |
| 测试与验收材料 | 安全测试范围、缺陷修复和验收结论 |
这些文件能证明组织不是仅在系统上线后才谈隐私保护，而是已将其纳入开发和支持过程的正式治理。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 开发安全只等于代码安全 | 最小化、删除和默认隐私原则缺席 | 把 PII 保护原则纳入研发规则 |
| 小变更和补丁不用看隐私影响 | 边界在频繁迭代中被逐渐磨损 | 让变更和平台评审持续覆盖 PII 风险 |
| 外包开发可按供应商习惯执行 | 交付质量和隐私能力难以对齐 | 将内部原则延伸到外包过程 |
6.11.2 真正要防止的，是组织把 PII 保护理解成“项目刚开始时想一次，上线前查一次”。标准在这里明确强调的是过程持续性。只要系统还在维护、升级、修补和外包，这条控制就一直在生效，不存在“已经做完”的状态。
因此，评估本条成熟度时，最好看最近几次真实迭代：变更是否评估了隐私影响，平台升级是否复核了关键控制，外包交付是否证明了隐私能力，测试是否覆盖了真实高风险场景。能在这些问题上持续拿出证据，才说明 6.11.2 已经进入组织的工程实践，而不是停留在概念层面。
本条最终守住的，是系统长期演进过程中的边界稳定性。PIMS 真正难的不是设计一次，而是设计以后还能一直守住。6.11.2 正是在处理这件最难的事。