事故應變流程範本（6 張互相連結的流程圖）

本套裝包含的內容

1. 1. 事故管理流程圖

   大門：偵測、登記、分流，以及重大事故的宣告。

2. 2. 事故嚴重等級分級流程圖

   路由其他一切的那個決策——影響、緊急程度，以及外洩測試。

3. 3. 網絡安全事故應變流程圖（SOC）

   保安分支：遏制、清除、鑑證，以及復原到乾淨狀態。

4. 4. 資料外洩應變流程圖（GDPR 72 小時時限）

   法規分支與它那個七十二小時的時鐘，包括通報與否的決定。

5. 5. 災難復原流程圖（IT 系統）

   重建：啟動權限、復原次序，以及回復服務之前的驗證。

6. 6. 業務持續運作流程圖：由啟動到解除應變

   重建進行期間，用臨時方案令業務繼續運轉下去。

各張圖表如何互相連接

事故管理流程圖 → 事故嚴重等級分級流程圖

「分類並設定優先級」是事故流程把判斷交給分級那張圖的位置。把嚴重程度獨立成一張圖，意味着 P1 只有一個定義，讓其他所有流程都指向它，而不是三套互相矛盾的說法。

事故管理流程圖 → 業務持續運作流程圖：由啟動到解除應變

「宣告重大事故」是問題由怎樣修好這個故障，變成業務在修好之前怎樣繼續運作的那一點。這是兩批人、兩份計劃、兩個時鐘。

事故嚴重等級分級流程圖 → 網絡安全事故應變流程圖（SOC）

「是否涉及資料或人身安全外洩？」是一個決策菱形，而把連結放在決策上，正是最有用的位置：決策恰恰就是一個流程分岔進另一個流程、而不是繼續向下走的地方。

網絡安全事故應變流程圖（SOC） → 資料外洩應變流程圖（GDPR 72 小時時限）

「確定受影響的資產與帳戶」是保安團隊得知個人資料是否落在範圍之內的位置。如果是，法規的計時由發現那一刻開始，而不是由這一步開始——這正是外洩流程用連結、而不是接在後面的原因。

網絡安全事故應變流程圖（SOC） → 災難復原流程圖（IT 系統）

「用乾淨備份重建系統」是保安交棒給基建的位置。保安決定甚麼算乾淨；復原決定各項服務回來的先後次序。

災難復原流程圖（IT 系統） → 業務持續運作流程圖：由啟動到解除應變

「批准啟動 DR」會同步觸發持續運作計劃，而不是之後才觸發。復原有它自己的 RTO；業務需要在那個時限用完之前，就已經可以繼續運作下去。

業務持續運作流程圖：由啟動到解除應變 → 災難復原流程圖（IT 系統）

「啟用臨時方案與人手流程」反方向連回去，因為持續運作往往是先被啟動的一方——業務會先發現自己做不到生意，基建才決定這是一場災難。

運作方式

1. 其他都可以遲些做，嚴重程度矩陣要先定好

   這套組合裡其他每一張圖，都按分級那張圖的輸出來路由。先把你們真正的影響與緊急程度定義填進去，然後回頭檢查那五張依賴它的圖是否仍然讀得通。

2. 每一個啟動權限，都要寫上具體姓名與電話

   重大事故的宣告與 DR 的啟動，都是權限決策。一張只寫上由管理層批准就算數的圖，會在最壞的時刻換來一場二十分鐘的爭論。

3. 在外洩那張圖上，把法規計時定在發現的一刻

   七十二小時由知悉開始計，而不是由確認開始。如果你們的圖暗示計時要等到法律部門獲得簡報才開始，它描述的是一個你們一定會錯過的限期。

4. 用這些連結當劇本，跑一次桌面演練

   帶着一組人由大門走進分級，再進入保安分支，然後出到復原，沿途跟着那些標記走。每一次對接下來由誰負責的猶豫，都是圖上的空隙，而不是那組人的問題。

5. 把資料夾以唯讀方式分享給全部當值人員

   這些正是凌晨三點有人會需要的圖。給整份當值輪值表唯讀權限沒有任何成本，卻可以徹底消除現時哪一份才是現行版本這條問題。

常見問題

這套是跟 ITIL 的嗎？

事故那張圖用的是 ITIL 的形狀——偵測、登記、分類、定優先級、調查、修復、結案——但沒有照搬 ITIL 的整套術語。保安、外洩、復原與持續運作那四張圖，跟的是 ISO 27035、ISO 22301 的做法與常見的法規模式，而不是 ITIL。

這個需要付費方案嗎？

需要——範本組合是 Plus 方案的內容。一個組合會一次過建立六張圖，而免費方案只可以存放三張。每一張圖也可以單獨免費使用。

為甚麼災難復原與業務持續運作會互相連結？

因為兩者都有可能先被啟動。基建可能在業務察覺之前就宣告災難，業務也可能在任何人稱之為災難之前，就已經啟用了臨時方案。單向連結只會描述到真實行為的一半。

七十二小時的計時是 GDPR 專有的嗎？

外洩那張圖以七十二小時的通報窗口為骨架，因為那是 GDPR 的要求，也是最常適用的一個。其他制度並不相同——關鍵基建的要求有些更短——所以請把圖裡的時距，改成你們實際受規管的那一個。