合规执行者最常卡在两句话上：一是「按规定周期做」，二是「发生重大变化时重评」，但周期到底多长、什么算重大变化，没人给你现成答案。团队要么一刀切每年一次走过场，要么出了事才补。这篇给一套判断顺序：先看适用哪类周期要求，再按数据变更幅度定触发阈值，最后把频率落进年度计划与留证清单。
合规执行者最常卡在两句话上：一是「按规定周期做」，二是「发生重大变化时重评」。但周期到底多长、什么算重大变化，条文不会给你现成答案。团队要么一刀切每年一次走过场，要么出了事才补。这篇给一套判断顺序：先看适用哪类周期要求，再按数据变更幅度定触发阈值，最后把频率落进年度计划和留证清单。
先说清一个前提：本文不替你做决定，只给判断口径和动作。具体的天数、条款编号、行业细则，一律回你适用的那份规定原文确认；站内只做整理与对照，最终以官方文本为准。
为什么「多久做一次」没有统一答案
周期要求通常写在法规和标准里，但落到你的业务，还取决于数据量级、敏感程度、处理方式和外部依赖。同一条「定期评估」，在一家 5 人小团队和一家多系统并行的大公司里，可执行的含义完全不同。所以第一步不是找标准答案，而是先承认没有唯一答案。
- 口径不固定，结论就没法比：评估对象是整条数据链路还是单个系统，频率结论能差出好几倍，先定口径再谈周期
- 同一家公司不同系统可以有不同频率：按最高标准一刀切浪费人力，按最低标准统一又会漏掉高风险系统
- 外部依赖会改变风险：只要接了第三方接口、外包运维或外部模型服务，评估范围就被撑大，周期要跟着收
- 历史事件是硬信号：出过一次问题还沿用原周期，等于明知风险不调整，这在检查时很难解释
先分清三类周期来源：法定、行业、自定
很多人上来就问「一年一次够不够」，其实该先问「我这套系统受哪类要求管」。三类来源的效力不同，混在一起谈最容易吵不出结论。
| 来源 | 给的是什么 | 怎么落地 |
|---|---|---|
| 法定与监管要求 | 通常是「定期」加「发生重大变化时」两个触发条件 | 天数回适用条文原文确认，别用二手转述 |
| 行业与上级要求 | 金融、医疗、政务、工业等往往有更细的自有节奏 | 以主管单位文件为准，冲突时从严 |
| 自定频率 | 前两类没覆盖的部分，由你按风险自己定 | 制度里要写明依据，不能只写「视情况」 |
三类里最容易含糊的是自定频率。它不是你随便填的数字，而是一段有推导过程的结论：因为数据敏感度是什么、暴露面多大、变更频率多高，所以定成这个档位。推导过程写进制度，人员轮换时才能交接，检查时也站得住。
条文和整理口径会更新，别拿半年前的记忆做判断。查最新口径和条文变化，到 /safety 核对当期整理；名词拿不准时先到 /ai-dict/category/safety 对照，避免制度里的用词和监管口径打架。
什么算「重大变化」：触发式重评的判定线
「定期」只是底线，「发生重大变化时重评」才是真正吃掉时间的那条。难点在于没人替你定义什么算重大。解决办法是把判定线写成可勾选清单，值班同学照着勾，而不是靠感觉。
- 列数据侧判定线新增敏感字段类型、数据量级跨档、处理目的改变、留存期限延长，命中任意一条即触发重评
- 列系统侧判定线上云迁库、换数据库或中间件、新增对外接口、接入第三方模型或外包服务，命中即触发
- 列组织侧判定线数据安全负责人变更、重大权限调整、发生安全事件或收到监管问询，命中即触发
- 把清单变成可执行动作每条判定线后面挂一个责任人，勾中后由谁在几个工作日内启动重评，写清楚，别只写「及时」
判定线的价值在于减少争论。有清单之前，「这算不算重大变化」是一场会议；有清单之后，它是一次打勾。清单不用一次做到完美，先覆盖最常发生的几类，跑一轮再补。
如果做的是接口类的数据流转，触发条件可以参照 /official-api 里同类业务的接口与数据范围描述做横向对照，看看同行的评估范围大概画在哪，避免自己划得过窄。
自定频率怎么推：按风险等级分档排周期
三类来源里，自定频率最需要方法。推荐做法是先给系统打风险分，再按档位排周期，而不是拍脑袋定一个统一数字。
| 风险档 | 判断特征 | 频率取向 |
|---|---|---|
| 高 | 敏感度高、暴露面大、调用方多、有历史事件 | 周期最短，触发式重评执行最严 |
| 中 | 部分特征偏高，但链路相对封闭 | 周期居中，年度确认加事件触发 |
| 低 | 数据不出内网、无第三方接触、变更极少 | 周期可最长，但保留年度确认，不等于免评 |
- 打分维度先定死：数据敏感度、暴露面、调用方数量、历史事件，四项固定，别每次换标准
- 三项以上偏高归高风险档，一到两项偏高归中风险档，其余归低风险档，分档标准写进制度
- 低风险不等于免评：至少保留一次年度确认，确认可以简化但不能没有记录
- 频率不是越密越好：评估要真跑一遍链路才有意义，跑不动的高频等于没做
- 频率调整要有理由：缩短或延长都写清触发原因，检查时这比数字本身更重要
分档尺度拿不准时，可以先跑一版试算，把各个系统分完档再看人力是否吃得下。如果高风险档数量多到跑不动，说明打分校准有问题，或者评估范围该收敛到关键字段而不是整条链路。
时间紧怎么办：把一次评估做成可复用的模板
频率定得再合理，执行不动也是空谈。提速的关键不是把评估做浅，而是把第一次做扎实，之后改增量。
- 固定四份底稿：评估范围、数据流图、字段清单、接触人员名单，下次改增量而不是重写
- 每一步留证据：谁评的、依据哪份材料、结论是什么、谁签的字，缺一样检查时都可能被判未有效执行
- 结论要对应整改动作和责任人，报告再厚，落不到整改就没法在下一次复用
- 把周期写进年度合规计划，和审计、演练排期错开，避免同一批人同一周被压三件事
- 报告口径和留证格式可参照 /tools/quality-check 的检查思路，先对齐再动笔
这些情况别照搬固定周期
前面讲的是一般规律。以下场景如果照搬自然年节奏，反而会做出无效评估，或者错过真正该评的时点。
- 项目制业务：项目结束数据即销毁的，按项目节点评比按自然年评更合理，节点没到就别硬凑
- 完全封闭的内网系统：数据不出内网、无第三方接触的，频率可适当放宽，但要有技术证据支撑，不能只靠口头说明
- 刚做完全面评估且期间无变更的：下一次可做范围收敛的复核，不必重复全量
- 监管临时要求或行业专项检查期间：以主管部门指定的节奏为准，自定周期自动让位
判断「不适用」也需要留证。你说这个系统可以放宽，凭什么？把技术控制、访问日志、无外部接口的证明留档，放宽才站得住。否则检查时这就是一个解释不清的口子。
频率定完之后：留证、复核与调整
周期不是定完就锁死的。每跑完一轮，回看一次频率是否合适：漏掉的触发事件、白跑的评估次数，都是调整信号。
| 动作 | 留什么 | 多久回看一次 |
|---|---|---|
| 单次评估 | 评估记录、整改台账、结论签批 | 评估完成后立即归档 |
| 频率复核 | 触发事件命中记录、评估耗时与人力占用 | 每轮周期结束时 |
| 制度更新 | 周期表与触发清单的最新版本 | 人员或业务发生变更时 |
- 年末把清单过一遍看这一年有没有该触发却没触发的事件，有就说明判定线写漏了，补进去
- 看人力占用是否合理某档系统的评估频繁到影响正常交付，说明分档过严或范围过宽，调整而不是硬扛
- 确认交接可用让没参与过的人只看制度文件，能否说清周期和触发条件，说不清就补写说明
- 同步到年度计划把下一年的周期排期写进合规计划，避免每年临时重新讨论一次
最后提醒一句：站内整理的周期口径和条文对照会更新，别把这里的表述当成条文原文。涉及具体天数、适用范围的判断，一律回到 /safety 看当期整理，并以你适用的官方文本为准。
下一步把本文的判断顺序落到你自己的系统清单上：先按 /safety 当期整理确认适用哪类周期要求，再给系统打风险分排档，最后把触发清单和周期表一起写进制度文件。→常见问题
数据安全风险评估必须每年做一次吗？
不一定。「定期」是原则性要求，具体周期取决于你适用的法规、行业规定和自身风险等级。有的系统要求更密，有的封闭系统可以放宽。关键是制度里要写明你依据什么定的周期，并能拿出按这个周期执行的记录。
业务没变化，是不是可以不做下一次？
不建议。触发式重评之外还有定期评估这条线，两者是并列的。而且「没变化」需要证据支撑：数据字段、接口、接触人员、第三方依赖都比对过一遍，才敢下这个结论。
评估频率定得太密会不会浪费人力？
会。跑不动的高频等于走形式。更稳的做法是分档：高风险系统周期短，低风险系统保留年度确认，把省下的精力花在高风险系统的深度评估和整改上。
换了一个第三方模型或中转服务，要重评吗？
要。数据处理者变了、数据流向变了，属于典型触发事件。重评至少覆盖新增的传输路径、对方的数据用途约束和留存策略，别只看对方官网的合规声明。数据边界的原则可先看 key-safety。
报告要留多久、给谁看？
留存期限跟着你的数据留存和审计要求走，通常不短于一轮评估周期。对内给数据安全负责人和审计，对外在监管问询时按需提供，平时不必主动分发。
