中华人民共和国数据安全法中规定了哪些内容

很多人被问「数据安全法到底管什么」时，只能背出「数据分级分类」几个词，真到填合规自查表、跟法务对口径就卡住。这篇按章过一遍：法律要求了哪些制度、给数据处理者派了哪些义务、哪些义务落到你头上，并给一份可勾选的对照清单。数字和条文口径到站内页面核对。

一章一章看：这部法到底立了什么

别一上来就背条文。先把这部法的骨架铺开：它大致是按「总则—数据安全制度—数据安全保护义务—政务数据—法律责任」这条线走的。先看总则划定边界，再看制度章讲国家建了哪些机制，最后落到义务章——那才是大多数公司真正要对照执行的部分。顺序看下来，你脑子里会有一张地图，再抠细节就不容易迷路。

看总则时抓三个点：谁受管、什么算数据、立法的取向是什么。这一章不给你具体动作，但决定了你后面要不要继续往下读。如果总则读完发现你根本不碰数据处理，那后面几章基本可以跳过；如果碰，哪怕只是顺带存了点用户信息，也得接着看义务章。

• 总则回答「我是谁」：判断你这家公司属不属于受管的数据处理者
• 制度章回答「国家建了什么」：分级分类、风险评估、出口管制、反制这些机制
• 义务章回答「我要做什么」：这一块才是你日常对标的对象
• 政务章回答「政府那摊怎么管」：和你是不是政务数据提供方直接相关
• 责任章回答「不做会怎样」：用后果倒推哪些义务不能拖

1. 先过一遍总则只看适用范围和原则那几句，写下「我是不是数据处理者」这个判断，答案模糊就先按「是」往下走
2. 再扫制度章把国家层面的机制名称列成一张清单，标一下哪些可能间接传导到你，比如涉及数据出境或敏感行业的
3. 重点放在义务章逐条对照自己的业务流：收集了什么数据、存在哪、谁能访问、有没有对外提供，把缺口记下来
4. 最后用责任章收尾回头看你标出的缺口，按可能被追责的严重程度排个优先级
5. 去站内页面对一遍条文措辞和制度名称别凭记忆背，到站内数据安全法相关页面逐条核对再下结论

这套地图有它不适用的地方。如果你所在行业有专门的监管规则、或者你的数据活动主要落在其他专门法里，那这部法的义务章可能只是你的底线而不是全部要求，得另外对照行业规定看。另外，条文的具体措辞和制度名称会随配套规定调整，别用几年前的记忆去套，去站内页面对一遍当时的表述再动手。

执行者的义务清单：哪几条是冲着你来的

数据安全法里真正落到具体人身上的义务，可以分三层看：一层是「你有没有在做事」的面状义务，一层是「出没出事」才知道有没有做的触发型义务，一层是「你手里有没有重要数据」决定的高阶义务。判断哪几条冲着你来，先别问公司多大，先问自己手里有什么数据、经手哪些环节。

面状义务：几乎所有处理者都要答的那几条

• 建立全流程数据安全管理制度：从采集、存储、使用到删除，每个环节谁负责、怎么审批、留什么记录，要能说清楚
• 组织数据安全教育培训：不是发个通知就算，要有培训记录、覆盖岗位、内容跟实际处理活动对得上
• 采取技术措施保障数据安全：加密、权限、日志、备份这些是底线动作，重点不是有没有买工具，而是有没有真的用起来
• 落到AI接入场景：把用哪家模型、传了什么数据、谁批的、留没留日志，写进制度而不是口头约定

这三条是典型的「面状义务」，特点是覆盖面广、平时不显眼。很多团队觉得制度文件没什么用，但真被检查或出事倒查时，第一句问的往往就是「你们有没有制度、有没有培训、有没有技术措施」。如果这几条答不上来，后面就算技术做得再好也容易被认定成管理缺位。不适用的情况很有限：纯个人、非经营性、完全不涉及境内数据处理活动的，多数义务不落你身上，但边界别自己拍，跟法务确认。

触发型义务：出事那天才开始算账的几条

1. 风险监测日常要有能发现异常的手段，比如访问日志、异常调用告警、数据外发监控；验证方式是问自己一句：真有人批量拉数据，我几天能发现
2. 补漏洞发现风险后要有整改闭环，谁改、什么时候改完、怎么验证；别只留一句「已处理」，要留下可复查的记录
3. 事件处置出事后先控制、再定位、再评估影响范围，动作顺序要提前定好，别现场临时想
4. 告知与报告达到需要告知或上报的程度时，按法定路径走，别自己判断「应该不用报」；判断门槛和流程去站内合规相关页面核对当时的口径

