ISO 27001 風險評鑑與風險處理怎麼做：情境、分級、殘餘風險

風險評鑑和風險處理是前後相接的兩個動作。有些文件把風險評鑑寫成「風險評估」，講的是同一件事。前者問「我們可能出什麼事、哪一件最該先處理」，後者問「那件事怎麼處理、處理完還剩多少、誰認這個剩餘」。兩個動作分開看，表格、計畫與簽核才不會全擠在同一頁，卻沒有一項交代得清楚。

要求出自 ISO/IEC 27001:2022，由國際標準化組織與國際電工委員會共同發布。它管的是組織的資訊安全管理系統（Information Security Management System，ISMS），一套保護資訊、讓資訊不至於失去機密性、完整性與可用性的管理制度。整份制度裡，風險評鑑與風險處理最花時間，也最常被稽核員抽問；後面的控制措施、適用性聲明、風險處理計畫，都是從這裡長出來的。

這篇寫給第一次做風險評鑑的人。你手上可能只有一張資產清單，或者一張從 ISO 9001 抄過來的「風險與機會」表格；表格長什麼樣、等級怎麼分、做完還剩什麼、最後誰要簽，心裡都還沒個底。讀完之後，你應該做得出可被稽核的風險清單，也會知道哪幾件事做錯一定被開單。

文章從條文的步驟與名詞講起，接著把風險準則、表格欄位拆成可以直接照抄的內容，再談分級、情境示例、處理選項、殘餘風險與簽核；後段處理「多久做一次」「稽核員會看什麼」、台灣法規，以及與 9001 的界線。

有一件事會影響你查資料：ISO/IEC 27001:2022 的標準本文是付費出版品，這一輪沒有取得全文。因此文中條文要求一律以「條號＋要求重點」自述，不拿引號假裝引用原文；能逐字引用的句子都附上來源。需要條文原句，請自行取得標準本文。

風險評鑑與風險處理是兩件事還是同一件？

條文上是兩個動作，各有各的紀錄義務；至於要分成幾份文件、用什麼格式，標準沒有規定。

ISO/IEC 27001:2022 用第 6.1.2 條管風險評鑑、第 6.1.3 條管風險處理，兩條末段都有一句「保留文件化資訊」。到了第 8 章的執行階段，§8.2 與 §8.3 又分別要求保留「評鑑結果」與「處理結果」。四處湊起來是這樣：

條號	要保留什麼	屬於
§6.1.2 末段	風險評鑑流程的文件化資訊	流程
§6.1.3 末段	風險處理流程的文件化資訊	流程
§8.2 末段	風險評鑑結果	結果
§8.3 末段	風險處理結果	結果

（上表條號與要求重點經驗證機構公開指引轉引；標準文中為付費出版品，文中未取得全文，不以引號引用原文。）

「流程」與「結果」的差別常被忽略。流程的紀錄回答「你怎麼做的」：準則長什麼樣、誰參與、怎麼辨識、怎麼打分、怎麼排優先序。結果的紀錄回答「你做出了什麼」：這一份清單、這一些等級、這一些處理決定。稽核員兩種都會翻。只有結果沒有流程，他問不出等級怎麼來；只有流程沒有結果，他看不到你評了哪些風險。

份數與格式沒有規定。驗證機構公開指引寫得很直接：「There is no particular requirement for the content or format of an organization’s risk treatments plan.（風險處理計畫的內容與格式並無特別要求。）」處理計畫如此，評鑑紀錄也一樣；標準要的是內容齊備，不是特定表頭。

實務上合成一份「風險評鑑與處理報告」是可以的，前提是內容同時交代流程與結果。前半句從條文推得，後半句是顧問實務的提醒：很多企業合併成一份之後只剩表格，沒寫「這份表是怎麼打下來的」，流程紀錄就這樣消失。合併沒問題，但同一份文件裡要留一節寫方法與準則、一節寫結果，兩節都能被單獨指認。

有個名詞這裡得先講清楚，後面每一節都會用到。判斷風險看的是資訊的三個面向：機密性（Confidentiality）、完整性（Integrity）、可用性（Availability），合稱 CIA。機密性指資訊只讓該看的人看到，完整性指資訊正確、未被不當修改，可用性指需要的時候拿得到、系統跑得動。這三個字不是修辭。§6.1.2 c) 要辨識的正是「與 CIA 損失有關的風險」，情境句如果寫不出「哪一份資訊、失去哪一個面向、會有什麼後果」，那一列就還沒寫完。

流程的後半段還會產出兩份東西：適用性聲明（Statement of Applicability，SoA）與風險處理計畫（Risk Treatment Plan，RTP），位置在 §6.1.3 的 d) 與 e)。這裡只交代它們在流程裡的位置，SoA 的欄位與撰寫步驟屬於另一篇。

條文要求做哪幾步？從 6.1.2 到 8.3 的順序

把條文攤開，路只有一個方向。先訂準則，再辨識、分析、評估，然後才處理；處理不完的部分要有人接受。

§6.1.2 的四段。 a) 建立並維持風險準則，裡面包兩類：風險接受準則（什麼程度以內可以接受）與執行風險評鑑的準則（用什麼量表、怎麼決定等級）。c) 辨識風險，並辨識風險擁有者。d) 分析風險，看後果、看實際發生的可能性，然後決定等級。e) 評估風險，拿分析結果與 a) 的準則相比，排出處理優先序。（條文經驗證機構公開指引轉引，未以引號引用原文。）

夾在 a) 與 c) 之間的是 b)，它要求「重複執行時，結果要一致、有效、可比較」。這一項管的不是某個步驟，是整個流程的品質：今年做的與明年做的要能對照，甲廠區與乙廠區要能放在同一張表上比。後面談「準則要先寫」，會一直回到這一句。沒有事先寫好的量表，一致性無從證明。

