ISO 27001 不是買一套資安軟體：企業如何建立真正能通過稽核的管理制度？

專題編輯：Iris Hsieh｜AI 資安與治理編輯

一家接到大型客戶資安問卷的中小企業，可能已經裝了防毒、備份也正常，卻答不出「誰核准員工使用外部生成式 AI？客戶圖面可以上傳到哪些服務？離職同仁權限是否定期清除？」這不是資訊部門沒有購買工具，而是企業沒有把資訊處理變成一套可追溯的決策流程。

ISO/IEC 27001 正是解決這類問題的管理系統標準。它要求組織依其環境和風險建立、實施、維持並持續改進資訊安全管理系統（ISMS），並非要求每家公司採用相同的產品清單。ISO 官方目前列示的核心版本為 ISO/IEC 27001:2022，另有 2024 年第 1 號修正案，涉及氣候行動相關考量。［S1］［S2］

先分清楚：資訊安全管理，不等於購買資安設備

資安設備處理特定威脅；管理制度則回答「風險是否被辨識、決策是否有依據、例外由誰批准、控制是否有效」。假設財務部門使用雲端表格，資訊單位可以設定多因素驗證；但企業仍需要確認帳號所有權、存取清單、共享範圍、資料保存期限、遺失資料時的通報與復原責任。

ISO 所描述的資訊安全包含機密性、完整性與可用性。機密性是只有被授權者能接觸資料；完整性是資料未遭未授權改動；可用性是需要時能取得資訊。三者經常互相牽動。例如，把所有資料鎖在離線設備，可能降低某些外洩機率，卻增加跨部門協作和災難復原的成本。因此企業需要從業務風險出發，而不是把「越封閉越安全」當成唯一答案。［S1］

2022 版到底規範什麼？企業應注意的是決策順序

實務上可把 ISO/IEC 27001 的工作理解為四個連續問題。第一，公司要保護哪些業務流程及資訊資產？第二，風險是什麼，嚴重程度如何評估？第三，哪些控制措施值得採用，為何採用或排除？第四，如何透過監控、內部稽核與管理審查證明制度不是紙上作業？

ISO/IEC 27001 是 ISMS 要求；ISO/IEC 27002 則提供資訊安全控制措施的參考指引，兩者功能不同。2022 版 Annex A 的控制措施整合為 93 項，常見誤區是把它理解為「公司必須不分情境做滿 93 項」。正確作法是依風險處理結果形成控制措施適用性說明書（Statement of Applicability，SoA），清楚記錄選擇、排除與理由；仍須符合標準本身的要求。控制措施不是越多越好，沒有脈絡的勾選也不能替代風險判斷。［S3］［S4］

不是每個公司都需要一樣的控制深度

具備工廠設備、個資、原始碼、商業報價或病患資料的企業，面對的威脅及責任不同。相同的「存取控制」，在行銷部門可能是限制客戶名單匯出，在研發部門則涉及程式碼儲存庫權限和供應商的保密義務。標準是共用語言，落地設計必須貼合公司現況。

準備 ISO 27001：先產出六份能被使用的文件

不少企業把導入做成文件整理專案，導致稽核前集中補資料、稽核後沒人繼續維護。比起追求大量模板，建議由六類實用成果建立管理循環。

這是供企業內部規劃的實務整理，不是完整條款清單。稽核前應向所採用的版本及驗證機構確認具體要求，並確保證據來自日常流程，而非事後臨時製作。

AI 導入後，ISO 27001 最需要補強的不是一張 AI 使用切結書

生成式 AI 讓資訊有新的流動方式。員工可能把合約、客戶清單、報價、設計圖、會議逐字稿交給模型；也可能讓 Agent 透過工具呼叫讀取、修改或寄送資料。當風險跨越員工個人帳號、外部供應商和內部系統時，原本資訊安全管理的邊界必須重新被檢查。

可以用「五個檢核點」盤點：

1. 資料輸入。 哪些資料可以送到何種 AI 平台？個資、客戶機密、研發成果是否有分級與遮罩？
2. 身分與授權。 員工、服務帳號與 Agent 是否各有最小必要權限？系統是否能夠直接拒絕越權要求？
3. 供應商與保留。 服務合約如何約定資料用途、保存、地區與刪除？是否有可確認的控制或佐證？
4. 輸出與動作。 AI 產生的結果是否會進入正式報價、付款、客戶回覆或帳務？哪些情況必須人工核准？
5. 記錄與應變。 出錯時能否查回哪位使用者、哪個工具、哪批資料與哪一次核准造成影響？

