BCP（營運持續計畫）不是只寫「主機故障時切備援」。 真正應先問的是：哪個業務流程停多久會傷到公司、顧客與合約？
BIA（業務衝擊分析）、BCP、DR（災難復原）三個名詞常一起出現，但各自回答不同問題。
| 名詞 | 主要問題 | 交付成果 |
|---|---|---|
| BIA（Business Impact Analysis） | 哪項業務中斷，何時開始不可接受？ | 重要流程、依賴、衝擊與復原目標 |
| BCP（Business Continuity Plan） | 事件發生後如何讓關鍵業務持續運作？ | 人員、替代流程、對外溝通與演練 |
| DR（Disaster Recovery） | IT 系統和資料如何恢復？ | 備份、切換、還原步驟與驗證 |
電商不只看網站有沒有活著
假設購物車網站可以正常下單，但物流 API 失效 18 小時，ERP 未同步新訂單。這時網站「在線」，客訴與營運風險卻可能持續累積。
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 與改善追蹤的實例。