什么是 数据主体访问请求（DSAR）？
在 GDPR 下，这通常被称为访问权。个人一般可以询问组织是否正在处理其个人数据、要求获取该数据的副本，并获得关于该数据处理方式的特定补充信息。
DSAR 不同于要求更正、删除、限制、反对或可携带个人数据的请求。这些是各自独立的数据保护权利，尽管个人可以在同一份请求中行使多项权利。
组织需要建立有效的 DSAR 流程，用于接收请求、在必要时核验身份、定位相关信息、就适用的豁免或第三方信息进行审查，并在适用的法定期限内安全地作出回应。
DSAR 是什么意思？
DSAR 是 Data Subject Access Request（数据主体访问请求）的缩写。
该术语在隐私与数据保护方案中被广泛使用，用于描述个人要求访问其个人信息的请求。
视法域而定，相同或类似的权利可能被称为：
例如，根据 UK GDPR 的指引，ICO 将访问权描述为获取个人信息副本以及其他补充信息的权利。
GDPR 下的 DSAR 是什么？
根据 GDPR 第 15 条，访问权允许个人获得其个人数据是否正在被处理的确认，并在适用的情况下访问该个人数据以及特定的补充信息。
补充信息可以包括以下事项：
- 处理的目的
- 个人数据的类别
- 接收方或接收方的类别
- 在适用的情况下，预计的留存期限
- 当数据并非从该个人处收集时，关于数据来源的信息
- 关于相关权利的信息
- 在适用的情况下，关于自动化决策的信息
- 在适用的情况下，关于国际数据传输的信息
因此，DSAR 所提供的不仅仅是一份数据库导出文件。
它帮助个人了解哪些个人数据正在被处理、为何被处理，以及组织如何对其进行处理。
个人可以通过 DSAR 请求哪些信息？
个人一般可以要求组织提供对其个人数据的访问。
例如，视组织及请求范围而定，这可能包括：
- 账户信息
- 联系信息
- 交易记录
- 客户服务记录
- 雇佣信息
- 通信内容
- 支持工单
- 个人资料信息
- 设备或在线标识符
- 特定的营销信息
- 内部系统中所包含的个人数据
- 由相关处理者或服务提供商持有的个人数据
确切的范围取决于适用的法律、组织的处理活动，以及任何适用的豁免或限制。
DSAR 与数据删除请求是一回事吗？
不是。
DSAR 主要是一项访问请求。
删除请求是要求组织在适用的法定权利存在时删除个人数据。
这些权利是相互独立的。
例如：
“请提供你们所持有的关于我的个人数据。”
“在我有权要求删除的范围内，请删除我的个人数据。”
“请更正不准确的个人数据。”
“请以可携带的格式提供适用的个人数据。”
单一一条来函可以包含多项请求，因此组织的受理流程应当能够识别每一项适用的权利并将其分流处理。
DSAR 与 SAR 的对比
DSAR 与 SAR 常常互换使用。
SAR 这一术语在英国的隐私实务中尤为常见。
其背后的概念都是个人的访问权。
ICO 明确使用“主体访问请求（SAR）”来指称依据访问权提出的请求。
DSAR 是如何运作的？
典型的 DSAR 工作流如下：
- 收到请求
- 识别请求
- 必要时核验身份
- 评估范围
- 定位数据
- 审查信息
- 考虑豁免
- 准备回应
- 安全交付数据
- 记录请求
接收请求
个人通过可用的渠道提交请求。
请求不一定需要使用“DSAR”或“第 15 条”这样的字眼。
组织应当建立流程，以识别那些构成行使访问权的请求。
必要时核验身份
组织可能需要核实请求人就是所请求数据所涉及的本人。
身份核验应当合理且适度。
ICO 的现行指引强调，在身份已经得到充分确认的情况下，组织不应自动要求提供正式身份证明。
确定范围
组织应当确定哪些系统和信息类别可能与之相关。
如果请求确实不够清晰，或者宽泛到合理地需要加以澄清，组织可以寻求澄清。
然而，不应仅仅为了让请求变得不必要地困难而使用澄清这一手段。
检索相关系统
组织应当针对所请求的个人数据进行适当的检索。
视业务情况而定，这可能涉及：
- CRM 系统
- 客户数据库
- 电子邮件
- 支持系统
- 人力资源系统
- 营销平台
- 数据仓库
- 云应用程序
- 已归档的系统
- 相关处理者
审查信息
在披露之前，组织应当就以下方面审查相关信息：
- 第三方个人数据
- 适用的豁免
- 保密信息
- 相关情况下受法律特权保护的信息
- 安全方面的考虑
- 请求的范围
- 适用的法律限制
准备回应
回应应当以适当且易于理解的格式提供个人数据以及所要求的补充信息。
安全交付
组织应当采用安全的方式向请求人交付个人信息。
记录请求
组织应当就以下内容保存适当的记录：
- 请求的收到时间
- 由谁处理
- 身份核验步骤
- 已检索的系统
- 所提供的信息
- 已考虑的豁免
- 回应日期
- 任何延期
- 相关的通信往来
这会形成一条审计轨迹，用于证明该请求是如何被处理的。
DSAR 需要多长时间？
期限取决于适用的隐私法律。
GDPR
在 GDPR 下，组织通常需要在收到有效请求后不得无故拖延地作出回应，并且应在一个月之内完成。
在因请求的复杂性或数量而确有必要时，该期限可以再延长最多两个月。请求人通常必须在最初的一个月期限内被告知该延期及其理由。
英国 ICO 目前在 UK GDPR 下描述了相同的一个月一般规则，对复杂请求或多项请求可以再延长最多两个月。
CCPA
加利福尼亚州的隐私法律采用不同的框架和术语。
对于 CCPA 下适用的消费者请求，标准回应期限通常为 45 天，并受适用的延期与相关要求的约束。
这也是 DSAR 平台应当采用针对具体法域的 SLA 规则，而不是假定一套期限全球通用的原因之一。
重要提示
并不存在一套通用的 DSAR 期限。
隐私管理系统应当根据以下因素确定适用的期限：
- 法域
- 适用的隐私法律
- 请求类型
- 身份核验
- 澄清要求
- 复杂程度
- 延期
- 适用的豁免
组织可以要求提供身份证明吗？
有时可以。
在披露个人信息之前，组织可能需要核验身份，尤其是当信息被披露给错误对象存在实质性风险时。
然而，身份核验应当适度。
ICO 的现行指引指出，组织在要求提供何种身份证明时应当保持合理，并且在没有必要的情况下不应要求提供正式身份证明。
因此，良好的 DSAR 工作流应当支持：
- 身份核验
- 基于风险的核验
- 必要时的安全文档处理
- 核验状态
- 请求人身份认证
- 审计记录
个人可以口头提出 DSAR 吗？
可以，具体取决于适用的法律框架。
根据 UK GDPR 的指引，主体访问请求可以口头或书面提出，包括通过社交媒体等渠道提出。请求人不一定必须使用规定的表格或法律术语。
这意味着，组织应当培训员工识别访问请求，即使这些请求是通过以下渠道到达的：
- 电子邮件
- 电话
- 在线客服聊天
- 客户支持
- 社交媒体
- 面对面交谈
- 在线隐私表单
DSAR 流程不应当完全依赖于单一的网页表单。
DSAR 必须被称为 DSAR 吗？
不必。
个人通常不需要使用“DSAR”这一术语，组织就应当能够识别出有效的访问请求。
例如：
“你们能把所持有的关于我的全部个人信息发给我吗？”
即使当事人从未使用 DSAR 这一术语，这也可能构成一项访问请求。
因此，组织应当培训客户服务、人力资源、支持和隐私团队，根据请求的实质内容来识别请求。
组织必须提供哪些内容？
在 GDPR 访问权之下，组织通常需要提供：
- 关于是否正在处理个人数据的确认。
- 相关个人数据的副本。
- 适用法律所要求的补充信息。
ICO 将访问权概括为包括处理确认、个人信息副本以及补充信息。
如果法定权利仅要求披露请求人的个人数据以及适用的补充信息，组织不一定必须完整提供每一份内部文件。
DSAR 可以包含关于他人的信息吗？
有可能，但这需要审慎的审查。
组织的记录中可能包含以下人员的个人信息：
- 请求人
- 员工
- 客户
- 家庭成员
- 业务联系人
- 其他第三方
组织应当考虑披露是否会不当地泄露他人的个人信息。
这也是即使初始收集流程已经自动化，DSAR 的履行往往仍然需要人工审查的原因之一。
组织可以拒绝 DSAR 吗？
访问权并非不受限制。
视适用法律而定，可能存在适用的豁免或限制。
例如，组织可能需要考虑涉及以下方面的问题：
- 第三方权利
- 法律特权
- 保密义务
- 监管限制
- 执法方面的考虑
- 明显缺乏依据或过度的请求
- 其他法定豁免
组织不应仅仅因为请求带来不便就予以拒绝。
在拒绝请求或扣留信息的情况下，组织应当遵循关于说明理由、豁免以及投诉或申诉权利的适用法律要求。
ICO 的现行指引指出，只有在适用豁免或限制的情况下，组织才可以拒绝访问，其中包括某些明显缺乏依据或过度的请求。
DSAR 是免费的吗？
在许多隐私制度中，个人行使访问权无需支付标准费用。
例如，根据 UK GDPR 的指引，组织通常不能就回应主体访问请求收取费用。
在有限的情形下可以允许收取合理费用，例如某些明显缺乏依据或过度的请求，或者额外的副本，具体取决于适用法律。
确切的规则取决于所涉法域。
DSAR 与数据可携带性
数据可携带性请求不同于 DSAR。
两者都可能涉及提供个人数据，但可携带性有额外的条件和特定的目的。
数据可携带性通常涉及以结构化、常用、机器可读的格式接收特定的个人数据，并在技术上可行的情况下将其传输给另一控制者。
并非每一项 DSAR 都符合可携带性请求的条件。
因此，隐私权利平台应当区分：
- 访问
- 更正
- 删除
- 可携带性
- 反对
- 限制
- 其他适用的权利
DSAR 与 GDPR
GDPR 第 15 条的访问权是 GDPR 下 DSAR 的主要法律依据。
该权利帮助个人了解其个人数据是如何被处理的，并允许其检查处理是否合法。
因此，设计良好的 DSAR 流程应当把访问请求与组织更广泛的 GDPR 问责方案连接起来。
DSAR 与 UK GDPR
UK GDPR 所包含的访问权与 GDPR 大体相当。
英国的组织应当遵循英国信息专员办公室（ICO）的现行指引，因为具体的操作要求和指引可能会不断演变。
特别是，组织应当考虑以下方面的现行规则：
- 回应期限
- 延期
- 澄清
- 身份核验
- 合理检索
- 豁免
- 安全披露
- 投诉
ICO 在 2025 年和 2026 年更新了其访问权指引，其中包括反映 Data (Use and Access) Act 2025 所引入变化的指引。
DSAR 与 CCPA
加利福尼亚州的隐私制度为消费者提供了与其个人信息相关的权利，其中包括访问信息的权利。
CCPA 使用其自身的术语、程序、豁免和期限，因此组织不应简单地照搬 GDPR 的 DSAR 工作流，并假定其就能满足加利福尼亚州的要求。
隐私权利系统应当识别适用的法域，并将请求引导至相应的工作流。
DSAR 与印度的 DPDPA
印度的 Digital Personal Data Protection Act（DPDPA）使用了与 GDPR 不同的术语。
DPDPA 将个人称为 Data Principal，而不是 GDPR 所用的“数据主体”。
因此，在印度开展业务的组织应当区分：
- GDPR / UK GDPR 的数据主体权利
- CCPA 的消费者权利
- DPDPA 的 Data Principal 权利
全球性的隐私平台应当采用针对具体法域的工作流，而不是把每一项隐私请求都当作 GDPR 下的 DSAR 来处理。
DSAR 与数据主体权利请求的对比
数据主体权利请求（DSR）或数据主体请求是一个比 DSAR 更为宽泛的概念。
权利请求可能涉及：
- 访问
- 更正
- 删除
- 限制
- 反对
- 可携带性
- 其他特定法域的权利
DSAR 专门聚焦于访问。
这一区分对隐私团队很有用，因为单一一条来函可能包含多项权利。
例如：
“告诉我你们持有哪些关于我的数据，更正我的地址，并删除我的营销画像。”
这条来函可能包含：
- 一项访问请求
- 一项更正请求
- 一项删除请求
组织应当识别并处理每一项适用的权利。
DSAR 与同意撤回的对比
DSAR 也不同于同意撤回。
“我撤回此前给予的同意。”
“请让我访问我的个人数据，以及关于其处理的适用信息。”
个人可以同时行使这两项权利，但不应将二者混淆。
例如，用户可以撤回营销同意，并另行请求访问组织所持有的关于其本人的个人数据。
DSAR 与 Cookie
DSAR 有可能涵盖与在线活动相关联的个人数据。
视具体情形而定，相关信息可能包括：
- 在线标识符
- 账户标识符
- 与 Cookie 关联的信息
- 广告标识符
- IP 地址
- 网站活动
- 营销画像
- 偏好记录
特定的 Cookie 或分析信息是否构成个人数据，取决于适用法律和具体情境。
因此，组织在执行 DSAR 检索时应当考虑相关的在线数据系统，而不是把检索范围局限在其 CRM 之内。
DSAR 与同意记录
同意记录可能与 DSAR 相关。
例如，组织可能持有能够显示以下内容的信息：
- 同意是何时收集的
- 展示了哪些处理目的
- 作出了哪些选择
- 展示的是哪一版本的告知
- 更改了哪些偏好设置
- 同意是何时撤回的
- 哪些标识符与该同意事件相关联
当这些信息构成该个人的个人数据并落入请求范围之内时，在履行请求的过程中可能需要加以考虑。
这正是同意记录与 DSAR 管理不应总是作为完全独立的系统运行的原因。
DSAR 与第三方处理者
组织经常使用第三方处理者和服务提供商。
因此，DSAR 可能需要在以下系统中定位信息：
- CRM 平台
- 电子邮件服务提供商
- 云存储
- 客户支持工具
- 营销平台
- 分析系统
- 人力资源平台
- 支付系统
- 数据仓库
- 其他处理者
即使相关数据存储于第三方系统或通过第三方系统处理，组织在适用法律下仍然负责管理其访问权工作流。
自动化如何助力 DSAR
随着请求数量和数据系统的增加，人工处理 DSAR 会变得越来越困难。
DSAR 管理平台可以将工作流的部分环节自动化，包括：
- 请求受理
- 案件创建
- 身份核验
- 请求分类
- 期限计算
- SLA 监控
- 分派
- 内部通知
- 数据源跟踪
- 履行工作流
- 安全交付
- 审计日志
- 升级处理
自动化应当为隐私团队提供支持，而不是取代适当的人工审查。
DSAR 自动化清单
成熟的 DSAR 工作流应当包括：
受理
- 集中化的请求受理
- 电子邮件与网页表单支持
- 手动创建请求
- 自动生成案件编号
分类
- 访问请求识别
- 权利分类
- 法域识别
- 优先级分配
身份核验
- 请求人身份认证
- 核验状态
- 适度的核验工作流
- 安全的证据处理
期限管理
- 适用 SLA 的计算
- 自动期限提醒
- 延期跟踪
- 升级提醒
数据发现
- 系统清单
- 检索任务分派
- 处理者协调
- 收集进度跟踪
审查
- 重复内容去除
- 第三方信息审查
- 豁免审查
- 人工批准
履行
- 安全导出
- 回应生成
- 交付跟踪
- 请求关闭
审计
- 完整的活动历史
- 时间戳
- 指派的用户
- 检索记录
- 决定
- 最终回应
- 完成证据
常见的 DSAR 误区
把每一项隐私请求都当作 DSAR
更正、删除、可携带性、反对和访问是各自独立的权利。
要求使用专门的表格
组织不应仅仅因为请求人没有使用特定表格，就让正当的访问请求变得不必要地困难。
自动索要政府颁发的身份证件
身份核验应当与风险相称。
只检索 CRM
个人数据可能存在于数十个系统之中。
忽视处理者
相关个人数据可能由云、营销、分析、支持或其他服务提供商持有。
错过期限
没有 SLA 计时的请求很容易被忽视。
以不安全的方式发送数据
个人信息应当通过适当的安全机制交付。
披露他人的信息
当记录中包含第三方个人数据时，DSAR 的回应需要审慎的审查。
把 GDPR 的期限当作通用期限
不同法域有不同的规则和回应期限。
没有审计轨迹就结案
组织应当能够证明该请求是如何被接收、评估、检索、审查和履行的。
面向企业的 DSAR 实施清单
- 明确界定什么构成 DSAR。
- 培训直接面向客户的员工识别请求。
- 提供便于使用的请求渠道。
- 在必要时适度地核验身份。
- 确定适用的法域。
- 计算正确的法定期限。
- 识别请求的范围。
- 检索相关系统。
- 必要时与处理者协调。
- 审查第三方个人信息。
- 评估适用的豁免。
- 以易于获取的格式准备回应。
- 安全地交付信息。
- 记录请求与回应。
- 跟踪期限与延期。
- 为审计目的保存证据。
- 定期审查流程。
DSAR 与 ConsentX
ConsentX 可以通过集中化的请求受理、身份核验、SLA 跟踪、履行与审计证据流程，帮助组织管理 DSAR 与隐私权利工作流。
典型的工作流可以是：
- 请求
- 身份核验
- 法域/规则识别
- SLA 计时
- 数据发现
- 审查
- 履行
- 安全回应
- 审计记录
这有助于隐私团队降低以下风险：
- 错过期限
- 请求无人负责
- 人工跟踪出错
- 请求记录不完整
- 履行不一致
- 可审计性差
目标并不仅仅是把邮件回复自动化。
目标是建立一套可供审计的隐私权利工作流。
要点总结
- DSAR 是要求访问个人的个人数据的请求。
- DSAR 通常也被称为主体访问请求（SAR）或访问权请求。
- DSAR 区别于要求删除、更正、可携带性、反对或限制处理的请求。
- 在 GDPR 下，访问权通常要求在一个月内作出回应，并可在符合条件时延期。
- UK GDPR 的指引同样规定了一个月的期限，对复杂请求或多项请求可以延期。
- CCPA 下的访问请求适用不同的规则和期限。
- 身份核验可能是适当的，但应当保持适度。
- 组织应当检索相关系统，并考虑由处理者持有的数据。
- DSAR 的回应可能需要就第三方信息和法定豁免进行审查。
- 安全履行与审计记录是 DSAR 管理的重要组成部分。
- DSAR 平台应当采用针对具体法域的规则和 SLA 计时，而不是一套全球通用的期限。
- 自动化可以简化受理、核验、发现、履行与审计证据等环节。