§6.1.3 的六段。 a) 依評鑑結果選擇處理選項。b) 決定所有必要的控制措施。c) 把 b) 的結果與附錄 A（Annex A）比對，確認沒有漏掉必要控制。d) 產出 SoA。e) 訂定風險處理計畫。f) 取得風險擁有者對處理計畫的核准，以及對殘餘風險的接受。（同上，條文經驗證機構公開指引轉引。）

§8.2 與 §8.3 進到執行期。 §8.2 要求在規劃的期間、或重大變更被提出或發生時，依 §6.1.2 a) 的準則執行風險評鑑，並保留結果。§8.3 要求實施風險處理計畫，並保留實施結果。規劃期做的事，執行期要再做一次，這一段很多企業漏掉：文件只做到規劃，沒有跑第二次。

§9.1 與 §9.3.2 把這條線接進管理循環。 §9.1 要求組織決定要監督量測什麼、方法、時機、由誰做，並保留結果證據；ISO/IEC JTC 1/SC 27 公開文件（未經 ISO 背書）指出，風險評鑑與風險處理這兩個流程必須被量測，因為 §9.1 要求流程要被監督或量測。§9.3.2 則要求管理審查的輸入包含風險評鑑結果與風險處理計畫的狀態。這份清單不是做完歸檔，每個週期都要端到管理階層桌上。

版本也要寫對。「ISO/IEC 27001:2022，Edition 3，2022-10 發布，現行有效（另有 2024 年氣候變遷修訂 Amd 1）。」2024 年那個修訂只動第 4 章（新增氣候變遷是否為相關議題的考量），不涉及第 6 章的風險評鑑與風險處理。文中提到的條號與要求，2022 版與含 Amd 1 的版本一致。

條號	要求重點（自述）	產出物
§6.1.2 a)	建立並維持風險準則：風險接受準則＋執行評鑑的準則	風險準則文件
§6.1.2 b)	重複執行時結果一致、有效、可比較（貫穿要求）	可比較的歷次紀錄
§6.1.2 c)	辨識與 CIA 損失有關的風險，並辨識風險擁有者	風險項目與擁有者
§6.1.2 d)	分析後果與實際可能性，決定風險等級	等級與分析說明
§6.1.2 e)	與準則比較，排出處理優先序	優先序清單
§6.1.3 a)–b)	選擇處理選項；決定所有必要控制措施	處理方向與必要控制清單
§6.1.3 c)–d)	與附錄 A 比對；產出 SoA	比對紀錄、SoA
§6.1.3 e)–f)	訂風險處理計畫；風險擁有者核准並接受殘餘風險	處理計畫、簽核紀錄
§8.2／§8.3	在規劃期間或重大變更時重做評鑑；實施處理計畫	評鑑結果、處理結果
§9.1／§9.3.2	量測這兩個流程；管理審查輸入含評鑑結果與處理計畫狀態	量測紀錄、審查紀錄

上面幾段收成一條線，長這樣：

風險準則	→ 辨識	→ 分析	→ 評估	→ 處理	→ 殘餘風險
§6.1.2 a)	§6.1.2 c)	§6.1.2 d)	§6.1.2 e)	§6.1.3 a)–e)	§6.1.3 f)

這條線有個容易搞錯的地方：殘餘風險往往被當成最後才想起來的事，其實它在處理選項決定的那一刻就出現了。你選了降低，降低之後還剩多少，要在同一列裡寫出來；寫不出來的那一列，代表處理方式還沒想清楚。

認證申請、兩階段稽核與矯正流程屬於另一篇，這裡只留一個入口：〈ISO 27001 認證怎麼申請？流程、導入與輔導重點〉。

風險、威脅、弱點、事件、殘餘風險的差別

看起來像在計較用字，其實決定你的表格填不填得完。名詞一混，典型的下場是整張表只有資產與漏洞，一條風險都沒有。

風險。 依 ISO/IEC 27000:2018 的定義（財團法人全國認證基金會（Taiwan Accreditation Foundation，TAF）中文譯本）：「風險是不確定性對於目標之影響，影響可為正面或負面。」（3.61）放到 ISMS 的情境裡，「目標」就是資訊的 CIA，實務上會講成「不確定性對資訊安全目標的影響」。

風險評鑑。 同一份術語標準寫得更清楚：「風險評鑑是由風險鑑別、風險分析及風險評估組成的整體過程。」（3.64，TAF 中文譯本；引述原文保留「評估」二字）這是官方定義，也順帶解掉一個常見誤解：風險評鑑並非「打一次分數」，它是三個動作合起來的整體。用語上還有個小差異。TAF 中文譯本譯作「風險鑑別」，多數台灣顧問說「風險辨識」，兩者是同一件事，文中統一寫「辨識」。

風險分析。「瞭解風險性質並判斷風險等級的過程」（27000:2018 3.63，TAF 中文譯本）。重點落在「判斷等級」：分析做完要有等級，不能只有描述。

風險處理。「風險處理是減緩風險之過程，可能造成新風險或修改既有風險。」（3.72，TAF 中文譯本）後半句值得停一下：處理本身會帶來新風險，加了加密就多了金鑰管理與效能問題。處理後的殘餘風險因此不等於「原本的風險減一點」，要看的是處理之後實際剩下的樣子。

資訊安全事件。 27000:2018 3.31 的定義是「單一或一連串有害或突發資訊安全事件，很有可能影響到企業營運，並威脅到資訊安全」（TAF 中文譯本）。條文用它區分「還沒發生的風險」與「已經發生的事件」。事件是事故處理與通報的對象，風險是評鑑與處理的對象，兩張表別混。

殘餘風險。 處理之後仍留下的風險。這個詞在 27000:2018 的官方中文譯本裡查無逐字定義（本輪未能取得 ISO 線上瀏覽平台的內容）。文中採驗證機構公開指引詞表的說法：風險處理後仍留下的風險，屬二手資料，內容轉述、不加引號。

