数据安全法建立了哪些国家层面的数据安全制度

你在做合规自查或跟客户解释时，常会被问一句「数据安全法到底定了哪些国家层面的制度」，答不上来或者只会背名字都很尴尬。这篇按制度清单加时间节点的思路，把每一类制度对应到你要做什么、去站内哪里核对当时的数字，最后给一份可照着走的自查顺序。

做合规自查或者给客户答疑时，「数据安全法确立了哪些国家层面的制度」这个问题出现频率很高。答不上来很尴尬，只背一串制度名字也没法落地。这篇换个思路：把每一项制度对应到「你要做什么动作、拿什么判断、去哪核对当前口径」，看完能直接照着走一遍自查。

先说清一个前提：这套制度不是并列的一排名词，而是分层嵌套的。定规则类的制度在前，管过程类的制度在中间，定角色类的制度兜底。分档没做完，后面的风险评估和出境判断都没有落脚点，所以顺序很重要。

先认清这套制度是分层设计的

• 分类分级是其他制度的前置条件，重要数据没定清楚，后面的风险评估和出境判断都无从谈起
• 三类制度要分开记：定规则决定标准，管过程决定动作，定角色决定谁负责，混在一起最容易乱
• 注意嵌套关系：出口管制和安全审查的判断，很多都依赖分类分级的结果，不要跳过第一步
• 什么情况下不适用：只处理公开数据、且不涉及个人信息的小型业务，多数制度只落在「一般数据」这一档，不必按重要数据口径自我加压

分类分级与重要数据目录：一切制度的起点

1. 盘数据资产按系统、按业务线拉一张表，标出数据来源、流向、存储位置和接触人。字段不用多，但每行都要能追到一个具体系统。
2. 分档并标注按行业监管口径分档，把疑似重要数据单独列一张表，不要混在普通业务表里。拿不准的按从高从慎处理，并留一问一答的记录。
3. 统一术语口径填表前先到 安全与合规分区（/safety） 看有没有对应的术语条目，口径统一后再填，避免各部门各写一套。
4. 留登记纯内部测试环境、数据不出开发机且不含个人信息的，可以先按低档管理，但仍要留一份登记，方便后续追溯。

风险监测预警与应急处置：从制度落到值班表

制度要求的是「发现—报告—处置」闭环，所以要准备的是三样东西：监测指标、上报接口人、处置预案。只写一句制度名字，检查的时候等于没有。

• 先定监测范围：哪些日志、哪些系统、采集频率多高，范围定太宽没人看，定太窄等于没监测
• 再定告警阈值和分级，区分「看一眼就过」和「必须叫人」两类
• 最后定上报链路：谁在什么时间点、通过什么渠道上报给谁，写清备份联系人
• 小团队没有对外服务、数据量很小，可以把监测频率放低，但应急联系人和止损路径必须写出来

监测口径写清之后，可以到 监控工具目录（/tools/quality-monitor） 比一比现成工具能覆盖到什么程度，别用人工盯替代自动化采集。

评估、认证与审查：什么时候必须做

风险评估

自己组织的例行体检，看现有措施和当前数据状况是否匹配

认证

由第三方机构出具的证明，用于对外说明合规状况

安全审查

特定场景触发的监管动作，通常与重要数据、出境、并购或集中采购相关

这三个经常被混成一件事。先分清再决定预算：例行风险评估要排进年度计划；认证按业务需要决定要不要做；安全审查属于被动触发，该申报的时候主动申报，不该申报的别硬凑。

• 判断标准：涉及重要数据、跨境、并购或集中采购的场景，通常触发审查类要求
• 只做内部系统、数据不跨境的一般业务，按例行风险评估节奏走即可
• 具体做几次、隔多久做一次，别照抄网上说法，到 /safety 找风险监测预警和评估类文章核对当前口径
• 数据全在本地、不跨境、不涉及重要数据的场景，不必主动去申报审查，但相关材料要能随时拿出来

一份能照做的自查顺序

1. 拉数据资产表按系统逐个过一遍，每条数据标出来源、用途、接触人。
2. 标注敏感项标出个人信息和疑似重要数据，单独建表，不要和普通业务数据混排。
3. 比对制度清单把三项定规则类、三项管过程类、三项定角色类逐条对，找缺口。
4. 补文件与责任人缺预案补预案，缺人补人，每份文件写清生效时间和负责人。
5. 留档每次自查留一份带日期的版本，后续被问到时能证明你什么时候做了什么。

时间节点不要凭印象说。实施日期和过渡安排在站内有多篇文章专门讲，直接到 /news/daily 追更新，或到 /safety 找实施时间相关的解读。

制度是底线不是上线；为了凑清单把低风险数据也按最高档管，成本会压垮执行。