一、ISO/IEC 27701:2019 6.11.2.7 标准原文
原文摘要：本条对应 ISO/IEC 27002:2013 14.2.7。标准要求组织督导和监视外包系统开发活动。实施指南指出，外包开发时应关注许可证、代码所有权和知识产权，合同中的安全设计、编码和测试要求，批准的威胁模型，交付件的验收测试，最低可接受安全和隐私能力的证据，恶意内容和已知脆弱性的测试证据，源代码托管安排，对开发过程和控制进行审计的合同权利，构建环境文件化，以及组织仍保有遵守法律法规和验证控制有效性的责任。2019版进一步补充，设计中的隐私原则和默认隐私原则同样适用于外包信息系统。对 PIMS 而言，这一条明确说明：开发工作可以外包，但处理 PII 的责任边界不能一起外包出去。
二、条款解读说明
6.11.2.7 是很多组织极其容易误判的一条。项目一旦进入外包模式，团队常常会把开发细节、技术路线甚至控制设计都交给供应商决定，自己只保留需求清单和上线时间表。但从标准角度看，外包开发从来不是责任转移，而是一种执行安排。特别是当系统处理 PII 时，组织仍需定义最低保护要求、验证交付是否达到这些要求，并保有对法律法规与合同义务的最终响应能力。
27002 在这一条里列出的内容非常具体，说明标准并不接受“在合同里写一句要安全开发”这种笼统做法。对外包项目，组织需要事先说清楚代码归属、谁负责安全设计、威胁模型由谁确认、哪些测试证据必须提供、接受哪些脆弱性阈值、对分包有没有限制、出了问题是否有权审计过程和工具链。否则等到交付件出现隐私缺陷时，双方很容易互相指责，却没有足够证据说明谁在什么阶段应承担什么责任。
| 外包控制点 | 如果缺失的典型问题 | PIMS中的重点 |
|---|---|---|
| 合同与所有权 | 代码、模型、日志和接口文档归属不清 | 发生争议时难以要求整改、审计或移交 |
| 安全与隐私设计要求 | 供应商按功能便利性设计默认流程 | 最小化、默认隐私和删除能力无法兑现 |
| 测试与验收证据 | 只提交可运行版本，不提交缺陷与测试结论 | 组织无法证明交付件是否足够保护 PII |
| 审计与分包控制 | 实际开发再层层转包，甲方不可见 | 真实接触 PII 设计和样本的人超出预期 |
2019 版补充“设计中的隐私原则和默认隐私原则也适用于外包信息系统”，这一点非常关键。它意味着外包项目不能因为供应商习惯不同，就放松原本应该纳入系统设计的 PII 要求。比如默认少收字段、默认少展示、按处理目的限制使用、便于按主体删除、日志不过度记录等，这些都应在外包项目初期就进入设计边界，而不是到上线前才要求供应商临时补丁式整改。
外包开发还会放大供应链问题。组织直接签约的供应商，未必就是实际写代码、管理样本和操作构建环境的人。若合同没有限制分包、没有要求传递隐私和安全基线、没有规定谁能接触测试数据和构建密钥，就会出现甲方只认识一级供应商，真正的风险却在更深层分包链路中积累。对 PII 系统来说，这种不可见性本身就是高风险。
标准强调组织仍保有遵守法律法规和验证控制有效性的责任，也是在堵一个常见借口：系统出问题了，不能简单说“这是外包商做的”。如果系统处理的是个人信息，对主体、客户或监管机构来说，首先面对的通常仍是委托开发的一方。因此，组织必须能证明自己在需求、合同、监督、测试、验收和上线前复核等环节已经做了应尽工作。
外包开发的真正难点，不在于把供应商管得多细，而在于把必须由组织自己定义的底线定义清楚。需求可以由双方共同澄清，技术实现可以由供应商负责，但哪些 PII 能收、默认展示到什么程度、日志记录到什么粒度、删除能力必须如何提供、上线前要拿到哪些证据，这些都不能模糊。
因此，6.11.2.7 的本质，是要求组织用合同、证据、过程监督和验收机制把外部执行纳入自己的 PIMS 逻辑，而不是把开发活动一旦外包就看成黑箱采购。
三、实施要点
- 在外包项目启动前明确安全与隐私基线，把设计中的隐私原则和默认隐私要求写入需求与合同。
- 要求供应商提交与威胁模型、测试结论、脆弱性处理、构建环境和交付件完整性相关的客观证据。
- 明确代码、文档、日志、测试工件和构建产物的归属与移交规则，避免后续整改受制于人。
- 对分包、远程开发、样本接触、构建密钥和审计权做清晰约束，不能只看一级供应商承诺。
- 6.11.2.7的核心是让组织在外包模式下仍能定义、验证并持续守住 PII 处理系统的设计底线。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 外包开发控制清单 | 把合同、证据、分包、验收和移交要求统一列明 | 条款矩阵和责任分配表 |
| 安全与隐私需求基线 | 把默认隐私、最小化和删除能力提前写入项目要求 | 需求规格和设计约束 |
| 供应商证据包机制 | 要求提交测试、构建、漏洞处理和缺陷修复证明 | 证据目录和验收记录 |
| 审计与源代码托管安排 | 保障过程可审、交付可移交、风险可持续管理 | 审计条款、托管协议和移交流程 |
实践中，很多外包项目真正需要的是一份“最低可接受控制包”，而不是无穷无尽的通用安全条款。对承载 PII 的系统，这份控制包至少应回答几个问题：系统默认如何限制个人信息收集和展示，供应商使用什么开发环境与数据规则，哪些安全测试必须通过，脆弱性接受标准是什么，若需真实样本由谁批准，交付时需提供哪些日志、文档、源代码和构建说明。把这些问题前置，通常比在验收阶段临时争论更有效。
如果组织历史上已经有多个外包项目，还应做横向复盘，看看哪些隐私缺陷总在外包场景反复出现。常见模式包括默认字段过多、日志留存过长、调试接口残留、删除能力缺失、供应商无法解释构建来源、分包链条不透明等。把这些真实经验沉淀到后续合同和验收模板里，控制效果会明显提高。
五、典型案例
- 按时交付了，但默认暴露也被交付了：某客户门户由外部团队开发，功能层面完全满足需求，但个人资料页面默认展示了远超业务所需的字段。项目之所以在验收前无人发现，是因为合同和评审从未把默认隐私原则列为必验项。
- 交付件可运行，却说不清从哪里构建出来：某组织接收了供应商提供的发布包，后续发现其中包含已知漏洞依赖和调试组件，但由于没有要求保留构建环境和依赖来源文件化，供应商也无法清楚证明问题是在何时引入的。
这些案例说明，外包风险往往不是供应商完全不作为，而是组织没有把“什么算合格交付”定义到足够细，导致功能完成被误当成控制完成。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 外包开发合同与附件 | 代码归属、审计权、分包限制、安全与隐私要求、移交规则 |
| 项目安全与隐私基线 | 默认隐私、最小化、日志、删除、测试和验收标准 |
| 供应商证据与验收记录 | 威胁模型、测试报告、漏洞修复说明、构建环境文档 |
| 分包与接触范围记录 | 实际参与方、接触权限、样本使用审批和外部访问说明 |
这些成文信息的作用，不只是为了审计留档，更是为了在项目后期出现争议、缺陷或监管问询时，能够清楚说明组织曾提出何种要求、供应商提交了哪些证据、哪些风险被接受、哪些问题被整改。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 外包后技术细节由供应商全权决定 | 默认隐私和最小化等底线无人定义 | 由组织先明确不可退让的 PII 处理要求 |
| 验收只看业务功能和页面效果 | 隐私风险直到上线后才显现 | 把安全与隐私测试结果纳入交付门槛 |
| 一级供应商可信就等于整条链路可信 | 分包团队和外部工具链处于盲区 | 要求供应商传递控制要求并保留可见性 |
6.11.2.7 最需要警惕的，是把外包项目管理做成纯采购管理。采购关注价格、时点和交付数量没有问题，但对 PII 系统来说，这远远不够。真正决定后续风险的，是组织有没有让供应商在设计、开发、测试和交付全过程都围绕既定隐私边界工作，并能拿出可验证证据。
检查本条是否真正落地，可以直接看一个外包项目的验收包里有没有这些内容：需求中的隐私约束、威胁模型、关键测试结果、漏洞整改说明、构建来源、源代码或托管安排、分包披露、上线限制条件。如果验收包只有需求说明和功能演示录像，那通常说明控制还停留在形式层面。
本条最终守住的，不是供应商是否听话，而是组织在借助外部能力开发系统时，仍然没有丢掉自己对 PII 处理边界的定义权、验证权和追责能力。