做合规或运维的同事常被问一句「网络安全法到底管了数据安全哪些事」，答不上来就只能翻全文，条款又散又抽象。这篇不谈立法背景，只把跟数据有关的几类制度拉成一张清单，配上「什么情况下用得上、什么情况下不适用」的判断口径，让你能对自己公司的日志、权限、应急预案对着查一遍。
做合规或运维的同事常被问一句「网络安全法到底管了数据安全哪些事」，答不上来就只能翻全文，条款又散又抽象。这篇不谈立法背景，只把跟数据有关的几类制度拉成一张清单，配上「什么情况下用得上、什么情况下不适用」的判断口径，让你能对自己公司的日志、权限、应急预案对着查一遍。
先说结论性的判断方法：别把这部法当数据安全法来读，它的主线是网络运行安全，数据安全是被嵌进去的一条支线。你真正要去对的，是网络运行安全里的等级保护、关键信息基础设施的特别要求、以及网络信息安全那一章里的个人信息与数据管理规定这几块。下面逐条拆。
先分清哪些条款真的在管数据
判断自己是否被覆盖，第一步不是看条款，而是看身份：只要你是通过网络向公众提供服务的运营者，大概率就算网络运营者，个人自用、纯内部不联网的工具通常不算。身份定下来，再去看具体义务落在哪一章，比从第一条读到尾高效得多。
- 先确认身份：是否通过网络向公众提供服务，是则按网络运营者自查；
- 再分清层次：网络运行安全是主线，数据相关义务散在等级保护、关基要求、网络信息安全三块；
- 再排除干扰：不要拿数据安全法的义务清单来套这部法，两者覆盖范围不一样；
- 口径拿不准时，到 /safety 看站内对这几部法交叉关系的整理，别在正文里死记条文编号；
- 把结论写成半页纸，注明「依据哪一章、适用条件是什么」，方便下次复用。
等级保护：最绕不开的一条
定级到测评这条链子，是数据侧义务里最先被检查的一环，很多单位卡在「先定几级」上。定级不是拍脑袋，要按受侵害客体和侵害程度两个维度去对，业务系统、数据库、办公网通常分开定，不要一个级别套全公司。
- 盘系统清单把对外提供服务、存公民个人信息、连公网的系统逐个列出来，标注各自承载的数据类型。
- 逐个写定级理由按受侵害客体和侵害程度写出为什么定这个级别，理由要能被人复述，不是只写个结论。
- 排测评与整改节奏按业务重要性排序，先测对外系统，再测内部系统，整改项要落到责任人和截止周。
- 留档备查定级理由、测评结论、整改记录放同一处，被问起时能直接调出来。
不适用的情况也要说清：纯内网不对外、也不涉及公民个人信息的离线系统，一般不走这条路；但一旦连了公网、或者被并入某个对外业务的数据链路，就该重新掂量。别为了省事把该定的系统漏掉，也别把离线系统硬塞进来。
关键信息基础设施的额外义务
被认定为关基运营者后，义务会比普通运营者多出一截，比如人员背景审查、年度检测评估、事件报告口径更严。要强调的是，认定是监管侧的动作，不是企业自封，你能做的只是提前按高标准把日志留存、权限分离、供应链清点准备好，等通知来了不至于手忙脚乱。
| 场景 | 要不要额外动作 | 判断口径 |
|---|---|---|
| 收到关基认定通知 | 要，按更严口径执行 | 以通知为准，别自行降级 |
| 没收到通知但给关基单位做供应商 | 可能要，看合同 | 合同里若引用关基义务条款，按同等强度对齐 |
| 中小团队做自有产品 | 一般不需要 | 碰不到认定，按普通运营者义务走 |
| 业务下沉到第三方云 | 看责任划分 | 云商承担一部分，你的数据管理责任不转移 |
自查顺序建议是：先确认有没有收到认定通知，再看合同里有没有被要求对齐关基义务，最后才谈技术整改。反过来先买设备、先上系统，往往花在不需要的地方。
日志留存与数据管理义务怎么落
留存不是「存得越久越好」，而是按最小必要定周期，同时保证出事时能拿得出、拿得全。落地时最容易漏的是两头：一是账号操作日志没和业务数据分开，二是删除动作没留痕，导致说不清什么时候清过、清掉了什么。
- 先定「什么算异常」，再决定日志留多久、谁能看，顺序别倒；
- 账号操作日志与业务数据分开放，检索和导出权限也分开；
- 删除、导出、批量查询这三类动作必须留痕，记录谁在什么时候做了什么；
- 日志脱敏规则写进制度，哪些字段不进日志要列清楚；
- 不确定周期和脱敏范围，先到 /tools 找本地处理类工具做一轮自查，再回来定制度。
具体留多久、字段怎么脱敏，各行业规定不一样，本文不给数字。你需要精确口径时，到 /safety 核对站内整理的当时有效要求，再结合自己行业的主管规定落地。
事件响应与报告口径怎么定
事件报告有明确的时限意识，但具体小时数按事件类型和行业规定走，别用一个数字套所有场景。内部先定三件事：谁判断等级、谁对外报、谁留证据，三权别压在同一个人身上，否则一出事就没人能独立复核。
- 划判断权限明确谁有权把一件事定性为需上报事件，避免人人都是判断人。
- 定上报接口把对监管、对客户、对内部的三个口径分开写，各自谁签字要说清。
- 固定取证动作事件一发生就按清单保存现场，别等复盘时才找证据。
- 季度回放每季度拿一次历史事件把上报链路走一遍，比写一堆预案文本管用。
不适用的情况也要讲明：纯内部误操作没造成数据外泄、也没触发监管关注时，按内部事故流程走即可，不必套用对外上报口径。判断的关键是有没有数据外泄、有没有外部主体受影响，而不是「看起来严重不严重」。
制度写得再全，没人回过一遍链路，真出事还是靠现场发挥。下一步把上面几块对着自己公司查一遍后，再到站内安全与合规栏目核对当时有效的条文口径与行业要求，避免拿旧结论做新判断。→
常见问题
网络安全法和数据安全法在数据这块到底谁管谁？
简单说，网络安全法管的是「网络怎么安全运行」，数据只是其中一部分；数据安全法才是专门管数据处理活动的。两者有重叠，比如都提数据分类分级和事件报告，但网络安全法更侧重系统侧和技术措施。实际合规时按业务场景对，别只挑一部看。
我们公司小，是不是等级保护就不用做了？
不是看公司大小，是看有没有对外提供网络服务、处理不处理个人信息。只要系统对外可用，通常就要走定级备案；纯内部、不触网、无个人信息的离线系统才可能绕开。拿不准就先盘系统清单，逐条写定级理由，比纠结要不要做强。
日志到底该留多长时间？
没有放之四海皆准的天数，要按数据敏感度、行业规定和业务需要三者取交集。做法是：先分类，敏感操作日志留长、普通访问日志留短，再写进制度并留删除记录，别口头约定。具体周期的参考数字到 /safety 页面按当时口径核。
