第二，风险管理应该识别残留风险，这正是应急计划必须存在的原因。因此，应急计划与评估和消减过程紧密相连。图2-1阐明了识别和实施安全控制、制定和维护应急计划、以及在事件发生后立即实施应急计划之间的关系。
为了有效确定IT系统在服务中断期间的特定风险，对IT系统环境的风险评估是必须的。完整的风险评估应该识别系统缺陷、威胁和现有控制手段并尽量确定风险的机率和威胁的影响。然后这些风险应该被评估并设定其风险等级（如高、中或低）。NIST特别报告书800-30《信息技术系统风险管理指南》提供了如何进行风险评估和确定适当的技术、管理和操作性安全控制的详细指导。
因为风险会随着时间变化并且在系统的发展中新的风险可能会替换老的风险，所以风险管理过程必须随之变化并且是动态的。负责IT应急计划的人必须知晓系统的风险并且能够判别现有的应急计划是够可以完全有效地处理残留风险。正如3.6节描述的那样，风险分布的漂移要求对应急计划进行不断地维护和测试，并且要定期检查。
2.2 计划类型
IT应急计划呈现了在紧急事件发生后为了维持和恢复关键的IT服务所进行的范围广泛的活动。IT应急计划适合于非常广泛的紧急事件准备环境，包括机构和业务处理连续性及恢复计划。最终，为了对影响机构IT系统、业务处理和设施的危害作出反应、恢复和保持连续性的活动，机构会应用一系列计划进行准备工作。因为在IT系统和其支持业务处理之间具有内在联系，所以应该在每个计划的制定和更新过程中进行协调以确保恢复策略及其支持资源不会互相抵消和进行重复劳动。
通常，对于IT应急计划及其相关计划的领域内没有普遍接受的定义。有时，这种情况会导致对于各种计划类型的实际范围和目的的混淆。为了对理解IT应急计划提供一个基础，本节确定了的几种其它计划类型并且描述了它们与IT应急计划相关的目的和范围。因为对于这些计划类型缺乏标准的定义，在某些情况下，机构实际制定的计划的范围和以下描述会有不同。但是本文在讨论这些计划时使用如下描述：
业务连续性计划(BCP) BCP关注在中断期间和之后维持机构的业务功能。业务功能的一个可能的例子是工资的支付处理或客户的信息处理。BCP可以专门为某个特定的业务处理编写也可以涉及到所有关键的业务处理。IT系统在BCP中被认为是对于业务处理的支持。在某些情况下，BCP可能没有涉及到对过程的长期恢复并使其回到正常运行状态，而只是包含过渡的业务连续性需求。灾难恢复计划、业务继续计划和场所紧急计划可以附加在BCP之后。在BCP中设定的职责和优先顺序应该和其在操作连续性计划（COOP）中的一致以消除可能的冲突。
业务恢复计划(BRP),也叫业务继续计划 BRP涉及到在紧急事件后对业务处理的恢复，但和BCP不同，它在整个紧急事件或中断过程中缺乏确保关键处理连续性的规程。BRP的制定应该与灾难恢复计划和BCP进行协调。BRP应该附加在BCP之后。
操作连续性计划(COOP) COOP 关注位于机构（通常是总部单位）备用站点的关键功能以及这些功能在回到正常操作状态之前最多30天的运行。由于COOP涉及到总部级的问题，它和BCP是互相独立制定和执行的。PDD
67《持久立宪政府和政府运行的连续性》要求对可行COOP能力的实现。FEMA做为联邦政府COOP的执行机构在FPC65《联邦执行部门的运行连续性》中提供了COOP的指导方针。COOP的标准要素包括职权条款、连续性的顺序和要害记录和数据库。由于COOP强调机构在备用站点恢复运行能力所以计划无需包括IT运行。另外，它不涉及到无需重新配置到备用站点的小型危害。但是COOP可以将BCP、BRP和灾难恢复计划做为附录。根据PDD-63《关键基础设施的保护》的要求，对于支持国家基础设施非常关键的系统的COOP计划将在2003年五月到位。
支持连续性计划／IT应急计划 OMB A-130规章的附录三要求制定和维护对于通用支持系统的支持连续性计划和重要应用的应急计划。本计划指南认为支持连续性计划和IT应急计划是同义词。因为每一个重要的应用和通用支持系统都要制定IT应急计划，在机构的BCP中可能会维护多个应急计划。
危机通信计划 机构应该在灾难之前做好其内部和外部通信规程的准备工作。危机通信计划通常由负责公共联络的机构制定。危机通信计划规程应该和所有其它计划协调以确保只有受到批准的内容公之于众。计划规程应该做为附录包含在BCP中。通信计划通常指定特定人员做为在灾难反应中回答公众问题的唯一发言人。它还可以包括向个人和公众散发状态报告的规程。计划中包括记者招待会的模板。附录D提供了危机通信计划及其信息资源的进一步讨论。
计算机事件响应计划 计算机事件响应计划建立处理针对机构IT系统攻击的规程。这些规程被设计用来协助安全人员对有害的计算机事件进行识别、消减并进行恢复，这些事件的例子包括对系统或数据的非法访问、拒绝服务攻击、或对硬件、软件、数据的非法更改（如有害逻辑：病毒、蠕虫或木马等）。本计划可以包含在BCP的附录中。
灾难恢复计划 (DRP) 正如其名字所表示的，DRP应用于重大的、通常是灾难性的、造成长时间无法访问正常设施的事件。通常，DRP指用于紧急事件后在备用站点恢复目标系统、应用或计算机设施运行的IT计划。DRP的范围可能和IT应急计划重叠，但是DRP的范围比较狭窄，它不涉及到无需重新配置的小型危害。根据机构的需要，可能会有多个DRP附加在BCP之后。
场所紧急计划 (OEP) OEP在发生有可能对人员的安全健康、环境或财产构成威胁的事件时，为设施中的人员提供反应规程。
OEP在设施级制定，与特定的地理位置和建筑结构有关。根据美国总务管理局（GSA）的OEP模板维护GSA所属设施的OEP计划。设施OEP可以附加在BCP之后，但是独立执行。有关人员安全和疏散方面的问题在附录D中讨论。
2.3 应急计划和系统开发生命周期
系统开发生命周期是指系统拥有者在系统的生命跨度内所进行活动的完整作用域。生命周期如图2-3描述的那样，起于项目初始止于系统废弃。
虽然应急计划是和发生在运行／维护阶段的活动有关，但是应急方法应该在计算机系统生命周期的所有阶段被识别和运用。这种方式降低了整个应急计划的成本；增强了应急功能并在应急计划实施时减小了对系统运行的影响。本节介绍了将应急策略融入整个SDLC过程中的通用方法。应急活动和策略的特别描述可参见第5节《应急计划的技术性考虑》。
初始阶段 在构思新的IT系统的时侯应该考虑应急计划需求。在初始阶段，根据相关的运行过程对系统需求进行辨别和匹配，初始的应急需求可能会显现出来。极高的系统可用性需求可能表明在备用站点需要冗余、实时镜像以及应将故障切换能力包括在系统设计中。同样，如果系统将运行于非常规环境下，如移动式应用或难以接近的位置，设计中还可能需要添加诸如远程诊断或自我修复功能等特性。在这个阶段，还应该根据所有其它现存系统和计划中的IT系统对新IT系统进行评估以确定恢复的适当优先顺序。此优先顺序将用于确定恢复多个IT系统时的顺序。
开发／获取阶段 当初始的概念演化为系统设计时，就可以将应急方案组合进来。同初始阶段一样，本阶段包含的应急方法应该反映系统和操作的需求。设计应该将冗余和健壮性直接包含在系统体系中以优化运行／维护阶段的可靠性、维护性和可用性。通过在初始设计中包含这些因素，可以降低成本并且有利于在运行／维护阶段对系统进行更新改造。如果多个应用运行于新的通用支持系统之上，应该对这些应用逐个设定优先级以便在执行恢复时选择适当的应急方法和顺序。这个阶段应该考虑的应急方法的例子包括冗余通信途径、减少单点故障、增强网络部件和接口的容错、具有适当后备电源的电源管理系统、负载均衡以及数据镜像和复制以确保系统的健壮和一致。如果将备用站点做为一种应急方法，对备用站点的要求应该在本阶段提出。
实施阶段 虽然系统经历了初始测试，但是还是应该对应急策略进行测试以确保技术特性和恢复规程的正确和有效。需要制定测试计划来对应急策略进行测试。这些应急方法经过验证之后应该清楚地记录在应急计划当中。
运行／维护阶段 当系统处于运行状态时，应该对用户、管理员和负责人进行包括应急计划规程内容和意识在内的培训。应该进行演练和测试以确保规程的持续有效。应该进行常规备份并将其存放在离线站点。计划应该及时更新以反映由于获得经验教训而导致的规程更改。当IT系统进行更新或进行任何其它形式诸如外部接口的更改时，
这些更改应该反映到应急计划中去。应该及时协调和记录计划的更改以维护一个有效的计划。
废弃阶段 不应忽视由于计算机系统退役或被其它计算机系统取代时应该考虑的应急问题。在新的系统处于运行状态和得到完全测试（包括其应急能力）之前，原来的系统应急计划应该随时准备运行。在原系统被替换时，应该提供应对新系统错误或故障的有效备份能力。在有些条件下，被新系统所替换的硬件设备的部件（如硬盘、电源、存储器芯片或网卡）可以被用作新运行设备的备用部件。另外，原系统可以被用作新应用的测试系统，这样就可以在非生产系统上对系统潜在的破坏性陷缺进行识别和矫正。
