ISMS 導入範圍怎麼界定?範圍太大或太小的風險
ISMS 導入範圍,是依 ISO/IEC 27001:2022 第 4.3 條,決定資訊安全管理系統涵蓋哪些部門、據點、系統與服務的邊界。界定時要考量第 4.1 條的內外部議題、第 4.2 條利害關係人的要求,以及組織和外部單位之間的介面與相依關係,並以文件化資訊保存。
範圍一旦定錯,後面全部要重來:範圍太大,人天與文件量暴增;範圍太小,客戶不認可證書。以下依界定步驟、兩種風險、範圍聲明範例與日後擴大方式依序說明。需要協助評估適合的範圍,可參考我們的 ISO 27001 驗證輔導。
ISMS 範圍為什麼這麼重要?
因為範圍同時決定三件事:稽核要查什麼、驗證要花多少人天,以及證書上寫什麼。客戶看證書時,第一個確認的就是範圍有沒有涵蓋他買的服務。
稽核人天依 ISO/IEC 27006-1:2024 附錄 C 計算,納入範圍的人數越多,初次驗證的基準人天越高:
| 範圍內人數 | 初次驗證基準人天(第一+第二階段) |
|---|---|
| 1~10 人 | 5 |
| 11~15 人 | 6 |
| 16~25 人 | 7 |
| 26~45 人 | 8.5 |
| 46~65 人 | 10 |
2024 年版明定,人數要計入在組織控制下工作的所有人,包括非正職員工;多據點預設以總人數計算。驗證機構可依風險與複雜度調整,減少幅度最多 30%,所以 ISMS 導入範圍切得越清楚,越有談人天的空間。網路上有文章說 ISMS 依 IAF MD 5 計算,這是錯的:MD 5 適用品質與環境管理系統,資訊安全依 27006-1。費用的完整拆解可參考 ISO 27001 費用。
ISMS 範圍怎麼界定?5 個步驟
範圍界定通常落在導入專案的第 1 至 2 週,由專案負責人主導,最後由高階主管核准。整體流程可參考 ISO 27001 導入流程。
| 步驟 | 做什麼 | 負責人 | 產出 |
|---|---|---|---|
| 1. 確認驗證目的 | 列出要求證書的客戶、合約與法規 | 業務、法務 | 驗證目的清單 |
| 2. 整理議題與要求 | 依 4.1、4.2 列出內外部議題與利害關係人要求 | 專案負責人 | 組織全景紀錄 |
| 3. 畫出三種邊界 | 組織(法人、部門)、實體(辦公室、機房)、邏輯(系統、雲端區域) | IT、行政 | 邊界示意圖 |
| 4. 找出介面與相依 | 共用的 IT、人資、財務,以及委外與雲端服務 | IT、採購 | 介面清單 |
| 5. 寫範圍聲明並核准 | 寫成一段文字,與適用性聲明(SoA)對齊 | 專案負責人、高階主管 | 範圍聲明 |

最常卡關的是第 4 步。範圍外的單位一樣會碰到範圍內的資訊,例如總部 IT 幫子公司管帳號、外包商遠端維護伺服器。這些介面不必納入範圍,但要寫清楚誰負責、怎麼控管,稽核員一定會追問。
範圍太大會有什麼風險?
範圍太大,成本、時程與缺失風險都跟著放大。最常見的情況是第一年就把全公司、海外據點一起納入,結果風險評鑑做不完、文件趕不出來,驗證時程一延再延。
- 稽核人天增加,驗證費與內部陪同時間同步上升。
- 每個部門都要產出紀錄,任何一個部門沒做到就可能被開缺失。
- 之後每年的追查稽核也要維持同樣範圍,維運成本長期偏高。
實務上,與其一開始就做全公司,不如先鎖定客戶最在意的那條業務線拿到證書,第二年再擴大。
範圍太小會有什麼風險?
範圍太小,證書可能對業務沒有幫助。客戶要的是「我買的服務受 ISMS 管理」,如果範圍只寫了 IT 部門,實際提供服務的團隊卻不在範圍內,證書就無法回應客戶的稽核問卷。
另一個風險是邊界切得不合理。例如服務實際跑在雲端,範圍卻只寫辦公室;或把負責帳號管理的團隊排除在外。這類範圍在驗證時很難說服稽核員,也會讓適用性聲明出現矛盾,例如排除了機房,卻又把實體安全控制措施標為適用。

