系统重大变更后：密评要不要重做，怎么判断
变更单上写着核心交换机替换、数据库迁移到政务云、登录方式改为统一身份认证。审批流程走完，系统照常运行，密评这一栏却空着。真正要回答的不是「要不要再做一次」，而是这次变更有没有让上一次评估的结论失效。
一、先把两个概念分开：周期性评估与触发式评估
《商用密码应用安全性评估管理办法》第九条要求，重要网络与信息系统建成运行后，每年至少开展一次密评。这是周期性义务，与变更无关。
同一体系里另有两处触发式要求。第十五条规定，运营者发现密码相关重大安全事件、重大密码安全隐患或者特殊紧急情况的，应当及时报告、启动应急处置方案，必要时开展密评。第七、八条则把评估嵌在「方案—建设—运行」的链条上：方案未通过评估不得作为建设依据，运行前未通过不得投入运行。
所以密评没有「有效期」一说，只有频率与触发时点。变更属不属于触发情形，取决于它动了什么。
二、三条法条接口，指向同一件事
第一条是方案接口。第七条把方案评估设为建设前置条件。方案是评估的对照基准，方案变了，原来的评估结论就失去了支点。
第二条是建设期接口。《关键信息基础设施商用密码使用管理规定》（令第 5 号，2025 年 8 月 1 日施行）第十二条写得最直接：建设过程中需要调整商用密码应用方案的，应当重新开展密评，评估通过后方可按调整后的方案继续建设。这条把「改方案就要重评」写成了明文，但适用范围限于关键信息基础设施，且限于建设过程中。
第三条是运行前接口。第八条规定，系统运行前应开展密评，未通过的应当改造，改造期间不得投入运行。一次大变更之后的系统，在密码应用意义上接近一个新系统。
三条合起来的口径是：变更只要改到了方案里写过的内容，就要回到方案评估；改到足以改变系统边界或等级，就要连运行前评估一起重做。
三、六个判断维度：什么算重大变更
运维侧可以用一张清单过一遍，任一项为「是」，就应当进入重评流程：
- 系统边界与等级：新增子系统、拆分或合并、等保等级上调
- 重要数据：新增重要数据类别、流向变化、出境或出域
- 密码技术产品服务：更换密码机、改用云密码机、更换算法套件或协议版本
- 密钥管理：密钥生成、分发、存储位置或责任主体发生变化
- 部署形态：自建机房迁至政务云或第三方 IDC，新增多活、灾备节点
- 身份与信任体系：口令改为证书认证，更换证书体系或时间戳来源
反过来，只做硬件扩容、同型号替换、性能升级，密码能力与方案描述一致、密钥管理机制未变，一般不构成重评触发，随年度评估覆盖并在变更记录里留痕即可。指标口径可对照等保测评标准与指标。
四、四种情形，四种处置
- 情形一，能力等价变更：不改方案，随年度评估覆盖，留存变更记录与设备台账
- 情形二，方案要素变更：先修订方案，再做方案评估，通过后实施，运行前评估，最后更新备案
- 情形三，边界或等级变更：先在等保侧重新定级备案，再重编方案、方案评估、运行前评估、备案
- 情形四，发生密码相关重大安全事件或隐患：按第十五条报告并启动应急处置，必要时开展评估
最容易出事的是情形二被当成情形一处理：换了密码产品，方案没改，年度评估时才发现对照基准已经对不上。
五、报告与备案怎么衔接
第十四条要求，评估报告形成后 30 日内报送备案，密码管理部门做形式审查，国家密码管理局可抽样检查，不合格的重新开展评估。变更后重新出具的报告，同样要走这道程序，不是上次备过案就不用再备。
旧报告不能覆盖新状态。它证明的是某个时点的方案与运行情况，变更之后仍应归档留存（自行开展评估的，原始记录与报告保存不少于 6 年），但不能拿来证明变更后的系统。
云上部署的系统还要多一层：平台侧报告由平台运营者出具，应用侧的变更仍需应用运营者自己评估，备案信息表里要填云平台的备案编号与评估结果。责任划分见等保等级划分。
六、四条常见误判
- 变更走了审批流程，就认为合规动作已经完成。变更管理管的是风险审批，不管密评义务
- 年度评估还没到期，先不动。周期性评估与触发式评估并行，不互相替代
- 只换了设备型号，性能更好，不必重评。判断标准是密码能力与方案是否一致，不是性能
- 云平台刚过评估，应用跟着过。平台结论只能支撑平台侧，应用侧要单独判定
还有一条更危险：改造期间先上线、回头补评。第八条对此是明确禁止的。
七、落地顺序与周期
建议把「是否触发密评」做成变更审批单上的一栏，由密码管理员签字。真的触发了，按五步推进：变更影响评估约 1–2 周，方案修订 2–4 周，方案评估 2–4 周，实施与联调 4–12 周，运行前评估与备案 3–6 周。整体周期以属地要求和项目实际情况为准。
密评相关栏目见密评整改与实施，机构与资质口径见密评机构说明。
就密评而言，辅导类服务包括差距分析、方案编制、改造陪跑与协助对接持牌检测机构；评估报告须由具备资质的检测机构出具。