供應鏈風險怎麼管?用風險登錄表建立六步治理閉環

內容目錄 顯示


供應鏈風險管理不是列一張「可能出事」的清單,而是用風險登錄表(risk register),把評估範圍、風險敘述、證據、原始風險、既有控制、剩餘風險、責任人、改善行動、預警指標、事件升級與審查紀錄串成持續更新的治理閉環。

外銷人員需要先理解 供應鏈風險,因為它會改變斷料時能否辨識影響、啟動替代方案並維持交貨。沒有把它放進報價、審查或出貨檢查點,可能讓團隊漏掉低金額卻關鍵的單點,等到交期失守才發現沒有備援。

實作順序可以濃縮成六個階段:識別、評分、控制、預警、事件處理、復盤。評分只是內部分流工具;制裁、出口管制、人身安全、重大資安與客戶禁止事項,還要另設 hard stop。採用 ISO、NIST、OECD 指引,或取得供應商證書,都不等於自動合規,也不能保證供應鏈永不中斷。

本文是一般管理框架,不構成特定供應商、交易、制裁、出口管制、資安事件或認證的法律結論。名單與規則會更新;實際交易應由法務、法遵、資安、品質與採購依當日官方資料共同判斷。

本文是一般管理框架,不構成特定供應商、交易、制裁、出口管制、資安事件或認證的法律結論。名單與規則會更新;實際交易應由法務、法遵、資安、品質與採購依當日官方資料共同判斷。

先分清楚供應鏈風險、issue、control 與韌性

團隊若用同一個「風險」稱呼所有事情,會議很容易停在互相通報,卻沒有人知道下一步要評估、改善還是應變。

名詞 實務意思 在風險登錄表中的位置
Risk 尚未確定、但可能影響既定目標的情況 risk statement、likelihood、impact、owner、controls
Issue/incident 事件已發生,或 hard-stop 條件已被觸發 incident ID、severity、decision log、escalation、closure
Control 已存在、可執行並可取得證據的預防、偵測或矯正措施 control owner、evidence、last tested、effectiveness
Action 尚待完成的改善工作 action owner、due date、status、completion evidence
KRI/trigger 暴露、趨勢或事件條件改變的預警訊號 metric/event、threshold、source、owner、escalation
Inherent risk 尚未計入現有控制前的風險 inherent likelihood/impact/rating
Residual risk 考慮「已驗證有效」控制後仍存在的風險 residual likelihood/impact/rating、acceptance

例如,「A 料缺料」已經發生時,它是 issue;在事件發生前,較完整的 risk statement 應是:「因關鍵 A 料只來自同一供應商的同一廠址,若該廠產能或運輸受限,可能使交付延誤,造成客戶承諾與營收受影響。

」這個句子同時交代原因、事件與影響,才有辦法找 owner、control 與 KRI。

供應鏈風險與供應鏈韌性不是同一篇事

兩者有關,但管理任務不同:

  • 供應鏈風險治理關心有哪些不確定性、證據是什麼、誰負責、現有控制是否有效、何時預警與升級。
  • 供應鏈韌性關心中斷時如何維持最低必要產出、切換替代路徑、在容忍時間內復原並用演練驗證。

本文停在 risk register、controls、KRI、事件升級與復盤;備援容量、替代路線、切換與復原設計,應交由供應鏈韌性計畫承接。至於供應鏈有哪些角色、物流/資訊/金流如何畫,則屬供應鏈基礎與地圖主題。

供應鏈風險的核心邊界與適用範圍

開始評分前,先定義範圍與判準