威脅、弱點、風險來源、風險擁有者的官方逐字定義，查無。 這一項照實寫：本輪沒有取得 ISO 線上瀏覽平台的內容，27000 的官方中譯本也只收錄到風險、風險分析、風險評鑑、風險管理、風險處理與資訊安全事件等詞，沒有 threat／vulnerability／risk source／risk owner 的逐字定義。要引用定義，請自行取得標準或術語文件，或向發證機構確認。

不過條文層面查得到幾件事，足夠判斷這幾個詞怎麼用。§6.1.2 c) 要求辨識的是「與 CIA 損失有關的風險」，不是「與資產有關的項目」。27000 的修訂註另外提到，威脅可能利用資訊資產（或一組資產）的弱點，對組織造成損害，這句話把威脅、弱點、資產三者的關係講出來了（TAF 中文譯本）。§6.1.2 c) 另外要求辨識風險擁有者，代表每一條風險都要有人認。

風險胃口（risk appetite）不是這套標準的術語。 ISO/IEC 27001 用的是「風險接受準則」。風險胃口是業界慣用說法，寫在內部文件裡無妨；別寫成「標準要求定義風險胃口」，也別拿它取代接受準則，兩者在流程裡的位置不同。後面談殘餘風險那節會把三者的層級排一次。

名詞	一句話定義	來源等級
風險	不確定性對於目標之影響，影響可為正面或負面	官方（27000:2018 術語，TAF 中譯）
風險分析	瞭解風險性質並判斷風險等級的過程	官方（同上 3.63）
風險評鑑	由鑑別、分析、評估組成的整體過程	官方（同上 3.64）
風險處理	減緩風險之過程，可能造成新風險或修改既有風險	官方（同上 3.72）
資訊安全事件	有害或突發、且可能影響營運並威脅資訊安全的事件	官方（同上 3.31）
殘餘風險	風險處理後仍留下的風險	二手（驗證機構公開指引詞表）
風險擁有者	對某條風險具當責與職權的人；官方逐字定義查無	二手＋條文要求辨識
威脅／弱點／風險來源	官方逐字定義查無；僅能由修訂註說明三者與資產的關係	查無
風險胃口	業界用語，不是本標準術語；標準說法是風險接受準則	業界用語

風險準則要事先寫什麼？可以事後補嗎

不行，而且不只是「不建議」而已，是文件上自證不了。§6.1.2 a) 的動詞是「建立並維持」，先建立、後維持：它得在評鑑之前就存在，並且隨組織變動更新。同一條的 b) 再補一句，重複執行時結果要一致、有效、可比較。兩句合起來，準則就從一張參考表變成流程的前置條件。

一份能用的準則，寫到四件事就夠：

要寫的四件事	內容	常見漏洞
可能性量表	1–5 分各代表什麼情況（多久發生一次、同業有沒有案例）	只寫「高／中／低」，沒有判準
影響量表	1–5 分各代表什麼後果，用 CIA 與營運中斷描述	只寫「資料外洩」，沒分嚴重程度
風險矩陣	可能性與影響怎麼合成等級	矩陣與後面的等級名稱對不上
接受門檻與重評時機	哪個等級以下可接受、什麼情況要重評	門檻寫「原則上」，沒有等級或條件

事後補的問題出在日期上。稽核員比對的是日期，不是內容好不好看（顧問實務）。準則文件的版本日期晚於評鑑結果的日期，等於自證「先打分數、後生規則」。即使你實際上真的先想清楚才打分，文件上也說不出來。這條時間軸最好查，也最難補。

最常見的錯誤示範是這樣：先開會把每一條風險打上分數，散會後才請人「生一份準則出來」，5×5 的矩陣印成一頁，日期押在會議之後。這份文件內容可能完全正確，卻證明不了那些分數是照它打的。（這是顧問實務中看到的順序問題，不是條文列舉的缺失類型。）

還有一種變形：準則寫得很完整，但沒人照著用。準則寫「影響 5 分＝核心業務中斷超過可容忍時間」，實際打分卻用「客戶會不會生氣」來判斷。這種不一致，稽核員通常一個問題就測得出來：「這一條為什麼是 4 不是 3？」答案回到準則判準就過；答案是「感覺」，那本準則就只是裝飾。

門檻在準則有沒有先寫、有沒有照著用，不在你選哪一套工具。工具可以換，這兩件事不能省。

風險評鑑表要有哪些欄位？（可直接照抄的清單）

下面這 12 欄，是一份可以拿去給稽核員看的風險清單長相。欄位順序不重要，每一欄「填什麼」與「最常填錯什麼」才要緊。這 12 欄是顧問實務整理；條文要求的是內容齊備（流程與結果各有紀錄），欄位名稱沒有規定。

#	欄位	填什麼	常見填錯
1	編號	讓後面所有文件都能引用的一組代碼（例如 R-01）	改版後重編，舊文件全部對不上
2	情境一句話	主詞＋條件＋後果：誰、在什麼情況下、哪份資訊會怎樣	寫成資產名稱或系統名稱（例如「ERP 主機」）
3	涉及資訊	哪一份資訊、屬於誰、放在哪裡	只寫「資料」，說不出是哪一份
4	可能性	依準則量表打分，並註明依據	憑印象打分，事後才補理由
5	影響	依準則打分，並寫出影響的是機密性、完整性還是可用性	一律寫「很嚴重」，三個面向沒分開
6	等級	由矩陣得出，寫等級名稱而不是只寫分數	只寫「4×5」，看不出等級
7	處理選項	避免／降低／分攤／保留，選一個為主	寫「加強管理」這種沒有對應選項的話
8	必要控制	對應的控制措施（可含自訂控制）	直接抄附錄 A 編號，說不出擋哪條風險
9	風險擁有者	組織內有決定權的職稱或姓名	寫單位名（「資訊部」）或寫顧問
10	期限	處理完成的目標時間	全部押同一天，或整欄空白
11	殘餘等級	處理後重新評估的等級	直接抄處理前的等級
12	接受者與日期	誰接受這個殘餘風險、哪一天接受	空白，或只寫「已接受」