这几条平时看不出差别，出事后就成了追责重点。容易被忽略的是「告知与报告」：很多团队出了事第一反应是内部压住、先修好再说，但该告知用户、该上报的时间窗口一旦错过，性质就变了。所以这几条要提前定人定流程，而不是出事再找人。

重要数据这条线：看数据，不看公司规模

判断门槛

核心问题是「你手里有没有重要数据」，跟公司人数、营收、规模没有直接关系

指定负责人

要有明确的负责人和管理机构，不能是「大家一起管」

定期风险评估

按周期做评估，并把结果按规定报送，不是做完自己留着

容易踩的坑

小团队也可能因为某类数据被认定为重要数据处理者；不确定就先别按「我们小没事」来判断

这一层最反直觉：不是大公司才要管，而是手里有没有那类数据才决定。一家 5 人小团队如果业务里经手了被认定为重要数据的内容，同样要指定负责人、定机构、定期评估并报送。反过来，规模不小但确实不碰这类数据的，这条线就不一定落在你身上。具体哪些属于重要数据、报送周期怎么算，以站内资料库和当时的官方口径为准，别凭印象定。

场景义务：AI接入和数据外发的团队重点看

• 委托处理：把数据处理外包或交给第三方时，要在协议里写清处理目的、期限、方式、安全要求，并做必要的监督
• 向第三方提供：不是签个合同就完事，要评估接收方、明确用途、留下审批和记录
• 数据出境：有单独的动作要求，先判断是否触发条件，再走对应路径，别先传了再补手续
• AI 接入要注意：把数据发给模型服务方，本质也是一种对外提供，属于要重点看的场景

先查自己手里有什么数据、经手哪些环节，再对照义务清单，比笼统地问「我要不要合规」有用得多。

从哪个角度给你派活：三个视角

《数据安全法》条文不少，但真到自己团队落地时，一条条背下来基本没用。更实际的做法是换三个角度来切：数据在哪一步、你在哪个角色、数据是什么等级。三个角度各查一遍，重叠出来的部分就是你要动手做的事。

按生命周期看

收集、存储、使用、加工、传输、提供、公开，每一环都有对应义务，适合拿来查漏。

按角色看

数据处理者、受托方、平台方，同一件事责任归属不同，先确定自己站哪一边。

按风险等级看

一般数据、重要数据、核心数据，等级不同要求不同，先打标再谈别的。

视角一：沿着数据生命周期排查

1. 列出数据流把自家系统里数据从进到出的路径画出来，标出收集、存储、使用、加工、传输、提供、公开这几个节点分别在哪段代码或哪个服务上。
2. 逐节点对义务每个节点问三件事：谁在操作、数据存在哪、会不会流到外部。答不上来的节点就是风险点。
3. 标注缺口把对不上义务的节点单独记下来，形成一张待处理清单，比笼统说「要合规」有用得多。

这个视角的好处是排查不会漏。很多团队只盯着「有没有把数据发给第三方」，却忘了收集环节的告知、存储环节的权限、加工环节的脱敏。生命周期是一条线，顺着走比跳着看靠谱。

视角二：先确认自己是哪种角色

接第三方 AI API 的团队，绝大多数情况是数据处理者，不是受托方。你决定把什么数据发出去、发给谁、用来干什么，这个决定权在你手上，责任也在你手上。别因为用的是别人的模型，就默认自己是受托方。

什么情况下不适用：如果你的产品只是纯转发，处理目的和方式完全由上游客户定，自己不留存也不判断，那才可能落到受托方那一侧。这种边界要结合具体合同看，拿不准就去站内合规相关页面核对当时的口径。

视角三：给数据打标，再谈动作

• 先做资产盘点：把库里、日志里、缓存里的数据字段列出来，不要求全，先求有。
• 给每个字段打上等级标签：一般、重要、核心，判不准的单独放一栏待定。
• 按等级定动作：一般数据按常规权限管理；重要数据要额外的访问控制、留痕和审批；核心数据从严，能不动就不动。
• 定期复核标签：业务变了，数据等级也会变，别打完一次就放着。

分级标准和重要数据目录的具体口径会调整，不要凭记忆，直接到站内的合规资料页看当时的版本。等级判错的代价比没分级的还大，因为你会按错误的假设做防护。

