ISMS 範圍可以只包一個部門或一個據點嗎？

可以。標準沒有限制範圍大小，可以是全公司，也可以是一條產品線、一個據點或一項服務。但範圍要考慮內外部議題、利害關係者的要求，以及和範圍外活動之間的介面與相依關係。如果客戶在意的服務不在範圍內，證書對客戶就沒有意義；只寫「資訊部」而說不出它支撐哪些業務，也常在稽核時被追問。

4.1 的內外部議題一定要寫成文件嗎？

標準沒有明文要求 4.1 與 4.2 寫成文件，只有 4.3 的範圍必須以文件化資訊形式可供取得。不過實務上幾乎都會留下一份議題表與利害關係者對照表，因為 6.1 規劃風險與機會時要考慮這些內容，管理審查也要檢視它們的變化，稽核員更會請你說明判斷依據。

2024 年的氣候變遷修訂，需要換證或重新驗證嗎？

不需要。ISO/IEC 27001:2022/Amd 1:2024 是對 2022 版的修訂，ISO 與 IAF 的聯合公告把它定位為釐清既有要求，沒有轉版期，證書也不必換發，驗證機構會從之後的例行稽核開始檢查。組織要做的是在 4.1 判斷氣候變遷是否為相關議題、在 4.2 留意相關要求，並留下判斷理由。實際做法以驗證機構的說明為準。

差距分析是驗證必要的文件嗎？

不是。差距分析不是標準要求的步驟，而是導入時普遍建議的起手式，用來找出現行做法和標準要求的落差、估算工作量與時程。驗證稽核不會要求一定要有差距分析報告，但它常延續成導入工作清單或風險處理計畫。要注意它只看「做了沒」，要用哪些控制仍要由風險評鑑決定。

組織全景、利害關係者與 ISMS 範圍｜ISO 27001 互動教學

💡 先搞懂問題

很多組織導入 ISO/IEC 27001 的第一個動作，是去找一份風險評鑑範本開始填。填到一半才發現問題：客戶合約裡寫著「資安事件 24 小時內通知」，卻沒有人知道；放在雲端的訂單網站到底歸誰管，資訊部和業務部各說各話；證書拿到了，客戶一看範圍只寫「資訊部」，直接說這張證書和他們的訂單無關。

這些都是跳過第 4 章的後果。第 4 章組織全景（Context of the organization）要組織先回答四件事：自己處在什麼環境、有哪些會影響資安成果的內外部議題（4.1，issues）；哪些利害關係者（interested parties，CNS 譯為「關注方」，指會影響組織、受組織影響或認為自己會受影響的人或團體）有什麼要求，其中哪些要透過 ISMS 處理（4.2）；ISMS 的範圍畫到哪裡、和範圍外的單位或供應商怎麼銜接（4.3）；以及整套制度由哪些過程組成（4.4）。

前兩項是後面風險評鑑的輸入，範圍則決定風險評鑑與附錄 A 控制要涵蓋哪些對象。2024 年的修訂（Amd 1）又在 4.1、4.2 加入氣候變遷的考量，讓這一章多了一道必答題。

議題與要求決定範圍，範圍決定風險評鑑與控制要涵蓋誰。

生活比喻：一家人搬家

想像一家四口要從台北搬到新竹。搬之前先盤點處境：外面的條件是新家附近的學區、通勤時間、那一帶下大雨會不會淹水；家裡的條件是預算多少、誰需要一間書房、阿嬤腳不方便，新家一定要有電梯。

接著弄清楚每個相關的人在意什麼。房東要求退租前把牆面恢復原狀；新大樓管委會規定搬家只能在週末、要先登記電梯；國中的兒子只在乎他的電腦和遊戲機不能摔壞，順便希望換一台新電腦。最後一項不歸這次搬家處理，那是另一筆預算。

最後和搬家公司確認範圍：搬哪些房間、陽台盆栽搬不搬、舊沙發直接丟掉。冷氣另外請冷氣行拆，所以得講好哪天拆、拆完室外機由誰搬下樓，否則搬家當天兩邊一定在現場互相推。出發前，爸爸先把舊家每個房間走一遍，列出要帶、要丟、新家還缺什麼。

回到 ISMS：剛才的學區、淹水風險、預算與家人需求，對應的就是 4.1 的內外部議題；房東、管委會、兒子各自的要求是 4.2 的利害關係者需要與期望，而「換電腦不歸搬家處理」就是 2022 版新增的 4.2 c：決定哪些要求透過 ISMS 處理。和搬家公司講好的清單是 4.3 的範圍，冷氣行和搬家公司之間的分工，就是範圍的介面與相依關係。出發前那趟巡房，則是導入時常做的差距分析。

