拿到 ISO 27001 證書，只是起點不是終點

這幾年，你應該常聽到兩種聲音：

• 「我們公司早就有 ISO 27001 了。」
• 「客戶一直問我們有沒有 ISO 27001，該不該導入？」

同一時間，資安事件與營運中斷的成本卻一路上升。IBM《Cost of a Data Breach 2024》指出，全球平均資料外洩成本已經來到 4.88 百萬美元，比前一年增加約 10%，創下疫情後最大漲幅。

對很多企業來說，ISO 27001:2022 的改版，不只是「條文換一版」，而是提醒我們：資訊安全管理系統（ISMS）要重新對焦到真正的營運風險與雲端、供應鏈環境。

這篇文章會一起陪你釐清三件事：

1. ISO 27001:2022 到底改了什麼？
2. 已經拿到證書的公司、正準備拿證的公司，各自會卡在哪裡？
3. 如果你不想只「交差」，而是希望制度真的保護營運，有沒有一條可落地的路線？

一、ISO 27001:2022 改了什麼？用白話先抓住重點

1. 附錄 A：從 114 條縮成 93 條，但難度其實變「實務化」

新版 ISO 27001:2022 把附錄 A 控制項從原本的 114 條整併為 93 條控制，並歸類為「組織、個人、實體、技術」四大主題，同時新增 11 個用來回應雲端服務、安全監控與資料保護的新控制。

很多人看到「條文變少」會以為變簡單了，但顧問實務上的觀察是：

文字變精簡，代表模糊空間變小，要求你把「本來就應該做、卻沒做清楚」的地方補齊。

例如新增的控制會明確談到：

• 威脅情報（Threat Intelligence）
• 雲端服務使用安全
• ICT 對營運持續的準備度（BC）
• 日誌監控、資料刪除、資料遮罩、防止資料外洩…

如果你的業務本來就高度依賴雲端、外包開發、SaaS，這些控制幾乎都是「對號入座」。

2. 條款本體：更講求治理、變更管理與績效量測

條款第 4–10 章的結構沒有大翻修，但對以下幾塊要求更具體：

• 組織背景與利害關係人（第 4 章）
• 風險評鑑與風險處理計畫（第 6 章）
• 監視、量測與績效指標（第 9 章）
• 持續改善與矯正措施（第 10 章）

說得直白一點：
新版更重視「高階管理階層真的有在看資安報表」，而不是只在簽管理審查會議紀錄。

二、對「已取得證書」公司的挑戰：不要讓 2022 版變成文件換皮

很多已經取得 ISO 27001 的公司，最常問的問題是：「我們只要把控制編號改一改就好了嗎？」

實話是：如果只改編號，轉版過得了稽核，但未必過得了真正的資安事件。

以下是常見的三個卡點：

挑戰一：風險評鑑沒有把雲端與供應鏈算進來

過去的風險評鑑，常常只列「內部伺服器、資料庫、AD、網路設備」。
但現在多數企業的重要作業，實際上在：

• 雲端 IDC 或公有雲平台上
• SaaS（CRM、ERP、工單、HR 系統）
• 外包開發與第三方 API

如果風險清單仍停在「機房內部設備」，卻沒有看到雲端、供應商與 API，那新控制怎麼寫都會覺得「跟我們沒關係」。

建議做法：

• 重跑一次「資訊資產盤點」，把雲端服務、SaaS、關鍵供應商列入。
• 開一場跨部門工作坊，讓 IT／資安／業務／營運一起檢視：
  • 真的不能停的服務是哪些？
  • 停機多久會影響到收入與客戶？

挑戰二：條款有寫「供應鏈」，採購流程卻完全沒有資安條款

新版附錄 A 對供應鏈管理、雲端服務使用都有明確控制，但很多企業實務上是：

• 合約範本沒有資安條款
• 沒有固定的供應商資安評估
• 也沒有明訂「資安事件通報時限」

建議做法：

把附錄 A 中跟供應商相關的控制，轉換成採購流程裡的 checklist，例如：

• 是否有資安事件通報機制與回應時限？
• 是否支援多因素驗證、加密、日誌保存？
• 重要系統是否支援異地備援或匯出完整備份？

挑戰三：管理層只看到「花了多少錢」，看不到「避免了多少損失」

外部研究顯示，資料外洩平均成本來到 4.88 百萬美元，主要由營運停機、客戶流失與後續補救成本組成。

但很多公司向老闆報告的，是：

• 今年買了幾套資安設備
• 今年做了幾場演練

卻很少把這些努力轉成「避免了多少停機成本」、「降低了多少外洩風險」。

建議做法：

• 在管理審查報告中，附上一張「風險–成本」對照圖：
  • 若核心系統停機 1 小時，大約會損失多少營收？
  • 若發生一次資料外洩，大約要付出多少客服、法遵與品牌修補成本？
