風險登錄
風險登錄（risk register）是一份持續維護的清單，逐列記錄具體的風險事件，並且每一列都寫明可能性、影響、處理方式、一位具名的負責人，以及下一次複查的日期。
這句定義裡有兩個容易被略過、但決定這份文件有沒有用的字：具體與持續維護。具體指的是每一列描述的都是「可能發生的一件事」，不是一個領域；持續維護指的是這份清單有固定的複查節奏，而不是為了某次募資或某次稽核產出一次就封存。少了前者，登錄會變成一張主題目錄，無法引導任何行動；少了後者，登錄會在幾個月內退化成一份與現實脫節的文件——它上面的數字仍然看起來很精確，但已經沒有人相信，也沒有人依它決策。
風險登錄與 角色當責 是同一個設計原則的兩個應用面：每一個重要的東西都要對得起一個名字。差別在於當責處理的是「已經在發生的結果」，風險登錄處理的是「還沒發生、但一旦發生會改變結果的事件」。它也與 營運節奏 互相依賴：複查日期若不掛進既有的月度或季度週期，就只是一個寫在欄位裡的願望。
風險是事件，不是主題
Section titled “風險是事件，不是主題”這是最常見、也最昂貴的錯誤。「現金流」不是風險，「資安」不是風險，「人才」也不是風險——它們是主題。風險是一個有原因、有後果的事件，寫出來應該可以套進這個句型：因為某個原因，某件事發生，導致某個具體後果。
比較兩種寫法就很清楚。寫「現金流」時，沒有人知道要做什麼、由誰做、做到什麼程度算完成；寫「主要客戶延遲付款 60 天，導致公司無法如期支付薪資」時，原因（單一客戶集中度加上帳期）、事件（延遲 60 天）與後果（薪資無法支付）都在句子裡，於是處理方式幾乎自動浮現：分散客戶、縮短帳期、預先安排額度、或提高現金緩衝。**能不能寫出具體的處理方式，本身就是檢查這一列有沒有寫對的方法。**寫不出來，通常不是因為不夠努力，而是因為那一列寫的還是主題。
同一個主題會長出好幾個不同的風險事件，而它們的處理方式可能完全不同。「資安」這個主題底下，「員工帳號遭盜用導致客戶資料外洩」與「機房電力中斷導致服務停擺 8 小時」都是風險事件，前者的處理偏向存取控制與資料最小化（見 隱私設計），後者的處理偏向備援與復原演練。把它們合併成一列「資安風險」，等於把兩個不相干的決策綁在一起。
期望損失是起點，而且它是風險中性的
Section titled “期望損失是起點，而且它是風險中性的”風險登錄最常用的排序工具是期望損失：
期望損失 = 可能性 × 影響金額
這個式子的用途是把不同量級的風險放到同一把尺上比較，它確實有用。但必須同時知道它的性質：期望值是風險中性（risk-neutral）的——它假設「5% 機率損失 2,000 萬」與「100% 機率損失 100 萬」對決策者而言是等價的，因為兩者的期望值都是 100 萬。
對一家現金有限的公司來說，這兩件事一點都不等價。第二種情況公司會很痛但活得下來；第一種情況一旦發生，2,000 萬的支出可能超過帳上所有可動用的現金，公司會直接結束。期望值沒有內建「破產」這個吸收壁：它把一次致命的損失，攤平成許多次不痛不癢的小損失來計算，而現實裡公司只有一次機會。
由此得到一條實用判準：先問影響金額是否超過公司的承受上限，再看期望損失排序。任何一列的影響金額若接近或超過可動用現金（這個上限的估法見 營運資金），它就必須被單獨處理，不能因為期望損失排在第三名就排在第三名處理。這也正是四種處理方式裡 移轉（保險或合約轉嫁）與 避免（不做這件事）存在的理由：它們處理的不是期望值，而是尾端。
固有風險與剩餘風險不是同一個數字
Section titled “固有風險與剩餘風險不是同一個數字”登錄上的每一列其實有兩個版本：固有風險（inherent risk） 是在現有控制措施之前的風險水準，剩餘風險（residual risk） 是控制措施實施之後仍然存在的水準。混用這兩個數字會造成兩種相反的錯誤：只寫固有風險，會讓已經做得不錯的地方看起來仍然危險，資源被誤導；只寫剩餘風險，會讓人忘記那個低數字是控制措施換來的，一旦控制被裁撤或失效，風險立刻跳回原位。
正確做法是兩欄並列，並在中間寫下「靠什麼控制」。這一欄同時回答了另一個問題：當公司為了省成本考慮取消某項作業時，可以立刻看出取消它會讓哪一列的數字回升多少。
一個名字、一個日期，否則登錄會變成小說
Section titled “一個名字、一個日期，否則登錄會變成小說”兩個欄位決定這份文件會不會腐爛。負責人必須是一個人名，不是部門；理由與當責完全相同，兩個人負責等於沒有人負責。複查日期必須是具體日期，而且到期時要有人真的重新看一次可能性與影響是否改變。
沒有這兩欄，可以預測會發生什麼：清單越寫越長（因為加一列沒有成本）、數字越來越舊（因為沒有人有義務更新）、而且沒有任何一列會關閉（因為沒有人有權判斷它已經不再相關）。一份健康的登錄，列數會上下波動，而不是單調增加。
最後一個邊界屬於制度層面：風險的處理經常牽涉保險條款、合約責任分配與法定義務，而這些不是全球通用的——可保範圍、責任上限的效力、通報義務與時限都因司法管轄區而異且時常修訂。登錄可以記下「這一列打算用移轉處理」，但實際條款必須就個案尋求當地合格的法律或保險專業協助，相關取捨見 保險、執照與專業協助課。
Fact-backed example（教學數字，本系列共用的虛構公司「宏茂科技」，一家做消費者 App 的小型軟體公司，單位：元）：
| 風險 | 可能性 | 影響金額 | 期望損失 | 處理方式 |
|---|---|---|---|---|
| 主要供應商中斷 | 20% | 3,000,000 | 600,000 | 降低 |
| 客戶資料外洩 | 5% | 20,000,000 | 1,000,000 | 移轉 |
| 關鍵人員離職 | 30% | 1,500,000 | 450,000 | 降低 |
| 匯率波動 | 40% | 500,000 | 200,000 | 接受 |
先驗算每一列：0.20 × 3,000,000 = 600,000、0.05 × 20,000,000 = 1,000,000、0.30 × 1,500,000 = 450,000、0.40 × 500,000 = 200,000。四列相加 600,000 + 1,000,000 + 450,000 + 200,000 = 2,250,000 元，這是全部四列的期望損失合計。單位一致（可能性無單位、影響金額為元，乘積為元），量級也合理。
真正要讀出來的資訊不在合計數，而在第二列與第四列的對比。匯率波動的可能性是 40%，是資料外洩 5% 的八倍，但公司對前者的處理是「接受」，對後者是「移轉」。若只看期望損失排序，資料外洩（1,000,000）確實排第一，看起來排序也沒錯；但真正的理由不是它期望損失最高，而是它的影響金額 20,000,000 元可能超過公司當下可動用的現金。匯率波動最壞的情況是損失 500,000 元，公司會不高興但照常營運；資料外洩最壞的情況是公司結束。兩者的差別是存續與否，而期望損失這把尺讀不出這個差別，所以它被移轉出去，而不是只做「降低」。
接著看一項控制措施要不要做。假設有一項作業（雙供應商 + 安全庫存）每年成本 300,000 元，可以把主要供應商中斷的可能性從 20% 降到 5%，影響金額不變：
- 期望損失下降
= (0.20 − 0.05) × 3,000,000 = 0.15 × 3,000,000 = 450,000元／年 - 淨效益
= 450,000 − 300,000 = 150,000元／年
交叉檢查：控制前的期望損失是 600,000，控制後是 0.05 × 3,000,000 = 150,000，兩者相差 450,000，與上式一致。淨效益為正，光看期望值就值得做。
再把同一項效果的成本換成 600,000 元／年：淨效益 = 450,000 − 600,000 = −150,000 元／年，期望值上不划算。但公司仍然可能要買它——如果 3,000,000 元的中斷損失會同時觸發違約與客戶流失，把公司推到現金斷點，那麼多付的 150,000 元買到的不是期望值，而是降低毀滅性結果發生的機率。這正是前一節的重點在數字上的樣子：**期望值是決策的起點，不是決策本身。**這裡的可能性與影響金額都是為了讓推導可驗算而設定的假設值，讀者必須換成自己的實際數字；四列的估計本身是 inference，不是觀測到的頻率。
Failed alternative： 另一種做法是為了募資或客戶問卷，一次性做出一份完整、漂亮、有顏色標示的風險矩陣，附在資料夾裡，之後再也沒有打開過。
它當時看起來相當合理：文件確實完整，涵蓋面比多數同規模公司更廣；投資人也確實接受了；而且在做的當下，團隊真的把風險討論了一遍，那次討論本身是有價值的。反對它的人很難提出具體理由——文件並沒有寫錯任何東西。
它失效的假設是「風險清單的價值在於它被寫出來」。實際上清單的價值幾乎全部來自它被重讀時發生的事：某一列的可能性因為新客戶集中而上升、某一列因為換了供應商而可以關閉、某一列的負責人已經離職。這些變化不會自己出現在文件上。預警訊號很好認：登錄上的日期欄位全部是同一天；沒有任何一列曾經被關閉或被調高；問「這一列現在還成立嗎」時得到的答案是「應該吧」；以及最典型的一種——公司實際發生的事故，在登錄上完全找不到對應的列。更嚴重的變體，是連風險文件本身都是從別處抄來的，於是文件描述的作業與公司真正在做的事完全對不上，其代價見 抄襲合規範本案例。
正確做法是把維護成本壓到能持續為止：列數控制在真正會影響決策的範圍（多數小公司十列以內就夠），每一列有名字與日期，並且把複查掛進既有的月會或季會，而不是另外發明一個會議。
讀者會在四種決策裡再次用到風險登錄。做年度或季度規劃時，它是把「我們擔心什麼」轉成預算項目的橋樑——每一項降低型的控制措施都應該能對上一列，對不上的支出要重新解釋。談保險與合約時，登錄決定哪些風險要移轉、移轉多少，這正是 風險登錄與處理課 展開的四種處理方式：避免、降低、移轉、接受。設計內部控制時，登錄提供優先順序，合約與內部控制課 則提供具體作業設計；沒有登錄的內控容易變成到處都要簽核，有登錄的內控才知道該把摩擦放在哪裡。處理特定領域的風險時，登錄是入口而不是終點：智慧財產的歸屬缺口見 智慧財產，個人資料的持有與外洩見 隱私設計，兩者都會回到登錄上具體的一列。想動手做一份，可用 風險與智慧財產稽核練習。
實務上的維護規則只有三條：每一列都能用「因為……導致……」的句型寫完，寫不出來就代表那一列還是主題；每一列都有一個人名與一個複查日期，缺任一欄就不算完成；影響金額接近可動用現金的列，一律單獨處理，不與其他列一起按期望損失排序。
OECD 公司治理原則中關於董事會職責的章節 支持本文的一項結構性前提：風險的監督是治理層的職責，而且必須配合資訊揭露與明確的答覆對象，而不是某個人私下的擔憂清單。本文把這個治理層的期待，向下轉譯成小公司可以操作的形式——一份具名、有複查日期的清單——這一步轉譯是作者的 inference，該原則本身討論的是董事會的職責範圍，並未規範風險登錄的欄位設計。範圍限制必須一併說明：該原則為 non-binding（不具法律拘束力），主要以公開發行公司為對象，未上市或小型公司是否採用、採用到什麼程度，取決於自身選擇與當地法規。
IFC 公司治理方法論工具頁 支持另一項邊界：風險與控制的安排必須配合組織的規模與成熟度。該頁明確指出公司治理沒有 one-size-fits-all 的做法，將評估分為多個成熟度層級，並對不同型態的組織（含中小企業、家族或創辦人持有的企業）提供不同工具，其評估面向亦包含控制環境（control environment）。本文據此主張：登錄的細緻程度應隨規模調整，五人公司不需要與百人公司相同的欄位與分層，但「一列一個事件、一個名字、一個日期」這條最低要求在任何規模都成立——後半句是作者的 inference，不是該頁的主張。
範圍限制與教學標示：期望損失 = 可能性 × 影響金額 是風險管理的通用分析慣例，不是任何法規或準則的強制要求；固有風險與剩餘風險的區分同樣是管理慣例，不同框架的用語可能不同。文中「宏茂科技」的四列風險、可能性、影響金額與控制成本全部是教學 example，不是任何真實公司的資料，也不是任何產業的基準值；期望損失的計算在給定假設下是確定性的算術，但假設本身（尤其是可能性）是估計，不是觀測，這是這類表格最脆弱的地方。凡涉及保險可保範圍、合約責任分配、法定通報義務或其期限的結論，皆因地區而異且時有修訂，不是全球通用；請就個案尋求當地合格的法律、保險或風險管理專業協助。兩筆來源 accessed 2026-07-31。