許多風險表失效,不是公式算錯,而是一開始沒說清楚在保護什麼。評估前,先回答六個問題:

  1. 目標是什麼? 例如某產品的客戶交付、品質、法規、資料保密或責任商業行為目標。
  2. 涵蓋哪個範圍? 是單一產品、客戶、市場、專案,還是公司層級。
  3. 看多長時間? 同一個「可能性」若有人看三個月、有人看三年,就不能比較。
  4. 看哪些依賴? 供應商法人、廠址、料件、服務、sub-tier、物流、系統、資料與付款角色。
  5. 哪些影響維度? 營運、品質、財務、客戶、法遵、人身/環境、資安/資料與聲譽。
  6. 誰能接受剩餘風險? risk owner 可以管理,不一定有權替公司接受重大法遵或客戶風險。

分數之外要有 hard stop

Likelihoood 與 impact matrix 適合排序,但不能把所有事情平均成一個數字。下列情況通常要另設旗標,由相應權限者決定是否停單、停出貨或升級:

  • potential sanctions/restricted-party match。
  • 出口管制的產品、end-use、end-user 或許可疑義。
  • 重大人身安全、強迫勞動、環境或賄賂疑慮。
  • 未受控的重大資安事件、敏感資料外洩或關鍵存取權限。
  • 客戶或契約明確禁止的來源、廠址、次供應商或材料。
  • 未授權改料、分包或製程變更。

Hard stop 不是判決。它的作用是阻止團隊用「總分還不高」繼續交易,先把問題交給有權限的法遵、法務、資安、品質或客戶窗口釐清。

供應鏈風險重點比較

供應鏈風險登錄表要有哪些欄位?

下列 18 欄是依 ISO 31000 的風險流程、NIST 的供應鏈資安治理與 OECD 風險導向盡職調查精神整理的實務模板,不是任何單一標準規定的強制表單。

欄位 要填什麼 常見錯誤
1. Risk ID 穩定、不重複的編號 用列號,排序後失去追蹤
2. Scope/objective 受影響的產品、客戶、流程或合規目標 只寫部門,沒有目標
3. Supplier/item/site/tier 法人、料件/服務、廠址與供應層級 只寫品牌,不知道實際廠址
4. Risk statement 原因/條件 → 可能事件 → 影響 只寫「缺料」「戰爭」
5. Category 主要類別與必要的次類別 每人自創類別,無法彙總
6. Evidence/source/checked time 來源、文件、數據與查核時間 複製舊資料,不知道新鮮度
7. Inherent likelihood 未計入控制前的可能性與理由 直接憑感覺填 1–5
8. Inherent impact 未計入控制前的分項影響與理由 只看金額,漏法遵/人身
9. Inherent rating 依公司 matrix 形成初始等級 把乘積當客觀機率
10. Hard-stop flags 法遵、制裁、安全、資安、客戶禁令等 被總分平均掉
11. Existing controls 已實際運作的預防/偵測/矯正控制 把未來 action 當現有 control
12. Control owner/evidence/effectiveness 誰執行、怎麼證明、何時測試、是否有效 只有制度名稱,沒有證據
13. Residual rating 計入有效控制後的可能性、影響與等級 control 未驗證就先降分
14. Treatment decision 避免、降低、分攤/轉移、接受;RBC impact 另定適切處置 高分一律解約,或低分一律接受
15. Action/owner/due/status 改善措施、負責人、期限、狀態、結案證據 只有「持續追蹤」
16. KRI/trigger/source 指標或事件、閾值、資料源、更新頻率、data owner 有 KPI,沒有升級條件
17. Incident escalation 等級、決策人、通知、證據與放行條件 事件後仍只改風險分數
18. Review/change log 最後/下次審查、重大變更與版本紀錄 表格被覆寫,看不到判斷歷程

最小可用版本也不能只保留「風險、分數、對策」三欄。至少要看得到 objective、evidence、owner、existing control、residual risk、KRI/trigger 與 review time,否則無法判斷誰在什麼資料下作了什麼決定。

供應鏈風險實作檢查清單

六階段建立供應鏈風險治理閉環

1. 識別|從目標、節點與證據寫風險敘述

先選一個範圍,例如某產品線或客戶專案,再沿著供應商、廠址、料件、物流、系統、資料與 sub-tier 找暴露點。不要先追求列出一百種風險,而要把每一筆寫成可判斷的句子。