這些管理問題可以納入既有 ISMS 的風險評估與控制；但取得 ISO/IEC 27001 證書不代表企業所有 AI 用途已被自動認證或符合任何 AI 專項管理標準。對 AI 專屬治理，可再參考 NIST AI RMF 的 Govern、Map、Measure、Manage 風險管理功能，依實際情境補足模型品質、誤用、偏差與人工監督等議題。［S5］

一個中小企業能理解的示意情境：供應商報價資料外傳

以下是教學用假設，不是已發生的資安事件。採購人員希望使用 AI 比較三家供應商報價，直接上傳合約附件到個人註冊的免費服務。資訊主管發現資料包含尚未公開的採購價格；部門主管則認為「只要 AI 不公開回答，就不會外洩」。這段爭論顯示技術選型之前缺了更重要的制度問題。

管理者首先要確認資料分級及合約限制，再依核准平台、用途和保留條款決定能否使用。若資料不能外送，可改採去識別化範例、既有企業授權環境，或先用本地工具整理結構化欄位。若確實允許使用，仍需指定覆核者，並避免 AI 產生的價格比較直接取代採購決策。最後，將例外申請、權限與刪除證據保存，下一次相似情境便不必重新爭論。

這個案例不是鼓勵企業一律採地端或一律禁止雲端，而是示範把「誰可以做什麼」變成事先可執行的規則。

取得認證之前，先決定哪些證據能持續產生

ISO 27001 導入應先有管理負責人和跨部門權責，再安排風險盤點、文件建立、控制運作、內部稽核、管理審查與改善。企業可以自行建構管理系統；是否申請第三方驗證，是額外的商業與信任決策。ISO 官方亦明確區分採用標準與選擇認證，認證由適當的認證／驗證體系執行，不是由 ISO 親自替企業核發證書。［S1］

真正值得追蹤的，不是制度文件完成率，而是關鍵資訊資產是否有人負責、權限審查是否準時、缺失結案是否留證據、資安事件是否能依規定通報。正式外部稽核前，應先檢查這些流程是否運轉，避免把一份靜態文件誤當成管理成果。

管理者可以帶進會議室的七個問題

1. 目前最不能洩漏、失真或中斷的三種資訊是什麼？
2. 每種資訊的擁有人是誰，誰批准存取與例外？
3. 供應商、外包與 AI 平台如何處理公司資料？
4. 離職、異動、權限過大、異常匯出如何被發現？
5. 發生事件時由誰決策、誰通報、如何保留紀錄？
6. 上一次復原測試、內部稽核與管理審查留下什麼證據？
7. 如果沒有驗證稽核員坐在面前，這套制度下個月還會不會運作？

如果前六題都找不到持續更新的證據，第七題多半也難以回答。ISO 27001 不是資安採購清單，而是企業將資訊風險正式納入經營責任的方法。

企業準備稽核時，最容易出現三種證據落差

第一種落差是「有政策，沒執行紀錄」。公司可能寫明每季審查帳號權限，但找不到審查人、清單版本、異常處理與關閉日期。對管理制度而言，政策是承諾，真正的管理能力需要運作證據。當稽核員問到一項控制措施，相關同仁應能從實際流程取出紀錄，而不是先向顧問詢問該填哪張表。

第二種落差是「有執行，沒決策依據」。例如每天有備份紀錄，卻沒有人決定哪些業務系統的恢復時間要求較高，也沒有定期測試是否真的能恢復。企業以為備份作業完成，就等於可用性風險已管理；實際上，備份成功與可恢復性是兩個問題。應由業務與 IT 確認重要系統、合理的中斷容忍度和復原測試方法，避免所有設備不分重要程度套用同一策略。

第三種落差是「證據很多，無法對應風險」。採購部門可能保存數十份廠商保密切結書，卻沒有評估外包公司能讀取哪些資料、合約終止後是否撤權，以及資料刪除如何確認。這代表文件活動存在，但尚未證明控制措施足以處理實際風險。比較可行的做法，是建立一條最短的證據鏈：資產與業務風險 → 風險處理決定 → 控制措施 → 實際執行證據 → 測試或改善結果。

