数据安全法从哪个角度设定合规要求

安全与风控

从立法视角讲清数据安全法设定合规要求的切入角度与逻辑,给出可对照的判定顺序与企业自查动作。

很多人读数据安全法,第一反应是找「第几条要求我做什么」,结果越读越乱——因为这部法不是按业务动作写的,而是按风险等级和责任层级来搭架子。这篇帮你把它的切入角度捋清楚:它先分类分级、再定主体责任、最后落到流程与留证,你顺着这个顺序看,才知道自己企业该从哪一步动手。

很多人读数据安全法,第一反应是翻条文找「第几条要求我做什么」,结果越读越乱。原因很简单:这部法不是按业务动作写的,而是按风险等级和责任层级搭的架子。你拿着「我是做电商的」「我是做 SaaS 的」去套,基本套不上;换成「我手里是什么数据、我在链条里站什么位置」再去读,条理立刻就出来了。

所以这篇不讲条文摘要,只讲它的切入角度和逻辑顺序:先分类分级,再定主体责任,最后落到流程与留证。你按这个顺序走,才知道自己企业该从哪一步动手,也能判断哪些条款其实跟你关系不大。下面按四个角度拆开说,每个角度都给出可直接执行的判断标准。

它不是按「你做什么业务」立规矩,而是按「你手里是什么数据」分层

这部法最底层的切入点是数据分类分级:先看数据的重要程度,再决定义务强度,业务类型只是背景信息。也就是说,同样的业务形态,一家公司可能只承担基础义务,另一家因为持有某类高影响数据就要多做不少动作。判断自己落在哪一层,关键不是看数据量大小,而是看这些数据被篡改、被泄露、被断供之后,影响会波及到谁、波及多广。

判断维度问自己的问题影响倾向
影响范围数据出问题会只影响自己,还是波及外部用户、合作方、公众波及越广,层级越高
可恢复性丢了能不能补回来,补回来要多久不可恢复或恢复很慢,层级越高
被利用性数据落到别人手里能不能直接拿去干坏事可直接利用,层级越高
依赖程度业务是否离了这份数据就转不动强依赖,层级越高
  • 同一家公司可能同时承担不同层级义务,一句「我们不是重点行业」带不过去
  • 定级结论必须能写成文档,写清依据和定级人,否则事后无法解释当时的判断
  • 定级不是一次性的,业务方向变了、数据来源变了,结论要重新过一遍
  • 别拿数据条数当唯一标准,几千条敏感记录可能比几百万条公开数据的层级更高

第二个角度是认角色:谁处理、谁委托、谁提供,义务不一样

搞清楚数据是什么之后,下一步是搞清楚你是谁。同一份数据在链条上流动时,各方的定位不同:自己决定处理目的的、受别人委托只干活的、把数据往外提供的,对应的动作清单并不一样。实践中特别常见的误区,是把外包供应商该做的事当成自己的免责金牌——实际上责任往往仍落在数据持有方身上,供应商出问题,你这边一样要交代。

  1. 画数据流转图从采集开始,把每条数据路径画出来,标出每一站谁在接触、谁在存储、谁在往外传、传给了谁。
  2. 标角色在每一站旁边写上这一方在法律里的定位,是自主处理、受托处理还是对外提供。
  3. 找义务按角色逐站对照要求,把「这一站该做什么」列成清单,而不是笼统写一句「加强管理」。
  4. 验变化定期回头看:原本只自用的数据后来开放了接口、接了新合作方,角色就变了,义务要跟着升级。

角色不是贴一次标签就固定的。业务从自用到共享、从内部到对外,链条上多一个环节,就可能多一层义务。建议把数据流转图当成活文档维护,每次新接系统、新签合作都顺手改一版。

第三个角度是把要求落到流程和留证,而不是停在制度文件上

前两个角度解决「该做什么」,这个角度解决「怎么证明你做了」。合规要求真正考核的通常是三件事:有没有做、怎么做的、能不能证明。制度文件写得再漂亮,如果找不到执行痕迹,一旦出事就很难解释。所以流程设计要和留证设计一起做,而不是先写完制度再补记录。