建議句型是:

因為「原因或條件」,可能發生「事件」,導致「對目標的影響」。

可用下列分類檢查盲點:

  • 供應商身分/財務: 法人、所有權、信用、保險、營運持續性。
  • 品質/製程/產能: 缺陷、製程漂移、設備瓶頸、未授權分包或變更。
  • 集中度/下層供應: sole source、共用廠址/區域、sub-tier 不透明。
  • 物流/地緣/災害: 港口、航線、邊境、衝突、災害、承運與保險限制。
  • 法遵/制裁/出口管制: restricted party、end-use/end-user、許可與產品管制。
  • 責任商業行為: 人權、勞動、環境、賄賂與消費者負面影響。
  • 資安/資料/軟體: 惡意功能、漏洞、假料、更新中斷、第三方存取與資料外洩。
  • 商務/契約/智慧財產: 價格、付款、責任限制、機密、IP 與單方變更。

風險證據要有來源與時間。台灣商工登記或出進口廠商登記可以協助核對公開的法人與貿易基本資料,但不能因此證明供應商財務穩健、品質可靠、沒有複雜所有權或符合所有法規。

2. 評分|先看 inherent risk,再套 hard stop

中小企業可以先用 1–5 的 likelihood 與 impact scale,但要把每一級寫成可重複使用的判準。

Likelihood 應指定 time horizon,並記錄歷史事件、當前暴露、趨勢與資料信心;impact 則應分別評估營運、品質、財務、客戶、法遵、人身/環境、資安/資料與聲譽。

若公司使用「likelihood × impact」作排序,請記住:3×4 與 4×3 雖然同分,代表的風險型態、控制方向與升級速度可能完全不同。矩陣不是實際機率模型,也不能把重大法遵或安全風險平均成可接受。

評分要保留理由與 evidence confidence,例如:

  • Likelihood 4:不是因為「大家覺得很可能」,而是因為哪段時間、哪些數據與事件訊號。
  • Impact 5:要說是哪個維度達到最高影響,以及誰有權確認。
  • Hard stop = sanctions potential match:不再用總分決定,改由法遵確認 identity、ownership、program、jurisdiction 與交易 scope。

3. 控制|把措施、owner、證據與有效性綁在一起

Control 是已經存在、有人執行、可以留下證據,而且能影響這一筆風險的措施。可以分成:

  • Preventive control: 例如合格供應商條件、change approval、security requirements、end-use/end-user due diligence。
  • Detective control: 例如 incoming inspection、KRI alerts、restricted-party rescreening、security incident notice。
  • Corrective control: 例如 CAPA、權限撤除、資料更正、補救與合約 remedy。

不要把「明年導入第二來源」先當作既有 control;在完成、驗證前,它只是 action。Control 要記錄 owner、執行頻率、最近一次 evidence、測試方法、例外與 effectiveness。只有控制確實有效,才可以據此重評 residual risk。

Residual risk 仍超過企業容忍度時,可考慮避免、降低、分攤/轉移或接受,但接受者必須有相應權限。

對人、環境與社會的負面影響,不能只用公司的財務損失邏輯;OECD risk-based due diligence 強調識別與評估 impact、停止/預防/降低、追蹤、溝通,以及在適當時提供或配合補救。

是否停止合作,須依影響嚴重度、企業與影響的關係、影響力與法規 hard stop 判斷,不是一張分數表自動決定。

4. 預警|KRI 要有資料源、owner、trigger 與新鮮度

KRI 不是報表上多一條線,而是「哪個訊號、來自哪裡、多久更新、越界後通知誰、要做什麼」。可考慮的訊號包括:

風險面向 KRI/trigger 例子 資料品質問題
交付/產能 lead-time variation、OTIF、積欠量、產能或排程異常 供應商自報與實際收貨是否一致
品質 defect trend、退貨、CAPA 逾期、未授權 change notice 分母、批次、site 是否一致
財務/商務 付款條件突然改變、保險/信用異常、訴訟或登記重大變更 資料日期與實體是否正確
物流/地緣 路線/港口狀態、貨態停滯、官方警示、保險除外 警示是否涵蓋實際節點
制裁/出口管制 名單新增、potential match、end-use/end-user 或產品分類疑義 alias、地址、ownership、來源清單與時間戳
資安/資料 供應商 incident notice、漏洞/更新異常、帳號或存取權限變更 通報延遲、資產與版本對應
RBC grievance、稽核發現、worker/stakeholder signal、corrective action 失效 稽核範圍、申訴可及性與報復風險

本文不提供通用紅黃綠閾值。每家公司要依 baseline、客戶承諾、資料延遲與 risk appetite 校正。

除了週期性 review,也要建立 event-driven refresh:供應商 onboarding、簽約/續約、下單或出貨、法人/所有權/廠址/sub-tier 變更、重大資安或品質事件、法規/名單更新、KRI 越界時重新查核。

5. 事件處理|Trigger 命中後,不要繼續只改分數

一旦事件已發生或 hard stop 命中,應建立 issue/incident record,與原 risk ID 連結:

  1. Verify and snapshot: 確認訊號、保存查詢條件、時間、原始資料與當時版本。
  2. Triage: 判斷影響範圍、severity、jurisdiction、產品/訂單/客戶與 hard-stop 類型。
  3. Assign: 指定 incident lead、risk owner,以及法遵、資安、品質、採購、業務與管理決策人。
  4. Contain/control: 在不破壞證據的前提下,採取與權限相符的停單、暫停存取、隔離批次或其他臨時控制。
  5. Decide and communicate: 記錄選項、依據、批准人與放行條件;依實際法規、契約與客戶要求確認通知對象與期限。
  6. Track: 保存 evidence log、open actions、owner、due date、狀態與例外。
  7. Close: 只有達成書面 closure criteria、剩餘風險有權接受,才能結案。

資安事件可參考 NIST SP 800-61 Rev. 3,把 incident response 納入整體 cybersecurity risk management;但法定通知、證據保存與客戶溝通仍依事件與 jurisdiction 確認。

若事件需要替代供應、切換路線或復原關鍵產出,則轉入供應鏈韌性/business continuity 流程,不在本篇展開。

6. 復盤|更新根因、控制、評分與資料品質

復盤不是寫一份「下次更小心」報告。至少要回答:

  • 原 risk statement 是否捕捉到真正原因與共同依賴?
  • KRI 有沒有提早出現?資料延遲、缺值或 false positive 在哪裡?
  • 哪個 control 沒有執行、證據不足,或設計本身無效?
  • Incident escalation 是否找到正確決策人?
  • 原 likelihood/impact criteria 是否低估,評分者是否一致?
  • Supplier requirements、contract、稽核、資料源或教育訓練要怎麼改?
  • Corrective action 的 owner、due date、完成證據與 effectiveness review 是什麼?

更新 risk register、control library、KRI、supplier requirement 與 decision log 後,再追蹤 action 是否真的關閉。開過會、寄過信或供應商承諾改善,都不等於控制已有效。


評分範例:簡單矩陣可以用,但不能製造假精確

假設企業定義 1–5 likelihood 與 1–5 impact,可把乘積分組成內部優先級;但每一筆仍應保留原始兩個值、最高 impact dimension、hard-stop flags 與證據信心。

風險 Likelihood Impact 乘積 為何不能同樣處理
供應商近期多次延遲,影響一般補貨 4 3 12 重點可能是交付趨勢、產能控制與客戶承諾
發生機率較低,但可能涉及受限交易或重大安全 3 4 12 即使同分,也可能命中法遵 hard stop,不能由採購自行接受

Inherent score 應先不計現有控制。接著逐一驗證 control:例如名單 screening 是否涵蓋所有交易角色、資料是否是最新、potential match 是否有人工 resolution、誰簽核、多久 rescreen。

