数据安全法违法案例

很多人翻完法条还是不知道红线画在哪，直到看到同行被罚才意识到自己也在做同样的事。这篇不讲法条逐条解读，而是把常见违法情形按「触发动作—监管关注点—后果」摆成对照表，再给一套自查顺序。读完你能判断自己手上的数据处理动作属于哪一类风险，以及该先改哪一步。

违法案例的四种典型类型

把公开的执法通报和处罚决定书翻一遍，会发现绝大多数案子都能塞进四类里。先别急着记条文，先学会把一件事往这四类里归位，归类之后才知道该盯哪条线、该改哪个环节。下面每类都给触发场景和监管关注点，方便你拿自己公司的现状做对照。

每类到底在查什么，可以这样自查

• 义务缺失类：先问自己「要一份安全管理制度，今天能拿出来吗」，拿不出来基本就落在这类；
• 出境类：把数据流画一遍，标出任何一台境外节点、任何一个境外账号能碰到的数据；
• 超范围类：把收集项和实际使用场景一一对应，对不上的就是风险点；
• 不配合类：把收到的每一次问询、每一份材料提交时间记进台账，别靠记忆

这四类不是互斥的，一个案子常常同时踩两三条。但监管在写处罚时会有侧重，归类决定的是你整改的先后顺序：义务缺失先补制度和记录，出境先停数据流再补评估，超范围先砍权限和用途，不配合先建立响应机制。顺序反了，改完还是会犯。

行政处罚和刑事追责是两条线，别混着看

行政处罚线

多对应义务层面的缺失，比如没建制度、没做评估、没按要求配合，处罚形式以责令改正、警告、罚款为主，前提是没造成严重后果

刑事追责线

通常和严重后果挂钩，比如数据被大规模泄露、被用于违法活动、造成重大损失，才会往刑法相关罪名上靠

判断分界

不是看数据多少，而是看有没有造成实际危害后果、主观上是否明知故犯、是否反复发生

具体幅度

罚款区间、情节认定这些会随法规修订和执法口径变化，到 /safety 与站内合规栏目核对当时的表述

1. 第一步：把自己的场景先归位拿上面那张表逐条比对，一个业务可能落进两三类，先把主类定下来；不要为了省事直接套用别人的处罚结论。
2. 第二步：判断走哪条线看有没有造成实际后果、有没有明知故犯、是不是反复出现。只有义务缺失、没有后果的，一般先按行政这条线准备；出现后果的，要同时做刑事风险预案。
3. 第三步：去站内核对当时的口径处罚幅度、情节认定这些数字会变，不要凭印象记；到 /safety 和合规栏目看当时的表述，再决定整改优先级。
4. 第四步：区分适用边界纯内部、不碰个人信息与重要数据的测试环境，按低风险处理即可；一旦接入真实数据或对外开放，必须按正式标准重新评估一次。

最容易踩雷的动作自查清单

查违法案例时，很多人盯着「有没有被黑」「有没有泄露」，但真正在处罚里反复出现的，往往是那些平时没人管、事后又说不清的动作。下面这份清单不按风险大小排，按「能不能留下证据」排，逐项对着自己系统过一遍，比看一堆案例标题有用。

最容易漏的是「看不见的动作」

• 日志本身可能变成风险点：为了排查方便把请求体全量落库，等于又存了一份数据，谁来读、存多久往往没人定。
• 训练数据从哪来：爬的、买的、合作方给的，来源不同，能用不能用的边界完全不同，说不清来源最麻烦。
• 外包和驻场能不能导出：给了账号就等于给了批量导出的可能，权限和导出通道有没有单独收口。
• 离职与转岗：账号回收、密钥轮换、本地副本清理，这些动作没有记录就等于没做。
• 共享给关联方或合作方：口头说「只用这一次」，但没有任何书面或技术约束。

这几项的共同点是：出问题时没人能证明「当时是怎么控制的」。案例的定性依据常常不是结果有多严重，而是过程里有没有可核查的动作。所以别急着解释意图，先把能拿出来的记录凑齐。

1. 第一步：先列数据清单按业务线把「有哪些数据、存在哪、谁能碰」写成一张表，字段粒度能到表或目录就够，目的是让后面的出境和共享有对象可谈。
2. 第二步：核对出境与共享拿着清单逐个问：有没有给境外主体访问、有没有通过接口或文件给到第三方；每一处确认走的是哪条路径、有没有留痕文件。
3. 第三步：最后补记录与留痕把审批、授权、导出记录、日志保留策略补齐，优先补能被外部核查的那几类，而不是先上监控工具。

违法案例里最要命的不是「做了坏事」，而是「说不清当时做了什么」。

处罚逻辑怎么读：不是看金额，是看情节

很多人翻处罚案例，第一反应是看罚了多少。但监管写处罚决定书是有固定顺序的：先认定你是什么角色、有没有被责令改正、改没改、有没有造成实际危害，金额是这一串判断走完之后的结果。所以同一部法律下，金额可以差很多，真正决定走向的是情节。具体口径每年可能调整，去 aitest123.com 合规栏目核对当时公开的表述。

把案例按时间轴拆一遍，会看到反复出现的分叉点：同样是未按规定做数据分类分级、同样是出了安全事件，主动报告并整改的，和不报告、拖着、甚至在检查时说假话的，处理结果往往不是一档。前者常见的是先责令改正、限期整改；后者才会往从重方向走。这个差异比金额本身更值得记。

• 先确认主体身份：是数据处理者、受托方，还是个人自用，责任范围完全不同。
• 再确认程序节点：有没有责令改正通知、期限是多久、有没有逾期。
• 然后看结果：有没有实际危害、影响多少人、有没有扩散。
• 最后才看金额，并且要看它对应的是哪一条、叠加了哪些从重情节。
• 同一案例里如果出现多个行为，要分开算，不要合并成一个结论。

真被点名时，先做什么、留什么

被监管或客户点名的那一刻，最忌讳先对外解释、后补内部情况。正确顺序是先固定事实：到底涉及哪些数据、流向哪里、从什么时候开始。链路没写清楚就对外沟通，很容易前后说法不一致，反而把一次问询变成一次调查。

1. 画清数据链路列出涉及的数据类别、存储位置、经过的系统与人员、最终流向的接收方，标明起止时间。写成一张表比写一段话更有效，方便逐项核对。
2. 固定时间边界确定问题从哪一天开始、是否仍在持续、中间有没有变更过处理方式。时间点含糊是后续所有解释的漏洞来源。
3. 先内部对齐再对外链路和时间在内部过一遍，确认口径一致再回复外部。对内说不清就对外说，等于把风险放大。

留证：按时间线归档，不是临时翻聊天记录

取证的关键是「可复现、可追溯」，而不是事后拼凑。处理记录、审批邮件、与第三方的协议、脱敏或加密的实施证据，都要按时间顺序归到一条线上，能说明谁在什么时候做了什么、依据是什么。取证与留存的思路可以先对照站内 /safety 下的相关条目，避免遗漏关键项。

上报义务：别自己拍板「不严重」

是否触发上报或通知义务，要按适用规则逐条比对，而不是凭感觉判断严重程度。案例里最常见的加重情节，就是当事人自认为影响不大、选择压下不报，结果被认定为隐瞒或拖延。拿不准的时候，把判断依据和待确认点写下来，走内部合规或外部专业意见确认，别由业务方单独决定。

• 先固定链路和时间，再开口对外；
• 证据按时间线归档，能复现才算数；
• 第三方协议重点看数据安全与责任条款；
• 上报与否按规则比对，留书面判断依据；
• 不确定就升级，不自行压下。