信息技术变更管理工作流（SOC 2 CC8.1）

运作方式

1. 从分类开始

   用你们自己系统里的具体例子来定义标准变更、常规变更和紧急变更。一套没人能在不发问的情况下套用的分类，实际结果就是所有变更都被归成“常规”。

2. 预先批准标准变更

   把低风险且反复发生的变更列成清单，让它们无需逐项审批即可执行。只有这样，正式路径才会被用在它真正该用的地方。

3. 把审批与上线分开

   这两步应当分处两条泳道，各有各的责任人。这是 SOC 2 走查最先测试的一点，而且事后几乎补不出证据。

4. 把紧急通道连同它的时限一起画出来

   紧急变更可以先于审批上线，但事后的审批与评审必须在节点上写明时限。没有时限的紧急通道，就是一条绕行路径。

5. 以实施后评审收尾

   补上评审失败变更与已回滚变更的那一步。上线失败中的规律正是在这里显现出来——而这也是最常被漏掉的一步。

常见问题

SOC 2 CC8.1 对变更管理有什么要求？

CC8.1（影响系统的变更）要求有成文程序来评估、审批、测试和上线变更，并要求提供证据，证明审计期内被抽查到的那些变更确实是按该程序执行的。

在变更管理上，QueryChart 与 Jira 这类工单系统有什么不同？

工单系统跟踪的是一个个变更工单；它们并不记录变更管理流程本身受控的当前版本。QueryChart 记录的是流程——也就是那份受控文件——好让审计员先看到设计，再到 Jira 或 ServiceNow 里对运行情况抽样。

标准变更、常规变更和紧急变更有什么区别？

标准变更低风险、反复发生并且已预先批准——例如例行的证书续期。常规变更必须先经过影响评估与审批，才能上线。紧急变更用于解决紧急的生产问题，可以先上线，条件是事后在规定期限内补齐审批与评审。三条通道都必须出现在图上，否则这张图描述的就不是实际在跑的那个流程。

所有变更都要经过变更咨询委员会（CAB）吗？

不需要，而且一个什么都审的委员会会变成瓶颈，组织随后就会开始绕开它。让委员会审那些跨部门、影响客户或需要停机的变更，其余的交由一位具名的变更负责人审批。对审计员而言，关键在于哪些变更必须上会的判定标准写在受控流程里——而不在于委员会是不是看过了所有东西。