只有實際運作且證據可查的部分,才可反映在 residual risk。

如果評分者對同一 evidence 的分數差很大,不應取平均後就結束;應檢查 criteria 是否模糊、time horizon 是否不同、impact 維度是否被混在一起。IEC 31010 提供多種風險評估技術,表示 matrix 只是工具之一,不是所有情境的唯一答案。


高更新風險怎麼查?供應商、制裁與資安要看時間戳

供應商身分:官方登記是起點,不是結論

台灣供應商可先用經濟部商工登記公示資料與國際貿易署出進口廠商登記查詢,核對公開的法人、代表人、地址與貿易基本資料。接著仍要依風險補查廠址、sub-tier、受益所有權、財務、保險、品質、產能、資安、訴訟/事件與責任商業行為證據。

每份 evidence 都要記錄 legal name、identifier、source URL、查核時間、查詢條件與 reviewer。公司改名、併購、所有權、廠址、銀行帳戶、聯絡網域或分包變更,都應觸發重新確認。

制裁與出口管制:No-match 不是合法保證

台灣出口商應依產品、目的地、最終用途、最終使用者與交易角色,查國際貿易署的戰略性高科技貨品(SHTC)與實體管理資訊;若交易涉及其他 jurisdiction,再查當地官方 restricted-party、sanctions 與 export-control sources。

美國 International Trade Administration 的 Consolidated Screening List(CSL)整合 Commerce、State、Treasury 的多個篩查清單。

官方頁面說明工具會每日自動更新,但也提醒它是 industry screening 的輔助;potential match 出現時,還要查來源機關的正式清單與 Federal Register。上游機關資料提供也會影響彙整工具的新鮮度。

OFAC Sanctions List Search 對名稱使用 fuzzy logic,適合找可能的拼字、音譯或相似名稱。Fuzzy score 不是「同一實體機率」,potential match 也不是違法判決;反過來,no-match 更不是交易合法保證。

正確做法是保存查詢證據,暫停由原交易人自行放行,交法遵核對法人、別名、地址、所有權、program、jurisdiction、產品、end-use/end-user 與交易角色。

供應鏈資安:供應商問卷只是開始

NIST SP 800-161 Rev. 1 提醒組織,技術供應鏈風險可能來自成品、元件、開發與製造實務,以及對技術如何被開發、整合與部署缺乏可視性。

NIST SP 1305 則可用來建立 C-SCRM capability,並向 technology suppliers 溝通 cybersecurity requirements。

實務上,資安欄位至少要知道:供應商會碰哪些資料/系統、有哪些 subprocessor/component dependencies、存取權限、更新與漏洞處理、incident notification、終止合作後的存取撤除與資料處理。

CISA 的中小企業 vendor/supplier assessment 資源可作問題庫,但不能原封不動視為所有產業的合規問卷。


ISO、NIST、OECD 怎麼搭配,不互相替代?

框架/標準 主要範圍 本篇可怎麼用 不能宣稱
ISO 31000:2018 通用風險管理 principles、framework、process 建立 scope、assessment、treatment、monitoring、communication 骨架 ISO 31000 可用於 certification,或採用後自動合規
IEC 31010:2019 風險評估技術 依目的選方法,不只靠單一矩陣 某一種 score 是唯一正確方法
ISO 28000:2022 Security management system requirements,含供應鏈安全面向 需要 security management system 時另做 gap assessment 涵蓋所有品質、財務、RBC、資安與法規風險
NIST SP 800-161/SP 1305 Cybersecurity supply chain risk management ICT/software/data/vendor cyber requirements 代表完整供應鏈風險或全部法律義務
OECD RBC due diligence 對人、環境與社會等實際/潛在負面影響 補足企業損失視角,安排 prevent/mitigate/track/communicate/remedy 一張財務風險分數即可取代 impact due diligence

