数据主体访问请求（DSAR）是指有人询问您持有关于他们的哪些数据，并且往往还要求您对这些数据做点什么。在 GDPR 之下，您通常有三十天时间作出回应；在 CCPA 之下则是四十五天。计时从请求送达时开始，逾期本身就构成合规失败。好消息是，只要有流程，DSAR 是完全可控的。下面就是这样一套流程。
第 0 天：登记请求
请求一到，立即记录在案。不要让它躺在某个人的私人收件箱里。记录下是谁提出的、要求什么、收到日期以及截止期限。
- 注明请求类型。访问、更正、删除和可携带各不相同。
- 从收到当天开始计时，而不是从有人注意到它的那天。
- 确认收到，让对方知道您已经在处理。
请求可能从任何地方进来：邮件、表单，甚至客服聊天。请训练团队把任何看起来像权利请求的内容都转到同一个可追踪的入口。
第 1 至 3 天：核验身份
您绝不能把个人数据交给错误的人。身份核验保护的是所有人，包括请求人本人。
- 确认请求确实来自数据主体本人或其授权代理人。
- 索取合理的证明，但不要索取超出所需的材料。
- 如果无法核验，请记录您的善意尝试及其原因。
过度收集身份证件本身就是一种隐私风险。核验到足以确信即可，然后停手。仅仅为了确认一个您档案中已有的邮箱地址，并不需要护照扫描件。
第 3 至 15 天：定位数据
这是主要工作量所在。您需要在每一个系统中收集关于此人的全部信息。数据地图越完善，这一步就越快。
- 搜索您的主数据库、CRM、分析工具、邮件工具以及备份。
- 包含代表您行事的处理方所持有的数据。
- 标注出您可以合法不予提供的内容，例如会暴露他人身份的数据。
如果您从未梳理过系统，第一份 DSAR 会很痛苦。不妨把它当作动力，把数据地图建起来，下一次就会很快。
第 15 至 25 天：准备回应
现在要把原始数据整理成清晰、可用的答复。
- 以对方真正能看懂的可读格式汇总数据。
- 对于删除请求，删除数据并确认删除了哪些内容。
- 对于更正请求，更新记录并注明变更内容。
- 对夹杂在其中的他人信息进行脱敏处理。
回复要直白。一堆数据库导出文件不是好答复。请说明您持有什么、为什么持有，以及您做了什么。
第 25 至 30 天：发送并归档
以安全的方式送达回应，然后保留您已履行的证明。
- 通过对方能够安全访问的渠道发送。
- 记录您回应的日期，以及您提供了什么或做了什么。
- 保留完整的处理轨迹，以备对方或监管机构日后查询。
这份记录就是您的抗辩依据。如果有人质疑您是否妥善处理了请求，日志会替您作答。
让下一次更轻松
第一份 DSAR 是对流程的检验。此后的目标，是让每一次处理都变成例行公事。可追踪的受理入口、明确的截止期限、已知的搜索范围、模板化的回复以及审计轨迹，能把一场手忙脚乱变成一张核对清单。
如果您希望在一个地方完成 DSAR 受理、SLA 计时、履行工作流与审计轨迹，请 免费开始使用 ConsentX，从此不再害怕下一份请求。