12 欄填不填得滿，關鍵在第 2 欄。情境句怎麼寫，後面「三個情境示例」那節會展開，這裡先給個判斷標準：讀起來像資產盤點表的一行，那不是風險；讀起來像「誰在什麼情況下會讓哪份資訊出事」，才是。

中小企業從哪裡開始？最小可行的版本是三件套（顧問實務，不是標準要求）：一張 20–40 條的情境清單、一份 1–2 頁的 5×5 準則、一張處理狀態表。清單是主體，準則是打分依據，狀態表拿來追蹤。再配兩個動作就足以自證一致與可比較：每季更新狀態表，週期到了或重大變更時重評一次並留下版本差異。

結構上還有一個建議：分兩層，不要塞成一張。管理層要看的是情境清單（20–40 條，看得出業務後果）；技術層要看的是掃描報告與修補清單（幾百條弱點）。把每台主機的每一條漏洞都塞進風險清單，通常第二年就維護不動，整份停擺。ISO/IEC JTC 1/SC 27 公開文件（未經 ISO 背書）把這種失效型態描述成「需要大量資料、無法維持」（意譯）。

「要幾個人做、花多少工作時間」沒有標準答案，也不該有，人力配置依組織規模與範圍自訂。真正影響作業量的是欄位數與情境條數，標準不會替你決定。上面建議先做 20–40 條，原因就在這裡；一次列到三百條，多半撐不到第二年。

還有一件事要提醒：風險清單不是資產清單。把盤點表改個標題就當成風險評鑑，是最常見的形式；委員會文件直接把這種情況點名為「風險評鑑其實是一份漏洞報告」的失效型態（意譯）。判別方法很簡單，拿掉「資產名稱」那一欄，整張表如果就空了，它本來就是資產清單。

風險等級怎麼分？一定要用 5×5 嗎

不必。ISO/IEC 27001 不要求特定方法：「ISO/IEC 27001 does not require a specific method.（ISO/IEC 27001 不要求特定方法。）」同一份文件也提醒稽核人員，不應推銷或要求特定做法。

另一句更直接：「ISO/IEC 27001 does not require the identification of risks by the identification of assets, threats and vulnerabilities.（ISO/IEC 27001 不要求以資產、威脅、弱點的辨識來辨識風險。）」照這句話，「一定要先做資產盤點」在標準裡找不到依據。

條文唯一的硬要求，是準則要事前建立並維持，重複執行時結果一致、有效、可比較（§6.1.2 a)、b)）。矩陣法、情境法、清單法都可以，重點是前後一致。

下面四張表是示例，不是 ISO/IEC 27001 的規定；標準未規定等級名稱、級數或門檻。先看清楚「長什麼樣」，再改成自己組織說得出口的版本。

（A）可能性量表

分數	名稱	判準寫法
5	幾乎確定	一年內很可能發生；同業已多次出現類似情況
4	很可能	一到三年內可能發生
3	可能	三年內有可能發生
2	不太可能	五年內難以想像，但並非不可能
1	罕見	只在特殊條件下才可能發生

（B）影響量表

分數	名稱	判準（以 CIA 與營運中斷為主軸）
5	嚴重	核心業務中斷超過可容忍時間；或大範圍客戶資料外洩，涉及通報義務
4	重大	核心業務中斷數日；或重要客戶資料受影響
3	中度	部分業務受影響，短期內可回復
2	次要	局部不便，內部可自行吸收
1	輕微	幾乎無感，僅需例行處理

（C）風險等級矩陣（可能性 × 影響）

可能性＼影響	1 輕微	2 次要	3 中度	4 重大	5 嚴重
5 幾乎確定	中	高	高	極高	極高
4 很可能	中	中	高	高	極高
3 可能	低	中	中	高	高
2 不太可能	低	低	中	中	高
1 罕見	低	低	低	中	中

（D）等級對應的處理規則（寫進風險準則的就是這一段）

等級	建議處置	誰決定
極高	立即處理；處理完成前先採臨時措施；提報高階管理	風險擁有者提案、高階核准
高	訂處理計畫與期限，納入追蹤	風險擁有者
中	可接受，但留下接受理由與日期（或加做低成本控制）	風險擁有者確認
低	例行程序管理，不需個別處理計畫	依組織規定

稽核一定會問「這一條為什麼是 4 不是 3」。要答得出來，量表的判準得寫到別人可以照著打。例如「4 分＝一到三年內可能發生」，「4 分＝很可能」就差得遠：前者可以被追問依據，後者只能被追問「誰說的」。

3×3、4×4 都可以，甚至只用「高／中／低」三級也行，只要準則寫清楚、前後一致、跨年度可比。等級叫什麼、分幾級無所謂，別人能不能重複打出同一個分數才有差。

三個中小企業情境示例（照這樣寫一句話情境）

以下為示例情境，非客戶案例，不含任何公司名或可識別個案。 三則都寫成中小企業常見的形狀，換成自己公司的系統名稱與資料就能用。

情境一句話	涉及資訊	可能性×影響→等級	處理選項	殘餘風險
ERP 顧問廠商持有可從外部連入的共用維運帳號，人員離職後未即時停用，可能被冒用修改訂單與客戶資料	客戶訂單、價格、往來資料（CIA 三個面向都受影響）	4×5 → 極高	降低（改為個人具名帳號、特權帳號管理、限制連線來源）＋分攤（委外契約明訂帳號管理與通報義務）	廠商內部人員仍有濫用可能，由風險擁有者接受並登錄
設備維護廠商以固定帳密遠端連線，沒有連線紀錄，事後無法追溯誰做了什麼	設備設定、維護紀錄、可觸及的系統資料	4×4 → 高	降低（連線需申請、全程留存紀錄、最小權限）＋避免（改為到場維護）	紀錄留存但不常檢視，併入每月抽查
業務筆電含客戶議價資料與合約，未做全碟加密；備份每天成功，但三年沒做過還原演練	客戶合約與議價資料、營運系統資料	3×4 → 高；備份還原 3×5 → 高	降低（全碟加密、遠端抹除、每季還原演練並留存紀錄）	已加密仍可能被破解；演練尚未涵蓋全部系統，接受並排定次年擴大範圍

