風險接受決策流程圖
風險接受決策流程圖：是否已評估應對方案、剩餘風險是否在風險胃納之內、誰有權簽署，以及這項接受何時屆滿。
甚麼是風險接受決策流程
接受是那種既不需要預算、亦不需要專案、更不需要誰去做任何事的風險應對方式——正因如此，它亦是各機構最容易在不知不覺間落入的一種。一條風險躺在登記冊裡，控制措施始終沒有獲得撥款，兩輪檢視之後，這個條目就被描述成「已接受」，儘管無人作過任何決定，亦沒有任何人的名字寫在上面。把接受畫成一棵決策樹，正是把「有人選擇去承擔的風險」與「所有人都不再看的風險」區分開來的辦法。
本頁是一棵決策樹，而不是一張流程圖。它只回答一個問題——這項剩餘風險是否應該被接受，以及誰有權接受它——辦法是按次序走完各道檢驗，最終抵達五個具名結果中的一個，而不是把所有分支重新收攏到一條順利路徑上。它並不描述外圍那個循環。識別、評分、控制措施成效以及檢視閉環屬於風險評估流程圖，那是一張說明「接下來發生甚麼、由誰來做」的跨職能流程圖。程序層面的文件用那一張；本圖用於其中那個需要在兩個選項之間作出判斷、並且需要有人簽署的時刻。
左側四條泳道命名的是誰來回答每個問題，而不是誰來做事：風險負責人、風險管理主管、法律與合規，以及接受風險的審批方。這棵樹有兩處刻意不留餘地。違反法定、監管或合約責任的風險根本不會走到審批方那裡，因為不合規不是機構可以自行接受的，它直接出口到整改。而超出胃納的剩餘風險不可以被永久接受：它需要一項補償性控制和一個屆滿日期，並作為由風險委員會批准的限時例外來承擔，而不是一簽了之。審核員要找的正是這兩條分支。
本流程圖涵蓋的內容
本範本包含
- 四條決策權泳道——風險負責人、風險管理主管、法律與合規、接受風險的審批方——鋪在五個階段上：提案、應對檢驗、適用性檢驗、附加條件，以及審批與紀錄。
- 在接受被擺上檯面之前的兩道關卡：「是否已評估應對方案？」把沒有依據的提案退回「補做應對方案分析」，而「應對是否可行而且合乎比例？」在「是」那一側直接出口到「採取應對而非接受」。
- 法律與合規泳道中的「是否違反法定或合約責任？」，其「是」分支通向「拒絕接受並整改」——這是全圖唯一一種從不送交審批方的風險暴露。
- 「剩餘風險是否在風險胃納之內？」分為「之內」與「超出」。之內繼續走向附加條件與權限的檢驗；超出則進入「是否已有補償性控制？」，要麼徹底拒絕接受，要麼經由「確認控制措施並設定屆滿日期」建立一個限時例外。
- 簽署權由級別決定，而不是由誰有空決定：「剩餘風險屬哪一級別？」把「低／中」送往「該經理是否持有授權權限？」，把「高／嚴重」送往「風險委員會是否接受該剩餘風險？」，因此「在經理層級接受」與「在高層層級接受」是兩個各自獨立的終點。
- 「接受是否設定限期與重估日期？」帶一條「否」分支，在任何人簽署之前先設定屆滿日期；全圖共有五個終止點：採取應對而非接受、拒絕接受並整改、在經理層級接受、在高層層級接受，以及暫時接受至屆滿日期。
何時使用本範本
- 你們正在編寫風險政策中關於接受或例外的條款，需要把各道檢驗寫下來，而不是用散文描述。
- 你們的風險登記冊裡有一些標著「已接受」的條目，既沒有簽署人，亦沒有附加條件和屆滿日期，你們需要令接受成為一個動作，而不是一種預設狀態。
- 你們正在訂定風險接受的授權分級，希望在下一次為「誰來簽署」爭論之前，把每一個級別都綁定到一個具名層級。
- 審核員或認證機構問起某項剩餘風險是誰接受的、依據是甚麼——例如 ISO/IEC 27001 就要求風險負責人批准應對計劃並接受剩餘的資訊保安風險。
- 某個團隊申請一項保安或政策例外，你們需要一套可重複的檢驗，帶附加條件和屆滿日期，而不是一次次逐案商議。
運作方式
把泳道改成你們的決策權
把風險負責人、風險管理主管、法律與合規以及接受風險的審批方，換成你們真正擁有的角色。令風險負責人與風險管理主管保持分開：一個承擔後果，另一個負責方法，而後者不應該是簽署的那個人。如果你們的高層團隊和風險委員會是同一個會議，就把它們合併成一個審批方，而不是畫一次從不發生的交接。
把你們的胃納門檻寫到胃納檢驗上
「剩餘風險是否在風險胃納之內？」是全圖的樞紐，所以要把風險政策裡的門檻寫在它旁邊——評分區間，或者用平實的話寫明機構在金額、停機時間、傷害或聲譽上願意與不願意承擔甚麼。只活在政策文件裡的胃納，只能憑記憶去估量，而這正是同一種風險暴露在一個人的枱上算「之內」、在另一個人的枱上算「超出」的原因。
把級別對應到具名的接受權限
把「低／中」和「高／嚴重」換成你們自己的評分區間，並寫明每一級由誰簽署。有兩條規則可以令這條分支保持誠實：當一項接受正是為某人自己的專案放行時，此人不得為自己承擔的事項簽署；以及經理那一支要明確檢查授權權限，而不是假定資歷自帶權限。任何超出該經理權限上限的都走向委員會——「該經理是否持有授權權限？」存在的意義正在於此。
定義甚麼才算補償性控制
在超出胃納那條分支上，補償性控制是橫在例外與拒絕之間的唯一一樣東西，所以要把檢驗寫清楚。它必須是已經在運作的，而不是計劃中的；必須有證據，而不是口頭聲稱；而且必須減少的正是這項風險暴露，而不是它旁邊的另一項。監察只有在有人被要求就它報出的情況採取行動時才算數。
為接受期限設上限，並寫明屆滿後會怎樣
為期限設一個上限，而不是交給提案人自行決定——常見做法是不長於下一次既定檢視，對高級別風險則更短——並加上事件觸發條件，例如一宗事故、一次系統變更、一份新合約，或者控制措施本身出現變化。寫明屆滿後接受即告失效，風險重新進入本樹，因為一項默默續期的接受，不過是一項貼了日期的無限期接受。
把決定記入登記冊，並只保留一個當前版本
這棵樹的產出是一條紀錄：誰接受、在哪一級別、依據哪一項授權權限，附加條件與補償性控制，屆滿日期與重估日期，以及那份論證「接受而非應對」的應對方案比較。把畫好的圖與風險、法律以及簽署的人一同走一遍，改成他們實際在做的樣子，然後發佈那一版，並保留此前的各版，好讓日後打開它的人知道自己讀的是哪一版。
常見問題
甚麼是風險接受？
風險接受，是在知情的前提下選擇保留一項剩餘風險，而不是降低、轉移或迴避它。ISO 31000 把「經知情決定而保留風險」列在應對方案之中，而要抓緊的正是「知情決定」這個詞：接受一項風險與無視一項風險的分別，在於有一位具名的、有權承擔它的人，有一份關於決定當時已知情況的紀錄，以及附加在這項接受上的條件。當應對方案已經計過成本並被判定與風險暴露不成比例時，接受是正當的。而當無人為控制措施撥款時，接受就不是正當的——這亦正是本圖頭兩道決策要在考慮接受之前先檢驗應對方案分析的原因。
誰應該有權接受一項風險？
對後果負責的那個人，而且層級要與風險級別相符。大部分機構把這寫進一份授權表：低與中級別由直線經理或部門經理簽，高與嚴重級別由高層負責人或風險委員會簽。有兩項保障比「界線畫在哪裡」更重要。本圖明確檢查授權權限——「該經理是否持有授權權限？」——而不是假定資歷自帶權限；任何超出上限的都升級處理，而不是在本地簽掉。另外，接受風險的審批方不應該是這項接受對其有利的那個人：如果這項接受正是為某人的專案或預算放行，那麼這個決定應該上移一級。
可以接受一項違反法律、法規或合約的風險嗎？
不可以。機構無法決定自己不合規，因此對法定、監管或合約責任的已知違反要走整改而不是接受，而在本圖中，那條分支根本到不了審批方，它出口到「拒絕接受並整改」。可以正當地設定時限的，是整改期間的過渡性風險暴露：一份有負責人和日期的計劃，向需要知情的人作的呈報，以及在適用之處就披露或申報責任徵詢的法律意見。把它記成一項已接受的風險，才是審核員和監管機構反應很差的那個版本，因為它記錄下來的是一個「決定承擔一項違規」的決定。
風險接受應該設屆滿日期嗎？
應該。一項接受，是對某一日的風險暴露、控制措施和應對成本所作的判斷——而這三樣都會漂移。為每一項接受設定限期和重估日期，把上限寫進政策而不是交給提案人，並令級別越高、限期越短。明確寫出屆滿後會發生甚麼：接受失效，風險回到這棵決策樹重新取得一個答案，而不是點一點頭就續下去。在日期之外再加上事件觸發條件——一宗事故、一次系統或供應商變更、一份新合約，或者補償性控制被更改或撤除——因為它們比日曆更早告訴你們，這個判斷已經過時。
這與風險評估流程圖有甚麼分別？
它們回答的是不同的問題。風險評估流程圖是一張跨職能流程圖：它展示接下來發生甚麼、由誰來做，由識別到評分、控制措施成效、應對，一直到檢視周期。本頁則是這個流程內部某一個時刻的決策樹——在那一刻，應對已經計過成本，有人必須在應對與接受之間作出選擇。這裡沒有要交接的任務，只有需要憑證據回答的檢驗，而且它止於五個各不相同的結果，而不是一份結案紀錄。如果你們要寫的是程序文件，就用風險評估流程範本。如果你們要了結的是「誰可以接受甚麼、在甚麼條件下、到甚麼時候為止」，就用本頁這一張。