用「一條證據鏈」抽查管理系統

拿出一個有真實業務影響的案例，例如離職同仁仍可存取專案文件。先找到與帳號權限有關的風險評估，再確認權限終止的控制規則、實際停權紀錄、延誤或失敗事件，最後看內稽是否發現這個缺口並要求改善。如果每一段資料各自完整，卻無法互相連接，就需要修正流程與責任設計。這種抽查比只問「文件完成了沒有」更接近管理制度的本意。

把 ISO 27001 的導入範圍訂得太小，也可能失去商業用途

公司可能希望先將單一資訊部門或一個場域納入範圍，以降低導入難度。範圍可依企業實際環境界定，但必須符合標準要求並真實反映所提供的服務及重要依賴。如果實際提供客戶服務的系統、資料處理或外包活動完全不在範圍內，即使有證書，也不能對外暗示整家企業所有服務都受到同等認證。

在與客戶溝通認證時，要清楚列出標準版本、驗證範圍與發證機構。客戶往往真正想知道的是：自己的資料經過哪些系統和供應商？安全控制是否涵蓋它們？如果認證範圍和對方關心的服務沒有交集，企業仍需透過合約、稽核報告或其他實際證據補足信任。

2024 年修正案，不是新增一張可以套用的設備採購清單

ISO/IEC 27001:2022/Amd 1:2024 是正式發布的修正案，涉及氣候變遷對組織情境與相關方要求的考量。它不等同要求每家公司立即添購某種資安設備，也不能據此宣稱所有企業必須完成碳盤查才可通過資訊安全驗證。企業應將其放在組織情境及相關方的分析中理解，並依適用性及實際稽核要求調整文件。［S2］

對需要同時管理多套管理制度的企業，還要避免將每套標準都做成互不相通的表格。像資產清冊、委外管理、訓練紀錄和異常處理，在符合各標準要求前提下可盡量共用來源及責任。重點是版本及證據可追溯，而不是為不同稽核員重複製作資訊。

常見問題

ISO 27001 與 ISO 27002 有何不同？

前者規範資訊安全管理系統的要求，後者提供資訊安全控制實務指引。企業應根據風險與適用性決定如何使用控制措施，而不是單純抄錄清單。［S1］［S3］

中小企業也適合 ISO 27001 嗎？

適合以相稱的方式建置。ISO 官方指出不同規模、產業都可採用；但人力分工、資產清冊與控制深度應依業務風險安排，避免照搬大企業架構。［S1］

通過 ISO 27001 就保證不會發生資安事件嗎？

不保證。認證反映特定範圍及時間點的管理系統符合性，不能保證未來零事故；企業仍需持續評估變更與有效性。

已通過 ISO 27001，可以放心讓 AI Agent 自主操作嗎？

不可以直接推論。必須另行驗證 Agent 的資料範圍、工具權限、人工批准、操作日誌與例外處理。治理原則可以接續使用，但不能以證書代替系統級測試。

下一步：把資安管理與 AI 應用放進同一張風險地圖

先挑選一項真實工作，畫出資訊從取得、處理、傳送到刪除的路徑，逐點標註資料擁有者、准用工具、權限、覆核與例外。完成之後，再決定需要新設備、教育訓練、控制措施或外部驗證。制度不是為了讓稽核員看懂，而是讓員工與主管每天做得對。

延伸閱讀：AI 治理是什麼？企業從風險分級到落地的完整指南。企業若希望評估資安邊界下的 AI 應用，可參考企業 AI 導入顧問與陪跑。

資料來源

［S1］ISO：ISO/IEC 27001:2022 標準介紹。
［S2］ISO：ISO/IEC 27001:2022/Amd 1:2024。
［S3］ISO：ISO/IEC 27002:2022 標準介紹。
［S4］DQS：ISO 27001:2022 Annex A 控制變更說明。
［S5］NIST：AI RMF Playbook。

圖片與素材說明

本文封面為原創 AI 概念插畫，用於呈現資訊安全管理，不是認證機構標章、稽核報告或產品畫面。本文提供管理實務整理，不構成認證、法律或資安審計意見。