三則拆開看，情境句的結構相同：主詞（誰）＋條件（什麼情況下）＋後果（哪份資訊會怎樣）。第一則「ERP 顧問廠商持有的共用維運帳號，在人員離職後沒有即時停用，可能被冒用修改訂單與客戶資料」，主詞是廠商與離職人員，條件是帳號未停用，後果是訂單與客戶資料被改。

「伺服器未更新」這種寫法為什麼不行？那句話是資產與狀態描述，回答的是「哪裡有問題」，不是「會出什麼事」。資產式敘述的代價很直接：判斷不了影響，因為不知道哪份資訊會受害；也排不出優先序，每條看起來都一樣嚴重。改寫成情境句，可能性與影響才有東西可以對應。

第三則值得單獨講，它示範「可能性不高、影響極高」怎麼判斷。每天備份成功，但三年沒做過還原演練：這件事發生的機會不算高（備份本身在跑），可是一旦需要還原而失敗，影響落在可用性與客戶信任上，屬高或極高。判斷的時候，別用「平常沒出事」去壓低可能性，要看「條件成立時後果多大」來撐住影響。影響量表要用 CIA 三個面向分開描述，原因也在這裡；只寫「資料外洩」的量表，量不出備份還原這一類風險。

三則的處理選項都以一個為主、另一個為輔，這是實務取捨：一條風險對應太多控制，第二年追不動；一條風險只對應一個主要控制，責任與期限才排得出來。殘餘風險那一欄別寫「已降低」，要寫「還剩下什麼」，例如「廠商內部人員仍有濫用可能」，那才是風險擁有者要簽的東西。

風險處理有四種選項，這是標準規定的嗎

標準沒有這樣規定。ISO/IEC 27001 第 6.1.3 條 a) 只要求組織依評鑑結果「選擇適當的風險處理選項」，沒有列出固定四選項（條文經驗證機構公開指引轉引）。「避免／降低（修改）／分攤（轉移）／保留（接受）」這組歸納出自 ISO/IEC 27005 的用語。2018 版目錄即列有風險修改、風險保留、風險避免、風險分攤四節，另有一節談風險接受；2022 版（第 4 版，2022 年 10 月發布）為現行版（ISO/IEC 27005:2022 標準頁）。

27005 的定位要說清楚。「ISO/IEC 27005:2022 為第 4 版、2022 年 10 月發布，屬指引（guidance），用以支援 ISO/IEC 27001 的導入。」它不單獨發證，也不是符合性評鑑標準。ISO/IEC JTC 1/SC 27 公開文件（未經 ISO 背書）明示，27002／27003／27005／27007／27008 這類指引「並非為符合性評鑑而寫，也不包含組織必須實施的要求」。ISO 31000 同樣是原則與指引：「ISO 31000 提供風險管理原則與指引，並非可驗證（certifiable）的風險管理標準。」（iso.org/standard/65694.html）

四種選項在中小企業的長相，跟教科書寫的不太一樣：

選項	中小企業常見做法	要留下什麼
避免	不做這件事（不上某個服務、不接某類資料、不改某段流程）	決定不做的理由，以及替代做法
降低	技術控制＋流程（權限、加密、備份、覆核）	控制做了什麼、做完的殘餘等級
分攤	契約條款、保險、委外分工	契約裡哪一條寫了什麼、對方承擔哪一段
保留	知情接受，不另外處理	接受的理由、接受者、日期

選完選項還沒結束。§6.1.3 b) 接著要求「決定所有必要的控制措施」：選了降低，就要說出降在哪裡；選了分攤，就要說出契約怎麼寫；選了保留，就要說出誰知情。最常見的斷點是表格上寫了「降低」，卻沒有任何一項控制措施對應，處理就停在動詞。

還有兩個用語要分。「轉移」與「分攤」常被混用：轉移暗示風險整個搬出去，分攤是共同承擔。實務上幾乎沒有真正的全部轉移，保險有理賠上限、契約有責任上限，剩下的還是你的，到頭來要回到殘餘風險那一欄。「保留」與「接受」也一樣：保留是處理選項的一種（決定不另外處理），接受是風險擁有者對殘餘風險的正式動作（§6.1.3 f)），兩者在流程裡的位置不同。

還有一句可以用來解釋條文為何不列舉：ISO/IEC 27001 的風險評鑑與處理流程，與 ISO 31000 的原則及一般指引一致。對齊的是一套通用原則，選項自然不會寫死成四種。

殘餘風險是什麼？誰簽、簽在哪一欄

殘餘風險是處理之後仍留下的風險。它跟「原本的風險變小一點」不能畫等號，講的是處理做完之後實際還剩下什麼。把共用帳號改成個人具名帳號，剩下的風險是「具名帳號被釣魚」，不再是「共用帳號被冒用」。

誰簽？§6.1.3 f) 要求取得風險擁有者對處理計畫的核准，以及對殘餘風險的接受。驗證機構公開指引另以註解強調：「風險擁有者負責核准風險處理計畫並接受殘餘風險。」（Certification Notes p.43 NOTE 11，條文經驗證機構公開指引轉引）簽的人既不是資安窗口，也不是寫文件的人，是那條風險的擁有者。

三個名詞常被當成同一件事，其實站在流程的不同位置：

