供應商、產品與 AI 持續變動，年度盤點標明版本、範圍與失效條件，才能支撐今天的風險決策。
文／游政卿
客戶在查核時臨時追問某項資安控制，會議室裡常出現熟悉的一幕：有人很快打開去年的資料夾。供應商問卷有簽名、軟體物料清單（SBOM）有版本、AI 使用者完成過訓練，弱點例外也有主管核准紀錄。文件看似齊全，現場仍得重新確認，它們是否仍在描述今天的系統。
[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]
這些紀錄多半真實，也符合當時情況；後續變更使適用條件改變。產品改版、雲端權限擴大、委外範圍增加、模型換版，或對外開放狀態改變，都可能讓原來的判斷失去依據。形式完整的舊文件，卻可能被拿來支撐當下的風險決策。
我在看這類資料時，通常先問三件事：「它對應哪個版本、涵蓋哪些範圍、成立時依賴哪些前提」。答案若含糊，文件可留作歷史紀錄；但今天的上線、續約或風險接受，則應以重新確認的資料為準。
證據的有效性取決於時點與條件
一份資安證據回答的是：某個對象在某個時間、版本與條件下，是否達到要求。
同一份滲透測試報告，可能足以說明上一版產品曾經測過，其證明範圍止於原有功能，新增應用程式介面（API）需要新的測試結果。
一份供應商查核報告也可能只涵蓋既有服務，今年新增的次級供應商需另行確認。證據的適用範圍，必須連同它要支撐的決策一起判斷。
美國國家標準暨技術研究院（NIST）SP 800-53 Rev. 5（Release 5.2.0）的 RA-3 將重大變更列為更新風險評估的觸發條件。CA-7 要求建立並執行持續監控計畫，其說明指出監控頻率應足以支援風險決策。年度檢查可作為定期複查的底線；變更發生後，仍須重新確認受影響的控制是否有效。
【編按】RA-3 是屬於風險評估（Risk Assessment, RA）控制家族中的「風險評估（Risk Assessment）」核心安全控制項；CA-7 是屬於「評估、授權與監控（Assessment, Authorization, and Monitoring, CA）」控制家族中的「持續監控（Continuous Monitoring）」控制項。
因此，文件過期後仍應保留。舊紀錄能說明當時的決策脈絡，對事件調查、稽核追溯與責任釐清都很重要。用途則需要重新界定–「一份文件可以保有歷史價值，同時失去支撐新決策的資格」。
文件還在，範圍已經變了
在我參與的查核中，最常出現這種落差的是「供應商問卷」。去年填寫的「沒有遠端連線」，描述的可能只是當時的服務模式；今年新增維運廠商、雲端區域或管理介面後，原答案涵蓋的仍是舊範圍。採購續約若只確認附件存在，供應商盡職調查就會延續舊答案，新增服務也會落在查核範圍之外。
「產品與軟體供應鏈」也一樣。SBOM 是某個版本或某次建置的元件快照。建置編號、產物雜湊值與交付版本，讓清單得以對應正式環境的實際元件。功能、元件、簽章或更新流程改變後，應重新評估原有威脅模型與安全測試是否仍涵蓋受影響範圍。
[ 推薦閱讀：當客戶開始追問 CVE，企業準備好說明決策了嗎？ ]
「AI 治理」也常出現證據與權限脫節。AI 素養課程反映員工當時的學習狀態；取得對外發布、自動執行或敏感資料存取權後，應補充新角色所需的訓練與能力確認。模型版本、工具權限或資料連接器變更，也會縮小原有評估結論的適用範圍。截至 2026 年 8 月，NIST 官方仍標示 AI 風險管理架構（AI RMF）1.0 正在修訂；修訂版發布前，企業可持續以 1.0 作為參考，並記錄採用版本與更新安排。
「弱點例外」與「復原演練」則呈現另一類前提條件。例外可能建立在服務僅限內部使用、補償控制有效或產品仍在支援期；其中任一條件改變，核准基礎就應重新檢視。去年演練採用舊架構、舊身分系統與較小的資料規模，代表的是當時的復原能力。
檔案狀態需要由人員或系統標示。對象、版本、權限與營運條件先變，等到客戶查核或事件調查時，文件可能早已落後現況。
有效日期之外，還要有失效條件
用於高風險決策的證據，至少要標明負責人、適用範圍、資料截至日期、依據、預定複查時間，以及會讓它提前失效的變化。日期負責定期複查，失效條件則把證據與系統變更接起來。
產品或模型改版、架構與介面調整、供應商更換、權限與資料範圍擴大、對外開放狀態改變、安全事件、新的威脅情報，以及法規或客戶承諾變更，都可成為重新驗證的觸發點。這些規則還要放進既有工作節點，讓每項變更直接觸發對應的重新驗證。
實務上的挑戰在於門檻。每次小改版都重新驗證，開發與採購流程很快就會塞車；等到重大事件後才啟動，許多日常變更又會被漏掉。
[ 閱讀所有 游政卿 的文章 ]
我通常先看資產重要性、資料敏感度，以及證據失準會影響哪些決策，再決定重新驗證的範圍。涉及對外開放、高權限、關鍵供應商或客戶承諾的變更，原則上要重新確認；界線模糊的案件，則由指定責任人判斷並留下理由。狀態可分為有效、待確認與已失效，也要事先規定待確認期間哪些作業可以繼續。
正式流程仍有盲區。員工自行採用雲端服務、擴張權限或擴大 AI 工具用途，都可能繞過原先設計的檢查點。因此，企業還要透過資產盤點、權限檢視與抽查補上盲區。供應商要求應依規模與風險分級；若要求每家中小型供應商對所有異動即時舉證，增加的成本可能反映在採購成本與合作時程上。
實際執行可以從既有節點開始：採購續約時更新供應商資料，產品發布前核對 SBOM、交付版本與安全測試，權限異動或模型換版時確認訓練內容與風險分類是否仍適用。跨部門爭議仍要有人裁決；管理層需要明確指定責任歸屬與優先順序，新的檢查點才有機會落實，也可減少行政拉鋸。
把黃燈放進管理報表
給資訊長（CIO）與資安長（CISO）的管理報表，若只顯示蒐集了多少份文件、完成了多少項查核，很容易把工作量誤認為風險狀態。
我更想看到的是：高風險資產有多少必要證據仍有效，有多少決策正在依賴待確認資料，重大變更後花多久完成重新驗證，以及客戶追問時能否交出與現行版本一致的答案。
這些指標也要有一致口徑。證據有效比例可用仍有效的證據數，除以高風險資產所需證據的總數；重新驗證時間則須先定義一致的起算點，例如變更核准日或異常發現日，再計算至責任人完成確認為止。
證據更新需要各部門共同負責。資安團隊可規範欄位、標示證據狀態並協助查核；依組織分工，供應商範圍由採購或供應商管理單位確認，交付版本由產品負責人或系統擁有人確認，AI 用途則由業務擁有人與系統擁有人共同確認。清楚的分工讓資安人員從追文件轉向核對事實，並掌握變更對證據效力的影響。
要求每份紀錄隨時保持最新，資源很快就會被耗盡。組織應先找出哪些決策一旦用錯證據，會影響客戶承諾、產品安全、營運持續性或風險接受，再替這些證據設定較嚴格的失效與重新驗證規則。
管理層評估「現在是否接受這個風險」時，去年做過什麼仍是背景；目前版本、適用範圍、待確認事項與重新驗證觸發條件，加上最後確認者與時間，才足以支撐今天的決策。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