ISO 31000 官方頁面明確說明它不能用於 certification。ISO 28000 則是 security management system requirements,性質與範圍不同。

即使供應商提出 ISO 或 sustainability certificate,也只能在核對發證/查驗者、有效期、scope、site、product coverage、例外與本風險的關聯後,作為一項 evidence。

OECD 也提醒,sustainability initiatives 在 scope、focus 與 credibility 上存在差異。


每次 risk review meeting 只問這八題

風險會議不需要逐列朗讀表格。把時間集中在決策與例外:

  1. 新增、關閉或升級的風險,有什麼新 evidence?
  2. 哪些資料已過期、缺漏,或法人/產品/廠址對錯了?
  3. 哪個 hard-stop flag 命中,誰有權放行或拒絕?
  4. Control 有沒有 owner、執行紀錄與 effectiveness evidence?
  5. Residual risk 是否由正確層級接受,接受期限與條件是什麼?
  6. KRI 是否越界、延遲、缺值或產生 false positive?
  7. Incident/near miss 揭露了什麼根因、共同依賴或評分偏差?
  8. 哪些 action 逾期,結案證據能否驗證?

審查頻率沒有萬用答案。關鍵供應商、重大法遵/資安風險與高波動資料可以更頻繁;低 criticality 項目可依企業規則安排。無論週期如何,重大變更、名單/法規更新、KRI 越界與 incident 都應有事件觸發的 review。


供應鏈風險常見問題

風險清單越長越完整嗎?

不一定。只有危機名稱、沒有 objective、cause-event-impact、evidence、owner、control、trigger 與 review 的清單,很難支援決策。先把最關鍵的一批產品與供應商寫完整,比追求數量更有用。

風險分數可以證明合規嗎?

不可以。Score 用來讓內部依一致 criteria 排序;法規禁令、restricted-party、許可、客戶禁止條款與通知義務要另行判斷。Hard stop 不能被低 likelihood 或其他低 impact 分數抵銷。

供應商有 ISO 證書,可以直接降低分數嗎?

不能直接降低。先核對證書真偽、發證機構、有效期、scope、site、產品/服務範圍與例外,再判斷它是否能支持某一項 control。證書沒有涵蓋的風險,不能因 logo 存在而降分。

名單篩查 no-match,就可以交易嗎?

No-match 不代表合法保證。還要確認 jurisdiction、所有權、別名、end-use/end-user、產品管制、目的地、付款/物流角色與其他 red flags。

Potential match 則要停在人工 resolution,不要把 fuzzy result 直接當同一實體或誤報。

多久要更新一次風險登錄表?

不要只依固定日期。可按 supplier criticality 與 risk tier 安排週期審查,同時在 onboarding、續約、下單/出貨、法人/所有權/廠址/sub-tier/產品變更、法規/名單更新、KRI 越界與 incident 時觸發更新。

高風險供應商一定要終止嗎?

不一定。要先看是否命中法律或客戶 hard stop,再區分公司 residual risk 與對人/環境的 adverse impact,評估控制效果、企業 influence、替代方案與適當補救。這類決定應由有權限的跨職能團隊作成,而不是由分數公式自動解約。


結論:先完成一版可稽核的 Risk Register

要開始管理供應鏈風險,可以先選一個關鍵產品與一批關鍵供應商,建立 risk register v1。

每一筆至少寫清楚 objective、supplier/item/site、cause-event-impact、evidence、inherent risk、hard-stop flags、existing controls、residual risk、owner、action、KRI/trigger 與 review log。

接著由採購、品質、法遵、資安、財務與業務共同校正 criteria:同一分數代表什麼、誰能接受剩餘風險、哪些條件必須停單升級、哪些資料過期就不能沿用。

當事件發生時,把 risk 轉成 issue record;結案後再把根因、控制有效性與 lessons learned 寫回登錄表,才是真正的治理閉環。


法規、平台、費率與其他高更新資訊,仍應以文末官方來源的最新版本為準。

官方來源

分享此內容: