风险报告怎么分层
风险报告按受众分层：治理层看整体暴露等级趋势、Top 风险与需要决策的事项；项目层看全部高暴露风险的状态、储备消耗与新出现的风险；团队层看与自己相关的触发条件与应对动作清单。同一风险在不同层的颗粒度不同，治理层并不需要逐条明细。分层做得好，会议时间会明显缩短；所有人看同一份长清单时，重点信息反而被淹没。
基本信息
| 治理层关注 | 整体暴露趋势、Top 风险、决策请求 |
|---|---|
| 项目层关注 | 高暴露风险状态、储备消耗、新增风险 |
| 团队层关注 | 触发条件与应对动作清单 |
| 通用要素 | 摘要、决策请求、明细附录 |
| 关键原则 | 颗粒度随受众变化，报告必须含决策请求 |
典型使用场景
- 月度治理会议前，为高层准备趋势与 Top 风险摘要
- 项目周会更新全部高暴露风险的状态与应对进展
- 团队站会或看板上呈现与本角色相关的风险触发条件
- 重大风险升级时，为决策者准备选项、建议与影响评估
- 项目收尾时汇总风险发生情况与应对效果，沉淀到经验教训库
分层示例
分层示例
# 治理层：整体风险等级趋势 + Top3 风险 + 决策请求
# 项目层：全部高暴露风险状态 + 储备消耗 + 新风险
# 团队层：与本角色相关的触发条件与应对动作清单报告要素模板
| 要素 | 内容 | 要求 |
|---|---|---|
| 摘要 | 暴露等级与趋势 | 一两句话说清 |
| 决策请求 | 选项与建议 | 明确需要谁决定什么 |
| 明细 | 风险台账 | 附录形式按需展开 |
| 变化 | 与上期对比的新增与关闭 | 突出趋势而非罗列 |
同一风险在不同层的呈现颗粒度不同：治理层不需要看每一条细节。
报告不含决策请求时，治理会议只能听取汇报，问题得不到处置。