业务连续性计划

业务连续性计划 (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手册和恢复基础设施时，测试阶段发现的问题通常必须重新引入分析阶段。