三个视角叠起来用

把生命周期当行、风险等级当列，格子里填自己该做的动作，这张矩阵比逐条背法条好落地得多。角色那一维可以叠加在备注里：同一格，数据处理者和受托方要做的事可能不同，谁的义务谁认领。

照着走：一次自查的动作顺序

自查这件事，最怕上来就翻法条。顺序反了，容易陷在条款细节里出不来，最后列一堆看不懂的术语交差。更实用的做法是反过来：先看自己手里有什么数据，再回头对义务。下面这套四步顺序，适合有一定数据量的团队照着走一遍。

1. 第一步：盘数据把团队经手的数据列成一张清单，按系统、按业务线、按用途各列一遍都行，关键是别漏。列完之后逐个标注：哪些可能落在敏感个人信息、重要数据这类高等级里。标不出来不要空着，先按最高等级的预案处理，等确认了再往下调。宁严勿松，漏标的代价比多标的代价大得多。
2. 第二步：对义务拿上面的清单当检查表，逐条对着法定的义务打勾：该做的做了没有，该有的有没有。缺哪个就记哪个，打不上勾的就是整改项，不要当场解释「我们情况特殊」，先记下来再说。这一步的产出应该是一张带勾和叉的表，不是一段感想。
3. 第三步：补机制整改项之外，还有四样东西是检查时最常被要的：制度文件、责任人、培训记录、事件处置流程。缺哪样补哪样。责任人要落到具体的人头上，写「某某部门负责」通常不算数；培训记录要有时间有内容有参加人；处置流程要能说清出了事谁先动、多久上报。
4. 第四步：留痕评估报告、整改记录、内部审批这些材料，按统一的命名和留存期限放好，放在大家都能找到的地方。别等到被问才现找，翻聊天记录凑材料，既慢又容易露馅。命名建议带业务线、材料类型、形成时间三个要素，谁都能一眼认出来。

想对照法条原文和站内整理的口径，可以到 指南中心的数据安全法页面（/guides/data-security-law） 看当时的梳理；如果要连中转站或第三方 API 一起纳入自查范围，建议把它们的可信度情况也一并过一遍，到 中转站可信度检测页面（/relay/trust-check） 核对当时的结果。具体义务条目的表述，以站内资料库对应页面的最新版本为准。

最容易踩的四个坑

先把一个常见的混淆讲清楚：数据安全法管的是「数据」这个大圈，个人信息只是其中一类。很多人写合规材料时，直接把个人信息保护法那套搬过来套数据安全法，结果范围对不上。判断方法很简单：先问这条内容的对象是「所有数据」还是「个人信息」，是前者才归数据安全法这条线。

第二个坑是「只写制度不落动作」。文档里写「建立数据安全监测能力」很容易，但检查的人会问：日志在哪、保留多久、告警发给谁、有没有处置记录。监测如果没有日志和告警，等于没有。写材料时把制度句改成动作句，每句话后面能接上「谁做、在哪留痕」才算落地。

• 制度写「开展监测」时，补一句监测对象和留痕位置，否则无法自证
• 日志要有人可查、可导、可追溯，只存不看不等于监测
• 告警要有接收人和处置闭环，否则出现异常也没人动
• 定期自查一次，把「说了」和「做了」的差距列出来补
• 判断适用性：如果业务根本不产生该类数据，这条可以简化说明，不必硬凑

1. 先分圈把手上内容按「所有数据」和「个人信息」分两栏，确认哪些属于数据安全法的主线，避免范围混着答。
2. 再落动作把每条制度句改写为动作句，补上执行人、留痕方式、检查口径；没有留痕的条目直接标为待补。
3. 认定重要数据先做数据目录和分类分级，再判断哪些属于重要数据；识别出来后确认是否需要报送以及走什么路径，两步都做完才算齐。
4. 定跨境路径不要默认走标准合同，先判断自身数据类型和场景对应哪条路径，路径定错，后面的材料准备都是返工。

第四个坑最隐蔽：跨境传输想当然。很多人以为签了标准合同就万事大吉，其实第一步是判断走哪条路径，路径选错，后面的评估、合同、备案都白做。判断顺序是先看数据类型和规模，再看适用哪种出境方式，最后才准备对应材料。什么情况下不适用：如果根本不涉及数据出境，这一段可以略过，但要能说清为什么不存在出境场景。