事件响应流程模板（6 张关联流程图）
覆盖完整升级阶梯的六张关联流程图：事件管理、严重级别分级、网络安全事件响应、数据泄露通报、灾难恢复与业务连续性，交接点全部画了出来。
一次 IT 事件会变成一次安全事件，再变成一次须依法通报的数据泄露，再变成一次灾难恢复启动——而这道阶梯的每一级，都由不同的团队按不同的时钟负责。
本模板包的内容
1. 事件管理流程图
前门：发现、登记、分诊，以及重大事件的宣告。
2. 事件严重等级分级流程图
决定其余一切走向的那个判断——影响、紧急度，以及暴露判定。
3. 网络安全事件响应流程图（SOC）
安全分支：遏制、清除、取证，以及恢复到干净状态。
4. 数据泄露响应流程图（GDPR 72 小时时限）
监管分支及其七十二小时时钟，含是否对外通报的判断。
5. 灾难恢复流程图（IT 系统）
重建：启动授权、恢复顺序，以及恢复服务前的验证。
6. 业务连续性流程图：从启动预案到解除响应
在重建进行的同时，用变通方案让业务继续跑下去。
它们之间如何衔接
- 事件管理流程图 → 事件严重等级分级流程图
- “分类并设定优先级”是事件流程把判断让给分级流程图的位置。把严重级别单独放一张图，意味着 P1 只有一个定义、其余流程都指向它，而不是三份互相打架的定义。
- 事件管理流程图 → 业务连续性流程图：从启动预案到解除响应
- “宣告重大事件”是问题从如何修复故障，转为业务在修复期间如何继续运转的那一刻。这是两拨人、两套预案、两条不同的时钟。
- 事件严重等级分级流程图 → 网络安全事件响应流程图（SOC）
- “是否涉及数据或人身安全暴露？”是一个判定菱形，而把链接挂在判定上是最有用的用法：判定恰恰就是一个流程分叉出另一个流程、而不是继续往下走的位置。
- 网络安全事件响应流程图（SOC） → 数据泄露响应流程图（GDPR 72 小时时限）
- “确定受影响的资产与账户”是安全团队弄清个人数据是否在范围内的地方。如果在，监管时钟是从发现那一刻开始走的，而不是从这一步——这正是泄露流程被链接、而不是被接在后面的原因。
- 网络安全事件响应流程图（SOC） → 灾难恢复流程图（IT 系统）
- “用干净备份重建系统”是安全交棒给基础设施的地方。什么算干净由安全决定；东西按什么顺序回来，由恢复决定。
- 灾难恢复流程图（IT 系统） → 业务连续性流程图：从启动预案到解除响应
- “批准启动 DR”会并行触发连续性预案，而不是等在它之后。恢复有自己的 RTO；在 RTO 走完之前，业务就已经需要照常运转了。
- 业务连续性流程图：从启动预案到解除响应 → 灾难恢复流程图（IT 系统）
- “启用变通方案与手工流程”反向链回去，因为连续性常常是先被启动的一方——业务先察觉到自己没法做生意，基础设施那边还没认定这是一场灾难。
运作方式
先把严重级别矩阵定下来
这套模板里其余每一张图，都按分级流程图的结果分流。先把你们真实的影响与紧急度定义填进去，再回头确认依赖它的那五张图仍然读得通。
给每一个启动授权写上名字和电话
重大事件宣告和 DR 启动都是授权决定。一张只写着由管理层批准的图，会在最糟糕的时刻制造一场二十分钟的争论。
在泄露图里，把监管时钟的起点定在发现
七十二小时是从知悉起算，而不是从确认起算。如果你的图暗示时钟要等法务被告知才开始走，它描述的就是一个你必然会错过的期限。
用这些链接当脚本跑一次桌面推演
带着大家从前门走过分级、进入安全分支、再出到恢复，全程跟着角标走。每一次关于谁接手的迟疑，都是图的缺口，而不是人的缺口。
把文件夹以只读方式共享给所有值班人员
这些正是凌晨三点要用的图。给整个值班轮值表开只读权限不花什么成本，却能彻底消灭手上是不是最新版本这个问题。
常见问题
这套图遵循 ITIL 吗？
事件那张图用的是 ITIL 的形态——发现、登记、分类、定级、调查、解决、关闭——但没有照搬 ITIL 的整套术语。安全、泄露、恢复和连续性这四张图，遵循的是 ISO 27035、ISO 22301 的实践和常见的监管模式，而不是 ITIL。
使用这套模板需要付费方案吗？
需要——模板套装包含在 Plus 方案中。一套模板会一次创建六张图，而免费方案只能保存三张。每一张图也都可以单独免费使用。
为什么灾难恢复和业务连续性互相链接？
因为任何一方都可能先被启动。基础设施可能在业务察觉之前就宣告灾难，业务也可能在还没人称之为灾难时就启用了变通方案。单向链接只能描述真实行为的一半。
七十二小时只针对 GDPR 吗？
泄露那张图按七十二小时的通报窗口来画，因为那是 GDPR 的要求，也是适用面最广的一个。其他制度并不相同——关键基础设施的期限有些更短——所以请把图里的时限改成你实际适用的那个。
把六张图全部加入我的资料库 — 6 张图表，同在一个文件夹中。Plus 套餐包含。