資訊科技變更管理工作流程（SOC 2 CC8.1）

運作方式

1. 由分類開始

   用你們自己系統裡的具體例子，去定義標準變更、常規變更和緊急變更。一套沒有人可以在不發問的情況下套用的分類，實際結果就是所有變更都被歸成「常規」。

2. 預先批准標準變更

   把低風險而且反覆出現的變更列成清單，讓它們無須逐項審批即可執行。只有這樣，正式路徑才會用在它真正應該用的地方。

3. 把審批與上線分開

   這兩步應當分處兩條泳道，各有各的負責人。這是 SOC 2 走查最先測試的一點，而且事後幾乎補不出證據。

4. 把緊急通道連同它的期限一併畫出來

   緊急變更可以先於審批上線，但事後的審批與檢討必須在節點上寫明期限。沒有期限的緊急通道，就是一條繞行路徑。

5. 以實施後檢討收尾

   補上檢討失敗變更與已回滾變更的那一步。上線失敗當中的規律，正是在這裡浮現出來——而這也是最常被漏掉的一步。

常見問題

SOC 2 CC8.1 對變更管理有甚麼要求？

CC8.1（影響系統的變更）要求有成文程序去評估、審批、測試與上線變更，並要求提供證據，證明審計期內被抽查的那些變更確實是按該程序執行的。

在變更管理上，QueryChart 與 Jira 這類工單系統有甚麼分別？

工單系統追蹤的是一張張變更工單；它們並不記錄變更管理流程本身受控的現行版本。QueryChart 記錄的是流程——亦即那份受控文件——好讓審計員先看到設計，再到 Jira 或 ServiceNow 裡對運作情況抽樣。

標準變更、常規變更與緊急變更有甚麼分別？

標準變更低風險、反覆出現而且已預先批准——例如例行的證書續期。常規變更必須先經過影響評估與審批，才可以上線。緊急變更用來解決緊急的生產問題，可以先上線，條件是事後在指定期限內補回審批與檢討。三條通道都必須出現在圖上，否則這張圖描述的就不是實際在跑的那個流程。

所有變更都要經過變更諮詢委員會（CAB）嗎？

不需要，而且一個甚麼都審的委員會會變成樽頸，機構隨後就會開始繞開它。讓委員會審那些跨部門、影響客戶或需要停機的變更，其餘的交由一位具名的變更負責人審批。對審計員而言，關鍵在於哪些變更必須上會的判定準則寫在受控流程裡——而不在於委員會是否看過所有東西。