IT 變更管理流程：ISO 27001 控制措施 8.32 實務
IT 變更管理是讓系統、網路、設定與雲端服務的每一次修改，都經過申請、風險評估、核准、測試、實施與紀錄的流程。ISO/IEC 27001:2022 附錄 A 控制措施 8.32 要求，資訊處理設施與資訊系統的變更應遵循變更管理程序；稽核時，變更紀錄也是最常被抽查的證據之一。
這篇以 IT 團隊的角度，說明變更管理怎麼從零建立：哪些算變更、六個步驟各由誰負責、核准權限怎麼分、緊急變更怎麼處理，以及一張可以直接使用的變更單範本。導入 ISMS 時需要協助，可參考 ISO 27001 驗證輔導。
搜尋「變更管理技術指引」時常會看到勞動部的同名文件，那是職業安全衛生管理系統中針對製程與作業變更（MOC）的指引，和本文談的資訊系統變更屬於不同領域。
變更管理是什麼？哪些修改算「變更」
變更管理是對資訊系統與處理設施的修改進行控制，目的在於變更過程中仍維持資訊安全，並在出問題時能追查與回復。ISO 27001:2022 的 8.32 合併了 2013 年版 A.12.1.2、A.14.2.2、A.14.2.3 與 A.14.2.4 四項控制。
範圍不只程式碼。防火牆規則、DNS、資料庫結構、作業系統修補、雲端與 SaaS 的設定、新系統上線與舊系統停用，都屬於變更。實務上我們最常看到的缺口，是程式改版管得很好，網路與雲端設定卻完全沒有紀錄。
另外要分清楚兩個「變更」：第 6.3 條談的是 ISMS 本身的變更規劃，例如擴大驗證範圍；8.32 談的是系統與設施的技術變更。
IT 變更管理流程 6 步驟
一般變更可依下列六個步驟進行，從提出申請到結案，時間依變更大小從一天到兩週不等（實務經驗，依團隊規模調整）。
| 步驟 | 做什麼 | 負責人 | 產出 |
|---|---|---|---|
| 1. 提出申請 | 說明變更內容、原因、影響的系統 | 申請人 | 變更單 |
| 2. 分類與評估 | 判斷標準、一般或緊急變更，評估資安與營運風險 | 系統負責人 | 風險等級 |
| 3. 核准 | 依風險等級由對應層級核准，核准者不得為申請人 | 主管或變更審查會議 | 核准紀錄 |
| 4. 測試 | 在測試環境驗證功能與資安設定 | 執行人、測試人員 | 測試結果 |
| 5. 實施 | 依計畫時段上線，準備好回復步驟 | 執行人 | 實施紀錄 |
| 6. 審查與結案 | 確認結果、更新文件與組態紀錄 | 系統負責人 | 結案紀錄 |
變更分類常借用 ITIL 的說法：標準變更指低風險、步驟固定且預先核准的例行作業，例如依既定程序新增帳號；一般變更需逐案評估核准；緊急變更則用於服務中斷或重大弱點，需走另一條快速路徑。
風險評估與核准：誰來簽？
核准的原則只有一條：寫變更的人不能自己核准。核准層級則依風險高低決定，避免小變更被流程拖住，大變更卻只有工程師一人判斷。
| 風險等級 | 判斷方式（範例） | 核准者 |
|---|---|---|
| 低 | 影響單一系統、可立即回復、不涉及個資與對外服務 | 系統負責人 |
| 中 | 影響多個系統或對外服務、需停機 | IT 主管 |
| 高 | 涉及核心系統、個資、資安設定或無法簡單回復 | IT 主管與資安負責人，必要時通知營運主管 |
評估時至少要回答四個問題：會不會影響其他系統、會不會降低資安設定（例如開放連接埠、關閉日誌）、要停機多久、失敗了怎麼回復。若公司同時導入 ISO 20000 ISO 27001 差異一文提到的 ISO 20000，兩邊的變更流程可以合併成一套。
緊急變更怎麼處理？
緊急變更指為了恢復服務或修補正在被利用的弱點，先處理、後補核准的變更。它不是跳過流程，而是走一條事先定義好的快速路徑。
實務做法是指定一兩位有權口頭核准的主管，工程師先電話取得同意再動手；處理完後在約定期限內（例如下一個工作日）補齊變更單、說明原因並做事後檢討。每季檢查緊急變更占全部變更的比例，若持續偏高，通常代表一般流程太慢，工程師被迫繞路。
變更紀錄與稽核：稽核員會抽什麼？
稽核員通常會從工單系統或版本控制紀錄中抽出幾筆實際變更，逐筆對照公司寫的程序：有沒有評估、誰核准、做了什麼測試、回復計畫是什麼、誰上線的。只要其中一筆對不上，就可能被開出不符合事項。
下面是一張可直接使用的變更單欄位範本：
| 欄位 | 填寫內容 |
|---|---|
| 變更編號與日期 | 系統自動編號 |
| 申請人與執行人 | 姓名、部門 |
| 變更類別 | 標準、一般、緊急 |
| 變更內容與原因 | 改什麼、為什麼改 |
| 影響範圍 | 系統、使用者、對外服務、是否涉及個資 |
| 風險等級與評估 | 低、中、高，及資安影響說明 |
| 測試結果 | 測試環境、測試項目、結果 |
| 實施時段與停機時間 | 預定與實際 |
| 回復計畫 | 失敗時的回復步驟與判斷條件 |
| 核准人與核准時間 | 不得與申請人相同 |
| 結案確認 | 結果、文件與組態是否已更新 |
使用 Git 與 CI/CD 的團隊不必另開紙本：合併請求就是變更單，強制的同儕審查就是核准，自動化測試與預備環境就是測試，部署紀錄就是稽核軌跡，重點是這些關卡無法被悄悄略過。適用資通安全管理法的單位也要注意，《資通安全責任等級分級辦法》附表十規定，防護需求等級「中」以上的資通系統在維運階段應執行版本控制與變更管理，開發、測試與正式環境也應區隔。若公司另有 SOC 2 需求，其 CC8.1 準則同樣要求變更經授權、測試與核准，同一份紀錄可以兩邊共用。
各步驟最常見的錯誤
第一是範圍太窄，只管程式不管網路與雲端設定，結果最常出事的防火牆規則沒有紀錄。第二是核准流於形式，申請人與核准人是同一個帳號，或主管一次批准整批變更卻不看內容。第三是沒有回復計畫，上線失敗時只能臨時想辦法。第四是結案後沒有更新文件，組態紀錄與實際設定越差越遠，下次變更的風險評估也跟著失準。
這些都是 ISO 27001 驗證稽核時常見的缺失，處理起來不難，難的是讓團隊每次都照做。
下週的第一張變更單怎麼開？
先把上面的變更單範本放進公司現有的工單系統或共用表單，訂出低、中、高三級核准人，再指定緊急變更的口頭核准窗口。從下週開始，要求所有防火牆、伺服器與雲端設定的修改都要開單，一個月後回頭檢查有沒有漏網的變更。
想確認現有流程離稽核要求還差多少，可以先請顧問看一下現況。
IT 變更管理常見問題
小變更也要申請嗎？
要有紀錄，但不一定要逐案核准。風險低、步驟固定的例行作業可以定義為標準變更，事先核准一次程序，之後照做並留下紀錄即可，例如依既定流程新增使用者帳號。只要會影響資安設定或對外服務，就不應歸為小變更。
變更由誰來核准？
依風險等級決定，但核准者不能是申請人或執行人本人。低風險可由系統負責人核准，中風險由 IT 主管，高風險則由 IT 主管與資安負責人共同核准。小團隊人力不足時，至少要找另一位工程師做同儕審查，並留下紀錄。
雲端服務的變更怎麼管？
雲端主控台的設定修改、基礎架構程式碼的變更與 SaaS 管理後台的權限調整，都應納入變更管理。做法是限制能修改設定的管理帳號、啟用雲端平台的操作日誌，並把基礎架構程式碼放進版本控制與審查流程；雲端服務商自己的變更，則透過合約與服務公告追蹤。
參考資料
- ISO/IEC 27002:2022 – 控制措施 8.32 變更管理的實施指引。ISO · 2022 年 2 月
- 資通安全責任等級分級辦法 – 附表十資通系統防護基準「系統發展生命週期」。數位發展部 · 民國 115 年 1 月 7 日修正
