出了安全事件，多数团队第一反应是「修好就行」，等到季度复盘才发现账单、客户流失、停工、法律成本各算各的，没人说得清到底亏了多少。这篇不讲概念，只给一套损失分类、一份逐项清点顺序和留证清单，让你在事件后能把损失算清、把证据留住，也顺便知道哪些项算不出来、只能给区间。
出了安全事件，多数团队第一反应是「赶紧修好就行」。等季度复盘时才发现，账单是财务算的、停机损失是业务估的、客户流失是销售说的、律师费是行政报的，各算各的，没人说得清到底亏了多少。这事麻烦的地方在于：直接损失能对账，间接损失没法对账，而后者往往更贵。
下面这套东西不讲概念，只给三样：损失怎么分类、按什么顺序清点、要留哪些证据。目标是事件后你能拿出一份能解释清楚的口径，而不是一个看着漂亮但没人信的大数。顺带说清楚哪些项根本算不出来，只能给区间。数字类的东西一律到站内页面核对当时的实际情况。
直接损失：先算能用票子对上的那几笔
直接损失的判断标准很简单：这笔支出能不能在某个后台、合同或工时表里找到来源。找不到来源的，先别写进报告，单独记在备忘里。四类最常被漏算：应急响应的人员工时（含加班和外部支援）、被刷掉或被滥用的接口与云资源账单、停机期间的业务收入缺口、外部采购（渗透测试、取证、律师、通知用户）。
- 应急与恢复工时：把参与人的时间按角色分开记，别只记一个总人天
- 资源账单：导出事件前后同一项目、同一接口的原始明细，用汇总页会丢因果
- 业务收入缺口：口径要事先定死，是按订单量还是按成交额，中途换口径等于重算
- 外部采购：合同、发票、付款凭证三样留齐，缺一样后面很难归到这次事件上
不适用的情况也说得直白点：事件还在进行、止损动作还没完成时，直接损失只能是滚动更新的中间数。这时候急着对外给一个总额，后面几乎一定要改口，反而更被动。
间接损失：真正贵的是那些不出现在发票上的
间接损失最容易被低估的三类：客户与续约的流失、招人周期变长、为了补窟窿被迫放缓的产品节奏。这三样都不会有一张发票写着金额，但它们通常比罚款和采购费加起来还重。写法上只能用区间和假设，而且要写清「按什么假设推的」，比如按流失了哪一档客户、按多久没恢复。
| 类别 | 怎么描述 | 什么情况下不适用 |
|---|---|---|
| 客户流失 | 按受影响客户档位给流失率区间 | 事件未对外披露、客户还没反应时只能算预估 |
| 招聘周期 | 用关键岗位从发岗到入职的周期变化描述 | 团队规模太小、本来就没什么招聘时意义不大 |
| 产品节奏 | 用被推迟的迭代数量或时间窗描述 | 本来就处于规划冻结期，推迟未必是事件导致 |
| 续约谈判 | 用谈判周期拉长或条款变化描述 | 客户本来就快到续约期，归因要谨慎 |
一句话原则：间接损失写进对外材料之前，先确认它已经能被观察到，而不只是你推算出来的。推算值放在内部复盘里没问题，对外就得说清是预估。
清点顺序：从定损范围到复盘归档的六个动作
顺序错了，数字就白算。最常见的问题是范围还没定死就开始算钱，结果算到一半发现受影响账号又多了几十个，前面全部作废。所以先定范围，再谈金额。
- 冻结时间线记下谁在什么时候发现、什么时候止损、什么时候恢复。这条线决定后面所有数字的时间口径，先写下来再动别的。
- 划定影响范围列出受影响的账号、数据、客户和系统。范围没定死就不要开始算钱，否则数字随时要推翻重算。
- 逐项取证每一项损失对应至少一份原始材料，账单导明细、工时看记录、沟通看聊天和邮件。截图要带时间戳和上下文。
- 逐项定价能对账的写实数，不能对账的给区间并注明假设。同一项不要出现两种口径。
- 内部复核让财务和业务各看一遍，重点看口径是否一致、有没有重复计算，比如停机损失里已经含了人力就别再单列。
- 归档定稿后连同证据一起归档，标明责任人和保留期限，别等要用的时候发现日志已经滚掉了。
止损阶段的处理思路，站内已经有一篇讲得比较细，这里不重复。原则层面的取舍可以去 /tools/speed-test 之外的相关指南页看，重点是对齐「先止损、再定损」这个次序。
留证清单：事后想追责或索赔，靠的是这些材料
留证不是为了打官司才做的事，内部追责、保险理赔、给客户的解释，全都靠它。核心是四样：完整日志（含访问与操作记录）、对外沟通记录、付款与退款凭证、内部决策纪要。少一样，链条就断一节。
- 截图必须带时间戳和上下文，单独一张报错图说明不了因果
- 账单导原始明细，不要用汇总页，汇总页看不出是哪笔调用被刷
- 留存期限和访问权限提前定好，谁能看、看多久，写进流程
- 沟通记录保留原始渠道，转述或整理版不能替代原始消息
- 决策纪要记清谁在什么时候拍了什么板，事后追责靠这个
举证和维权的具体做法，站内另有一篇专门讲，两篇配合看效果更好。这里只强调一点：留证动作要在事件进行中就做，事后再补基本补不回来。
算不出来的那部分：怎么诚实交代
品牌信任、员工士气、潜在的监管关注度，这几样很难量化。硬凑一个精确数字，短期看着完整，一旦被追问推演过程就露馅，反而把整份报告的可信度拉低。诚实交代比数字好看更重要。
替代做法是用可观察的替代指标来描述：投诉量变化、客服工单的主题分布、招聘岗位关闭周期的变化。这些不能直接换算成金额，但能说明趋势，足够支撑结论。
| 分类 | 写什么 | 适合谁看 |
|---|---|---|
| 已量化 | 有原始凭证支撑的实数 | 财务、管理层 |
| 可估算 | 带假设的区间值 | 业务负责人 |
| 无法量化 | 替代指标与趋势描述 | 对外沟通、复盘会 |
不适用的情况：如果这份材料要用于保险理赔或法律用途，无法量化的部分不要自己下结论，交给专业人士判断，你只负责把原始材料备齐。
能对账的写实数，不能对账的给区间，算不出来的就说算不出来——这比一个漂亮的大数有用得多。下一步把损失口径和证据清单落成团队模板之前，先去站内看看现有的安全与合规类指南，避免和已有流程打架。→
常见问题
没有造成数据泄露，只是被刷了接口，也算安全事件损失吗？
算，但损失结构完全不同。这类事件的主要成本是资源账单和应急工时，几乎没有客户流失和法律成本。清点时把被刷掉的调用量、扩容费用、人工排查时间单独列出来，再判断要不要升级为对外披露事件。判断口径可以参考站内安全与合规分区的相关说明。
损失金额要不要写成一封对外说明？
通常不建议在事实没查清前给出总额。对外只讲已确认的影响范围和已完成的处置动作，金额区间留给内部复盘和监管沟通。一旦对外报了具体数字，后面再修正会被解读成隐瞒，反而放大信任损失。需要对外时先过法务和公关。
中小团队没人做安全，怎么用最少动作把损失控制住？
先做三件事：把关键账号的日志留够天数、给接口加一层额度上限、出事时固定一个对外口径负责人。这三件不需要专职安全岗，成本也低。真出事时按上面的清点顺序走，别一边救火一边算钱。上线前的自查项可参考站内上线前安全自查那篇。