风险评估
定期做,并且在数据范围、业务模式发生重大变化时重做,结论要留档
权限与访问
谁能看、谁能导出、谁能改,要有记录,权限变更尤其要留痕
事件响应
出事的处理顺序提前定好,谁上报、谁处置、多久内动作,写成可执行的预案
留证方式
不是堆截图,而是能串起时间线的记录:谁在什么时候基于什么理由做了这个决定

留证这件事有个实用标准:假设半年后有人问你「当时为什么这么定级、为什么给这个人开了权限」,你能不能在三分钟内翻出一份说得清来龙去脉的记录。能,就说明留证做到位了;不能,就说明记录只是形式。具体到举证形式和事件复盘写法,可以到站内的事故复盘与举证类文章里对照着看。

另外提醒一句:这套流程在小团队里可以简化,但简化的只是文档厚度,不是动作本身。盘数据、定级别、对义务、补记录,四件事少一件都会在关键时刻掉链子。

给企业的落地顺序:四步自查别跳步

把上面三个角度合起来,落地就是一条固定顺序。跳步的代价很明显:没盘数据就定级,级别是拍脑袋的;没定级就对义务,清单是抄来的;没对义务就补动作,补的往往不是最要紧的那块。按下面四步走,每一步都留下可检查的产出。

步骤做什么产出物常见错误
盘数据列出实际持有和流转的数据类型数据清单只写系统名称,不写数据类型
定级别按影响范围给每类数据定级定级表加理由只写级别,不写为什么
对义务按级别和角色逐条对照差距清单笼统写「基本符合」
补动作优先补可留证的部分评估报告、权限变更记录先补制度文件,忽略记录
  • 盘数据时按「一类数据一张卡」的方式记,写清来源、用途、存放位置、经手方
  • 定级理由写一句话就够,但要写清是谁在什么依据下定的
  • 对义务时把「不适用」也写下来,并说明为什么不适用,这本身就是解释材料
  • 补动作按风险排序,先补出事时最需要自证的那几项,比如权限变更和评估结论
  • 小团队可以把四步压在一份表格里,但四步的动作一个都别省

不适用的情况也要说清楚:如果企业根本不持有任何对外有影响的数据、也不参与对外提供,那高强度的义务清单确实跟你关系不大。但这个结论必须建立在盘过数据、写得出理由的基础上,而不是凭「我们规模小」一句话带过。规模小不等于影响小,这点在定级时尤其容易判断错。

下一步把上面的四步自查表先落成一份内部文档,再去站内翻中转站可信度与合规相关的对照资料,看看自己对外采购和调用 API 的环节有没有缺记录——很多企业的漏洞不在内部流程,而在对外这一环。

常见问题

数据安全法的合规要求和网络安全法有什么侧重区别?

网络安全法更偏向网络运行与系统层面的安全,数据安全法把焦点放在数据本身的分类分级、处理活动和流转责任上。两者有交集但不互相替代,实际做合规时常需要对照看,站内的法规关系类文章可以帮你区分三者的边界。

我们公司数据量不大,是不是就不受约束?

约束强度看的是数据重要程度和影响范围,不是绝对数量。少量但涉及重要行业运行或大量个人信息的数据,义务可能比海量普通日志更重。判断方法是先按影响范围定级,再对照义务,而不是按条数拍脑袋。

制度文件写完了,是不是就算合规了?

它的切入角度是分层的:先按数据的重要程度分类分级,再按你在处理活动中的角色确定义务,最后把要求落到流程与留证上。所以读它时不该从业务动作找条文,而应从数据影响范围倒推自己该承担哪一档责任。

自查从哪里开始比较不走弯路?

从盘数据开始,先弄清自己实际持有和流转什么数据,再定级、对义务、补动作。跳过盘点直接抄模板,往往对不上自己的实际情况,白做一遍。具体的技术侧检查项可以参考站内的安全自查与审计类清单。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。