保安事故應變流程圖
保安事故應變流程的泳道圖：由偵測與分流，經嚴重程度分級、遏制、證據保全與清除，一直到資料外洩通報、事後檢討與結案。
運作方式
把泳道改成你們真實的角色
把這五條泳道換成你們真正擁有的角色：SOC 或 MSSP、服務台、保安主管、平台團隊、資料保障主任、外部鑑證機構或外洩事故法律顧問。如果某個角色並不存在，就刪掉那條泳道，而不是讓它空著無人承擔。
訂定你們的嚴重程度判定準則
打開「對嚴重程度與影響分級」方格，把說明換成你們自己的矩陣：甚麼樣的事故算作高嚴重程度、誰有權宣佈，以及每個等級各自承諾甚麼樣的應變時間。
確定通報時限與對應的監管機構
編輯「是否屬須通報的外洩？」決策，令它寫明適用於你們的制度：英國或歐盟 GDPR（72 小時之內通報監管機構）、NIS2、HIPAA、行業規則，以及合約訂明的客戶通知期限——後者往往比法定期限更短。
補上人們在凌晨三點需要的聯絡資料
把事故通道、當值電話、事故總指揮更表和證據存放位置寫進方格備註裡，這樣這張圖在事故當中也用得上，而不只是在檢討時才拿出來。
調整迴路並補上缺失的步驟
判斷「系統是否驗證乾淨？」回到隔離的這條分支是否符合你們的工作方式，並補上你們環境中特有的內容，例如啟用常設合約的鑑證供應商、網絡保險通報，或者一個客戶對外稿件的審批步驟。
分發簽署並保留版本
把這張圖交給保安主管、IT 營運和法律部門簽署確認，然後保留獲批版本。事故應變計劃是一份受控文件，你們演練的版本應當就是你們發佈的版本。
常見問題
事故應變流程分為哪些階段？
本圖使用五個階段：偵測與報告、分流與分級、遏制、清除與復原，以及通報與檢討。它與 NIST SP 800-61r2 高度對應，後者使用偵測與分析，遏制、清除與復原，以及事後活動。NIST 另有一個準備階段，但準備是持續性的工作（工具、更表、演練、常設服務合約），而不是你在事故當中執行的一個步驟，因此沒有畫在流程上。
保安事故應變與 IT 事故管理有甚麼分別？
一次 IT 服務事故在服務復原時就完結了。保安事故不是，因為存在一個對手。過早復原可能等於把攻擊者的存取權重新交回去，而且它還帶有 ITIL 事故流程並不承擔的責任：在重建之前保全證據、判定哪些資料受到影響、並在需要時通報監管機構和個人。這正是本圖把證據保全與映像放在清除之前，並在復原之後加上一條通報分支的原因。
誰應當擔任事故總指揮，甚麼時候指派？
事故總指揮應當是有權做決定的人（把一套生產系統下線、聘請外部法律顧問、聯絡客戶），而不一定是當下技術最強的人。他們負責協調，而不是負責調查。在本圖中，只有當「是否為高嚴重程度事故？」得到「是」時才指派總指揮；嚴重程度較低的事故仍留在保安團隊。在一次長時間的事故中，這個角色會在每次換更時明確交接。
72 小時的外洩通報時鐘由甚麼時候開始？
在英國和歐盟 GDPR 之下，這 72 小時由機構知悉發生了個人資料外洩時起計，而不是由攻擊開始時、也不是由調查結束時起計；如果尚未掌握完整情況，可以分階段通報。通知受影響的個人是另一項判定：當外洩很可能為他們帶來高風險時，須在不當延誤的情況下通知。其他制度運行的是不同的時鐘，因此請把適用於你們的那一個寫在決策方格上。