名稱	什麼時候	誰	寫在哪
風險接受準則	事前（評鑑之前）	組織（管理階層核定）	風險準則文件（§6.1.2 a)）
殘餘風險的接受	事後（處理計畫訂好之後）	風險擁有者	風險清單的接受欄（§6.1.3 f)）
風險胃口	—	—	業界俗稱，不是本標準術語

簽在哪一欄？實務上四欄就夠（顧問實務）：殘餘等級、接受者、接受日期、理由。接受者寫人名或職稱，別寫單位名。「資訊部接受」這種寫法，出事時找不到人。理由那一欄最常被留白，偏偏它才是「知情」的證據：寫「已加密，仍存在裝置遺失後被破解的風險，評估可接受」，比寫「可接受」有力得多。

結構上還能再建議一層：把簽核設計成「風險擁有者簽＋管理審查確認」兩層（顧問實務）。第二層的道理在 §9.3.2，管理審查的輸入本來就包含風險評鑑結果與處理計畫狀態，管理階層會看到這份清單；把它變成正式確認，比事後補一份簽呈自然。要強調的是，條文沒有規定要總經理簽、也沒有規定要資安長簽；簽核層級由各組織自己定，寫進準則即可。

最後一條紅線：風險擁有者不能掛顧問或外部人員。 這個角色要有組織內的當責與職權，能決定要不要花資源、能改變流程、能承擔後果。外部顧問沒有這些職權，簽了不成立。稽核員看到「風險擁有者：○○顧問」，下一個問題一定是「公司內部負責這件事的是誰」。

做完風險評鑑，下一步是 SoA 還是風險處理計畫

依條文順序，先 SoA，再風險處理計畫。反過來做不行。 §6.1.3 的 a) 到 f) 是同一個流程內的前後項，d) 在 e) 之前（條文經驗證機構公開指引轉引）；先排計畫再補 SoA，補的痕跡會留在版本與日期上。

步驟	條號	產出
評鑑結果排出優先序	§6.1.2 e)	風險清單（含等級與優先序）
選處理選項	§6.1.3 a)	每條風險的處理方向
決定必要控制	§6.1.3 b)	必要控制措施清單（可含自訂控制）
與附錄 A 比對	§6.1.3 c)	比對紀錄（有沒有漏）
產出 SoA	§6.1.3 d)	適用性聲明
訂處理計畫	§6.1.3 e)	誰做、何時、怎麼確認有效
核准與接受殘餘風險	§6.1.3 f)	簽核與接受紀錄

第 4 步最容易誤解。「與附錄 A 比對」的意思，不是把附錄 A 的 93 項全部勾「已實作」。要做的是拿自己決定的必要控制去對照附錄 A，確認沒有漏掉該做的事。比對的結果可能是「這一項我沒想過，要補」，也可能是「這一項不需要，理由是我的業務沒有這個活動」。兩種都算比對的產出；「全部勾已實作」不算。

處理計畫的格式不必傷腦筋：「There is no particular requirement for the content or format of an organization’s risk treatments plan.（風險處理計畫的內容與格式並無特別要求。）」（Certification Notes p.43 NOTE 12，條文經驗證機構公開指引轉引）實務上每一列只要答得出三件事就夠：誰做、什麼時候做完、做完怎麼確認有效。

界線說明一下。SoA 的欄位與撰寫步驟屬於另一篇，這裡不展開；附錄 A 的四大主題與 93 項控制措施的逐條內容，見〈ISO 27001 Annex A 的 93 項控制措施怎麼看〉。這裡只講「評鑑的輸出怎麼餵進這一步」。

多久要做一次？什麼情況算重大變更

條文沒有規定固定週期。§8.2 的寫法是「在規劃的期間、或重大變更被提出或發生時」執行風險評鑑，並且要依 §6.1.2 a) 建立的準則來做（條文經驗證機構公開指引轉引）。「多久一次」留給組織自己訂，訂在風險準則裡。

常見的誤解，是把別人的週期當成規定。標準裡找不到「固定一年做一次」這種要求。ISO/IEC JTC 1/SC 27 公開文件（未經 ISO 背書）在談「何時該更新」時，把它列為組織應自行訂規則的項目，年度只是它舉的例子。你可以選年度、選半年，也可以只寫觸發條件；選哪一個，理由要寫得出來。

什麼算重大變更，條文沒有列舉，同樣由組織自己決定並寫進準則。以下是顧問實務的常見觸發清單，不是標準列舉：新系統上線或上雲、委外或換商、據點新增或併購、業務模式改變、重大資安事件、法規變更。這六項用來幫你起頭；文件上別寫成「依標準規定之六項重大變更」，那句話一定被追問「哪一條」。

除了重評，還有一層常被漏掉：§9.1 要求量測這兩個流程。ISO/IEC JTC 1/SC 27 公開文件（未經 ISO 背書）指出，因為 §9.1 要求流程要被監督或量測，風險評鑑與風險處理必須被量測，量測方式由組織自訂。可以量的例子不少：評鑑有沒有照排定時間完成、處理行動有沒有照期程關閉、處理完成後風險等級是否真的下降。第三個最有力，因為它同時驗證了處理有沒有用。

做法上不複雜：把重評時機寫進準則，每一次重評的版本與差異說明都留著。差異說明不用長，一頁以內寫清楚「這次多了哪幾條、哪幾條降級、為什麼」就夠。它的作用是讓下一次的稽核與管理審查看得到變化，而不是只看到一份新的清單。

稽核員會看什麼？最常做錯的 10 件事

三張表要先分清楚：表 A 是條文要求的文件化資訊，表 B 是實務上會被翻看的檢視點（不是條文要求），表 C 是最常見的十種做錯方式。三張分開看，才不會把實務習慣誤當成標準規定。

表 A：條文要求的文件化資訊

