ISO/IEC 27001 資訊安全管理系統（ISMS）

**現行依據為 ISO/IEC 27001:2022 及 Amd 1:2024。**2022 版取代 2013 版，延續第 4～10 章管理系統架構及風險導向方法；主要調整包括附錄 A 控制重組，以及變更規劃、流程互動與管理審查等要求。2013 版原本已有風險管理及領導責任，不宜描述為只做靜態防護。ISO 官方目錄

ISO/IEC 27001 是 ISMS 要求；ISO/IEC 27002:2022 提供資訊安全控制的實施指引。可與其他管理系統整合，但資安驗證不等於所有系統沒有漏洞，亦不自動證明符合所有個資或網路安全法規。

2024 氣候修正

4.1 要求判定氣候變遷是否為相關議題；4.2 備註提醒相關利害關係人可能有氣候要求。可評估高溫、淹水、供電及備援場址等情境，相關時再銜接風險處置；不能一律推論須碳盤查或對每項氣候情境採取同一控制。

2013 版轉換期已結束

依 IAF MD 26:2023，既有獲認可驗證組織轉至 2022 版的期限為 2025 年 10 月 31 日。未完成轉換的舊版證書不能繼續作為有效的獲認可驗證。現今仍使用舊制度者，應依現行要求改善，並向受理驗證機構確認適用申請程序，不再沿用歷史過渡方案。IAF 正式轉換要求

核對日期：2026 年 9 月 29 日。本頁依公開官方資料與專業機構指南整理，未取得付費標準全文；不取代正式標準或逐條符合性判定。

• **主體條款：**新增 6.3 變更規劃，釐清流程與互動、角色溝通、目標監督及管理審查等要求。
• **控制架構：**附錄 A 從 14 個領域、114 項控制重組為四大主題、93 項控制。數量減少不代表可以直接刪除原有措施，應核對新版對應與風險需求。
• **新增控制：**11 項新增控制涵蓋威脅情資、雲端、持續營運所需 ICT 準備及資料保護等，完整清單見下節。
• **屬性：**ISO/IEC 27002:2022 提供屬性分類方法，用於按控制類型、資訊安全特性等角度檢視措施；不是 ISO/IEC 27001 強制新增的 SoA 欄位。
• **文件與證據：**SoA、風險處置及控制執行情形須一致。可更新既有文件與對照，不必預設全部從零重寫。

屬性與指引定位參考：BSI ISO/IEC 27002 修訂說明。

附錄 A 的四大主題

正確的 11 項新增控制

下列中文名稱為閱讀用摘要，正式名稱及要求以標準為準。

供應鏈與遠端工作已有舊版控制基礎；「AI 系統資安」不是這 11 項中的獨立控制。企業使用 AI 時仍應按資訊風險評估適當措施。新增控制與主體變更參考：NQA 改版差距指南。

4. 組織所處之環境

辨識影響 ISMS 預期結果的內外部議題、相關利害關係人及相關要求，並確認哪些要求由 ISMS 處理。法規與契約應依所在地、資料及業務情境辨識，不能一律套用所有地區的法律。

範圍應清楚交代服務、場所、系統及內外部依賴；不能用縮小邊界掩蓋範圍內服務依賴的共享系統。4.4 釐清必要流程及互動；具體流程準則與執行控制則銜接 8.1。

**實務建議：**沿一項服務的資料取得、處理、傳輸與保存，檢查人員、雲端及外包介面是否被納入風險考量，並保留氣候相關性判定的依據。

5. 領導力

最高管理階層應展現承諾、確保政策及目標與組織方向相容、提供資源，並安排清楚的職責與權限。2022 版對角色權責在組織內的溝通更明確。

領導責任不是本次才新增；也不應把「取消強制管理代表」列成 2013 至 2022 的核心差異。可依組織需要配置資安負責人、團隊及協調窗口。

**實務建議：**重大風險應有明確負責人、資源與追蹤方式，讓管理階層掌握處置進度與剩餘風險。

6. 規劃

**6.1 風險與機會：**建立一致的資訊安全風險評估準則，評估機密性、完整性與可用性風險，選擇處置方式與必要控制，並取得風險負責人對處置計畫及剩餘風險的適當核准。

**6.2 資安目標：**在可行時量測，監督進度，安排責任、資源、期限及成果評估方式。零信任或監控工具可作為措施選項，不是每家企業必須導入的標準指定技術。

**6.3 變更規劃：**需要變更 ISMS 時，應以規劃方式執行。雲端遷移、新服務及組織改組可作為檢視情境；事前評估、核准、回復及事後確認是可採用的實務安排，不能把一整套固定流程都說成 6.3 的逐字要求。

SoA 適用性聲明如何使用？

SoA 源自 6.1.3 風險處置規劃，不是只在 8.3 才產生。應包含必要控制、納入理由、實施狀態，以及排除附錄 A 控制的理由。

