早上 7:26，資安部門在公司群組發了一則緊急通知。
「今天要處理所有使用舊版 PHP 的系統，部分版本有高風險漏洞。」
資訊部門回覆：「收到，請提供受影響主機清單。」
資安：「你們不是有資產清冊？」
資訊：「清冊上有 14 台。」
資安：「那就先處理這 14 台。」
資訊：「可是我們昨天掃到 19 台。」
群組安靜了三分鐘。
資安：「多出來的五台是什麼？」
資訊：「還在確認。」
資安：「為什麼清冊沒有？」
資訊：「因為上次做 ISO 稽核的時候只有 14 台。」
資安：「那現在呢？」
資訊：「現在有 19 台。」
至少目前是。
這就是 ISO 27001 資產盤點最麻煩的地方：清單上有設備、有負責人，真的問下去，卻沒人知道那台系統到底誰在管。
系統還在跑，負責人已經離職五年
上午 9 點，資訊部門終於整理出一份比較完整的清單。
其中一台是行銷部五年前委外製作的活動網站。
活動早就結束了。
網站還活著。
行銷說，當初負責的同事離職了，但網站好像還有其他功能，所以不能直接關。
另一台是舊版員工系統。
人資說現在已經不用它了。
資訊準備停機時，財務突然打電話過來。
「等一下，我們每個月底的薪資對帳資料還是從那邊匯出的。」
資訊：「不是說沒在用了嗎？」
人資：「我們沒在用啊。」
財務：「可是我們有。」
最後還找到一台不知道誰申請的虛擬主機。
資產負責人欄位寫著一個英文名字。
那個人 2020 年就離職了。
資訊打電話問前主管，前主管說印象中好像是某個舊專案。
再問原廠。
原廠回覆：「這個版本已經停止維護，我們可以提供新版導入報價。」
資訊問：「那舊版誰維護？」
原廠：「原合約已經到期。」
很好。
系統還在上班，工程師退休了，廠商不認識它，合約也死了。
只有每個月的帳單證明它確實還活著。
資安說要修，營運說不能停，財務要求成本分析
上午 10:30，緊急會議開始。
資安說明，部分主機存在高風險漏洞，需要儘速修補或採取隔離措施。
營運主管問：「會不會影響訂單？」
資訊：「不確定，要先測試。」
營運：「那今天不能動，我們正在出貨。」
資安：「如果不處理，可能被入侵。」
營運：「可是現在還沒有被入侵吧？」
資安：「目前沒有確認遭入侵，不代表之後不會。」
營運：「那等出完貨再說。」
財務表示支持資安改善，但要求先評估停機對營收的影響。
資訊說，舊系統沒有完整測試環境，更新後能不能正常運作沒有人保證。
財務問：「如果更新失敗，誰負責？」
資訊沒回答。
資安也沒回答。
主管看了一眼會議室。
「所以我們現在的選項是什麼？」
資安：「修補漏洞。」
資訊：「但需要安排測試。」
營運：「測試不能影響出貨。」
財務：「停機要先有成本評估。」
主管：「那請各部門先協調。」
會議結束。
每個部門都同意要處理。
也成功讓處理這件事變得不可能。
下午，資安部門收到一封信。
主旨：「關於高風險漏洞改善計畫，請協助提供預計完成日期。」
寄件人是管理部。
資安轉寄資訊。
資訊轉寄營運。
營運回覆：「待業務確認。」
管理部在追蹤表填入：
處理中。
為什麼做了 ISO 27001 資產清冊，還是找不到真正的系統？
看到這裡，大概能理解為什麼有些公司的 ISO 文件很完整，出事時卻找不到負責人。
圖解：找得到資產不等於找得到能處理問題的人
清冊有了。
欄位填了。
流程也有了。
只是負責人早就離職，流程從沒演練，清冊最後更新時間是上一次稽核前。
問題不一定是資訊部門偷懶。企業真正使用的系統，未必都經過資訊部門採購。
行銷的活動網站、財務自己建立的報表工具、營運委外的倉儲設備、客服買的 SaaS、某個工程師留下的自動排程，全部都可能還在處理公司資料。
這類不在正式 IT 管理視線內的工具，常被稱為 影子 IT（Shadow IT）。
如果資產清冊只列公司採購的實體設備，卻沒有實際運作的系統、雲端服務、資料流與業務依賴關係，清冊填得再漂亮也不能代表風險已經受到管理。
NIST《Cybersecurity Framework 2.0》也將硬體、軟體、系統與服務的辨識及清冊維護列入資產管理，強調先知道企業依賴哪些資產，才能決定如何保護。
參考：NIST Cybersecurity Framework 2.0。
所以企業做資產盤點，最先該問的往往不是「有幾台伺服器」，而是：
「明天把這台關掉，會有誰打電話來罵我們？」
能回答這題，才比較有機會知道它真正支援什麼業務。
但不要真的靠拔網路線來測試。那叫製造事故，不叫資產盤點。
Equifax：資安發給 400 多個人修補通知，偏偏沒通知到真正負責的那個人
這類管理落差，在真實事故中也出現過。
2017 年，美國信用資料公司 Equifax 發生重大個資外洩，約 1.47 億名消費者受到影響。
根據美國聯邦貿易委員會（FTC）後續公布的資料，Equifax 的資安團隊在 2017 年 3 月收到 Apache Struts 高風險漏洞警報後，向 400 多名員工發出內部通知，要求負責相關軟體的人在 48 小時內修補。
結果那封信，偏偏沒有寄給實際負責受影響 ACIS 系統的維護人員。
公司後來也做了自動弱點掃描。
但掃描器設定不正確，沒掃出那套仍有漏洞的系統。
直到數月後偵測到可疑流量，才發現攻擊者早已利用未修補的漏洞入侵。
FTC 在 2019 年公布的和解安排，涉及至少 5.75 億美元、最高可能達 7 億美元的款項。
這個案例最荒謬、也最值得企業注意的地方是：
資安知道。
通知發了。
掃描做了。
真正需要修補的人沒收到通知。掃描也沒查到。系統就這樣繼續跑。
不是公司完全沒有漏洞管理制度，而是管理流程沒有成功連到那台真正有問題的系統。
FTC 也特別指出，沒有正確掌握哪些系統使用哪些軟體，是這次修補失敗的重要背景。
來源：CFPB／FTC：Equifax 5.75 億美元個資外洩執法裁罰案專頁、CFPB：Equifax 個資外洩和解案核心事實與資安管理要求公告。
ISO 27001 要解決的，不是叫 IT 無條件把老主機關掉
ISO/IEC 27001:2022 是資訊安全管理系統（ISMS）標準。
相關管理控制涵蓋資訊資產清冊、資訊安全角色與責任、技術弱點管理、變更管理和供應商關係等主題。
但 ISO 27001 不是叫企業只要發現漏洞，就不顧營運直接拔掉電源。
有些系統真的不能隨便升級。
一改就可能讓倉庫無法列印出貨標籤，或讓財務月底無法結帳。
這些顧慮都合理。
不合理的是，大家都知道有問題，卻始終沒有人負責作決定。
如果系統無法立即修補，企業至少要講得清楚：
| 大家常講的話 | 真正需要追問的事 |
|---|---|
| 「這個不能停。」 | 停了會影響哪些業務？有沒有測試過？ |
| 「更新怕出問題。」 | 有沒有測試環境、備份及回復計畫？ |
| 「廠商說不支援。」 | 合約誰管？有沒有替換或隔離方案？ |
| 「我們已經通知了。」 | 真正的維護人員是否收到、處理並回報？ |
| 「這個風險先接受。」 | 誰有權接受？期限與補償措施是什麼？ |
| 「會議決議持續追蹤。」 | 下次誰交付什麼證據？什麼情況才算結案？ |
即使短期真的不能打補丁，也不代表只能任它暴露。
在可行的情況下，還可以評估限制連線、隔離系統、關閉不必要服務、加強監控，並規劃後續替換或修補。處置方式仍需依系統風險及營運影響判斷。
CISA 的防護建議也重視縮減不必要的網路暴露面、限制存取、網路分段與監控；至於已知遭實際利用的漏洞，則應列入優先處理的風險。這比把「不能更新」當成結案理由更有用。
參考：CISA 勒索軟體防護指南、CISA 已知遭利用漏洞（KEV）目錄、ISO 官方：ISO/IEC 27001。
重點不是保證每個系統永遠不會出事，而是有人知道風險、能做決定，也能拿出決策和執行的紀錄。
ISO 27001 資產盤點至少要查哪六件事？
如果想知道公司那份資產清冊到底有沒有用，不必先開十場會議。
先問六個問題。
- 我們到底有哪些系統？ 不只實體主機，也包括虛擬機、雲端服務、網站、SaaS、委外設備與各部門自己建立的工具。
- 現在誰在管？ 不是清冊上五年前留下的名字，而是目前能聯絡、能維護、能決策的實際責任人。
- 它在做什麼？ 哪個業務依賴它？處理訂單、薪資、會員、庫存，還是傳送資料給外部廠商？
- 它跟誰連線？ 使用哪些帳號、API 金鑰、資料庫及對外服務？停止或隔離會影響哪些上下游？
- 上次漏洞怎麼處理？ 有沒有修補紀錄、驗證結果、例外核准和後續複查？還是只有「已通知」？
- 今天真的出事，誰能決定？ 資安、IT、營運和管理層的角色是否明確？必要時誰有權批准停機或接受風險？
這不是完整的 ISO 27001 驗證清單，而是一份先抓出「大家以為有人管，其實沒人管」的起點。
如果查出問題，可再做ISO 27001 差距分析，把制度要求、現場狀況、缺少的證據與改善責任人逐項對照。
要正式整理風險情境，也可參考ISO 27001 風險評鑑與風險清冊；委外系統則要連同供應商資安風險管理一起查。
公司做 ISO 27001 前，先找找有沒有這幾種東西
「我們公司有沒有還在運作，但負責人已經離職的系統？」
「有沒有哪台主機，大家都知道很舊，但因為怕影響業務所以一直沒更新？」
「有沒有委外廠商提供的設備，我們不知道裡面裝了什麼、誰有權限進去？」
「上次發現高風險漏洞，有沒有紀錄最後到底怎麼處理？」
「如果今天要緊急關閉某個系統，誰有權批准？」
要是每一題的答案都是：
「這個可能要問一下。」
那就很值得查了。
對電商品牌來說，這不只發生在機房。購物車、CRM、物流 API、行銷追蹤工具、外包客服與會員資料匯出流程，都可能藏著類似的責任空白。
如果企業正在準備 ISO 27001 導入、客戶資安審查或正式驗證，可以先把主要系統、委外範圍、資產責任與現有證據整理清楚，再決定需要哪些改善工作。
最後，那台伺服器怎麼了？
下午 4:40，資安又追問了一次。
「那台舊主機現在能更新嗎？」
資訊：「原廠不支援。」
資安：「可以關嗎？」
營運：「會影響出貨。」
資安：「可以隔離嗎？」
資訊：「要先確認跟哪些系統連線。」
資安：「什麼時候可以確認？」
資訊：「要找原本的工程師。」
資安：「他不是離職了？」
資訊：「對。」
最後，主管交辦資訊部門提出改善計畫，資安持續追蹤，營運協助確認影響範圍。
會議紀錄寫著：
各單位均已充分了解風險，後續持續追蹤改善。
伺服器沒有更新。
負責人沒有找到。
下次稽核前，清冊倒是一定會更新。
企業最大的技術負債，未必是十年前寫的程式。
而是十年來，每個人都很認真地做好自己的工作，最後卻沒有人知道，這件事到底歸誰管。