一、ISO/IEC 27701:2019 6.11.3 标准原文
原文摘要：本节对应 ISO/IEC 27002:2013 第14.3章“测试数据”。该章的目的，是确保用于测试的数据得到保护。标准进一步指出，系统测试和验收测试通常需要大量尽可能接近运行数据的测试数据，因此组织不能把测试数据当成无关紧要的临时材料。对 PIMS 而言，这一节提醒组织，测试活动本身也可能构成 PII 处理场景；一旦测试数据的选择、生成、复制、使用和清理缺乏控制，开发和测试环境就会迅速演变成影子数据处理体系。
二、条款解读说明
6.11.3 虽然只是一个节标题，但它在研发控制体系里的意义并不小。很多团队把测试数据理解成测试工程师临时准备的素材，认为只要系统本身安全，测试阶段的数据不需要过多关注。然而 ISO/IEC 27002 把“确保用于测试的数据得到保护”单独设为目标，正是在强调：测试数据并不是研发细节，而是研发活动中必须被治理的一类资产。
对 PIMS 来说，测试数据的风险尤其突出，因为测试场景天然追求“接近真实”。系统越复杂，测试就越希望拥有真实结构、真实分布、真实边界条件和真实业务轨迹的数据。也正因为如此，很多组织最容易在这一环节滑向直接复制生产数据、长期保留真实样本、将含 PII 的数据用于调试培训、在外包或多团队协作中不断传播测试副本。表面上这些行为都在支持质量保障，实质上却把 PII 带入了大量原本不必要的场景。
| 测试数据生命周期阶段 | 常见问题 | PIMS中的重点 |
|---|---|---|
| 选择与生成 | 优先复制生产数据，缺少假数据和合成数据策略 | 避免不必要地把真实 PII 引入测试 |
| 复制与分发 | 通过共享盘、邮件、工单或即时通信传播副本 | 控制测试数据的流向和接触范围 |
| 使用与留存 | 测试结束后仍长期保存或复用旧副本 | 防止测试环境变成常态化隐性数据仓库 |
| 清理与证明 | 数据删除无记录，谁持有副本说不清 | 形成可验证的清理和审计闭环 |
本节之所以重要，还因为它连接了多个前后条款。安全的开发环境决定测试数据放在哪、谁能接触；系统安全测试和验收测试决定测试数据如何被使用；后续的供应商关系和事件响应又会受到测试数据外流、误用和清理失败的影响。换句话说，测试数据并不是某个单一控制点，而是研发治理是否真实落地的一面镜子。只要测试数据管理混乱，前面的很多控制看起来再完整，也很容易被架空。
对处理 PII 的系统而言，测试数据治理的核心不是一味追求“绝不碰真实数据”，而是先明确优先级。首选始终应是假的或合成的数据，其次才是在确有必要时、带着充分理由和等效控制使用少量真实数据。很多团队的问题不在于偶尔因复杂故障排查需要接触真实样本，而在于从一开始就把真实副本视为默认方案。标准想纠正的，正是这种默认思维。
测试数据还涉及组织内部不同角色之间的责任划分。谁可以批准使用真实数据，谁负责生成合成数据，谁维护脱敏规则，谁确认测试完成后清理，谁负责记录复制和下载，谁对外包团队的测试样本使用承担监督责任，这些都不应处于模糊状态。对 PIMS 来说，角色不清就意味着风险出现时很难快速收口。
另一个容易被忽视的问题，是测试数据与文档、截图、录屏、案例工单和培训材料之间的关系。即使数据库副本本身管理得还不错，只要真实 PII 被复制进测试报告、错误截图、接口回包说明、培训课件或聊天讨论中，测试数据的边界依然会被打破。因此，测试数据治理不能只盯数据库或文件包，还要覆盖围绕测试活动产生的辅助材料。
因此，6.11.3 的本质，是把测试数据从“临时资源”提升为“受控对象”。只有这样，组织才能确保研发和验收阶段不会悄悄扩张 PII 的实际处理范围。
三、实施要点
- 将测试数据纳入正式治理范围，覆盖选择、生成、复制、使用、留存和清理的全过程。
- 优先建立假数据和合成数据能力，把使用真实 PII 视为需要额外论证和审批的例外场景。
- 控制测试数据在仓库、共享盘、工单、聊天工具、录屏和报告等多种载体中的扩散。
- 明确测试数据相关责任人和清理证明机制，避免副本长期散落在不可见位置。
- 6.11.3的核心是防止“为了测试方便”演变成无边界的 PII 复制和传播。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 合成与脱敏数据策略 | 为常见测试场景提供不依赖真实 PII 的数据来源 | 规则集、模板和生成说明 |
| 测试数据审批流程 | 管理例外使用真实数据的必要性和范围 | 审批记录和使用条件 |
| 数据流向与清理台账 | 记录测试数据被复制到哪些环境和载体 | 副本清单和清理证明 |
| 辅助材料检查机制 | 控制截图、录屏、工单和报告中的真实 PII 暴露 | 审查记录和整改清单 |
实践中，组织不一定需要一开始就建设非常复杂的合成数据平台，但至少要先把高频测试场景的基础样本标准化，例如注册、认证、权限切换、同意管理、撤回授权、下载导出、删除请求、异常报错和接口联调。只要这部分场景有了可复用的假数据样本，团队对真实 PII 的依赖就会显著下降。
对于历史上已经大量依赖生产副本的团队，较务实的第一步往往是先盘清现状，而不是立刻要求全部清零。组织可以先识别哪些系统和团队仍在使用真实测试数据、这些数据在哪里、谁能访问、保存多久、是否流向外部供应商，再按风险高低逐步收缩。这种渐进治理比口号式禁令更容易真正落地。
五、典型案例
- 测试库变成事实上的第二生产库：某团队长期将生产数据定期复制到测试环境，用于回归测试和培训演示。几年后，测试环境中的账号体系、导出功能和共享访问远比生产宽松，结果问题不是一处漏洞，而是测试库本身已经演变成高风险 PII 资产。
- 真实样本从数据库外溢到文档体系：某项目虽然对测试数据库做了权限控制，但开发和测试人员在缺陷单、培训文档和会议截图中大量使用真实姓名、号码和地址，导致组织低估了实际的数据传播范围。
这些案例说明，测试数据风险并不只存在于数据库转储文件中，只要测试活动需要“解释问题”，真实 PII 就可能顺着各种辅助材料继续扩散。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 测试数据管理制度 | 数据来源优先级、审批要求、使用边界和清理规则 |
| 合成与脱敏规则说明 | 样本生成方法、字段替换逻辑和适用场景 |
| 测试数据副本台账 | 复制位置、使用团队、保留期限和销毁状态 |
| 辅助材料审查记录 | 工单、截图、录屏和报告中真实 PII 的检查与整改 |
这些文件能帮助组织说明测试数据不是无人负责的临时物料，而是一类有来源、有边界、有记录、有退出机制的受控资产。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 测试数据不是正式业务数据，无需严格管理 | 真实 PII 在测试场景中长期复制和传播 | 把测试数据纳入正式治理和审计范围 |
| 只控制数据库，不必管文档和截图 | 真实 PII 通过缺陷单、录屏和培训材料继续外溢 | 覆盖测试活动产生的各类辅助载体 |
| 先复制生产数据提高效率，后面再慢慢治理 | 测试环境逐渐成为不可见的第二处理体系 | 优先发展合成数据并压缩真实数据例外范围 |
6.11.3 最值得警惕的，是把测试数据治理理解成单点技术问题。实际上，它更像一个组织习惯问题：团队是否已经习惯在遇到复杂场景时先找假数据方案，还是第一反应就是复制真实记录。前一种习惯会逐步降低 PII 接触面，后一种习惯则会让影子数据处理不断扩张。
判断本节是否成熟，可以直接看组织对三个问题有没有明确答案：哪些团队仍使用真实测试数据，为什么必须使用，测试结束后如何证明清理完成。如果这三个问题长期无人能答，说明测试数据治理尚未真正启动。
本节最终守住的，是研发和验收活动与真实 PII 处理之间的边界。测试应服务于质量，而不应成为另一个难以察觉的数据处理场景。