災難復原流程圖（IT 系統）
IT 災難復原流程的泳道圖：啟動準則、按 RTO 與 RPO 排定優先次序、切換、資料還原、驗證，以及回切至正常運作。
運作方式
把泳道改成你們真實擁有的角色
把偵測／營運、災難復原統籌、管理層、基礎設施團隊和應用系統負責人換成你們真實的角色：網絡營運中心或監察團隊、IT 服務持續運作經理、危機當值表上的高層、平台與資料庫團隊、具名的服務負責人。規模較細的機構常把統籌和基礎設施兩條泳道合併；如果一條泳道裏沒有人，就刪掉它，而不是留着一條無人承擔的泳道。
把你們的啟動準則寫到決策上
令「是否符合災難復原啟動準則？」客觀到有人能在壓力之下直接套用：主場地無法進入、預計中斷時間超過某個一級系統的 RTO、主儲存或資料庫在原地無法還原。寫明獲授權啟動的角色和一位替補，並記錄在工作時間以外如何聯絡到他們。
為每個系統附上真實的 RTO 與 RPO 數值
這些目標應取自業務影響分析，而不是取自基礎設施目前做得到的水平，並按層級列在「按 RTO 與 RPO 排定系統優先次序」旁邊。除了優先次序，亦要記錄依賴次序，因為一個一級應用系統在它下面的身分、網絡和資料庫服務起來之前，根本無法驗證。
寫清楚你們真實的復原機制
對複製式基礎設施、暖備站點、第二個雲端區域和由備份媒體重建來說，「切換到復原站點」的含義各不相同。把機制、操作手冊連結、憑證與緊急存取帳戶的存放位置，以及任何需要人手執行的 DNS 或網絡變更寫進方格註釋，令這張圖在復原過程中亦用得着，而不只是在檢討時才拿出來看。
定義「完整性已驗證」是甚麼意思，以及由誰判定
把「資料完整性是否已驗證？」背後的檢查項定下來：紀錄條數、一致性與參照完整性檢查、應用層冒煙測試、與最後一個已知良好狀態的比對。決定「較早的副本」指的是甚麼、在升級呈報之前你們嘗試幾次還原，並註明每向回退一步，你們最終要按 RPO 申報的資料流失量就會增加。
補上回切，然後演練這張圖並保留版本
確認回切路徑與你們的實際做法一致：時間窗口、由復原站點回同步資料、變更控制審批，以及正式解除災難復原狀態的時點。然後演練這張圖，在事後檢討中把你們實際達成的復原時間和資料流失量與目標對照，並發布獲批版本，令大家演練的修訂版就是他們在真實事件中會遵循的那一版。
常見問題
災難復原和業務持續運作有甚麼分別？
業務持續運作關注的是在中斷期間用一切可用手段令機構繼續交付產品與服務：人手替代方案、備用場地、人員調配、備用供應商、客戶溝通。災難復原是當中的 IT 部分：恢復機構賴以運作的系統、資料和基礎設施。優先次序由持續運作工作設定，因為業務影響分析決定哪些活動最重要、以及它們最長能中斷多久；災難復原把這些時限承接為 RTO 與 RPO 目標並去達成。沒有持續運作輸入的災難復原計劃，往往會先復原最容易復原的東西。
RTO 和 RPO 到底是甚麼意思？
RTO，即復原時間目標，是一個系統或服務必須重新可用的目標時間，由中斷發生起向前計算，而不是由有人簽署啟動表格的那一刻起計。RPO，即復原點目標，是資料必須被還原到的那個時間點，由中斷向回計算，因此實際上它就是機構願意接受的最大資料流失量。兩者驅動的投入並不相同：RTO 取決於你們把基礎設施拉起來的速度（備用容量、自動化、演練），而 RPO 受限於資料被複製出去的頻率，因此無論還原跑得多快，每晚一次的備份都支撐不了短於約一日的 RPO。這兩個術語在 ISO 22301 等業務持續運作標準中都有定義。
災難復原的啟動應由誰批准，甚麼時候批准？
啟動權應當落在能夠承擔切換成本與風險的角色上，通常是一位高層或危機負責人，並配一位具名替補和一條成文的非工作時間聯絡路徑。本圖刻意把它與災難復原統籌的角色分開：統籌評估並提出建議，管理層批准，然後由統籌執行復原。觸發條件應當事先寫好，並且能夠用中斷早期就拿得到的事實來檢驗，因為代價高昂的錯誤不是啟動得太早，而是在 RTO 時鐘一直在行的時候，花三個小時討論今次算不算。
如果還原出來的資料通不過完整性校驗會怎樣？
本圖選擇形成迴路，而不是硬着頭皮往前推：「資料完整性是否已驗證？」的失敗分支通向「由較早的副本還原」，再回到還原步驟，於是驗證會重新執行一次。這個迴路正是 RPO 在真實條件下受到檢驗的地方，因為每向回退到一個更舊的副本，你們最終要申報的資料流失量就更大；到了某個程度，誠實的答案是目標無法達成，業務方需要被告知他們必須人手重建哪一段時間的資料。值得事先議定的是：你們嘗試幾次、誰有權接受比 RPO 更差的復原點，以及這個落差如何記錄。
災難復原流程應該多久測試一次？
頻率要足以令計劃反映當前的環境，而且結果要寫下來。大多數機構採用組合做法：對備份做頻密的還原校驗，全年做若干次組件級或部分切換測試，並按固定週期做一次更完整的演練，通常是一年一次，受監管行業和關鍵服務會被期望做得更多。比間隔更重要的是測試了甚麼。一份從未真正掛載並讀取過的備份甚麼也證明不了；而一次略過驗證與回切步驟的演練，往往會掩蓋真實事件中最傷的那兩個問題：應用系統負責人發現了無人預料到的故障，以及沒有議定好回到主場地的路徑。