临时被要求出一份数据安全风险评估报告，打开模板发现每节都不知道写什么；或者写完了被法务、审计打回来，说证据不足、结论没依据。这篇按章节顺序把报告骨架拆开，告诉你每节该放什么、放到什么颗粒度算够，以及什么场景下这套骨架不适用。
临时被要求出一份数据安全风险评估报告，打开模板发现每节都不知道写什么；或者写完了被法务、审计打回来，说证据不足、结论没依据。多数时候不是能力问题，是没人把「每节该放什么、写到什么颗粒度算够」摊开讲过。
下面按章节顺序把报告骨架拆一遍，每节给可落地的填写口径和留证要求，最后说清楚什么场景下不该照这套走。目标读者是正在赶报告的安全从业者，不是做学术综述。
报告骨架：必备章节与先后顺序
主线是固定的：评估范围与依据—资产与数据梳理—威胁与脆弱性—现有控制措施—风险判定—处置建议—结论与签署。这条链条缺任何一节，评审基本都会退回补充，因为后面每一节的结论都依赖前一节的输入。
| 章节 | 必须回答的问题 | 最容易被退回的原因 |
|---|---|---|
| 评估范围与依据 | 这次评了什么、没评什么 | 边界含糊，没写清排除项 |
| 资产与数据梳理 | 有哪些数据、在哪、怎么流 | 只列系统不列数据流 |
| 威胁与脆弱性 | 谁会用什么方式打进来 | 威胁和脆弱性对不上号 |
| 现有控制措施 | 现在已经做了什么 | 写成「应该做什么」 |
| 风险判定与处置 | 风险多高、怎么降 | 等级口径不统一 |
| 结论与签署 | 能不能接受 | 只有描述没有结论 |
- 范围章节只写这次评了什么、没评什么，边界含糊是后面所有争议的源头；
- 依据章节列清楚引用了哪些制度、标准和内部规范，别只写一句「依据相关法规」；
- 结论章节必须有明确结论（可接受/需整改/不可接受），不能只堆描述；
- 每节开头用一句话交代本节输入来自哪一节，方便评审顺着链条看。
资产与数据梳理怎么填才不空
这一节最常写成系统清单，评审一看就知道没摸过数据。换成按数据流填：按「数据类别—存放位置—流转路径—责任部门」四列成表，一条数据流一行，比大段文字描述更容易被认可。
- 定数据类别按业务含义分类，比如客户身份信息、交易记录、运营日志，避免用「敏感数据」这种笼统词。验证方式：让业务方看一眼能认出是哪块业务的数据。
- 标存放位置与流转路径写清落在哪个库、哪个对象存储、哪些日志和备份里，以及是否对外提供。验证方式：随机挑一条链路，让运维按路径走一遍能对上。
- 写数据分级口径把分级判定标准落在报告里，比如按影响范围或敏感程度，口径写不清后面风险等级就没法自洽。验证方式：用同一个口径复核两批数据，分出的级别不矛盾。
- 标明覆盖方式梳理不全时写明抽样方法与覆盖比例，别假装全量。验证方式：抽样方法可复现，别人按同样方法能得出一致范围。
重点标注对外提供、跨系统流转、落到日志和备份里的那几条链路，这些是风险高发位置。日志和备份的边界判定，可对照站内 /guides/data-boundary-audit 的检查项来核。
威胁、脆弱性与现有控制措施
威胁按来源分：内部误操作、外部攻击、第三方环节。脆弱性要对应到具体配置、流程或人员环节，两者必须能一一对上，对不上就是凭空写的。
现有控制措施写「已经做了什么」，不是「应该做什么」。已有制度、技术手段、监控能力分条列出，每条注明证据位置，比如制度文件编号、配置截图存在哪个目录。控制措施还要标出覆盖缺口，缺口才是后面风险判定的打分依据。
- 同类风险合并写，不要为每个系统复制一遍；
- 每条控制措施后跟一句「覆盖范围」，写明覆盖哪些资产、哪些没覆盖；
- 第三方环节单独成条，写清对方承担了什么、你保留了哪些核查手段；
- 描述控制措施时避免形容词，用可验证的动词描述，比如「每周导出访问日志并留存」；
- 缺口不写「有待完善」，写具体缺在哪个环节。
风险判定、处置建议与留证
判定用统一口径：可能性乘影响，把每个等级的判定标准写在报告里。不同章节用不同口径，是结论互相打架的最常见原因。处置建议要能落地：改什么、谁负责、什么条件下算完成，别写「加强管理」这类无法验收的话。
证据链要能自证：截图带时间戳、日志导出保留原始文件、访谈记录写明对象与日期。截图和账单类材料的留存要点，可参考站内 /guides/dispute-evidence-keep 的做法。报告版本、修改记录、审批签署一并留档，后续复审要能追溯到这一次。
- 判定口径
- 可能性与影响的打分标准，写在报告开头，全篇复用
- 验收条件
- 整改到什么状态算完成，用可观测指标描述
- 证据位置
- 每条结论对应材料存在哪个目录或系统，评审能按图索骥
- 版本记录
- 谁在什么时候改了什么，复审时能定位差异
哪些情况下这套骨架不适用
- 只做单点技术检测时，比如扫一遍接口或配置，不需要走完整评估报告骨架，出检测记录即可，别硬套；
- 监管或客户指定了固定模板时，以对方模板为准，本文只当作自查缺项的对照表；
- 业务刚立项、资产还没定型时，先做范围界定和初步识别，不要急着下最终风险等级；
- 已经把评估做成常态化流程的团队，重点放在版本对比和整改闭环，而不是每次重写报告结构；
- 纯内部自查、不对外提交时，可以压缩依据和签署章节，但风险判定和证据链不能省。
判断标准很简单：报告是不是要提交给外部或用于追责。如果是，骨架一节不能少；如果只是内部摸底，可以裁剪，裁剪的也要在报告里写清楚为什么裁。
下一步写之前先去站内指南中心翻一遍同主题的检查清单，对着缺项补；涉及对外提供的链路，顺手核一下工具目录里的检测项，能省掉一轮返工。→常见问题
数据安全风险评估报告必须包含哪几章？
至少要有评估范围与依据、资产与数据梳理、威胁与脆弱性、现有控制措施、风险判定、处置建议、结论与签署这几块。缺了范围或依据，后面所有结论都站不住；缺了处置建议，报告就只描述问题不解决问题，通常会被打回补充。
没有完整资产清单，能先出报告吗？
可以先出，但要在范围章节写清这次是抽样评估，并说明抽样方法和覆盖比例，同时把未覆盖部分列为后续工作。硬写成全量评估，一旦被抽查到漏项，整份报告的可信度都会受影响，后续复审也很难解释。
报告里的证据要留到什么程度？
到能让第三方复核的程度：截图带时间戳、导出文件保留原始格式、访谈记录写明对象和日期、审批留签署记录。只写「已核实」而没有可回溯材料，在内部审计或监管检查时基本等于没写。