• 讓高層看到：導入控制、做演練、做異地備援，不是花錢，而是在買保險。

三、對「準備取得 27001」公司的挑戰：不要以為 ISO 只是「客戶要、所以導」

如果你所在的公司是第一次導入 ISO 27001，最容易遇到的心聲是：

• 「就是客戶要，我們只好導。」
• 「稽核過了就好吧？」

這裡有三個提醒，可以幫你少走彎路。

挑戰一：一開始就把範圍（Scope）畫太小或太怪

為了「快點過」，有些公司會把範圍畫在某一個系統或某一個部門，結果導完之後，真正被客戶關心的 SaaS 或雲端平台反而不在範圍內。

建議做法：

• 在決定範圍前，先列出：
  • 客戶最在意、最常問的服務或產品
  • 對營收影響最大的系統
• 優先把這些服務納入第一期範圍，即使導入會辛苦一點，但證照才「有用」。

挑戰二：把 ISO 導成「一堆文件」而不是「一套作法」

初次導入時，文件一定會變多，這是正常的。
但真正的關鍵在於：

這些政策與程序，能不能貼近你們本來的作業，而不是「為了 ISO 硬生出另一套」。

建議做法：

• 請顧問或內部負責人協助，把現有流程畫出來（流程圖、RACI）。
• 把 ISO 條款需要的控制，嵌進既有流程，而不是再多開一個沒人會用的系統。

挑戰三：沒有預留「維運」的人力與時間

導入時大家很熱血，但一過稽核，維運就交給一位超忙的 IT 人員，最後變成：

• 每年稽核前兩週熬夜補文件
• 問卷、演練、風險評鑑都變成「考古題」

建議做法：

• 一開始就跟高層談好：
  • 每年用多少人天做內部稽核、風險評鑑與演練
  • 誰是 ISMS 管理代表，有沒有相對應授權與時間
• 把這些「維運工時」寫進專案計畫中，避免之後變成額外加班。

四、導入＋轉版一體規劃：顧問常用的四階段路線圖

不論你是第一次導入，還是從 2013 版轉到 2022 版，都可以用下面這條路線來安排：

1. 盤點與差距分析（0–3 個月）
   • 盤點資產、雲端服務、供應鏈與現有控制。
   • 做 Gap Analysis：以 2022 版控制項對照現況，列出差距清單。
2. 設計與決策（3–6 個月）
   • 決定控制策略：哪些自建、哪些導入外部服務（例如 SOC、WAF、備援機房）。
   • 調整範圍（Scope），確保包含關鍵服務與客戶最在意的部分。
3. 實作與導入（6–12 個月）
   • 完成政策、程序與實作控制（帳號權限、日誌、備援、供應商管理…）。
   • 執行教育訓練與演練，累積「可以拿給稽核看的證據」。
4. 內部稽核與管理審查（12–18 個月）
   • 透過內稽找出制度中真正不順手的地方，而不是只找「缺文件」。
   • 管理審查時，把成果用「降低風險與成本」的角度，向高層報告。

如果你同時也在規劃外部資安服務（EASM、MDR、WAF、異地備援機房…），可以在第二階段就一起評估，讓 ISO 27001 的要求直接變成選擇外包服務的規格清單，這樣預算比較容易過，也能避免重複投資。

五、導流收尾：想把 ISO 27001 變成「真的有用」的工具，可以怎麼開始？

如果你看到這裡，心裡可能有幾個想法：

• 「我們有證書，但好像真的比較像文件專案。」
• 「客戶一直問 27001，我們不確定要不要導，或是該從哪裡開始。」

很現實的一句話是：沒有公司真的那麼愛 ISO 27001，大家要的是可預期的營運與客戶信任。

你可以先做一件很簡單的事：

把你目前最在意的三件事寫下來——可能是雲端、供應鏈、異地備援、或是客戶稽核壓力——
再回頭看 ISO 27001:2022，有哪幾條可以直接拿來「幫你跟老闆講道理」。

如果你希望有人一起幫你看這些差距、把「條款」翻成「實際可做的清單」，也可以預約 Cloudmax 顧問團隊的 ISO 27001 改版健檢／導入諮詢，一起看看：

• 現在的 ISMS 哪裡做得很好，值得保留？
• 哪些地方只差「一點點」調整就能兼顧認證與實際防禦？
• 哪些資安服務（例如託管安全、防護機制、異地備援、EASM）可以直接對應到條款，而不是多一堆看不懂的設備？

你的公司不需要變成資安公司，但可以擁有一套 懂生意、也懂 ISO 條款的安全做法。這是我們很樂意一起陪你完成的事。

FAQ

歡迎轉載！請見：轉載原則。

Image by AI-generated via Pixabay