當我們把 Risk Register 建立好、指標也在 Dashboard 上盯著，最不希望發生的事往往還是會發生—->事故（Incident）來了。

很多從 IT 或純技術資安背景，看到「事故應變（Incident Response, IR）」和「營運持續規劃（BCP）」，第一反應都是：「這我知道啊！就是 Log 排查與鑑識、系統失效( Failover) 切換、Log跟災害演練嘛，這我們組織很常定期在作」。

但ISACA CRISC 看待事故和 BCP 的視角，跟工程師救火完全是兩回事。
工程師關注的是「怎麼把系統盡快恢復起來、暫時性措施趕快執行，如：把封包擋掉或異常來源的IP鎖掉」；而 ISACA CRISC關注的是：「這個業務中斷，有沒有超過組織可以承受的底線？」

這就是為什麼在 CRISC 的知識體系中，BIA（業務衝擊分析, Business Impact Analysis）永遠是 BCP 的起手式，您必須先跟業務單位討論出兩個核心指標：
1.RTO（復原時間目標）：系統最多能停多久？
2.RPO（復原點目標）：資料最多可以遺失多久時間？

如果不知道業務能忍受多久，技術團隊花大錢建了 5 分鐘內切換的高可用性（HA）機制，結果那個系統其實停機 2、3 天也不影響公司營運，從風險管理的角度來看，這就是典型的「過度控制（Over-control）與資源浪費」。
另外一個管理與實務一樣都很容易踩坑的點是「演練（Exercise）」。

大家在實務工作上做 DRP 演練，最怕動到正式的生產環境，但又怕被稽核要求要有驗證紀錄。故ISACA CRISC同ISC2知識體系同，都很喜歡詢問不同演練類型的適用時機：

1. 想用最小代價、讓高層和各單位熟悉應變流程？可考慮 Tabletop Exercise（桌上演練/沙盤推演）。
2. 想驗證備份資料能不能真的還原？可能可以考慮 Parallel Test（平行測試）。
3. 只有在極度確定且風險可控的情況下，才會做到 「全面中斷測試」。

在ISACA CRISC 的邏輯裡，一場好的演練，重點永遠不是「有沒有完美完成演練工作」，而是「有沒有找出原先 BCP 計劃裡的漏洞與盲點」。

實務上，IR事故應變與 BCP企業持續演練永遠都不是 IT 部門的獨角戲，它是一場以「業務是否能持續營運」為目標的跨部門協同。把技術資源精準投資在業務最痛的地方，才是風險管理的精髓。

最後，走過了風險識別、評估、應變到監控，整套 CRISC 的知識體系已經大致拼湊完整了。