数据安全风险评估应当覆盖哪些内容

做评估时最容易卡在两处：一是不知道要评到多细，写出来的报告被上级说「太虚」；二是不知道哪些项可以留到下一轮。这篇把评估维度拆成可勾选的检查项，并说明每项在什么情况下不适用，方便你排优先级、分工和留证。

做数据安全风险评估，最常见的两种翻车方式：一是范围写得太宽，最后交上来一份什么都提了一句、但每项都停在概念层面的报告，上级看一眼就说「太虚」；二是范围写得太细，把全公司所有系统都塞进本轮，结果三个月交不出东西。真正可用的做法是：先把评什么、评到什么深度钉死，再按维度逐项打勾，最后把不符合项排成能排期的整改清单。

这篇给的是可勾选的检查项和判断标准，不是概念科普。每一节都会说清三件事：这一维度要看什么、常见取证动作是什么、什么情况下这一项可以不适用。你可以直接拿这份结构当评估底稿，把不适用的项标注理由即可，不必强行凑满。

先把评估范围钉死：评什么系统、评到什么深度

范围定义是整份评估里最容易被跳过、也最影响后续工作量的一步。建议用「数据—系统—人员—外部接口」四条线画边界：数据是哪些数据项，系统是哪些承载系统，人员是哪些角色能接触，外部接口是哪些对外传输或调用点。四条线交叠出来的才是本轮评估对象，边界外的写进「本轮不评」清单并注明原因，例如「该子系统无真实数据流转，待上线后纳入下一轮」。

• 区分两类评估：一次性的合规基线评估，和随业务变化触发的持续评估。二者检查项重叠，但取证方式和复评周期不同，别混在一张表里。
• 范围章节里写明评估依据：引用了哪些内部制度、哪些外部要求。没有判定尺子，后面的整改结论就没法说服人。
• 预留一句范围变更说明：评估过程中若发现新的数据流向，是纳入本轮还是留到下轮，由谁拍板。

什么情况下不适用：刚立项、还没上线的系统，直接做正式风险评估意义不大，先走上线前安全自查；等有真实数据流转之后再补正式评估，检查项才落得下去。

数据资产梳理与分级分类：所有维度的底座

资产梳理的颗粒度决定了后面所有维度能不能做。只写到「用户数据」这种层级，后面就没法判断某次访问是否越权、某个字段外发是否合规。落到字段级之后，权限、链路、日志三个维度才有一致的判定对象。

• 逐条列出数据项，每项至少写：来源、存储位置、留存期限、是否含个人信息或敏感字段、责任岗位。
• 分级分类口径要能落到字段，不是落到系统。同一系统里不同字段级别可能不同，评估表里分行列。
• 标注三类特殊流向：跨境、对外共享、二次利用。这三类往往触发更严格的评估路径，单独成表。
• 每项数据标注可删除或可匿名化的程度，这直接影响后续整改方案的可选项。

1. 拉一份字段级清单找业务或研发要一份数据字典，自己对一遍字段。验证方法：挑三个字段，问业务负责人它的来源和留存期限，答不上来就说明清单没做透。
2. 对分级分类口径打样抽几个字段按内部分级标准试分级，看是否出现同一字段两人分到不同级。若分歧大，说明口径本身要细化。
3. 标注特殊流向把跨境、共享、二次利用的字段单独标色，作为后续链路评估和合同审查的输入。

不适用情形：纯内部、不落盘的临时计算结果，可以在评估里声明豁免，但必须写明理由和责任人。含个人信息的字段即使不落盘，也要看是否进过外部接口。

账号、权限与最小化：问题最集中的一段

这一维度在实际评估中出现不符合项最多，也最容易被写成「加强管理」这类空话。可操作的做法是把账号清单和权限清单拉出来对撞，看有没有对不上的地方。重点盯三类：离职人员账号、共享账号、长期未使用的服务账号。

密钥存储这一项，原则和常见坑在站内安全与合规相关条目里已经讲过，本篇只做取证：密钥存在哪、多久轮换一次、谁能读到。评估时别只记录「已加密」，要记录加密方式和访问路径，否则整改无法验证。

