在資安工作中，我們應該都遇過這種情境：

「這台主機的漏洞為什麼還沒修？」
「因為是一線核心系統不能停。」
「那什麼時候可以修？」
「等廠商處理或適當時間，再安排該漏洞修補。」

講到這裡，很多時候就會變成一句：「那就先申請例外吧！」
但問題來了，資安例外真的只是「先放著不管」或「例外不管理」嗎？

如果從 ISACA 的 CRISC（Certified in Risk and Information Systems Control）角度來看，答案當然不是。
目前 CRISC 的 Domain 3「Risk Response and Reporting」佔整體考試比重 32%，其中就明確包含「Issues, Findings, Exceptions and Exemptions Management」。換句話說，例外管理並不是行政作業，而是 IT 風險管理的一環。

一、那為什麼會需要「例外管理」？
實務上，不是所有資安控制都可以百分之百做到。
例如：組織規定 Critical Vulnerability 必須在 30 天內完成修補，但某個組織核心系統因為版本老舊、廠商尚未提供修補程式，或系統更新可能影響重要業務，因此無法在期限內完成。

這時候，真正專業的做法不是「不修了」，而是建立正式的 Exception Management。也就是把問題攤開來看：

1.為什麼不能符合要求？
2.不符合要求會產生什麼風險？
3.誰負責這個風險？
4.在正式修復之前，有沒有其他補償性控制措施可以降低風險？

這才是 CRISC 所強調的風險思維。

二、例外不是免責，而是風險正式化
Exception Management 可以簡單記成六個字詞：

原因、風險、責任、控制、核准、期限。

首先，要向長官說明為什麼需要例外；接著進行風險評估，確認這個例外到底造成多大的風險。
再來要指定 Risk Owner，不能發生「大家都知道有問題，但沒有人負責」的情況。

如果原本的控制暫時做不到，就要思考補償性措施(Compensating Control)，例如 IPS、Firewall、WAF、MFA、網路隔離、加強監控等方式，先把風險降下來。
最後還要有適當層級的核准流程，以及最重要的——到期日(何時日期到期，要進行處理)。

因為沒有期限的例外，很容易最後就變成「永久例外」。

三、例外管理最重要的，其實是 Residual Risk
原本要處理的該風險可能是 High，透過 IPS、Firewall、WAF、隔離及監控後，也許降低成 Medium。

這時候真正要管理的是：
Residual Risk（剩餘風險）是否仍在組織可以接受的 Risk Appetite / Risk Tolerance 範圍內？
如果超過組織可以接受的程度，就不能只是「核淮簽核完畢」，而應該重新思考風險處理方式。
這也是 CRISC 很重要的一個核心觀念：不是追求零風險，而是在組織可以接受的範圍內管理風險。其實這也是蠻多長官的誤區，覺得風險可以控制到「零風險」或「沒有風險」來對下屬要求。

四、最後一定要「關閉」例外
一個完整的 Exception，不應該只有「申請」和「核准」。
應該還包含後續追蹤：

1.原始問題什麼時候解決？
2.誰負責？
3.預計完成日期？
4.是否需要重新評估風險？
5.補償性控制措施是否仍然有效？

最後，上述條件都滿足完成後，才能正式關閉該例外 (Close Exception)。
所以如果要用一句話來總結 CRISC 的 Exception Management，可以說：

例外不是讓問題暫時消失，而是把原本無法立即解決的問題，轉換成一個可以被評估、被負責、被監控，而且最終必須被關閉的風險。

這也是CRISC 很值得學習的地方。

它不是教你把所有風險都消除，而是教你面對「現實上做不到」的情況時，如何用風險管理的方式，把事情繼續往前推。