這個比喻有三個地方和實際不同。第一，搬家做一次就結束，組織的處境與利害關係者的要求卻一直在變，所以 9.3 管理審查要檢視這些變化，清單要定期更新。第二，搬家清單照「想帶什麼」決定，ISMS 範圍卻要考慮議題、利害關係者要求與介面；只挑容易的部分，拿到證書也幫不上客戶。第三，冷氣行不在搬家公司的合約內，你仍然得管它；同樣地，雲端服務商或外包廠商不在 ISMS 範圍內，不代表不用管，它們提供的服務要依 8.1 與附錄 A 的供應商控制來管制。

🎮 互動實驗室一：利害關係者對照

示意組織：一家 220 人的精密零件製造商。新竹總部有業務、研發、資訊、人資與財會；台中工廠有產線、品保和一間小機房，ERP 與圖面管理系統的伺服器都放在那裡。客戶是海外車廠，透過架在公有雲上的訂單入口網站下單、上傳設計圖面。

下方是 12 項要求或期望，請把每一項配給提出它的利害關係者。桌機可以直接拖曳；手機請先點一下要求，再點利害關係者。配對成功後，要求會出現在那一格，請再判斷它要不要透過 ISMS 處理（4.2 c）。最下面還有 4 題 2024 年氣候變遷修訂的判斷題。

配對 0 / 12

4.2 c 判斷正確 0 / 12

配錯次數 0

畫面說明：還沒有動作。先選一項要求，想想是誰會在合約、法規、會議或保單裡提出它。

加碼：2024 年氣候變遷修訂判斷題

Amd 1 要組織在 4.1 判斷氣候變遷是不是相關議題，並在 4.2 留意利害關係者可能有氣候相關的要求。下面 4 個情境都是虛構的，請選最恰當的做法。

氣候題 0 / 4

🎮 互動實驗室二：範圍界定模擬器

同一家製造商的海外車廠客戶要求：證書範圍要涵蓋「客戶設計圖面與訂單資訊的接收、保管與處理」。第一次導入，人力有限。請點選要納入範圍的部門、場址與系統；外包與雲端服務不會「納入範圍」，但可以把它們列為介面管理。每點一下，右下會即時檢查邊界與相依性，並產生一段示意的範圍描述。也可以先按上面的預設，看看常見的錯誤畫法。

缺口 0

提醒 0

客戶需求：未涵蓋

第一次導入工作量（示意）：—

畫面說明：紅色是會讓範圍站不住的缺口，黃色是可以接受、但要寫清楚介面或理由的提醒。被點名的項目會在地圖上加框。

🎮 互動實驗室三：差距分析小工具

差距分析（gap analysis）是把現行做法逐條對照標準，標出「沒做、部分、已做」。下面挑了第 4 到 10 章各條文最常被問的 16 個項目，請替你的組織（或示意組織）勾選現況，右邊會畫出各章的示意成熟度，並列出缺口最大的地方。可以先按「載入示意現況」，看一家已有 ISO 9001 的製造商常見的起點。

畫面說明：長條是各章項目的平均分數換算成百分比（沒做 0、部分 50、已做 100），只是示意，不是驗證判定。

📘 原理補完

第 4 章四個條文的分工

條文	在問什麼	標準對文件的要求	常見做法	稽核常見的缺失
4.1 Understanding the organization and its context	哪些內外部議題會影響 ISMS 達成預期結果；2024 起還要判斷氣候變遷是否相關	沒有明文要求寫成文件，但要能說明判斷，並追到 6.1 的規劃	議題表，常用 PESTLE、SWOT 或簡單表格；寫出議題、來源、影響、對應的風險或目標	清單多年未更新、和風險評鑑對不起來、完全沒處理氣候變遷
4.2 Understanding the needs and expectations of interested parties	誰和 ISMS 有關、他們有哪些要求、哪些要透過 ISMS 處理	沒有明文要求寫成文件，但取捨要說得出理由	利害關係者對照表：對象、要求、來源（法規、合約、期望）、是否由 ISMS 處理、對應流程	只寫「客戶、員工、政府」幾個名詞，沒有具體要求；漏掉 4.2 c 的取捨
4.3 Determining the scope of the ISMS	ISMS 的邊界與適用性，考慮議題、要求與介面相依	範圍必須以文件化資訊形式可供取得	範圍文件：業務或服務、單位、場址、系統與網路邊界、介面、排除與理由	範圍太籠統、證書範圍與實際不符、略過雲端或外包這類介面
4.4 Information security management system	依標準建立、實施、維持並持續改善 ISMS，包括所需過程與交互作用	沒有規定特定文件	過程清單或過程地圖，列出負責人、輸入與輸出	各流程各自存在、彼此沒有銜接

標準要求「做出判斷」，但沒有規定用什麼工具、清單要多詳細、多久更新一次，這些都由組織自行決定。實務上幾乎每家組織都會把 4.1、4.2 寫下來，因為 6.1 規劃風險與機會時要用到，稽核員也一定會請你說明；而 9.3 管理審查的輸入包括內外部議題的變化，以及 2022 版新增的利害關係者需要與期望的變化，等於每一輪都要回頭檢查這兩張清單。

