数据安全风险评估方法及实施指南

很多人第一次做数据安全风险评估，卡在两头：不知道要收集哪些材料，也不知道做完到底该交出一份什么东西。中间的风险判定又容易被做成「拍脑袋打勾」。这篇按阶段把输入和输出列出来，你照着走就能把一次评估做成可复核、能交接的流程，而不是一份写完没人看的文档。

很多人第一次做数据安全风险评估，卡在两头：不知道要收集哪些材料，也不知道做完到底该交出一份什么东西。中间的风险判定又容易被做成「拍脑袋打勾」，不同的人评出来的结果完全对不上。这篇按阶段把输入和输出列出来，你照着走就能把一次评估做成可复核、能交接的流程，而不是一份写完没人看的文档。

先明确一件事：评估不是一次性报告，而是一条有起点、有产物、有交接的流水线。每个阶段的产出都要能直接喂给下一阶段，中间断了就得回头补。下面按定范围、收输入、判风险、出报告四个阶段拆开讲，每节都说清要什么、产出什么、什么情况下这套做法不成立。

第一步：定边界和盘资产

范围一定要写成一句话，比如「本次评估覆盖某业务系统的用户资料与对话记录，时间窗口为最近一个季度」。范围不写死，后面所有结论都没法复用，换个系统就得全部重来。判断范围划得对不对，用一个标准检验：能不能画出一条从数据产生到数据落地的完整链路。

• 先把评估范围写成一句话：评的是哪套系统、哪类数据、哪个时间段
• 资产清单至少包含四类：数据本身、承载系统、账号权限、数据流经的第三方（含模型服务和中转环节）
• 判断标准是「能不能画出一条完整链路」，链路画不通说明范围划小了或划大了，先修范围再往下走
• 不适用的情况：纯新建、尚无任何数据流入的系统，可以先做威胁建模，等有真实数据再补这一轮

盘资产的时候，第三方这一段最容易被漏。很多团队只盘自己机房里的东西，忘了数据会经由外部模型服务、代理中转、日志平台出去。这部分链路梳理的做法，可以参考站内 /data-boundary-audit 页面的检查思路，把出站路径一条条列出来，而不是只写个「接口调用」了事。

第二步：收集输入，别急着打分

评估做到一半发现证据不够，是常见翻车点。所以第二阶段的目标不是出结论，而是把四类输入凑齐并落成文件。凡是口头确认的内容一律不算数，必须落到可回溯的载体上，否则复评时没人能验证你当时凭什么这么判。

收完材料后，把互相矛盾的地方单独记一份「待澄清清单」。这份清单往往比风险条目本身更有价值，因为矛盾点通常指向真实的管理缺口，而不是纸面问题。另外提醒一句：如果连日志都拿不到，别硬做评估结论，改成先推动日志留存能力补齐，这本身就是一条有价值的发现。

第三步：判风险，用两个维度卡住口径

风险判定最怕口径不统一。同一件事，有人觉得严重有人觉得无所谓，最后报告没人服。解决办法是用「影响程度 × 发生可能性」分档，但关键在于：每一档都要写出判定例子，让不同的人按同样的例子去对照，结果才可比。

1. 定档位先约定影响程度和可能性的档位数量，并为每档写两到三个判定例子
2. 写风险描述按「场景 - 后果 - 现有措施 - 缺口」四段式写，只写「存在泄露风险」这种话等于没写
3. 标责任每条风险标注责任人和建议动作，动作要能落到具体配置或流程节点
4. 交叉复核由未参与初评的人抽几条重判，看口径是否一致

有一种情况要单独说：合规硬性条款该判高就判高，不要用概率维度把它稀释掉。比如某些数据出境或留存要求，是「必须满足」而不是「可能出问题」，这类条目直接按高影响处理，不参与概率拉平。

第四步：出报告、留证、定复评节奏

报告结构建议固定下来：范围与方法、资产与数据流、风险清单、整改建议、遗留问题与复评计划。固定结构的好处是，交接给别人时对方知道去哪一节找什么，而不是每次都要重新翻一遍。

留证要能自证：截图带时间与来源、访谈有记录、版本可回溯。具体怎么留，可以参考站内 /dispute-evidence-keep 的留存思路，重点是让第三方只看材料就能还原你当时的判断过程。整改项分「本次内改」和「排期改」两栏，每栏明确谁验收，避免整改清单变成许愿池。

复评触发

按业务变化触发，而不是只按日历；系统换模型、换供应商、开通新数据出口，都该触发一次局部复评

局部复评

只覆盖变化部分的链路和风险，不必全量重做，但结论要回填到原报告

遗留问题

本轮明确不处理的事项，写清原因和预计处理条件，避免被当成已解决

复评节奏这件事，很多团队只设了定期，结果系统早就换了供应商，报告还停留在上一版。正确的做法是把「变化事件」当成主触发器，日历只做兜底。