不适用情形：人数很少的小团队，角色分离的检查项可标注不适用，但要补一条替代检查——关键操作（导出、删除、授权变更）是否可追溯到人。若连这条也做不到，就列为必改项。

数据流转链路与第三方：从提示词到日志的全过程

数据流图是这一维度的核心交付物。画图时不要画系统之间的架构图，要画数据从产生到销毁经过的每一个主体，包括调用外部模型接口、写进日志、进缓存这些容易漏的环节。每一个箭头都是一次数据出域的机会，都要有对应的说明。

• 每个传递点写清：传了哪些字段、目的是什么、对方如何留存、是否有书面约定。
• 缺约定的传递点一律列为风险项，等级看字段敏感度，不看待办心情。
• 使用第三方或中转通道的，确认它是否中转、是否落库。可去站内中转站目录逐个核对，那里对各家通道的检测项有更细的说明。
• 外部接口的调用凭证如何管理、谁能调用、调用频次是否可查，要写进表里。

什么情况下不适用：完全本地部署、不出内网的链路，第三方检查项可以标为不涉及。但仍然要评内部横向流转，比如测试环境能不能连生产库，这类问题跟出不出内网无关。

日志、审计与可追溯：出事时能不能还原

日志维度最怕写成「有日志」三个字就交差。可追溯性要能回答四个问题：谁做的、什么时候做的、对什么对象做的、结果是什么。评估时别只看日志是否存在，要做一次真实检索验证——随便挑一条历史敏感操作，让人当场还原出来。

1. 确定关键操作清单把下载、导出、删除、权限变更、对外接口调用列为关键操作。验证方法：问运营或运维，这些操作现在有没有留痕。
2. 核对留存与权限确认留存时长、谁能查看、能否按人按时间检索。留存时长的要求到站内合规专区核对当时的说明。
3. 做一次检索演练挑一条历史记录，限定时间内还原出人、时间、对象、结果四项。检索不出来，就说明审计能力有缺口。
4. 检查日志自身的敏感度确认日志里有没有完整记录敏感字段，避免审计手段本身变成新的泄露面。

不适用情形：日志能力还没建设的小团队，先保证关键操作有记录即可，其余列入整改计划，不必在本轮就要求全量日志平台。但关键操作的记录缺失，不能豁免。

威胁面与场景推演：别只对着表格打勾

只对着检查表打勾，容易漏掉组合型风险。加一段场景推演能把检查项串起来。建议按四类威胁来源各推演一到两个场景：内部人员误操作、权限滥用、外部攻击、供应链与通道风险。每个场景不必写得很长，但要落到具体的数据范围和控制措施上。

威胁来源的完整分类可以参考站内安全与合规专区里的条目，本篇只保留评估时的记录方式：每个场景写出触发条件、可能影响的数据范围、现有控制措施、剩余风险四项，缺一项这条场景就不算写完。

不适用情形：发生概率极低且已有兜底方案的极端场景，可以标注为接受风险，但必须写明决策人和接受理由。没有决策人签字的「接受风险」，复评时还是会被翻出来。

评估结论与整改排期：把清单变成能交差的输出

评估结论最忌讳只写一段文字描述。每个检查项给出四档结论——符合、部分符合、不符合、不适用——「部分符合」必须写清缺哪一部分。四档制的好处是评审时能横向比较，也方便下一轮复评时看趋势。

• 风险按影响面和可修复成本排序，拆成本轮必改和下轮计划两档。
• 每项落到责任人和验证方式，验证方式要写成可执行的检查动作，不是「持续关注」。
• 结论里写清残余风险和接受风险的理由，附决策人。
• 写明下次复评的触发条件：新增数据流向、更换供应商、业务模式变化等，触发即复评。

不适用情形：纯合规备案类的评估，结论格式要按监管口径来，别自创字段。这类评估的检查项和本篇重叠，但输出格式要服从要求。想对照各家通道与工具的实际检测情况，可以到站内目录和工具页面看当时整理的结果。