组织在开展DRP项目建设灾难恢复体系过程中，应该开展风险分析工作。在《信息技术安全信息系统灾难恢复规范》中有这样的定义和描述“风险分析的主要内容包括：标识信息系统的资产价值，识别信息系统面临的自然的和人为的威胁，识别信息系统的脆弱性，分析各种威胁发生的可能性并定量或定性描述可能造成的损失，识别现有的风险防范和控制措施。通过技术和管理手段，防范或控制信息系统的风险。”
在项目具体开展过程中，有些人员对于风险分析的分析范围，有一些不适当的理解和期望，希望能够对信息系统进行“全面”的风险分析，而不希望把风险分析对象局限在生产中心外部及机房环境风险或IT架构风险上。为什么会说DRP项目中开展全面风险时不恰当的呢？我们可以参考下表:
从上表我们可以清晰看出，不同类型的风险对信息系统运行有着不同的影响，解决策略和方法也各有不同：
业务资源类风险完全不会对信息系统的正常运行造成影响，所以不会导致信息系统服务中断或不可接受；
开发测试类风险例如业务逻辑缺陷或数据逻辑缺陷可能会导致系统服务中断，但是因为主备一致性要求会使上述问题同时存在于生产系统及备份系统中，所以即使切换灾备，该问题依然存在，系统服务在问题排除前依然不能正常运行。
运行风险中的外部攻击可能造成信息系统服务中断，在排除外部攻击前，即使切换了灾备系统，也无法保证信息系统能够正常提供服务。
当生产者中心发生运维人员误操作或软硬件故障、机房内外部环境事件导致信息系统运行服务中断时，组织可以通过切换灾备系统恢复系统服务。
中国人民银行在《银行业信息系统灾难恢复管理规范》（JR/T0044-2008）对风险分析（risk analysis）定义为“确定影响信息系统正常运行的风险，评估对单位业务运营至关重要的功能，定义降低潜在危险控制手段的流程。风险分析经常会涉及到对特殊事件发生可能性的评估。”对此我们应该正确理解，风险分析的三段论识别风险-风险管控-残余风险的开门砖识别风险，识别的影响信息系统“正常运行”的风险，识别的前提就是信息系统已经处于正常运行状态，所以有关于软件架构设计数据结构设计等设计问题，已经排除在外了，另外业务资源等不会影响到系统运行的风险，也同样不在本定义范围之内。
对于DRP项目的风险分析，核心重点在于识别会影响信息系统“正常运行”的风险例如运维操作、IT系统本身固有问题（软硬件故障）、机房内外部环境问题，以及识别可以通过灾备切换进行恢复系统服务的残余风险。如果该风险不影响生产系统正常运行，或者该风险无法通过灾备切换进行恢复，那么组织就应该通过其他项目对风险进行识别及管控，不应由DRP项目来进行风险的处置。
