审计师认可的变更管理证据

在 SOC 2 Type II 审计中，变更管理（CC8.1）是抽样最频繁的控制之一：审计师会从整个审计期间抽取变更，要求您逐一证明每项变更在投入生产前均已获得授权、经过测试并已批准。ISO 27001（A.8.32）、PCI DSS（6.5.1、6.5.2）以及 NIS2 实施条例（第6.4点）的要求措辞不同，但实质相同。工程团队通常已经完成了这些工作，缺失的往往是证据。

审计师测试什么

对于抽取的变更样本，审计师希望看到：

1. 变更已提出并作出描述：有工单或拉取请求说明变更内容及原因。
2. 由作者以外的人员进行了审查：职责分离。
3. 在投入生产前经过了测试，并附有测试结果。
4. 在部署前已获得批准。
5. 部署的内容与获批的内容一致：没有未经审查的代码进入生产环境。
6. 样本总体完整：每项生产变更都经过了该流程，包括基础设施和配置变更。

有效的证据

• 分支保护：主分支在合并前须至少有一名作者以外人员的批准审查，并通过所有检查。导出设置，并证明其在审计期间未发生变更。
• 仅通过流水线部署：生产部署仅可通过 CI/CD 从受保护分支发起；工程师无法直接推送。
• 关联记录：每次部署均关联到已合并的拉取请求，而该拉取请求又关联到其工单。
• 基础设施即代码：适用相同规则，使基础设施变更留下同样的记录轨迹。
• 部署工具导出的完整变更清单：涵盖整个审计期间，审计师可据此抽样。

紧急变更

每个流程都需要为事件设置快速通道，审计师也期望有此安排。请明确定义：谁有权批准、事后审查须多快完成（通常为一到两个工作日内），以及变更如何关联到事件。然后确保紧急变更确实很少发生。

导致审计失败的情形

• 拥有生产环境直接访问权限的管理员，有时会绕过流水线。
• 自我批准的拉取请求，或仅由机器人完成的审查。
• 在控制台中进行、没有任何记录的配置变更。
• 审计期间"临时"关闭分支保护。
• 除"CI 已通过"外没有测试证据，而该变更本需要更多测试。

抽样：审计师实际会做什么

在 SOC 2 Type II 审计中，审计师通常会要求提供审计期间全部生产变更的完整总体，从中抽取样本（样本量取决于总体规模及审计师的方法），并要求您针对每项抽中的变更提供以下证据：变更请求、作者以外人员的审查、测试结果、审批记录，以及部署内容与获批内容一致的证明。

由此带来两点实际影响。第一，总体必须完整且可导出：如果变更可以通过多种途径进入生产环境，则每种途径都需要有记录。第二，任何一项被抽中的变更若缺少证据，都会在报告中形成例外事项。与其在审计时补做记录，不如改进流程，使证据自动生成，成本更低。

SOC 2 CC8.1 页面 展示了该标准条款如何与 ISO 27001、PCI DSS 和 NIS2 对应。

一个流程，适用所有框架

在本站数据中，变更管理要求在各框架之间存在关联：

方向	已映射	弱相关	无映射
已有 SOC 2 → 需要 NIS2	47 / 49 (96%)	1	1	报告 →
已有 NIS2 → 需要 SOC 2	37 / 61 (61%)	0	24	报告 →

基于拉取请求、配合受保护分支和仅流水线部署的流程，可同时满足 SOC 2、ISO 27001、PCI DSS 和 NIS2 的要求。PCI DSS 另有几项额外要求：将预生产环境与生产环境分离（6.5.3）、禁止在测试中使用真实账户数据（6.5.5），以及在重大变更后确认安全要求（6.5.2）。

请参阅安全开发主题了解相关要求，并阅读我们的文章在 SOC 2、ISO 27001 和 PCI DSS 之间复用证据。

常见问题

对于 SOC 2 而言，拉取请求是否算作变更批准？

通常可以，前提是代码仓库在合并前强制要求作者以外的人员进行审查，部署仅限于已批准的代码，并且您能够针对整个审计期间的变更样本证明这一点。

审计时应如何处理紧急变更？

设定明确的紧急流程：如有需要先修复；随后在规定时间内完成事后审查和批准，并保留一份记录，将变更与触发该变更的事件相关联。