先按風險處置決定必要控制，再與附錄 A 比對以避免遺漏；控制也可來自其他來源或由組織自行設計。因此既不是 93 項全部照抄，也不是可任意挑選。法律、契約及其他相關要求也應納入判斷。

更新時可沿用仍適當的內容，加入新版對照、差距與實施狀態；不必一律重新編寫整份文件。第 4～10 章的管理系統要求，不能用 SoA 的控制排除方式任意刪除。

7. 支援

提供資源，確認影響 ISMS 的人員能力與意識，規劃溝通及文件化資訊。外包或供應商人員的訓練、告知及能力確認應依實際工作與控制關係安排，不預設所有人接受同一課程。

**實務建議：**保留政策、風險評估、SoA、處置計畫與必要執行紀錄。版本、存取與保存方式應能支持追溯，文件頁數不是有效性的判準。

8. 運作

• **8.1 運作規劃與管制：**建立流程準則，依準則管制執行、變更及相關外部提供的流程、產品或服務。
• **8.2 資安風險評估：**在規劃間隔，或重大變更提出或發生時評估，保留結果。
• **8.3 資安風險處置：**執行已規劃的風險處置，保留處置結果，並與 SoA 及實際控制相互核對。

**實務建議：**抽查離職停權、雲端設定、備份還原或供應商存取，確認實際執行與風險表的承諾一致。

9. 績效評估

監測與評估 ISMS 及相關控制是否有效，內部稽核應有適當規劃、能力及客觀性。管理審查分為 9.3.1 一般要求、9.3.2 輸入與 9.3.3 結果，並納入相關利害關係人需求與期望的變化。

**實務建議：**漏洞修補時效、風險處置逾期及還原測試等，可依管理目的設為指標。事件數增加也可能反映偵測改善，需結合嚴重程度與背景解讀。

10. 改善

2022 版以 10.1 持續改善、10.2 不符合與矯正措施安排內容。對不符合處理原因、措施及有效性；資安事件則依事件管理程序評估及回應，不代表每件事件都自動構成管理系統不符合。

**實務建議：**將事件分析、稽核及控制評估的結果用於改善，並確認是否有相似問題及需更新的風險。

以下適用於新導入或現有制度改善；2013 版的歷史轉換期已結束。

Step 1：差距分析

以現行標準及氣候修正為依據，檢查流程互動、變更、管理審查、附錄 A 對照及 SoA，列出控制與證據缺口、責任人及期限。

Step 2：跨部門規劃

納入管理階層、資安、IT、業務、採購及法務等相關單位，安排資源、訓練、文件調整、技術改善、內稽與管理審查。

Step 3：分層訓練

• 管理階層：風險決策、資源與治理責任。
• 內稽人員：現行條款、控制適用性及證據判讀。
• 相關人員：依工作需要安排雲端、變更、遠端作業及事件通報等訓練。

Step 4：更新必要文件與控制

修訂風險評估、處置計畫及 SoA，保留仍適當的既有內容；依差距調整作業及技術措施，不預設全部重寫或必須購買新工具。

Step 5：執行、內稽與管理審查

累積足以檢視有效性的紀錄，完成內稽、改善及管理審查。確認 SoA 的實施狀態與現場證據相符，處置剩餘風險及資源缺口。

Step 6：確認驗證程序

新申請依受理機構的初次驗證程序辦理；已有 2022 版證書者依監督或重新驗證安排評估。完成審查與驗證決定後始核發證書，輔導與文件編製不保證通過。

只更新附錄 A 和 SoA 就夠？

也要檢查主體條款、流程互動、變更及管理審查，並確認新增或調整措施的實際運作。

93 項必須全做，或可以任意排除？

應按風險與相關要求決定必要控制，完整比對附錄 A，並在 SoA 交代納入、排除理由及實施狀態。

資安全是 IT 部門的工作？

領導責任持續適用；資訊使用、契約、人員異動及資源決策涉及多個單位，應有明確分工。

供應商簽保密合約就完成管理？

應依風險與適用控制，檢視存取、服務要求、變更、監督與退出安排。保密條款只是可能採取的措施之一。

氣候修正可以忽略？

仍需判定相關性，相關時評估機房、供電及備援等風險；不能只增列一句政策，也不必無條件套用所有氣候措施。

凱騰可依需求討論資訊風險、SoA、日常控制、訓練、內部稽核及外部稽核準備；實際範圍、費用與專業分工於需求確認後約定。弱點掃描、滲透測試、設備採購及工程修補分項討論，驗證由受理的獨立機構決定。

初談可提供服務與系統範圍、資訊流、現有風險表及控制資料目錄，使用去識別化樣本說明事件與作業問題。

• ISO/IEC 27017 雲端資安控制
• ISO/IEC 27701 隱私資訊管理系統
• ISO 管理系統企業內訓
• 聯絡凱騰討論需求