#	文件化資訊	條號
1	風險評鑑流程的紀錄	§6.1.2 末段
2	風險評鑑結果	§8.2 末段
3	風險處理流程的紀錄	§6.1.3 末段
4	風險處理結果	§8.3 末段
5	適用性聲明（SoA）	§6.1.3 d)
6	風險處理計畫	§6.1.3 e)
7	風險擁有者的核准與殘餘風險接受	§6.1.3 f)
8	版本與管制紀錄	§7.5.2、§7.5.3
9	監督量測結果	§9.1 末段
10	管理審查結果	§9.3.3（輸入含 §9.3.2）

（條號與要求重點經驗證機構公開指引轉引；標準文中未取得，不以引號引用。）

表 B：實務檢視點（顧問實務，不是條文要求）

#	檢視點	看到的問題長什麼樣
1	版本與日期	不知道手上這份是哪一版、什麼時候做的
2	風險擁有者簽核欄	只有單位名，沒有人名與日期
3	準則日期是否早於結果	準則日期晚於評鑑，順序反了
4	處置狀態與逾期原因	狀態欄空白，或逾期沒有任何說明
5	前次稽核後是否重評	上次缺失之後，清單完全沒動
6	殘餘風險欄	每條都寫「已降低」，或整欄空白
7	控制與風險能否雙向追	從控制追不回風險，或反之

表 B 這七點之所以有效，是因為每一點都「抽一條就能驗」。例如第 7 點：稽核員從風險清單抽一條風險，問「這條用哪個控制處理」，再從控制措施清單抽一項，問「這項在擋哪條風險」。兩個方向都通，代表你的文件是一套系統；有一個方向不通，那一項控制就變成孤兒。

表 C：最常做錯的 10 件事

查無驗證稽核的分類統計，沒有公開的缺失統計可以引用。下表因此不給排名、不給比例，只列十種在實務上會直接被退回的寫法。

#	做錯什麼	為什麼不行	怎麼改
1	風險清單＝資產清單	只有資產沒有後果與等級，等於沒有評鑑	每列改寫成情境句，補可能性與影響
2	準則事後補	日期順序自證不了「事前定義」	先寫 1–2 頁準則，日期押在評鑑之前
3	93 項全納入當成已處理	比對不等於全部納入；全部納入等於沒有取捨理由	由風險推必要控制，再與附錄 A 比對補漏
4	沒有殘餘風險與接受紀錄	§6.1.3 f) 要求接受，缺這欄流程沒走完	加殘餘等級、接受者、日期、理由
5	風險擁有者掛顧問	外部人員沒有組織內職權，簽了不成立	掛組織內有決定權的職稱或姓名
6	做完不更新	三年不動的清單，第二年就與現況脫節	重評時機寫進準則，留版本差異
7	9001 表格直接套	問的問題不同，欄位與判準不能照搬	共用登錄格式，另建 27001 的準則與後果描述
8	範圍只做 IT 核心系統	範圍漏掉，評鑑就不完整	用 §4.3 的範圍逐項對照資訊、系統、地點、人員、委外
9	控制與風險來源脫鉤	說不出在擋哪條風險，變成為了做而做	每個控制回鏈一條風險編號
10	方法太複雜，第二年維護不動	資料量太大，人力跟不上就整份停擺	分兩層：管理層看情境清單，技術層看掃描報告

這十條裡，前三條造成的退件最多，共通點是「文件看起來很完整」。一張兩百列的資產清單、一份事後補的矩陣、一份 93 項全部勾「已實作」的 SoA，放在桌上都很有份量。抽一條問「這是什麼風險、誰認、處理完剩多少」，三個洞會同時露出來。

資通安全管理法有要求做風險評鑑嗎？投標會看嗎

這一題得分兩層看，兩層的答案不一樣。網路上常見的錯誤，就是把兩層混著講。

第一層：法文中。《資通安全管理法》現行版本為民國 114 年 09 月 24 日修正，全文 35 條（全國法規資料庫）。全文出現「風險」只有 2 處，都與「危害國家資通安全產品」的審查程序有關。法文中沒有明定組織要做 ISO/IEC 27001 式的風險評鑑，也沒有規定方法。

第二層：施行細則。《資通安全管理法施行細則》現行版本為民國 115 年 01 月 05 日修正，全文 15 條；其第 9 條第 1 項第 7 款把「資通安全風險管理」列為資通安全維護計畫應包括的事項（全國法規資料庫）。對被納管的機關來說，這是法定應含事項：維護計畫裡要有這一項，但條文沒有規定用哪一種評鑑方法，也沒有規定分級方式。

引用時有個版本陷阱。110 年 08 月 23 日之前，同一條款的用語是「資通安全風險評估」，現行（115/01/05 版）已改為「資通安全風險管理」。 引到舊版條文，等於引用一個已被修正的用語，遇到熟悉法規的對方就會被指出來。

層	文件	版本	對風險評鑑的要求
法文中	資通安全管理法	114/09/24 修正，35 條	未明定風險評鑑，也未規定方法
施行細則	資通安全管理法施行細則	115/01/05 修正，15 條	第 9 條第 1 項第 7 款列「資通安全風險管理」為維護計畫應含事項；方法未規定
分級辦法	資通安全責任等級分級辦法	115/01/07 修正	附表為另附文件，本次未解析；等級對應的辦理頻率查無

第三列要特別說明：分級辦法的附表（各級機關應辦事項）是另附文件，本輪沒有取得與解析。所以任何「哪一級、多久辦一次」的等級對應頻率，文中都不寫，查無依據。要確認自己單位的應辦事項與頻率，請直接看分級辦法附表，或向主管機關確認。

投標會看嗎？查無「政府採購或共同供應契約通案要求投標者提供風險評鑑文件」的公開依據。能寫的說法是：採購案可能依個案在招標文件或契約中要求提供資安風險相關文件；是否要求、要求到什麼程度，要看該案的文件。 查證方式很具體，看招標文件的需求說明與契約條款，有沒有指定要交哪一份文件、要不要含風險清單或處理計畫。沒寫的，就別自己加碼，也別對外宣稱「政府採購都要求」。