4.2 c：不是每個期待都照單全收

2022 版在 4.2 新增一個步驟：組織要決定利害關係者的要求中，哪些要透過 ISMS 處理。實驗室一裡「交期準時」「廢水排放合格」都是真實的要求，但它們分屬品質與環境管理，不需要擠進 ISMS；「事件 24 小時內通知客戶」「投保條件要求多因子驗證」則直接落在 ISMS 的流程上。判斷結果最好和要求寫在同一張表，並能追到對應的控制、流程或風險。被判斷為「不透過 ISMS 處理」不等於忽略，只是由組織其他管理機制負責。

2024 年氣候變遷修訂（Amd 1）

2024 年 2 月，ISO 與國際認證論壇（International Accreditation Forum，IAF）發布聯合公告，替採用共同結構的一系列管理系統標準加入氣候變遷考量，27001 的修訂文件是 ISO/IEC 27001:2022/Amd 1:2024。改動只有兩處：4.1 要組織判斷氣候變遷是不是相關議題，4.2 加了一則註，提醒利害關係者可能有和氣候變遷相關的要求。聯合公告把它定位為釐清既有要求，因此沒有轉版期、證書不必換發，驗證機構從之後的例行稽核開始檢查。標準沒有要求一定要判斷為「相關」，但結論與理由要說得出來；若判斷相關，就要讓它流進風險評鑑與營運持續的安排，例如機房淹水、長時間停電、關鍵供應商停擺。實際稽核時怎麼查、查到什麼程度，以驗證機構的說明為準。

畫範圍的步驟（常見做法）

從 4.1、4.2 出發：客戶、法規、母公司最在意哪些服務或資訊？這些通常就是範圍的核心。
沿著資訊流走一遍：資訊從哪裡進來、存在哪些系統、經過哪些部門、放在哪個場址的機房、由誰維運。
畫出邊界：列出納入的業務或服務、組織單位、場址、資訊系統與網路區段。
標出介面與相依關係：範圍外的單位、雲端服務、外包廠商、集團共用系統，各自提供什麼、怎麼管制。
寫下排除項目與理由，確認排除後不會在邊界上留下沒人管的空隙。
把範圍寫成文件，和預計的證書範圍文字核對；之後若要擴大，依 6.3 規劃變更，並和驗證機構安排擴增稽核。

範圍外，不等於不用管

4.3 要求組織考慮自己執行的活動和其他組織執行的活動之間的介面與相依關係。公有雲服務商、外包維運廠商不會出現在你的範圍「裡面」，因為你無法替它們建立 ISMS；但它們提供範圍內需要的服務，所以要當成外部提供的過程、產品或服務，依 8.1 管制，並套用附錄 A 5.19～5.23 的供應商與雲端服務控制。同樣地，範圍外的部門若會存取範圍內的系統，例如人資通知離職、研發人員登入圖面系統，這條線也要寫成介面，說明由範圍內的哪個流程控管。

ISMS 範圍、驗證範圍與差距分析

ISMS 範圍與驗證範圍：ISMS 範圍是組織依 4.3 自己決定並寫成文件的邊界；驗證範圍是驗證機構稽核後寫在證書上的文字，原則上應一致，但證書措辭通常較精簡，而且不能超過實際稽核過的部分。ISMS 證書通常也會註明所依據的適用性聲明版本。行銷文件寫「全公司通過 ISO 27001」，證書卻只涵蓋一個機房，是驗證機構會要求改正的情況。

差距分析：它不是標準要求的步驟，而是公開導入指引普遍建議的起手式，用來估工作量、排時程、向高層說明投入。它問的是「標準要求的事有沒有做」；要選哪些控制，最後仍要由風險評鑑與處理決定。已經有 2013 版驗證的組織，可以把重點放在 2022 版的差異，例如 4.2 c、6.3 變更的規劃、11 項新增控制，以及 Amd 1 的氣候變遷判斷。

2013 與 2022 版在第 4 章的差別

2022 版第 4 章的變化有三點：4.2 新增 c 項，要決定哪些要求透過 ISMS 處理；4.4 明確寫出 ISMS 包含所需的過程及其交互作用；4.3 的實質要求沒有改變，仍要考慮議題、要求與介面相依，並把範圍寫成文件。再加上 2024 年 Amd 1 在 4.1、4.2 加入的氣候變遷考量，就是目前第 4 章的全貌。

稽核常見的不符合

範圍只寫「資訊部之資訊安全管理」，說不出它支撐哪些業務；範圍納入了某套系統，卻排除放它的機房或管它的外包廠商；利害關係者清單有了，合約裡的通知時限卻找不到對應的事件程序；氣候變遷只寫「不相關」而沒有任何理由；全景與利害關係者清單從第一次驗證到現在從未更新，和管理審查的輸入對不起來。

✅ 自我檢測

以下 6 題都是原創情境題，選完會立即顯示對錯與解析。目前得分：0 / 6