合规岗最常见的卡点不是「要不要做评估」，而是接到通知后不知道从哪儿下手：评估项列不全、材料交上去被打回、报告写完发现缺了资产清单。这篇按评估前、评估中、出报告三段，把评估项和交付物对齐成一张可勾选的表，同时说清哪些情况下这套口径不适用。
合规岗接到「做一次数据安全风险评估」的通知，最容易卡在第一步：不知道评估项从哪来、交付物长什么样，于是先去网上搜模板，抄一份别人的清单往自己业务上套。结果交上去被打回，理由是「资产范围没写清」「副本和测试数据没覆盖」。这篇按评估前、评估中、出报告三段，把评估项和交付物对齐成一张能勾选的表。
先明确一件事：评估项不是一张通用问卷，它跟着你的数据流走。下面四层是梳理顺序，不是照抄顺序；具体条目按你的业务画完数据流之后再对标准，缺项往往就藏在副本、测试数据、离职账号这些边角位置。
评估项先分四层，别一上来就填表
第一层看资产和数据本身：数据分类分级的结果、数据在哪些系统之间流转、存在哪里、有几个副本、备份策略是什么。这一层不做实，后面全是空中楼阁。很多团队的返工就出在这里——只列了主库，忘了备份库、测试库、导出到本地的表格文件。
第二层看处理活动。收集、存储、使用、加工、传输、提供、公开、删除这几个环节，逐个问：谁在碰这批数据、走什么权限、有没有审批记录。第三层看管理和技术措施，制度文件有没有正式发布、权限是否做到最小化、脱敏和加密具体落在哪个字段、日志留多久。第四层看主体和外部关系，供应商、外包、跨境传输、第三方接口，凡是数据出了你控制的边界的，都要单独列。
| 层级 | 评估什么 | 常见漏项 |
|---|---|---|
| 资产与数据 | 分类分级、流转路径、存储位置、副本备份 | 备份库、测试数据、本地导出文件 |
| 处理活动 | 各环节操作人、权限、审批留痕 | 运维直连、临时提权 |
| 管理技术措施 | 制度发布、权限配置、脱敏加密、日志审计 | 制度没版本号、日志覆盖不全 |
| 主体与外部 | 供应商、外包、跨境、第三方接口 | 离职账号、停用但未回收的接口 |
- 先画一张自己的数据流转图，标注每个节点存在哪个系统、谁有权限
- 拿这张图逐条对标准条目，缺的补，不适用的标注理由
- 重点排查三类高频缺口：数据副本、测试环境、离职或转岗账号
- 评估项清单定稿前让业务方过一遍，技术侧列全了业务侧未必认账
交上去之前：证据材料按「可核对」来准备
评审方看的不是你的描述，是你能不能当场调出一份材料对上。制度类证据要有发布版本和生效记录，技术类证据要有配置截图或导出的策略文件，别只写一句「已配置加密」。凡是写成结论而没有出处的条目，评审时都要现场翻系统。
访谈记录也属于证据。别只写「已确认权限最小化」，要记清问了谁、在什么场景下问的、对方具体怎么答的。这条在事后追责时是你自己的免责凭证——证明你尽到了核查义务，而不是抄了别人的结论。
- 材料清单按数据流顺序编号，和评估项一一对应
- 每份材料标注获取方式：谁提供、从哪个系统导出、导出时间
- 附件命名统一，别出现「新建文件夹」「最终版2」这种命名
- 不确定某条标准的当前表述口径，去 /safety 的对应条目对照，别沿用旧模板
交付物别只交一份报告
很多人以为交付物就是一份评估报告，交完才发现对方要整改计划和附件包。稳妥的做法是三件套：评估报告正文、问题与整改清单、支撑材料附件包。组织规模大一点、要过管理层的，再加一份摘要，把风险发现和资源需求讲清楚。
报告正文的骨架基本固定：评估范围与依据、数据资产和处理活动描述、风险发现、风险等级判定、整改建议与责任分工、结论。整改清单必须有责任人和时间点，没有责任人的整改项基本等于没有——评审完就没人跟了。
- 先出正文骨架按固定六段搭框架，先填范围和资产描述，这两段不实后面全返工
- 再出问题清单每条风险对应一条整改项，写清责任部门、动作、时间点
- 最后收拾附件包按评估项编号排列，和正文里的引用编号一致
- 提交前自检让没参与评估的同事按附件清单随机抽查两条，看能不能对上
报告留证注意版本管理。改一版留一版，别在同一个文件上反复覆盖，否则事后说不清哪一版是提交版。涉及具体数字的部分，比如整改项数量、覆盖系统数，统一到 /tools/quality-check 核对当时的统计口径，避免不同版本对不上。
什么情况下这套口径要打折
不是所有团队都该做全套。业务数据量很小、不涉及个人信息和重要数据的团队，硬套全套评估项，最后产出的是一堆没人看的文档，占用的是本可以做实事的工时。这种情况聚焦两件事就够：数据资产盘点、权限核查。这两件做完，风险面基本就摸清了。
纯内网、无外部传输、无第三方接入的环境，跨境传输和供应商条款这部分可以直接标注不适用，但要在报告里写明判断理由，不能只写「不适用」三个字，否则评审方会认为你漏项。
- 刚评估完、业务和数据流没有变化，短期内重复做收益很低，频率怎么定去看 /ai-dict/category/safety 的相关条目
- 评估范围只覆盖部分系统时，结论里要写清边界，别让读者以为全公司都评过了
- 拿不准自己属于哪一档，先用 /tools/quality-check 自查，把明显缺口补上再决定要不要启动完整评估
- 涉及跨境或行业监管特殊要求的，以监管口径为准，别用通用清单替代
常见问题
评估项是不是必须一条不落地全做？
不是。评估项是检查维度，不是逐条打卡表。真正要保证的是每一类风险都有对应的判断结论，哪怕结论是「不适用，理由如下」。写不适用比空着更安全，因为评审方能看到你确实判断过。如果数据量小又无个人信息，硬做全套只会堆出一堆没人维护的文档。
报告交上去被打回，最常见的原因是什么？
多数是资产清单和实际数据流对不上：报告里写的存储位置、副本数量、权限范围跟现场一查不一样。其次是整改项没有责任人和时间点。建议提交前自己按数据流走一遍，把每个环节的负责人和对应材料编号核对齐，再交出去，返工成本会低很多。
评估做一次能管多久？
没有统一答案，取决于业务变化速度。业务线、数据流向、第三方供应商、部署位置任一发生变动，之前的结论就要重新看。判断标准不是时间到了没有，而是这几项变了没有。具体频率惯例可以到 /ai-dict/category/safety 对照当期口径，别直接照搬别人的周期。