這段收在一個分界上。不是資安法納管的機關，法律沒有要求你做風險評鑑；是被納管的機關，維護計畫裡要有「資通安全風險管理」這一項，但方法由你自己定。

跟 ISO 9001 的「風險與機會」差在哪

兩邊都叫「風險」，問的問題不同。ISO 9001 問「這件事會不會讓品質系統達不到目標」，對象是產品、服務與流程的符合性。ISO/IEC 27001 問「這份資訊會不會失去機密性、完整性或可用性」（§6.1.2 c) 1)，條文經驗證機構公開指引轉引），輸出還要接到必要控制、SoA、風險處理計畫與殘餘風險接受。

比較項	ISO 9001 的風險與機會	ISO/IEC 27001 的風險評鑑
問的問題	品質系統會不會達不到目標	這份資訊會不會失去 CIA
對象	產品、服務、流程	範圍內的資訊與其處理
輸出接到哪裡	品質目標、流程改善	必要控制、SoA、處理計畫、殘餘風險接受
誰簽	依組織規定	風險擁有者（§6.1.3 f)）

版本上有一件事必須寫對：「ISO 9001:2015 已撤銷（Withdrawn），由 ISO 9001:2026 取代。」不要再寫「9001 現行版是 2015」，這個錯誤在轉版期間特別容易被抓。

表格共用可以，欄位與判準不能照搬（顧問實務）。實務上常見的做法是共用一張登錄表的格式（編號、描述、擁有者、期限、狀態），但 27001 這一份要另建自己的準則與 CIA 後果描述。直接套用 9001 的「風險與機會」表格，最常見的結果是整張表都在講人員流動、供應商延遲這類品質議題，卻沒有一條在講資訊的機密性、完整性或可用性。

9001 的條文這裡不寫，兩套制度怎麼整合也不寫；整合牽涉文件共用、稽核排程與轉版順序，屬於另一篇。正在處理多系統整合的人，可以從〈ISO 9001 14001 整合轉版｜多系統整合轉版排程與整合稽核安排〉開始。

ISO 27001 風險評鑑 常見問題 FAQ

下一步｜與我們聯絡

不確定企業是否需要導入 ISO，或想了解輔導範圍、費用與時程？

歡迎先與我們聯繫，先了解您的需求與現況，再依實際情況安排電話討論、線上會議或到廠訪談。

全台皆可洽詢，北、中、南均提供 ISO 輔導服務。

聯絡方式

• 免付費專線：0800-695-996
• 各區電話：台北 02-6604-4178｜台中 04-2327-0352｜高雄 07-334-2260
• LINE 官方帳號：@zgs9595e
• 線上表單：與我們聯絡

結語：先確認對方要的是哪一份文件，再決定風險清單要列到多細

回到最初的問題。風險評鑑沒有標準格式，要求的是內容：準則事前寫、辨識有情境、分析有等級、評估有優先序、處理有選項與控制、殘餘風險有人簽。六件事湊齊，表格用 Excel、Word 或系統欄位都無所謂；缺一件，表格再漂亮也會在稽核現場被追問。

實際動手的順序大概是這樣。先寫 1–2 頁準則（量表、矩陣、接受門檻、重評時機），再列 20–40 條情境，打分並排優先序，選處理選項、定必要控制、與附錄 A 比對，產出 SoA 與處理計畫，最後由風險擁有者核准並接受殘餘風險。順序反過來做，會花更多時間改文件，稽核現場也講不清日期為什麼對不上。

下一步通常是同一個問題：範圍要劃多大、顧問在這一套流程裡負責哪一段、要問對方哪些問題。先確認你的 ISMS 範圍，再決定風險清單要列到多細。文末延伸閱讀的〈ISO 27001 顧問與驗證機構怎麼選？12 個企業最常問的問題〉與〈ISO 輔導顧問怎麼選？6 項判斷依據、費用問法與 3 個常見誤判〉把該問的問題整理成清單。

驪鑫做的是 ISO 輔導：輔導為主，可協助企業走完驗證流程；服務範圍為全台、北中南皆有據點，可就近安排或到廠。我們不發證，判定與發證由驗證機構為之。

延伸閱讀

以下為站內已發布的相關頁面；CNS 是我國國家標準的代稱，與 ISO 9001 分屬不同發證體系。

• ISO 27001 顧問與驗證機構怎麼選？12 個企業最常問的問題
• ISO 輔導顧問怎麼選？6 項判斷依據、費用問法與 3 個常見誤判
• CNS 認證是什麼？CNS 12681 與 ISO 9001 差在哪、該驗證哪一個

參考資料

本篇引用的官方文件與查詢入口（查閱日 2026-11-04）：

• 資通安全管理法（全國法規資料庫）：全國法規資料庫
• 資通安全管理法施行細則（全國法規資料庫）：全國法規資料庫
• ISO/IEC 27001:2022：ISO/IEC 27001 標準頁
• ISO/IEC 27000:2018：ISO/IEC 27000 標準頁
• ISO/IEC 27005:2022：ISO/IEC 27005 標準頁
• ISO/IEC 27001：ISO/IEC 27001 標準頁
• ISO/IEC 27005：ISO/IEC 27005 標準頁
• ISO 9001:2015：ISO 9001:2015 標準頁
• iso.org/standard/27001：ISO/IEC 27001 標準頁
• ISO/IEC 27005:2022 標準頁：ISO/IEC 27005 標準頁
• iso.org/standard/80585.html：ISO/IEC 27005 標準頁
• iso.org/standard/65694.html：ISO/IEC 27000 標準頁
• 全國法規資料庫：全國法規資料庫
• iso.org/standard/62085.html：ISO 9001:2015 標準頁