ISO 27001 風險評鑑怎麼做？資產盤點到風險處理計畫
ISO 27001 風險評鑑，是依條文 6.1.2 先訂好風險準則，再找出哪些情況會讓資訊的機密性、完整性或可用性受損，評估後果與可能性、算出風險等級，最後依 6.1.3 決定處理方式並產出適用性聲明（SoA）。標準不指定計算公式，但要求方法前後一致，換人評估也能得到可比較的結果。
多數企業卡關的地方，不是公式，而是準則沒先講清楚、資產清單列得太細，以及風險處理計畫沒有人簽核。以下照實際做的順序整理，附一份可以直接套用的風險表。若希望由顧問帶著把整套 ISMS 一起建起來，可以參考我們的 ISO 27001 驗證輔導。
風險評鑑在 ISO 27001 的位置
風險評鑑是 ISO 27001 的核心：條文 6.1.2 規定怎麼評估，6.1.3 規定怎麼處理，8.2 與 8.3 則要求實際執行並保留紀錄。附錄 A 的 93 項控制措施要選哪些、排除哪些，都要從風險評鑑的結果推導出來。
條文 6.1.2 的要求可以拆成五件事：訂定風險接受準則與評估準則、確保結果一致且可比較、識別風險並指定風險擁有者、分析後果與可能性、依準則評估並排定處理優先順序。8.2 則規定，ISO 27001 風險評鑑除了依計畫定期執行，有重大變更時也要重新評估，例如導入新系統、搬遷機房或併購。在 ISO 27001 導入流程 中，風險評鑑通常排在範圍界定與差距分析之後。
風險評估方法怎麼選：資產式還是情境式？
ISO/IEC 27005:2022 描述了兩種識別風險的方式：資產式從資訊資產出發，逐項找威脅與脆弱性；情境式（事件式）從可能發生的事件出發，例如勒索軟體加密主要系統。兩種方法可以單獨使用，也可以搭配。
| 比較 | 資產式 | 情境式（事件式） |
|---|---|---|
| 起點 | 資訊資產清冊 | 可能發生的資安事件或營運中斷情境 |
| 優點 | 覆蓋完整，容易對應控制措施 | 貼近管理階層語言，項目少、好溝通 |
| 缺點 | 資產多時表格龐大，容易流於填表 | 可能漏掉不顯眼的資產 |
| 適合 | 系統與資料種類清楚的企業 | 第一次導入、想先抓重大風險的中小企業 |
實務上常見的折衷做法，是把資產「分群」後再評估，例如把所有員工筆電視為一群，而不是一台一台列；重大情境再用情境式補強。
ISO 27001 風險評鑑步驟
ISO 27001 風險評鑑可以分成六個步驟，從準則到處理計畫依序完成。每一步都要留下紀錄，驗證稽核時稽核員會抽查其中一筆，從資產一路追到控制措施。
- 訂定準則：決定可能性與衝擊的評分方式、風險等級的計算方式，以及多少分以下可以接受，由管理階層核定。
- 盤點資產：依條文範圍列出資訊、系統、設備、人員與委外服務，並指定資產負責人。
- 識別威脅與脆弱性：例如「客戶資料庫」面臨未授權存取的威脅，脆弱性是管理帳號未啟用多因子驗證。
- 分析風險：依準則評估可能性與衝擊，算出風險值。
- 評估與排序：與接受準則比較，超過門檻的列入處理。
- 決定處理方式：選擇降低、避免、轉移或接受，寫成風險處理計畫，交風險擁有者核准。
風險矩陣範例
風險矩陣用「可能性 × 衝擊」算出風險值，是最常見的資產風險評估做法。以下為 3 × 3 的範例，分數與門檻是示意，請依公司的風險準則調整：
| 可能性＼衝擊 | 低（1） | 中（2） | 高（3） |
|---|---|---|---|
| 高（3） | 3 中 | 6 高 | 9 高 |
| 中（2） | 2 低 | 4 中 | 6 高 |
| 低（1） | 1 低 | 2 低 | 3 中 |
若準則訂為「3 分以下可接受」，上例中 4 分以上就要處理。以製造業的生產排程系統為例：勒索軟體加密的可能性評為中（2）、停線衝擊評為高（3），風險值 6，屬於高風險，需要列入處理計畫，例如離線備份與網段隔離。
衝擊的評分最好用公司能理解的語言定義，例如「停線超過 4 小時」「影響 1,000 筆以上客戶資料」，而不是只寫高、中、低。評分定義寫得越具體，換人評估時結果越一致，也就越符合 6.1.2 對可比較結果的要求。
風險處理計畫與 SoA
風險處理有四種選擇：降低（加控制措施）、避免（停止該活動）、轉移（例如保險或委外並以契約分擔）、接受（風險擁有者在了解後果下簽核保留）。依 6.1.3，選定的控制措施要和附錄 A 比對，確認沒有遺漏，並產出適用性聲明。
適用性聲明要列出必要的控制措施、納入理由、是否已實施，以及排除附錄 A 控制措施的理由。風險處理計畫則要寫清楚做什麼、誰負責、何時完成，並由風險擁有者核准計畫、接受處理後的殘餘風險。下面這份風險表欄位，可以直接當作範本使用：
| 欄位 | 填寫範例 |
|---|---|
| 資產或情境 | 客戶資料庫 |
| 資產負責人／風險擁有者 | 資訊部經理／業務副總 |
| 威脅 | 未授權存取 |
| 脆弱性 | 管理帳號未啟用多因子驗證 |
| 可能性／衝擊／風險值 | 2／3／6 |
| 處理方式 | 降低 |
| 控制措施（附錄 A） | 8.5 安全鑑別 |
| 負責人與期限 | 系統管理員，3 個月內 |
| 殘餘風險 | 2（接受，業務副總簽核） |
風險評鑑常見錯誤
實務上，驗證稽核最常被開出缺失的，往往不是公式錯，而是紀錄串不起來：
- 準則沒有事先核定，評分邊做邊改，前後結果無法比較。
- 資產列到每一條網路線，表格上千列卻沒人看得懂。
- 只評估技術風險，漏掉人員、委外廠商與實體環境。
- 風險擁有者都是 IT 人員，業務單位沒有參與，接受風險的決定不具代表性。
- SoA 排除控制措施只寫「不適用」，沒有說明理由。
- 評估完就放著，系統上線或組織異動後沒有重新評估。
第一次做風險評鑑，要做到多細才夠？
第一次做 ISO 27001 風險評鑑，夠用比完美重要。建議先用資產分群加上 5 到 10 個重大情境，把高風險項目找出來並排進處理計畫；第二年再依稽核發現與事件紀錄細化。重點是準則清楚、紀錄完整、每一筆處理都有人負責。
想確認自己的風險評鑑能不能通過驗證稽核，可以 先請顧問看一下現況。
ISO 27001 風險評鑑常見問題
風險評鑑多久做一次？
依條文 8.2，要依計畫的時間間隔執行，並在有重大變更時重新評估。多數企業訂為每年至少一次，配合管理審查；導入新系統、搬遷機房或組織調整時，則另外針對受影響範圍重新評估。
一定要用資產清冊嗎？
ISO 27001 沒有規定一定要用資產式方法，情境式也可以。不過附錄 A 的 5.9 要求建立資訊及其他相關資產清冊，因此不論用哪種方法，企業通常都還是要有一份清冊。
風險接受由誰決定？
依條文 6.1.3，由風險擁有者核准風險處理計畫，並接受殘餘風險。風險擁有者應是有權責與預算決定該風險的人，通常是業務或部門主管，而不是只由資訊人員決定。
參考資料
- ISO/IEC 27001:2022 – 條文 6.1.2、6.1.3、8.2、8.3 風險評鑑與處理要求。ISO
- ISO/IEC 27005:2022 – 資訊安全風險管理指引，資產式與事件式方法。ISO · 2022 年 10 月
