業務連續性計劃

業務連續性計劃 (BCP) 方法用於制定計劃，使組織能夠在某種中斷其正常運營的情況下繼續運營。該方法需要能夠擴充套件到任何規模和複雜程度的組織。儘管該方法起源於受監管行業，但任何型別的組織都可以建立 BCP 手冊，而且可以說，每個組織都應該擁有一個 BCP 手冊，以確保組織的長期生存。災難生存統計資料表明，公司沒有投入足夠的時間和資源來進行 BCP 準備。火災導致 44% 的受影響企業永久關閉。在 1993 年世貿中心爆炸事件中，受影響的 350 家企業中有 150 家未能倖存下來。相反，在 911 襲擊中受影響的擁有完善且經過測試的 BCP 手冊的公司在幾天內就恢復了營業。

小型組織的 BCP 手冊可能只是一個印刷手冊，安全地存放在主要工作場所之外，其中包含危機管理人員、一般員工、客戶和供應商的姓名、地址和電話號碼，以及異地資料備份儲存介質的位置、保險合同副本和其他對組織生存至關重要的材料。

BCP 手冊最複雜的版本可能概述了一個輔助工作場所、技術要求和準備情況、監管報告要求、工作恢復措施、重新建立物理記錄的方法、建立新的供應鏈的方法或建立新的生產中心的方法。公司應確保其 BCP 手冊在危機期間切合實際且易於使用。因此，BCP 與危機管理和災難恢復計劃並存，是組織整體風險管理的一部分。

BCP 手冊的開發包含五個主要階段：分析、解決方案設計、實施、測試和組織接受以及維護。

BCP 手冊開發中的分析階段包括影響分析、威脅分析和影響場景，以及由此產生的 BCP 計劃需求文件。

影響分析

影響分析會區分組織的關鍵職能和非關鍵職能。如果由於組織受到損害而導致利益相關者的影響被認為不可接受，則該職能可能被視為關鍵職能。建立和維護適當的業務或技術恢復解決方案的成本可能會改變對中斷可接受性的看法。如果法律規定，該職能也可能被視為關鍵職能。接下來，影響分析會得出每個關鍵職能的恢復要求。恢復要求包含以下資訊

災難發生後必須恢復關鍵職能的時間範圍
恢復關鍵職能的業務需求，或
恢復關鍵職能的技術需求

威脅分析

在定義恢復需求後，建議記錄潛在威脅，以詳細說明特定災難的獨特恢復步驟。一些常見的威脅包括以下內容

自然災害（例如地震、颶風、洪水、火災）
疾病
駭客攻擊
停電
恐怖主義

上面示例中的所有威脅都具有共同的影響 - 損害組織基礎設施的可能性 - 只有一個例外，即疾病。疾病的影響最初純粹是人性的，可以透過技術和業務解決方案緩解。在 2002-2003 年非典爆發期間，一些組織將員工分成不同的團隊，並在主要工作場所和輔助工作場所之間輪換團隊，輪換頻率等於疾病的潛伏期。

這些組織還禁止在工作時間和非工作時間內不同團隊成員之間的面對面接觸。透過這種分離，組織提高了對政府下令隔離措施的抵禦能力，即使團隊中有一人感染或接觸到該疾病。

洪水造成的損害也具有獨特的特徵。如果辦公環境被非鹽水和無汙染的水淹沒（例如，管道破裂），裝置可以徹底乾燥，並且可能仍然可以使用。

影響場景定義

在定義潛在威脅後，建議記錄構成業務恢復計劃基礎的影響場景。通常，為最廣泛的災難或干擾制定計劃優於為較小規模的問題制定計劃，因為幾乎所有較小規模的問題都是較大災難的一部分。像“建築物損失”這樣的典型影響場景很可能包含所有關鍵業務職能，以及任何潛在威脅的最壞結果。如果組織擁有不止一棟建築，業務連續性計劃還可以記錄其他影響場景。還可以記錄其他更具體的影響場景 - 例如，某棟建築物中特定樓層暫時或永久損失的場景。

恢復需求文件

