第2章数据主体权利

数据主体权利：访问权、删除权、限制处理权、数据可携权等

好，咱们今天聊聊数据主体权利。说实话，这是GDPR里最“接地气”的部分。为什么？因为用户真的会用。我在做审计时，见过太多公司把隐私政策写得天花乱坠，结果用户一发访问请求，整个法务部就懵了。

说白了，数据主体权利就是给用户一把“钥匙”，让他们能控制自己的数据。你想想看，如果一家公司连用户想看自己的数据都做不到，那还谈什么合规？

访问权是基础中的基础。用户有权问：“你们到底存了我哪些数据？”公司必须在收到请求后一个月内回复。

我个人习惯，在审计时先看公司的数据映射表。如果连数据在哪都找不到，那访问权基本是空谈。

  核心要点：
  用户有权确认自己的数据是否被处理
用户有权获取数据副本
公司必须提供处理目的、数据类别、接收方等信息
回复时限：通常1个月，复杂情况可延长至2个月

我在项目中遇到过一家电商公司，用户要求导出所有个人数据。结果IT部门花了三周才从12个不同系统里把数据扒出来。嗯，这就是典型的数据治理没做好。

避坑指南： 我曾经见过一家公司，把用户访问请求的回复做成了PDF，但PDF里全是系统截图。这其实不合规。用户要的是结构化数据，不是截图。最好提供CSV或JSON格式。

删除权，也叫“被遗忘权”。用户可以说：“我不想让你们再存我的数据了，删掉吧。”但注意，这不是绝对的。

为什么会这样？因为有些数据公司必须保留。比如财务数据，法律规定要保存7年。这时候就不能删。

我建议你在设计系统时，就考虑好“删除流程”。别等到用户提请求了，才去翻数据库。我曾经审计过一家SaaS公司，他们的删除操作居然是DBA手动跑SQL脚本。这风险太大了，万一删错了呢？

注意： 删除权不仅适用于主数据库。备份数据、日志文件、缓存里的数据，都得考虑。我在项目中见过一家公司，主库删了，但备份磁带里还躺着三年前的数据。这算不算违规？严格来说，算。

这个权利有点意思。用户不说“删掉”，而是说“先别动我的数据”。相当于按了暂停键。

什么情况下用户会用这个权利？

你想想看，这个权利对系统设计的要求很高。你不能直接把数据删了，也不能继续处理。我见过最好的做法是：在数据库里加一个“限制处理”标记，所有下游系统读取时都跳过这些记录。

实战经验： 我曾经帮一家金融科技公司设计限制处理流程。他们的做法是：在用户数据表里加一个 processing_restricted 字段，值为 true 时，所有ETL任务、报表生成、API调用都跳过该用户。嗯，这个方案挺实用的。

数据可携权，说白了就是用户可以把数据从你家搬到别人家。比如从微信导出聊天记录，导入到钉钉。

这个权利有两个前提：

如果数据是纸质档案，或者处理是基于法律义务，那就不适用可携权。

  格式要求：
  必须提供结构化、通用、机器可读的格式
常用格式：CSV、JSON、XML
如果技术上可行，用户要求直接传输给另一家公司，你也得照做

我在项目中遇到过一家健康管理App，用户要求把运动数据导出给保险公司。结果他们发现数据存在20多个不同的表里，关联关系复杂得要命。最后花了两个月才搞定导出接口。嗯，这就是一开始没考虑可携权的后果。

注意： 可携权只适用于用户自己提供的数据，以及用户活动产生的数据。但不包括公司基于这些数据推导出的“衍生数据”。比如，用户的身高体重可以导出，但公司根据这些数据算出的“健康评分”就不一定了。

下面这张图，是我梳理的数据主体权利核心逻辑。你可以把它当作审计时的检查清单。

这张图把四个核心权利的关系理清楚了。你审计时，可以对照每个权利的子节点，逐一检查公司的落地情况。

我的建议： 别等到审计时才准备。在设计系统之初，就把这些权利考虑进去。比如数据库设计时，加一个 consent_status 字段，记录用户同意状态。这样后续处理删除权、限制处理权时，就方便多了。

好了，数据主体权利这块，核心就是这些。记住一句话：用户的权利，就是公司的义务。你把这些权利实现好了，合规自然水到渠成。