界定範圍時最常犯的 5 個錯誤
多數錯誤都發生在第 3、4 步,而且要到第一階段稽核才被發現。下面 5 種情況,界定 ISMS 導入範圍時可以先避開:
- 照組織圖切,而不是照服務切:範圍寫「資訊部」,但服務其實由產品、維運、客服三個部門一起提供。
- 漏掉遠端與委外人員:在家工作的工程師、駐點的外包人員,只要參與範圍內的服務,就要納入考量。
- 只寫辦公室,沒寫雲端:系統跑在公有雲,範圍卻沒有寫明雲端服務與區域。
- 把適用性聲明當成範圍:範圍決定哪些單位與系統納入,適用性聲明決定哪些控制措施適用,兩者不能互相取代。
- 範圍定了就不再檢視:組織改組、新增產品或據點時沒有回頭更新,追查稽核時才被發現。
範圍聲明範例
範圍聲明要寫得具體到外人看得懂:哪個法人、提供什麼服務、哪些據點與系統。下面兩個範例可以直接改寫:
範例一:SaaS 公司
本公司資訊安全管理系統適用於「○○雲端服務平台」之設計、開發、維運與客戶支援,涵蓋台北辦公室之相關人員與作業,以及部署於○○雲端服務區域之系統與資料,依適用性聲明第 ○ 版。
範例二:製造業的資訊部門
本公司資訊安全管理系統適用於新竹廠資訊處所提供之企業資源規劃(ERP)、電子郵件與網路基礎設施之維運服務,涵蓋新竹廠機房與資訊處人員,依適用性聲明第 ○ 版。
寫完 ISMS 導入範圍聲明後,用三個問題自我檢查:客戶要的服務有沒有在裡面?範圍外的單位碰到範圍內資訊時,介面是否寫清楚?適用性聲明的排除理由是否和範圍一致?範圍決定後,ISO 27001 風險評鑑 就只需針對範圍內的資產進行。
日後要擴大範圍怎麼做?
可以,但要事先和驗證機構安排。一般而言,擴大範圍會搭配年度追查稽核或三年一次的重新驗證,另外增加稽核人天,新納入的部門也要先跑過風險評鑑、內部稽核與管理審查。

建議在第一年的管理審查就決定擴大計畫,給新單位至少一季的運作時間再申請。擴大後,範圍聲明、適用性聲明與風險評鑑都要同步更新。反過來,若業務收掉、要縮小範圍,一般而言也要通知驗證機構,由其調整證書內容,不能自行沿用舊證書對外說明。
ISMS 導入範圍常見問題
可以只驗證一個部門嗎?
可以。標準允許部分範圍,常見做法是先驗證一條業務線或一個據點,前提是邊界合理、與其他單位的介面有控管,而且對外不能宣稱證書涵蓋全公司。
客戶會接受範圍小的證書嗎?
取決於範圍有沒有涵蓋客戶購買的服務。範圍小但正好涵蓋該服務,多數客戶可以接受;範圍大卻不包含該服務,反而沒有用。
範圍怎麼寫在證書上?
證書會載明驗證範圍,通常包括業務活動與據點地址,實務上多數驗證機構也會註記所依據的適用性聲明版本。申請前可以先請驗證機構確認範圍文字,避免核發後才發現與客戶要求不符。
範圍還沒決定,先問自己哪個問題?
先問:「哪個客戶、哪份合約要我們拿證書?」答案指向的服務,就是第一年範圍的核心。完整的標準架構可參考 ISO 27001 的介紹。
拿不準範圍該切多大,可以 直接與顧問聊聊貴公司的狀況。
參考資料
- ISO/IEC 27001:2022 Information security management systems — Requirements – 第 4.3 條 ISMS 範圍。ISO
- ISO/IEC 27006-1:2024 – 驗證機構要求與附錄 C 稽核人天。ISO
