💡 先搞懂問題
很多組織的「事件處理程序」只有一句話：發現異常請通報資訊部。平常看起來夠用，真的遇到勒索軟體時才發現問題一個接一個冒出來：同仁不確定該不該報，怕報錯被笑；資訊部收到十幾則訊息，不知道哪一則要先處理；工程師急著重灌主機，把攻擊者留下的痕跡一起抹掉；主管們在通訊群組裡討論要不要斷網，沒有人確定自己有權拍板；備份拿出來才發現從來沒還原過。
ISO/IEC 27001:2022 附錄 A 的 5.24 到 5.30 就是在處理這些事，再加上人員控制裡的 6.8。前五項是一條事件管理的流水線：事先準備（5.24）、判斷一個資安事件（information security event）要不要升級成資安事故（information security incident）（5.25）、依程序應變（5.26）、事後學習（5.27）、保全證據（5.28）。後兩項處理營運中斷：中斷期間資安不能鬆掉（5.29），以及資訊與通訊系統（ICT）要能在業務可以忍受的時間內恢復（5.30）。
事件是「值得有人看一眼的異常」，例如一封可疑郵件、一次失敗的登入；事故是評估後確認會或可能傷害組織、需要啟動應變的事件。中文譯名各家不同，有的寫「事態／事件」，有的寫「事件／事故」，本頁一律用事件（event）與事故（incident），組織內部統一用詞即可。
生活比喻：社區大樓的火災應變
想像一棟兩百戶的社區大樓。管委會平常就排好消防編組：誰是指揮官、誰負責打 119、誰引導疏散、誰去關總電源，每年演練一次。某天晚上，住戶在樓梯間聞到煙味，他不需要先找到起火點，只要立刻打給警衛室。警衛到場判斷：是有人在陽台燒紙錢，還是配電箱真的冒煙？如果是後者，就依編組按警鈴、疏散、用滅火器先壓住火勢，並且不要急著把燒焦的配電箱拆掉丟掉，因為消防局和保險公司要來看現場。火滅了以後，管委會開檢討會，發現逃生門被住戶堆了雜物，於是修改規約並重新宣導。
如果火災讓整棟大樓停電，電梯和門禁暫時不能用，管理員改用人工登記訪客，但不能乾脆把大門敞開；發電機要能在多少分鐘內接手、能撐幾小時，也是事先就該算好並定期試車的事。
比喻有三個地方容易誤導。第一，火災很明顯，資安事件卻常常無聲無息，攻擊者可能潛伏好幾週才動手，所以通報門檻要比「聞到煙味」更低，連「這封信怪怪的」都值得報。第二，火災有消防隊接手指揮，資安事故的應變多半由組織自己主導，執法機關或主管機關介入的時機要依適用法規判斷。第三，火不會反擊，攻擊者會：他可能還在系統裡觀察你的動作，所以聯絡應變小組、討論處置時，最好使用不受影響的通訊管道。
🎮 互動實驗室一：勒索事件應變演練
一家 180 人的模具製造商（虛構）在週一早上遇到一起事件。時間軸會依序推進 7 個關卡，每關請選出最符合 ISMS 程序的做法。選完會顯示對應的附錄 A 控制、稽核員之後會要求看的紀錄，旁邊（手機在下方）的「事件紀錄」會自動寫下你這一步留下的軌跡。選錯不會卡關，但影響擴大指數會上升。
🎮 互動實驗室二：事件分級器
值班窗口每天會收到各種通報與告警。請先判斷每張卡片是只需記錄觀察的事件（event），還是要啟動應變的事故（incident）；選事故的話，再依下面的示意分級表決定嚴重度。事件或事故判斷錯誤不給分，事故判對但嚴重度差一級給半分。
🎮 互動實驗室三：RTO／RPO 備援試算
先選一個系統（或自己拉滑桿）設定營運衝擊分析得出的目標，再選一種備份或備援方案，看它在「硬體故障」與「勒索加密」兩種情境下能不能達標。所有時數與成本都是示意，用來體會取捨，不是產品規格。
📘 原理補完
八項控制各管哪一段
下表把附錄 A 的 5.24 到 5.30 與 6.8 放在一起。附錄 A 的控制只寫「要做到什麼」，細節例如分級幾級、多快通報、RTO 訂多少、多久演練一次，標準都沒有規定，由組織依風險評鑑與業務需求自行決定，再寫進程序。表中「稽核常看」是驗證稽核的常見做法，不是標準條文。
| 控制 | 英文短標題 | 白話在做什麼 | 稽核常看的紀錄 | 2013 版對應 |
|---|---|---|---|---|
| 5.24 | Information security incident management planning and preparation | 事先定好流程、角色、決策權限、聯絡與通報清單、工具與訓練 | 事件管理程序、應變小組名單、分級標準、演練紀錄 | A.16.1.1 |
| 6.8 | Information security event reporting | 讓所有人都知道怎麼回報可疑狀況，而且懷疑就報 | 通報管道公告、通報紀錄、員工訪談 | A.16.1.2、A.16.1.3 |
| 5.25 | Assessment and decision on information security events | 判斷事件要不要升級為事故，並決定等級 | 事件清冊的分級欄位、判定理由與判定人 | A.16.1.4 |
| 5.26 | Response to information security incidents | 依程序遏止、根除、復原，並在過程中溝通與記錄 | 應變時間軸、處置紀錄、通知對象、結案確認 | A.16.1.5 |
| 5.27 | Learning from information security incidents | 事後找根本原因，把改善落實到控制、程序與訓練 | 檢討報告、改善行動追蹤、程序新版本 | A.16.1.6 |
| 5.28 | Collection of evidence | 讓證據可信：映像、雜湊、保管鏈，必要時找外部鑑識 | 證據保全程序、保管鏈表單、證據清單 | A.16.1.7 |
| 5.29 | Information security during disruption | 中斷期間的替代做法也要有資安要求，事後收回 | 營運持續計畫中的資安要求、臨時措施與收回紀錄 | A.17.1.1–A.17.1.3 合併 |
| 5.30 | ICT readiness for business continuity | 依營運持續目標規劃 ICT 恢復能力，並測試證明做得到 | BIA 結果、各系統 RTO／RPO、還原或切換測試紀錄 | 2022 新增 |
一起事故從頭到尾的處理步驟
- 通報（6.8）：任何人發現可疑狀況，用公告的管道回報，不自行測試、不刪除、不重開機。
- 評估與判定（5.25）：指定窗口依分級標準判斷事件或事故、決定等級，寫下理由與時間。
- 召集與遏止（5.24、5.26）：依等級通知應變小組，由程序授權的人決定隔離、停用帳號或中斷連線。
- 保全證據（5.28）：在根除前先做映像、匯出日誌、記錄保管鏈；遏止與保全常要同時進行。
- 通知（5.26、5.5）：依程序通知管理階層、受影響客戶，並依適用法規與主管機關公告判斷是否對外通報及時限。
- 根除與復原（5.26、5.29、5.30）：移除惡意程式、修補入侵途徑，從乾淨的備份在隔離環境還原，依 RTO 優先序恢復，臨時做法也維持存取控制。
- 結案與學習（5.27、10.2）：確認事故已處理完畢，召開檢討，改善行動有負責人與期限，並追蹤到完成。
營運持續的兩把尺：RTO 與 RPO
5.30 的起點通常是營運衝擊分析（Business Impact Analysis，BIA）：找出關鍵業務能忍受多久中斷、最低要維持什麼服務水準，再推回每個系統的 RTO（中斷後多久內要恢復）與 RPO（最多能接受遺失多久以前的資料）。RTO 決定你需要多快的恢復手段，例如備援主機或雲端災難復原；RPO 決定備份或複寫的頻率。實驗室三想讓你看到兩件事：第一，同步複寫在硬體故障時很快，但勒索軟體加密的檔案也會被同步過去，所以還需要一份不會被改寫的備份；第二，表上的數字如果沒有測過，只是期望值。5.30 要求的是規劃、實施、維護並測試，稽核員會拿實測紀錄和目標比對。
資安事件管理的指引，不能拿來驗證。第 1 部說明原則與流程，第 2 部談規劃與準備，第 3 部談 ICT 事件回應作業，第 4 部（2024 年新增）談多個組織之間如何協調。設計 5.24 到 5.28 與 6.8 的程序時，很適合當骨架。
可驗證的管理系統標準，範圍是整個組織的營運持續，包含人員、場地與供應商。27001 的 5.29、5.30 只要求資訊安全與 ICT 的部分；客戶要求完整營運持續能力時，可以再擴大到 22301，兩者能共用風險評鑑、內稽與管理審查。
2013 版與 2022 版的差別
2013 版把事件管理放在 A.16，共 7 項控制；2022 版把通報事件與通報弱點兩項合併成人員控制 6.8，其餘五項成為 5.24 到 5.28，內容方向大致相同。營運持續方面，2013 版 A.17.1 的三項控制合併成 5.29，A.17.2.1 的備援設施移到技術控制 8.14，而 5.30 ICT 營運持續備妥是 2022 年新增的 11 項控制之一。轉版時常見的工作是補上 BIA 與 RTO／RPO 的依據，以及實際的還原測試紀錄。
台灣法規怎麼放進程序
適用資通安全管理法的機關與特定非公務機關，事件分級、通報與應變另有子法規範（現行名稱為「資通安全事件通報應變及演練辦法」）；涉及個人資料外洩時，還要看個人資料保護法及其相關規定；上市櫃公司則有主管機關與證券交易所的資安規範與重大訊息要求。這些通報時限與分級方式，請依適用法規與主管機關最新公告為準。程序裡可以引用法規名稱並把組織的分級對照上去，同時指定專人追蹤法規修正，避免程序寫的時限已經過時。
常見誤解與稽核常見的不符合
「一年零事件，代表我們很安全。」稽核員通常會反過來追問：通報管道有沒有人知道？防毒與防火牆的告警都去哪了？零件數多半代表沒人通報或沒有記錄，而不是真的沒事。
「事件處理都在通訊軟體群組裡，很即時。」即時沒問題，問題是事後找不到分級理由、處置時間與決策者。群組訊息可以是原始紀錄，但事件清冊與結案報告要另外整理。
「程序寫了分級，所以 5.25 做到了。」常見的情況是程序有高中低三級，實際紀錄全部標成「一般」，或明顯涉及個資的事件被標低級而沒有通報，這會被開立不符合。
「備份每天成功，5.30 沒問題。」備份成功不等於還原得回來。RTO 寫 4 小時但從沒測過，或實測要兩天，都是常見的不符合；演練只做桌上推演、從未實際還原，也常被要求改善。
「點了釣魚信的同仁要懲處，才會有警惕。」懲處通報者會讓下一個人選擇隱瞞，直接傷到 6.8。紀律程序（6.4）處理的是蓄意違規，不是誤觸後主動通報的人。
✅ 自我檢測
6 題原創單選題，選完立即顯示對錯與解析。目前得分：0 / 6