向不同读者的分层汇报
同一份结论往往要面对三类读者：管理层关心影响范围与处置状态，技术团队关心时间线、指标与加固建议，法务合规关心授权依据、保管链与证据清单。分层不是把内容删减，而是按读者的关注点重新组织，同时保证任何一层的表述都能在完整报告里找到出处。
基本信息
| 管理层 | 影响范围、处置状态、结论与建议，一页摘要 |
|---|---|
| 技术团队 | 时间线、指标、检测与加固建议，完整报告与附录 |
| 法务合规 | 授权文件、保管链、证据清单与哈希 |
| 一致性 | 各层材料的关键数字与结论必须一致 |
| 版本控制 | 对外材料单独评审，标明对外版本与内部版本 |
典型使用场景
- 向上汇报时先给结论与影响面，再按需展开细节
- 与运维或研发对齐时直接给时间线与关键指标
- 应法务要求提交授权材料与保管链记录
- 事件复盘会上按不同角色分发对应材料
- 归档时保留各层材料与报告版本的对应关系
交付核对
交付核对
ls /case/2026-001/deliverables/
# exec-summary.pdf report-v2.0.pdf ioc.csv custody.pdf auth-letter.pdf
# 每份对外材料标注版本号与对应的报告版本
sha256sum /case/2026-001/deliverables/* > deliverables.sha256 # 交付前固定清单分层对照
| 读者 | 关注点 | 载体 |
|---|---|---|
| 管理层 | 影响范围、处置状态、结论 | 一页摘要加口头汇报 |
| 技术团队 | 时间线、指标、加固建议 | 完整报告与附录 |
| 法务合规 | 授权、保管链、证据清单 | 报告与保管链文件 |
摘要里的每个数字都要能在完整报告里找到出处，否则一旦被追问就只能临时解释，可信度会大打折扣，也容易出现不同材料之间互相矛盾的情况。
对外材料与内部材料要分开评审：内部可以写明尚未验证的线索与猜测，对外材料里未经验证的推断必须标清置信度，避免被当作既定事实引用到更大范围。