風險登錄表（Risk Register）是專案管理中記錄、分析與追蹤所有已識別風險的核心文件。這篇教學帶你從欄位結構、填寫方式到風險圖製作，一步步建立你的第一份風險登錄表。
什麼是風險登錄表（Risk Register）？
風險登錄表是一份系統性記錄專案所有已識別風險的動態文件，從專案啟動階段建立，貫穿規劃、執行到監控結案的整個生命週期。它不只是一張「風險清單」——很多人把兩者搞混，但差異很大。
風險清單只是列出「可能出問題的事」，而風險登錄表還包含每個風險的分析評分、優先順序、回應計畫、負責人與追蹤狀態。簡單說，風險清單是靜態的備忘錄，風險登錄表是活的管理工具。
誰需要它？ 專案經理是主要維護者，但 PMO、營運主管、產品負責人也需要它來做決策。我們團隊在管理跨部門專案時，風險登錄表是每週例會的必看文件——沒有它，討論風險就像在黑暗中射箭。
風險登錄表的核心價值可以用一句話概括：讓不確定性變得可管理。 你無法消除所有風險，但你可以讓每個風險都有人負責、有計畫應對、有時間追蹤。
本文的欄位設計符合 ISO 31000 風險管理原則，適用於大多數產業的專案情境。如果你正在準備企劃書，風險登錄表就是其中「風險管理」章節的核心附件。
風險登錄表的欄位結構：每個欄位的意義與填寫方式
這是整篇文章的核心。以下逐欄說明每個欄位的用途與填寫方式，每個欄位都附上實際範例。
風險 ID 與風險描述
風險 ID 是每個風險的唯一編號，建議用「R-001」、「R-002」這樣的格式，方便在會議中快速引用（「R-007 的狀態更新了嗎？」比「那個供應商可能延遲交貨的風險」有效率得多）。
風險描述 是最容易寫錯的欄位。很多人只寫「供應商延遲」，但這太模糊。建議用這個格式：
因為 [原因]，可能導致 [事件]，造成 [影響]
範例（IT 系統導入專案）：
- ❌「ERP 上線延遲」
- ✅「因為關鍵使用者對新系統操作不熟悉（原因），可能導致 UAT 測試階段發現大量操作錯誤（事件），造成上線時程延後 2-4 週（影響）」
這個格式的好處是：原因指向預防措施，事件指向監控指標，影響指向回應計畫。一句描述就能驅動後續所有欄位的填寫。
風險類別（Category）
將風險分類能幫助你發現盲區。常見分類包括：
- 技術風險：技術選型錯誤、系統整合失敗、效能不達標
- 外部風險：法規變更、市場波動、供應商問題
- 組織風險：人員異動、跨部門溝通障礙、高層支持度不足
- 專案管理風險：估算失準、範疇蔓延、資源不足
不同產業應調整分類。製造業可能需要加入「設備風險」和「安全風險」；軟體業則常見「資安風險」和「技術債風險」；建設業需要「天候風險」和「法規審查風險」。
實務上，分類不需要一開始就完美——先用通用分類，隨著專案推進再調整。重點是確保每次識別風險時，都檢查一下「是否有某個類別完全沒有風險？」如果組織風險欄是空的，通常不是沒有風險，而是你還沒找到。
發生機率與影響程度（定性分析）
這是風險登錄表中最關鍵的評分欄位。最常用的方式是 1-5 分制：
發生機率評分：
- 1 分：極低（< 10%）
- 2 分：低（10-30%）
- 3 分：中等（30-50%）
- 4 分：高（50-70%）
- 5 分：極高（> 70%）
影響程度評分（可分別評估對範疇、時程、成本、品質的影響）：
- 1 分：微小影響，可忽略
- 2 分：輕微影響，需要小幅調整
- 3 分：中等影響，需要變更計畫
- 4 分：重大影響，威脅專案目標
- 5 分：災難性影響，可能導致專案失敗
風險優先數（RPN）= 機率 × 影響。例如機率 4 × 影響 5 = RPN 20，這是最高優先的風險。RPN 幫你快速排序：先處理分數最高的，資源有限時可以暫時接受低分風險。
💡 何時需要從定性升級到定量分析？ 當專案預算超過 NT$5,000 萬、或涉及人身安全時，建議對 RPN 前五名的風險進行定量分析（如蒙地卡羅模擬），用數據取代主觀評分。大多數中小型專案用定性分析就足夠了。
風險擁有者（Risk Owner）
每個風險必須指定一位負責人。這是風險登錄表能否真正運作的關鍵——沒有擁有者的風險，就是沒人管的風險。
最常見的錯誤是把所有風險都填「專案經理」。PM 的職責是維護整份登錄表，不是處理每一個風險。正確做法是依風險類別分配給對應的職能主管：
- 技術風險 → 技術主管 / 架構師
- 供應商風險 → 採購經理
- 人力風險 → 部門主管 / HR
- 預算風險 → 財務負責人
風險擁有者的責任包括：監控風險狀態變化、執行回應計畫、在風險審查會議前更新登錄表。如果你發現某位擁有者從來不更新，那是管理問題，不是工具問題。
風險回應策略
識別風險後，你需要決定怎麼應對。PMBOK 定義了四大策略，每種都有適用情境：
迴避（Avoid）：改變計畫以消除風險。 台灣情境範例：某電商平台開發專案，原本計畫整合一個穩定性未知的第三方金流 API。PM 評估後決定砍掉這個整合，改用已驗證的金流服務——直接消除了「API 不穩定導致交易失敗」的風險。
轉移（Transfer）：把風險的影響轉移給第三方。 台灣情境範例：建設公司在標案中購買工程保險，將「施工意外造成的賠償風險」轉移給保險公司。軟體業常見的做法是將高風險模組外包給專業廠商，合約中明訂 SLA 與罰則。
減輕（Mitigate）：降低風險的機率或影響。 台灣情境範例：ERP 導入專案中，「使用者抗拒變革」是高優先風險。PM 提前安排三場變革管理工作坊，並指派各部門的種子使用者——這不能完全消除抗拒，但能大幅降低影響。另一個常見的減輕做法是技術驗證（POC）：在正式開發前先進行概念驗證，確認第三方 API 的穩定性與效能是否符合需求，避免到整合階段才發現技術不可行。前者處理的是人的面向，後者處理的是技術面向，兩種減輕策略經常搭配使用。
接受（Accept）：承認風險存在，不主動處理。 分為主動接受（設定應變計畫和觸發條件）和被動接受（發生時再處理）。例如「颱風導致戶外活動延期」——你無法阻止颱風，但可以預先準備室內備案場地（主動接受）。
在決定策略時，可以用艾森豪矩陣的思維來輔助判斷：高機率高影響的風險優先迴避或減輕，低機率低影響的風險可以接受。
剩餘風險與次要風險
執行回應策略後，風險不會完全消失。剩餘風險（Residual Risk） 是回應後仍然存在的風險。例如你購買了工程保險（轉移策略），但保險理賠流程可能耗時 3 個月——這段期間的現金流壓力就是剩餘風險。
次要風險（Secondary Risk） 是因為執行回應策略而「新產生」的風險。例如你決定將模組外包（轉移策略），但外包商的交付品質可能不如預期——這就是次要風險。
這兩種風險都必須記錄在登錄表中，否則你以為問題解決了，其實只是換了一個問題。
狀態與更新日期
風險狀態通常分為三種：
- 開放（Open）：風險仍然存在，需要持續監控
- 已關閉（Closed）：風險已不再適用（例如該階段已完成）
- 已實現（Realized）：風險已經發生，轉為議題（Issue）處理
更新日期記錄的是「最後一次檢視這個風險的時間」。如果一個開放狀態的風險超過兩週沒更新，代表沒人在看它——這比風險本身更危險。
建議更新頻率：每週例會前 24 小時，由各風險擁有者更新自己負責的風險狀態。
以下是完整的風險登錄表欄位結構示意：
| 欄位名稱 | 說明 | 填寫範例 |
|---|---|---|
| 風險 ID | 唯一編號 | R-001 |
| 風險描述 | 因為→導致→造成 | 因為關鍵工程師可能離職，導致核心模組開發停滯，造成上線延後 4 週 |
| 風險類別 | 技術/外部/組織/PM | 組織風險 |
| 發生機率 | 1-5 分 | 3（中等） |
| 影響程度 | 1-5 分 | 5（災難性） |
| RPN | 機率 × 影響 | 15（高優先） |
| 風險擁有者 | 指定負責人 | 技術部門主管 王經理 |
| 回應策略 | 迴避/轉移/減輕/接受 | 減輕：交叉訓練第二位工程師 |
| 剩餘風險 | 回應後仍存在的風險 | 第二位工程師熟練度不足，開發速度降低 30% |
| 狀態 | Open/Closed/Realized | Open |
| 更新日期 | 最後檢視日期 | 3/15 |
風險識別：如何找出值得記錄的風險？
填表之前，你得先知道風險從哪裡來。很多 PM 的困擾不是「不會填表」，而是「不知道該填什麼」。以下是五種最實用的風險識別技術。
常用風險識別技術
腦力激盪（Brainstorming） 是最直覺的方法。召集核心團隊成員，用 30 分鐘自由發想「這個專案可能出什麼問題」。適合 5-10 人的敏捷團隊，門檻低、速度快。缺點是容易被聲音大的人主導，安靜的成員可能不敢發言。
德爾菲法（Delphi Technique） 解決了腦力激盪的缺點。透過匿名問卷收集專家意見，經過多輪彙整後達成共識。適合需要跨部門或外部專家參與的大型專案，但耗時較長（通常需要 2-3 輪，每輪 3-5 天）。
SWOT 分析 不只是策略工具，也是風險識別的好幫手。從「弱點（Weakness）」和「威脅（Threat）」欄位中，你可以直接萃取出風險項目。如果你的團隊已經做過 SWOT 分析，別浪費那些洞見。
查核清單法（Checklist） 是最省力的方式——用過去專案的風險登錄表作為起點，逐條檢查「這次專案是否也有類似風險」。前提是你的組織有保留歷史資料（後面會談到歸檔的重要性）。
根本原因分析（Root Cause Analysis） 則是從已知問題反推。如果上一個專案因為「需求變更頻繁」而延期，你可以追問：為什麼需求會變更？是因為利害關係人沒有在早期參與？那「利害關係人參與度不足」就是這次專案需要記錄的風險。
| 識別方法 | 適用情境 | 所需時間 | 優點 | 缺點 |
|---|---|---|---|---|
| 腦力激盪 | 小型敏捷團隊 | 30-60 分鐘 | 快速、門檻低 | 易被少數人主導 |
| 德爾菲法 | 大型專案、需匿名意見 | 1-2 週 | 避免群體思維 | 耗時、流程複雜 |
| SWOT 分析 | 策略性專案 | 1-2 小時 | 結合策略與風險 | 偏向高層視角 |
| 查核清單法 | 有歷史資料的組織 | 30 分鐘 | 不遺漏常見風險 | 可能忽略新風險 |
| 根本原因分析 | 問題導向的專案 | 1-2 小時 | 找到深層原因 | 需要經驗判斷 |
台灣常見專案風險情境（依產業）
不同產業面對的風險截然不同。以下是我們觀察到的台灣常見情境：
製造業：供應鏈斷鏈（尤其是半導體相關零件）、原物料價格波動、設備交期延誤、環保法規趨嚴導致產線需要改造。
軟體／IT：需求頻繁變更（台灣甲方文化的經典痛點）、關鍵工程師離職、第三方 API 不穩定、資安事件導致專案暫停。
建設／工程：法規審查延誤（都市計畫變更、環評）、颱風季施工中斷、分包商履約能力不足、鄰損爭議。
活動企劃：場地臨時取消、贊助商撤資、講者缺席、天候影響戶外活動。
💡 實務案例：某台灣中型企業的 ERP 導入專案，PM 在啟動階段透過腦力激盪識別出 23 個風險。其中「使用者抗拒變革」被評為 RPN 最高（機率 4 × 影響 5 = 20）。PM 提前安排了三場變革管理工作坊，並在每個部門指派種子使用者。最終專案準時上線，使用者滿意度達 78%——遠高於業界平均的 55%。這個案例說明：風險識別做得早，回應計畫才有時間發揮作用。
如果你的團隊正在進行數位轉型，「使用者抗拒變革」幾乎是必然會出現的風險，務必在啟動階段就記錄進登錄表。
風險圖（Risk Map）：讓風險優先順序一目了然
風險登錄表的資料量一多，逐條看很痛苦。風險圖（Risk Map，也叫 Heat Map）就是把登錄表的評分資料視覺化，讓你一眼看出哪些風險最需要關注。
風險圖是一個二維矩陣：X 軸是影響程度，Y 軸是發生機率。每個風險根據評分標示在對應位置，再用顏色區分優先等級。
三個區域的行動指引
紅區（高機率 × 高影響，RPN 15-25）：這些風險需要立即制定回應計畫，指派擁有者，每週追蹤。如果紅區風險超過 5 個，代表專案本身的可行性需要重新評估。
黃區（中等風險，RPN 5-12）：持續監控，準備應變計畫但不需要立即行動。設定觸發條件——當某個指標達到閾值時，啟動回應計畫。
綠區（低機率 × 低影響，RPN 1-4）：接受並記錄。每月檢視一次即可，除非外部環境發生重大變化。
風險圖的實務價值與限制
💡 實務案例：某新產品開發專案的 PM 在週會上展示風險圖，高階主管在 10 分鐘內就完成了優先順序決策，取代過去逐條討論 1 小時的低效模式。主管只需要問：「紅區有幾個？上週是幾個？趨勢是增加還是減少？」
但風險圖也有限制：定性評分本質上是主觀的。同一個風險，樂觀的人可能評 2 分，悲觀的人評 4 分。解決方法是在團隊中建立共識——第一次評分時，讓所有人獨立評分，然後取中位數並討論差異。經過 2-3 次校準後，團隊的評分標準會趨於一致。
如果你想用視覺化工具來呈現風險圖，可以參考流程圖製作的工具選擇，許多工具同時支援矩陣圖的製作。
風險登錄表範本：免費下載與工具選擇
我們準備了可直接使用的 Google Sheets 風險登錄表範本，包含本文介紹的完整欄位結構、條件格式和風險圖。
👉 免費下載風險登錄表範本（Google Sheets） — 點擊後會自動複製一份到你的 Google 雲端硬碟，可直接編輯使用，也可以下載為 Excel 格式。
範本包含三個工作表：精簡版（5 欄）、標準版（10 欄）、進階版（15 欄），根據你的專案規模選擇適合的版本即可。
三種版本的適用情境
精簡版（5 欄）：風險 ID、描述、擁有者、回應策略、狀態。適合 3 人以下的小型專案或初次使用風險登錄表的團隊。重點是先養成「記錄風險」的習慣，不要被複雜的欄位嚇跑。
標準版（10 欄）：加入風險類別、機率評分、影響評分、RPN、更新日期。適合大多數 5-15 人的專案團隊，能支撐完整的風險分析與優先排序。本文的欄位結構就是標準版。
進階版（15 欄）：再加入剩餘風險、次要風險、觸發條件、應變預算、定量分析結果。適合預算超過 NT$5,000 萬或涉及高風險的大型專案。
如何用 Google Sheets 自訂風險登錄表
如果你想根據自己的需求調整範本，以下是關鍵設定步驟：
步驟 1：調整欄位結構。 根據你的專案需求增減欄位。凍結第一列方便捲動查看。
步驟 2：設定下拉選單。 對「風險類別」、「回應策略」、「狀態」欄位使用資料驗證功能，建立下拉選單。這能避免每個人用不同的文字描述同一件事（例如有人寫「開放」、有人寫「Open」、有人寫「進行中」）。
步驟 3：用條件格式自動標色。 對 RPN 欄位設定條件格式：15-25 分標紅色、5-12 分標黃色、1-4 分標綠色。這樣打開表格就能一眼看到高優先風險。
步驟 4：建立風險圖。 選取機率和影響欄位的資料，插入散佈圖或泡泡圖。X 軸設為影響程度，Y 軸設為發生機率，泡泡大小可以對應 RPN 值。
風險登錄表工具比較：試算表 vs. 專案管理工具
Google Sheets 免費且彈性高，但當團隊超過 5 人時，你會開始遇到問題：版本控制混亂（誰改了什麼？）、沒有自動通知（風險擁有者忘記更新）、無法與專案排程整合。
這時候專案管理工具的優勢就很明顯。我們團隊實際使用 monday.com 管理風險登錄表，最大的好處是：每個風險可以直接指派擁有者並設定到期日，狀態變更時自動通知相關人員，而且風險登錄表和專案看板在同一個平台上，不用在不同工具之間切換。
如果你的團隊偏技術導向，ClickUp 也是不錯的選擇，它的自訂欄位功能很強，可以精確複製你需要的風險登錄表結構。
| 功能 | Google Sheets | monday.com | ClickUp |
|---|---|---|---|
| 費用 | 免費 | 免費方案可用，進階功能 NT$288/月起 | 免費方案可用，進階功能 NT$210/月起 |
| 即時協作 | ✅ 基本 | ✅ 進階（含即時通知） | ✅ 進階（含即時通知） |
| 自動通知 | ❌ 需手動 | ✅ 狀態變更自動通知 | ✅ 可自訂觸發條件 |
| 風險圖 | 需手動建立圖表 | 內建儀表板視覺化 | 內建儀表板視覺化 |
| 與專案排程整合 | ❌ 獨立檔案 | ✅ 同平台整合 | ✅ 同平台整合 |
| 適用規模 | 1-5 人 | 5-50 人以上 | 5-30 人 |
| 開始使用 | — | 免費試用 → | 免費試用 → |
我們的建議：5 人以下小團隊先用 Google Sheets 範本建立習慣；5 人以上、需要跨部門協作的團隊，直接用專案管理工具。monday.com 的免費方案不需要信用卡，可以先試用看看是否符合需求。
（推薦試試 monday.com 的免費方案，我們團隊用它管理風險登錄表後，風險審查會議的準備時間從 2 小時縮短到 30 分鐘）
如果你的團隊更偏好技術導向的工具，ClickUp 的自訂欄位和自動化功能也非常適合建立風險登錄表。
風險登錄表的維護與更新：讓它真正發揮作用
建立風險登錄表只需要 1-2 小時，但讓它持續發揮作用需要紀律。這是競品文章最常忽略的部分——大多數風險登錄表在建立後兩週就變成「沒人看的文件」。
何時更新風險登錄表？
除了固定的每週更新節奏，以下事件應該觸發即時更新：
- 里程碑完成：某些風險可能因為階段完成而不再適用，應關閉
- 範疇變更：新增功能或調整需求，幾乎一定會帶來新風險
- 新風險出現：團隊成員在日常工作中發現的潛在問題
- 已識別風險發生：風險變成了議題，狀態應改為「已實現」
建議的固定節奏：每週例會前 24 小時，由各風險擁有者更新自己負責的風險。PM 在例會前 2 小時彙整，確認是否有需要升級討論的項目。
風險審查會議（Risk Review Meeting）怎麼開？
風險審查會議不需要很長，但需要結構化。以下是我們實際使用的 40 分鐘議程：
- 回顧上期高優先風險狀態（10 分鐘）：只看紅區和黃區的風險，確認回應計畫是否在執行
- 新增風險識別（10 分鐘）：每位成員分享過去兩週發現的新風險
- 調整優先順序與回應計畫（15 分鐘）：重新評估機率和影響，調整 RPN 排序
- 指派行動項目（5 分鐘）：明確誰要做什麼、什麼時候完成
頻率建議：大型專案（超過 20 人）每兩週一次；小型專案（10 人以下）每月一次。
常見失敗原因：只有 PM 在更新，其他成員沒有參與感。解決方法是讓每位風險擁有者在會議中報告自己負責的風險——當你知道下次會議要報告，你就會提前更新。
💡 實務案例：某 50 人規模的軟體公司導入 OKR 系統時，PM 每兩週舉行 30 分鐘風險審查。第一個月高優先風險有 8 個，PM 在會議中用風險圖展示趨勢。三個月後，高優先風險降至 2 個，專案準時交付。關鍵不是風險消失了，而是團隊養成了「提前處理」的習慣。
如果你的團隊也在導入 OKR，可以參考 ClickUp 的 OKR 範本，將風險管理與目標追蹤整合在同一個平台上。
風險登錄表與其他文件的整合
風險登錄表不是孤立的文件，它需要與其他專案文件連動：
與專案計畫（Project Plan）：回應計畫中的行動項目應該反映在工作分解結構（WBS）中。例如「安排變革管理工作坊」這個回應行動，應該出現在專案排程裡，有明確的時間和負責人。
與議題日誌（Issue Log）：當風險「已實現」（真的發生了），它就不再是風險，而是議題。這時應該將它從風險登錄表移至議題日誌，用不同的流程追蹤解決進度。
與 RAID Log：RAID Log 是更廣泛的追蹤文件，包含風險（Risk）、假設（Assumption）、議題（Issue）、相依性（Dependency）。風險登錄表可以視為 RAID Log 中「R」的詳細展開版本。小型專案可以直接用 RAID Log 取代獨立的風險登錄表。
專案結束後的歸檔
這是大多數團隊忽略的步驟。專案結束後，風險登錄表應該歸檔為組織過程資產（Organizational Process Assets）。未來類似專案的 PM 可以用它作為查核清單的起點——「上次 ERP 導入遇到了哪些風險？」比「大家想想可能有什麼風險」有效率十倍。
歸檔時建議加上一欄「經驗教訓」：這個風險的回應策略有效嗎？如果重來一次，會怎麼做？這些資訊對組織的長期風險管理能力至關重要。
結論
風險登錄表不是一份「做完就放著」的文件，它的價值在於持續使用。以下是本文的核心重點：
- 風險登錄表是動態文件，包含識別、分析、回應計畫與追蹤，不只是風險清單
- 七大欄位各有功能：風險 ID、描述、類別、機率影響評分、擁有者、回應策略、狀態——每個欄位都在驅動下一步行動
- 四大回應策略（迴避、轉移、減輕、接受）要根據風險的 RPN 和成本效益來選擇
- 風險圖讓決策更快：用 5×5 矩陣視覺化，紅黃綠三區對應不同行動層級
- 維護比建立更重要：固定更新節奏、結構化審查會議、專案結束後歸檔
你的下一步行動：① 下載免費風險登錄表範本（Google Sheets，可轉存 Excel）→ ② 用腦力激盪或查核清單識別風險，填入範本 → ③ 指定每個風險的擁有者，並排定每兩週一次的審查會議。
如果你的團隊超過 5 人，需要自動通知和跨部門協作功能，建議直接在 monday.com 上建立風險登錄表看板。用自訂欄位設定機率、影響、RPN 評分，再搭配自動化規則——例如「RPN 超過 15 時自動通知 PM 和風險擁有者」。10 分鐘就能建好，比 Excel 省下大量後續維護時間。
風險登錄表常見問題
風險登錄表和風險評估表有什麼不同？
風險評估表（Risk Assessment）通常是一次性的靜態分析工具，聚焦在「評分」這個動作——列出風險、評估機率和影響、計算分數。風險登錄表則是動態文件，除了評估之外，還包含回應計畫、擁有者指派、狀態追蹤，貫穿整個專案生命週期。簡單說，風險評估表是風險登錄表的「子集」——評估完的結果會記錄在登錄表中，但登錄表的功能遠不止於評估。
誰應該負責維護風險登錄表？
主要責任在專案經理（PM），負責維護整份文件的完整性和更新節奏。但每個風險的日常監控和狀態更新，由該風險的擁有者負責。專案發起人或 PMO 則扮演審核角色，在風險審查會議中確認高優先風險的回應計畫是否足夠。好的領導力能讓團隊成員主動參與風險管理，而不是被動等 PM 來追。
小型專案也需要風險登錄表嗎？
是的，但可以用精簡版（5 欄：ID、描述、擁有者、回應策略、狀態）。判斷標準：只要專案有超過 3 個利害關係人或超過 1 個月工期，就建議建立。即使只記錄 5 個風險，也比「什麼都沒記錄」好——因為當風險發生時，你至少有一個回應計畫可以參考，而不是從零開始應對。
風險登錄表要記錄多少個風險才夠？
沒有固定數字，取決於專案的規模和複雜度：
- 小型專案（3-5 人、1-3 個月）：5-15 個風險
- 中型專案（10-20 人、3-6 個月）：15-30 個風險
- 大型專案（20 人以上、6 個月以上）：30 個以上，建議依類別分組管理
如果你識別出超過 50 個風險，可能需要重新檢視粒度——是不是把「議題」也混進來了？風險是「尚未發生的不確定事件」，已經發生的問題應該記錄在議題日誌中。
風險登錄表（Risk Register）和 RAID Log 有什麼差別？
RAID Log 是更廣泛的追蹤文件，包含四個面向：風險（Risk）、假設（Assumption）、議題（Issue）、相依性（Dependency）。風險登錄表是 RAID Log 中「R」的詳細展開版本。如果你的專案規模較小（10 人以下），可以直接用一份 RAID Log 涵蓋所有面向；如果是大型專案，建議將風險登錄表獨立出來，因為光是風險的數量和分析深度就足以撐起一份獨立文件。
