一旦你收集了要求的数据，是时候进入计划的第二阶段了：分类以及一个操作的响应蓝图。如果这个听起来非常像“传统的”泄露响应，其实的确如此。实际上，云泄露响应可以作为更为广泛的响应计划工作的扩展，从而更好地实现。的确，由于环境不同，比如优先次序不同，技术响应选项和警报/通知路径不同，但是记得大多数用例都会在云和传统IT元素之间有一个交互点。这意味着为云组件尝试隔离维护单独的响应流程不可避免的导向更加的复杂性，缺乏透明度(比如，运营责任)和事件中产生的额外开支。

正如传统的灾难恢复和事故相应计划，优先级应该基于影响，反映了数据类型的功能以及业务危险程度。这两个因素也允许你了解是否或者什么时候或者其他的流程如何，比如外部公开的规程，都应该算在内。对比现有的事故响应流程额一个不同就在于，有助于基于关系自定制响应习惯，因为一些动作你可能系统包含在同CSP的交互中。比如，你可能要求你的CSP影响技术改变或者提供额外的信息。在这样的情况下，你可能会选择记录下来这些同CSP的经验。

问题在于，收集足够的信息可以为实际的策略活动构建你要完成的“响应蓝图”.因为响应的细节因环境、用例和关系而多变，加上其他的一些变量，你可能希望更加具体的技术活动;比如，事件响应计划和技术清单。为什么?因为你可能希望给予提供商所做的以及技术上不允许你做的等内容自定制技术响应活动。

需要牢记的是在做云端响应的时候并没有任何不同，首先要做的就是详细规划，在技术计划中为你的组织机构如何对这些不同做出说明是非常有用的第一步。

(责任编辑：)