分析階段完成後，會記錄業務和技術計劃需求，以便開始實施階段。對於以辦公室為基礎、資訊科技密集型的企業，計劃需求可能涵蓋以下元素，這些元素可以歸類為 ICE（緊急情況下）資料

在輔助場所中，在主要業務場所之外所需的辦公桌數量和型別，無論是否專用或共享
參與恢復工作的人員以及他們的聯絡方式和技術資訊
輔助場所辦公桌所需的關鍵業務職能的應用程式和應用程式資料
手動解決方法
應用程式允許的最大停機時間
外圍需求，如計算機印表機、影印機、傳真機、計算器、紙張、筆等

其他業務環境，如生產、分銷、倉儲等，將需要涵蓋這些元素，但可能需要在破壞性事件發生後管理其他問題。

解決方案設計

解決方案設計階段的目標是確定最具成本效益的災難恢復解決方案，以滿足影響分析階段的兩個主要要求。對於 IT 應用程式，這通常表示為

最低應用程式和應用程式資料要求
必須提供最低應用程式和應用程式資料的時間範圍

除了 IT 應用程式領域之外，可能還需要災難恢復計劃，例如，以硬複製格式儲存資訊或恢復過程工廠中的嵌入式技術。此 BCP 階段與災難恢復計劃方法重疊。解決方案階段確定

危機管理指揮結構
輔助工作場所的位置（如有必要）
主要工作場所和輔助工作場所之間的電信架構
主要工作場所和輔助工作場所之間的資料複製方法
輔助工作場所所需的應用程式和軟體，以及
輔助工作場所所需的物理資料型別。

實施

實施階段簡單來說就是執行在解決方案設計階段確定的設計元素。工作包測試可能會在解決方案實施期間進行，但是工作包測試不能替代組織測試。

測試和組織接受

測試的目的是為了讓組織接受業務連續性解決方案能夠滿足組織的恢復要求。計劃可能由於恢復要求不足或不準確、解決方案設計缺陷或解決方案實施錯誤而無法達到預期。測試可能包括

危機指揮團隊召集測試
從主要工作地點到次要工作地點的技術切換測試
從次要工作地點到主要工作地點的技術切換測試
應用程式測試
業務流程測試

至少，測試通常按半年或年度計劃進行。在初始測試階段發現的問題可能會彙總到維護階段，並在下一個測試周期中重新測試。

維護

BCP手冊的維護分為三個定期活動。第一個活動是確認手冊中的資訊。第二個活動是測試和驗證為恢復操作建立的技術解決方案。第三個活動是測試和驗證記錄的組織恢復程式。半年或年度維護週期是典型的。

資訊更新和測試

所有組織都會隨著時間的推移而發生變化，因此BCP手冊必須發生變化以保持與組織的相關性。一旦資料準確性得到驗證，通常會進行呼叫樹測試以評估通知計劃的效率以及聯絡資料的準確性。手冊中應識別和更新的一些變化型別包括

人員變動
人員角色
重要客戶及其聯絡方式的變更
重要供應商/供貨商及其聯絡方式的變更
部門變動，如新部門、關閉的部門或發生根本性變化的部門。

測試和驗證技術解決方案

作為持續維護的一部分，必須檢查任何專門的技術部署的功能。一些檢查包括

計算機病毒定義分發
應用程式安全和服務補丁分發
硬體可操作性檢查
應用程式可操作性檢查
資料驗證

測試和驗證組織恢復程式

隨著工作流程的不斷變化，以前記錄的組織恢復程式可能不再適用。一些檢查包括

所有關鍵功能的工作流程是否都已記錄？
執行關鍵功能所使用的系統是否發生了變化？
記錄的工作清單對員工來說是否有意義和準確？
記錄的工作流程恢復任務和支援的災難恢復基礎設施是否允許員工在預定的恢復時間目標內恢復？

處理測試失敗

正如本文中包含的圖表所示，測試和維護階段與影響階段之間存在直接關係。從頭開始建立BCP手冊和恢復基礎設施時，測試階段發現的問題通常必須重新引入分析階段。