半夜收到告警说某台机器在往外传数据，或者同事转来一张截图说客户信息好像流出去了——这时候最怕的不是事情本身，是没人知道下一步该干什么。这篇不讲法条原文，只给安全负责人一份能照着走的应对顺序：先定级、再掐断、再留证、最后复盘，并把每一步的判断标准和不适用的情形写清楚。
半夜收到告警说某台机器在往外传数据，或者同事转来一张截图说客户信息好像流出去了——这时候最怕的不是事情本身，是没人知道下一步该干什么。很多人第一反应是冲去翻法条，其实没用，法条不会告诉你先掐哪根线。
这篇给安全负责人一份能照着走的顺序：先定级、再掐断、再留证、最后复盘。每一步都写清楚判断标准和什么情况下不适用，至于法规条文的具体门槛、各家服务的实时报价，一律到站内对应页面核对当时的数字，别拿旧截图做决策。
第一小时先做三件事：定位、定级、定指挥
第一小时最容易乱，因为所有人都在问「真的假的」。这时候要先把线索分三类：日志异常、外发流量突增、第三方告知。三类紧迫度不一样，疑似阶段不要先大规模关停业务，关停本身也是事故。
- 先分清是「疑似」还是「已确认」：三类线索的处置紧迫度不同，疑似阶段优先做取证性观察，别急着停服务
- 定级别拍脑袋，按受影响数据类型、涉及人数、是否可恢复三个维度粗判，拿不准就往高一档报，宁可多叫人不叫漏人
- 明确一个现场指挥和一条对外口径，其他人不要各自去问供应商、问客户、发朋友圈
- 先把「谁负责对外说话」定下来，现场指挥负责技术动作，两条线不要混
不适用的情形要提前想好：如果只是内部测试环境的异常，按轻量流程走即可；但只要涉及真实个人信息或对外可访问的服务，就按正式事件处理，别用「应该没事」说服自己。
止损顺序：先断开传播路径，再谈修漏洞
- 处置凭据停用泄露的凭证与账号，确认旧凭证真正失效而不是只改了备注，验证方式是拿旧凭证再试一次，必须失败
- 切断外联切断异常外联，先看目标地址是哪里、是否还在传，再决定是封 IP 还是整体断网
- 隔离主机隔离受影响主机的网络，保留磁盘和内存镜像的顺序不要搞反，镜像是为了后续分析
- 暂停接口暂停相关对外接口，用只读或限流降级代替直接下线，避免影响正常业务
- 回头排查最后才回头排查漏洞根因，顺序反了就会出现边修边漏
凭证轮换的具体做法参照站内 key-leak-response-runbook 的顺序，别跳步，否则容易出现旧的还在用、新的已经发出去的混乱局面。如果数据已经流向第三方或外部模型服务，第一时间确认对方是否留存、留存多久、能不能要求删除，不要等复盘时才想起来。
不适用的情形：涉及生产核心链路时，直接全停可能造成更大损失，此时应做限流和只读降级，而不是一刀切断网，降级方案要提前有预案，临时想来不及。
留证与记录：这一步做漏，后面全是空口
| 要留的东西 | 判断标准 | 常见漏项 |
|---|---|---|
| 告警与时间戳 | 原始记录不加工 | 只截了聊天截图 |
| 影响范围清单 | 哪张表、哪些字段、大概多少条 | 一开始就报精确到个位的数字 |
| 处置时间线 | 谁在什么时候做了什么决定 | 只有结果没有过程 |
| 对外沟通记录 | 邮件、工单、会话单独归档 | 混在个人聊天记录里 |
- 日期和时间点都按原始系统时间记录，改过的记录不如没有记录
- 数据范围要能说清「哪张表、哪些字段、大概多少条、是否含个人信息」，说不清就先圈范围再逐步收敛
- 对外沟通的邮件、工单、会话单独归档，举证和维权的留存方式可参照站内 dispute-evidence-keep 的思路
- 当天就写一份事件日志，别等复盘时靠回忆补
要不要报、报给谁、什么时候报
判断依据是数据类别、影响范围和是否已造成实际危害，具体门槛以当时的法规文本和行业主管部门要求为准，站内 /safety 有对应条目可供对照，别凭印象决定报不报。
内部报送要同时走安全条线和法务/合规条线，别只发在一个群里，时间点以你方内部制度规定的时限为准。对外通知用户这件事要谨慎：措辞过头会引发恐慌与索赔，措辞不足又可能被认定隐瞒，建议由法务定稿、安全提供事实。
- 对外口径
- 一份事实陈述加一句后续安排，不写结论性判断
- 中间态说明
- 事实未确认时可以发「正在核实」，但要给出下次更新的时间
- 报送对象
- 按数据类别和行业要求确定，拿不准时问法务不要问同行
不适用的情形：还在调查阶段、事实未确认时不宜对外发布结论性表述，可以发中间态说明，但要给出下次更新的时间点，否则用户会更慌。
复盘：把这次事故变成可复用的清单
复盘只问三件事：哪一环发现得晚、哪一环处置得慢、哪一环没有留痕，对应改监控、改预案、改记录模板。不要开成追责会，追责会的结果是下次没人敢早报。
- 把这次的处置时间线整理成团队的检查表，下次同类事件直接照着走
- 定期做一次桌面推演就够了，重点是把「谁在半夜被叫起来」提前定下来
- 更新监控规则时同步更新告警阈值，只看不调的规则等于没写
- 准入与合同条款要同步更新，尤其涉及第三方或中转站时
不适用的情形：如果是外部供应商或中转站的问题，复盘重点应放在准入与合同条款上，而不是内部流程。选供应商前可以去 /sites 和 /rankings 看当时的可信度与稳定性记录，具体数字以页面当时显示为准。
事故应对比拼的不是谁知道得多，而是谁在半夜也知道下一步点哪个按钮。下一步把这份顺序存成团队的一页纸预案，然后去站内 /safety 核对与你们行业相关的条目，具体门槛和当时的数据都在那里。→
常见问题
数据安全事件发生后，第一件事到底该做什么？
先确认事实再动作。第一步是把线索固定下来——告警截图、异常时间点、涉及的系统名，然后拉一个最小范围的处置小组。不要一上来就大面积停服，也不要先去找责任人。事实没确认之前，所有动作都应以「不扩大影响、不破坏证据」为前提。
怎么判断自己的事件要不要向监管部门报送？
看三点：数据类别是否属于重要数据或个人信息、影响范围有多大、是否已经造成或可能造成实际危害。具体门槛和时限以当时的法规文本和主管部门要求为准，站内 /safety 分区有对应条目可以逐条核对。拿不准的情况下，建议先内部报法务，由法务判断报送路径。
处置过程中哪些记录必须留？
至少留四类：告警原始记录与时间戳、受影响数据范围清单、处置动作时间线、关键决策的责任人。对外沟通的邮件和工单单独归档。这些材料既用于内部复盘，也可能在后续举证或报送时用到，事后补记的可信度会大打折扣。
