安全事件响应流程图
安全事件响应流程的泳道图：从检测与分流，经严重性分级、遏制、证据保全与清除，一直到数据泄露通报、事后复盘与结案。
运作方式
把泳道改成你们真实的角色
把这五条泳道换成你们真正拥有的角色：SOC 或 MSSP、服务台、安全负责人、平台团队、数据保护官、外部取证机构或泄露事件法律顾问。如果某个角色并不存在，就删掉那条泳道，而不是让它空着无人承担。
设定你们的严重性判定标准
打开“对严重性与影响分级”方框，把说明换成你们自己的矩阵：什么样的事件算作高严重性、谁有权宣布，以及每个等级各自承诺什么样的响应时间。
确定通报时限与对应的监管机构
编辑“是否属须通报的泄露？”决策，让它写明适用于你们的制度：英国或欧盟 GDPR（72 小时内通报监管机关）、NIS2、HIPAA、行业规则，以及合同约定的客户通知期限——后者往往比法定期限更短。
补上人们在凌晨三点需要的联系方式
把事件通道、值班电话、事件指挥官排班和证据存放位置写进方框备注里，这样这张图在事件当中也用得上，而不只是在复盘时才拿出来。
调整回路并补上缺失的步骤
判断“系统是否验证干净？”回到隔离的这条分支是否符合你们的工作方式，并补上你们环境中特有的内容，例如启用常年合约的取证供应商、网络保险通报，或者一个客户沟通稿的审批步骤。
分发签署并保留版本
把这张图交给安全负责人、IT 运维和法务签署确认，然后保留获批版本。事件响应计划是一份受控文件，你们演练的版本应当就是你们发布的版本。
常见问题
事件响应流程分为哪些阶段？
本图使用五个阶段：检测与报告、分流与分级、遏制、清除与恢复，以及通报与复盘。它与 NIST SP 800-61r2 高度对应，后者使用检测与分析，遏制、清除与恢复，以及事后活动。NIST 另有一个准备阶段，但准备是持续性的工作（工具、值班排班、演练、常年服务合约），而不是你在事件当中执行的一个步骤，因此没有画在流程上。
安全事件响应与 IT 事件管理有什么不同？
一次 IT 服务事件在服务恢复时就结束了。安全事件不是，因为存在一个对手。过早恢复可能等于把攻击者的访问权重新交回去，而且它还带有 ITIL 事件流程并不承担的义务：在重建之前保全证据、判定哪些数据受到影响、并在需要时通报监管机构和个人。这正是本图把证据保全与镜像放在清除之前，并在恢复之后加上一条通报分支的原因。
谁应当担任事件指挥官，什么时候指派？
事件指挥官应当是有权做决定的人（把一套生产系统下线、聘请外部法律顾问、联系客户），而不一定是当下技术最强的人。他们负责协调，而不是负责调查。在本图中，只有当“是否为高严重性事件？”得到“是”时才指派指挥官；严重性较低的事件仍留在安全团队。在一次长时间的事件中，这个角色会在每次换班时明确交接。
72 小时的泄露通报时钟从什么时候开始？
在英国和欧盟 GDPR 之下，这 72 小时从组织知悉发生了个人数据泄露时起算，而不是从攻击开始时、也不是从调查结束时起算；如果尚未掌握完整情况，可以分阶段通报。通知受影响的个人是另一项判定：当泄露很可能给他们带来高风险时，须在不当延误的情况下通知。其他制度运行的是不同的时钟，因此请把适用于你们的那一个写在决策方框上。