假設電商大促當天，網站不斷跳出新訂單，廣告平台的轉換數字也很好看。
倉庫卻打電話來：「今天怎麼完全沒有新單？」
行銷：「不可能，網站訂單一直在增加。」
資訊檢查後發現，購物車和金流都正常，只有 ERP 與物流的資料同步停了。網站仍然可以收錢，倉庫卻拿不到出貨資料；客服開始被問出貨時間，財務則擔心付款和訂單對不起來。
技術窗口說：「網站沒有當機。」
問題是，公司已經沒辦法正常做生意。
這就是企業為什麼不能把 BCP（營運持續計畫）當成一張「主機故障就切備援」的表格。要先弄清楚哪些業務流程不能停、停多久會造成不可接受的損失，才知道該先救哪個系統。
| 名詞 | 主要問題 | 交付成果 |
|---|---|---|
| BIA（Business Impact Analysis） | 哪項業務中斷，何時開始不可接受？ | 重要流程、依賴、衝擊與復原目標 |
| BCP（Business Continuity Plan） | 事件發生後如何讓關鍵業務持續運作？ | 人員、替代流程、對外溝通與演練 |
| DR（Disaster Recovery） | IT 系統和資料如何恢復？ | 備份、切換、還原步驟與驗證 |
電商不只看網站有沒有活著
假設購物車網站可以正常下單，但物流 API 失效 18 小時，ERP 未同步新訂單。這時網站「在線」，客訴與營運風險卻可能持續累積。
圖解：BIA 從業務中斷影響倒推所需復原能力
BIA 至少要拆清楚：訂單接收、付款確認、庫存扣減、出貨通知、物流交付和客服查單；找出每個流程依賴的系統、替代方案和容忍中斷時間。
RTO、RPO 怎麼用？
- RTO（Recovery Time Objective，復原時間目標）： 服務中斷後，計畫在多久內恢復到可接受狀態。
- RPO（Recovery Point Objective，復原點目標）： 事故後可接受損失多少時間範圍內的資料。
例如某項系統設定 RTO 為 4 小時、RPO 為 30 分鐘，不等於「承諾永遠 4 小時內恢復」。還要看實際架構、資源、備份測試與事故條件。
最容易忽略的三個依賴
- 第三方 API。 購物車或金流正常，不代表物流、簡訊、會員整合都正常。
- 人員和替代流程。 系統恢復前誰接單、誰通知客戶、誰審核資料重送？
- 資料一致性。 恢復後是否有重複扣款、漏單、錯誤庫存或會員名單版本衝突？
一次有意義的演練應記錄
情境、開始與結束時間、參與角色、切換步驟、實際達成的 RTO／RPO、失敗環節、改善負責人及複查日期。「今年已完成演練」只是描述活動，不是證明有效。
圖解：目標數字不等於實際可以做到的承諾
對規模較小的電商品牌，先把訂單、付款、物流與客服的關鍵依賴畫出來，通常比一開始採購昂貴的備援設備更有決策價值。
用一張表找出復原順序
| 中斷流程 | 後果開始惡化的條件 | 替代處置 | 需要先確認的依賴 |
|---|---|---|---|
| 付款回傳失敗 | 已付款卻無法確認訂單 | 暫停自動催款，保留交易待核對 | 金流交易序號、對帳與客服 |
| 出貨系統無法同步 | 訂單持續累積但庫存不一致 | 人工匯出待出貨清冊並控管版本 | ERP、倉儲、物流 |
| 客服平台停擺 | 大量消費者無法確認訂單 | 官網公告與替代聯繫窗口 | 客服權限、消息核准人 |
這是評估範例，不是對任何企業建議固定 RTO。復原優先序應以實際訂單量、合約、付款風險和對消費者的影響決定；且要定期測試備援流程能不能真的用。
資料來源：ISO 27001。BIA/BCP/DR 的目標與方法需按企業實際風險制定。
同主題延伸閱讀：ISO 27000 家族怎麼分？27001、27002、27005、27006 一張表看懂、ISO 27001 管理審查怎麼做？PDCA、KPI 與改善追蹤的實例。