透過 AI 建立風險登記表：完整指南
風險登記表是一個列出可能出錯的情況及其發生機率的表格。它還記錄了會造成的損害、負責人以及您決定採取的行動。大多數團隊都是在發生了沒人記錄過的錯誤之後，才建立第一個風險登記表。本指南將介紹手動建立的方法，以及使用您現有匯出資料的更快速方法。
什麼是風險登記表
最清晰的定義來自 NIST 的詞彙表，將其稱為「風險資訊的儲存庫，包含隨著時間推移對風險所了解的資料」。
同一頁面上的第二個條目對於實際工作更有用。它將其描述為特定範圍或組織內當前風險的集中記錄。
該條目隨後做出了一個大多數範本都忽略的區分。當前的風險既包括您已接受的風險，也包括有計劃緩解路徑的風險。
這就是整個核心概念。風險登記表不是等待解決的問題清單。它是決策的記錄，而「我們評估過這個問題，並決定接受它」也是一個合理的條目。
這種區分具有實際的影響。如果遺漏了已接受的風險，就沒人能分清一個風險是經過權衡後被排除，還是根本就沒被發現。六個月後，這兩者看起來一模一樣，但其中只有一個是決策上的失敗。
在建立之前，請注意一個範圍說明。NIST 的資料背景是聯邦與網路安全。其 詞彙表條目 指向了 OMB Circular A-11，以說明聯邦登記表必須包含的內容。以下介紹的是大多數團隊實際需要的管理版本，而不是為了符合合規標準而建立的登記表。如果您是根據特定的框架進行申報，請使用該框架的欄位清單。
不過，該文獻中的一個觀點確實可以借鑑。NIST 的 IR 8286 是圍繞登記表構建的。其摘要解釋了「將通常在較低系統和組織層級處理的風險衡量指標，彙總到更廣泛的企業層級的價值」。
這在第一個版本中就值得納入設計。一個評分基於可比數據的登記表可以與其他團隊的登記表合併；而一個基於個人主觀判斷建立的登記表則無法做到。
開始之前您需要準備什麼
三個輸入要素，且它們很少存在於同一個地方。
- 危害清單。 無論您的團隊已經在擔心什麼，不論記錄得有多非正式。
- 曝險資料。 供應商支出、合約條款、各據點員工人數、系統庫存、事件歷史記錄。
- 負責人對照表。 誰能真正做決定，而不是誰回報了這個問題。
您還需要預先商定一個數字。那就是決定某個項目是否該納入風險登記表的影響門檻。如果沒有這個門檻，表格將會充斥著沒人會去處理的項目。
請將其設定為與您的曝險資料相同的單位。以年度支出表示的門檻是可驗證的；而以「重大」表示的門檻則會在每次審查時重新引發爭論。
如何手動建立風險登記表
選項 1：試算表中的單一表格
每個風險佔用一行，並以可能性和影響作為欄位。這幾乎是所有登記表的起點，對於小型團隊來說已經足夠了。
代價是維護成本。每一行都需要手動輸入，而且在產出該登記表的研討會結束後的一週內，登記表就會過期。
選項 2：為風險評分並排序
為可能性和影響分別評分，將兩者相乘，然後進行排序。現在表格有了順序，這是讓它在會議中發揮作用的第一步。
難點在於一致性。兩個人在相隔一個月後對同一個風險進行評分會產生分歧，而試算表中沒有任何機制可以發現這一點。
選項 3：將評分建立在您自己的資料基礎上
這是經得起質疑的版本。您不需要憑記憶對供應商風險進行評分，而是提取真實的數據。年度支出、合約通知期以及有多少團隊依賴該供應商，共同決定了影響評等。
FEMA 的 Ready.gov 指南在實體風險方面也指向了相同的方向。其 風險評估頁面 建議企業「尋找可能使您的企業更容易受到危害損害的脆弱性或弱點」。該指南指出，這些弱點「會在事件發生時加劇損害的嚴重程度」。
同一頁面還從投資的角度建構了應對措施。影響「可以透過投資於緩解措施來減輕」。在潛在影響重大的情況下，制定緩解策略「應該是高度優先的事項」。
這是正確的方法，但也是緩慢的方法。每個風險都意味著需要重新查看不同的匯出資料。
如何使用 AI 建立風險登記表
步驟 1：上傳描述您曝險情況的匯出資料
開啟 Powerdrill Bloom 並上傳您擁有的資料：供應商支出匯出資料、合約清單、系統庫存、過去的事件記錄。請將它們一起上傳，而不是一次上傳一個。
然後用自然語言描述您的範圍。說明該登記表涵蓋業務的哪個部分、您的影響門檻是多少，以及您使用什麼標準進行評分。
步驟 2：要求提供每個風險的曝險數據，而不是評等
要求提供一個表格，每個候選風險佔用一行，並包含決定評分的數據。例如年度支出、依賴該供應商的團隊數量、通知期以及過去一年的事件數量。
要求提供每個數據的來源。平台會返回有依據的答案，並附帶每個數字背後的頁碼和行數。在風險登記表中，這種可追溯性決定了您的評分是經得起考驗還是漏洞百出。
根據這些數據自己進行評分。判斷是應該由人類保留的部分。
步驟 3：加入您的決策並匯出
針對每一行記錄決策：接受、緩解、轉移或規避。如果決策是緩解，請加入計劃採取的行動、負責人和審查日期。
然後匯出該表格，並按評分排序。保留曝險數據欄位，不要刪除它們。下個季度的審查將從這些數字是否發生變化開始。
如果登記表成為一項例行交付成果，每個方案中都列有排程任務，其中 Free 方案提供 1 個，Pro 及以上方案提供 20 個。每季更新一次適合大多數團隊。
每一行應該包含什麼
| 欄位 | 為什麼它佔有一席之地 |
|---|---|
| 風險描述 | 以因果關係撰寫，而非僅僅是一個主題 |
| 可能性 | 佔評分的一半，也是人們憑空猜測的一半 |
| 影響 | 應該可以追溯到真實的數據 |
| 曝險數據 | 影響評等所依據的數字 |
| 決策 | 接受、緩解、轉移或規避 |
| 緩解措施與負責人 | 只有指定單一負責人時才有意義 |
| 審查日期 | 如果沒有它，登記表會在不知不覺中過期 |
曝險數據欄位是大多數範本都會忽略的。保留它可以將主觀的評等轉化為下一個審查者可以驗證的內容。
最佳實踐與常見錯誤
同時記錄已接受的風險。 僅包含未解決項目的登記表只是一份任務清單。當日後有人詢問是否有人考慮過某個風險時，已接受的條目就是您的保護傘。
將風險寫成因果關係。 「供應商集中度」只是一個主題。「我們的計費依賴於一家有 90 天通知期的供應商」才是一個您可以評分的風險。
將影響與數字連結。 即使是粗略的數字也比憑空捏造的評等要好，而且這能讓下一次審查變成對比，而不是重新爭論。
為每一行指定一位負責人。 共同承擔風險通常意味著沒人去審查它，而負責人應該是能夠授權執行緩解措施的人。
按行設定審查日期，而不是按登記表設定。 供應商風險和法規風險的變化週期不同，單一的季度全面審查會將它們混為一談。
將其與供應商績效分開。 它們使用重疊的匯出資料，但回答不同的問題。根據交付和品質對供應商進行評估屬於我們關於 供應商計分卡 的指南內容；而登記表則是關於如果該供應商失敗會發生什麼事。
統一界定您的術語。 可能性區間和影響層級對每個評分人員來說應該代表相同的含義。這與我們在建立 資料字典 的逐步教學中所涵蓋的原則相同。如果輸出結果成為常設文件，AI 報告產生器 頁面展示了其具體形式。
結論
風險登記表之所以有價值，是因為它將零散的擔憂轉化為決策記錄，包括接受某事並繼續前進的決策。難點從來不在於表格的版面配置，而是在於將每個影響評等建立在數字而非感覺之上。
從您現有的匯出資料中建立風險登記表，並在評分旁邊保持曝險數據可見。為每一行指定負責人和審查日期。
已經有供應商和事件匯出資料了嗎？立即試用 Powerdrill Bloom，並在本週建立您的第一個版本。
常見問題
什麼是風險登記表？
NIST 的詞彙表將其描述為風險資訊的儲存庫，涵蓋隨著時間推移對風險所了解的內容。在實務上，它是一個記錄每個風險、其評等、負責人以及對其所做決策的表格。
風險登記表應該包含哪些欄位？
最起碼要包含：以因果關係撰寫的風險、可能性、影響，以及影響評等背後的數據。然後是決策、緩解措施及其負責人，以及審查日期。
已接受的風險應該保留在登記表中嗎？
是的。NIST 的定義將當前風險視為既包括已接受的風險，也包括有計劃緩解路徑的風險。移除已接受的項目會遺失該決策的記錄。
應該多久審查一次？
請按行設定審查日期，而不是針對整個文件，因為不同類別的風險在不同的時間尺度上發生變化。對評分最高的行進行季度審查適合大多數團隊。
這與風險評估相同嗎？
不同。Ready.gov 將風險評估描述為識別危害並分析可能發生之情況的過程。而登記表則是記錄結果和決策的產物。