如何处理 GDPR 被遗忘权请求：合规团队的实操工作流

处理 GDPR 被遗忘权（删除权）请求，核心动作就四步：核实请求人身份；判断请求在 GDPR 第 17 条项下是否成立、第 17 条第 3 款（Art. 17(3)）的例外情形是否适用；在一个月内执行删除（或给出有理由的拒绝）；并把你做了什么、为什么这样做全部记录下来。本文面向 SaaS 企业的 DPO（数据保护官）、合规负责人和运营经理，逐步拆解整个流程——包括一个真正棘手的情形：数据主体的个人数据存留在已签署合同和审计轨迹中，而这些记录可能恰恰不允许删除。

本指南为科普性质，依据公开的 GDPR 条文（第 12 条第 3 款 Art. 12(3)、第 17 条、第 17 条第 3 款、第 5 条第 2 款 Art. 5(2)）撰写，不构成法律意见；边缘情形请与贵司法务顾问确认，或参考监管机构的指引。

GDPR 第 17 条规定，凡满足六种法定事由之一，任何欧盟/欧洲经济区（EU/EEA）的数据主体均有权要求"在无不正当延迟的情况下"删除其个人数据。实务中与企业团队最相关的事由是：

数据对当初收集的目的已不再必要。
数据主体撤回同意，且处理没有其他法律依据。
数据主体反对处理，且不存在压倒性的正当利益事由。
数据从一开始就是被违法处理的。
为履行法律义务而必须删除。
数据系就信息社会服务向儿童收集的。

有两个范围界定问题常在早期就把团队绊住。第一，请求针对的是个人数据——即能够识别到自然人的信息——不适用于公司、不适用于匿名化数据，也不适用于你实际从未持有的数据。第二，该权利覆盖你控制之下任何位置的数据：生产数据库、CRM、营销自动化工具、客服工单、电子签平台、备份，以及你分享过数据的所有下游处理者。第 17 条第 2 款（Art. 17(2)）还补充规定：如果你已将数据公开，必须采取合理措施，告知其他正在处理该数据的控制者有人提出了删除请求。

一个月的期限（以及何时可以延长）

第 12 条第 3 款（Art. 12(3)）设定了期限：无不正当延迟地作出回应，且无论如何应在收到请求后一个月内完成。时钟从你收到请求之日起算——而不是从你的工单系统把它分派到正确队列的那一天起算。这就是为什么受理环节的纪律如此重要。

你最多可以延长两个月，但仅限于请求复杂、或请求数量众多的情形。若决定延长，必须在第一个月内告知数据主体，说明理由，并给出新的期限。"我们太忙了"不构成复杂性理由；跨多系统的数据核对、庞大的数据量，或真实存在冲突的法律义务，才可以构成。

把这个期限当作硬性运营约束来对待：几天内确认收到，把完成目标定在远低于一个月的位置，并把延期告知函做成模板——这样启用延期是一个决策，而不是临时手忙脚乱。

删除任何数据之前，先核实请求人身份

删除是不可逆的，因此身份核实是整个工作流中风险最高的一步。第 12 条第 6 款（Art. 12(6)）允许你在对请求人身份存在合理怀疑时，要求其提供确认身份所必需的额外信息。

比例原则是总纲：要求提供足以让你确信的证明，但不要索取超出你既存数据范围的信息，更不要借核实之名收集新的个人数据。可扩展的实操做法包括：验证对方对存档邮箱的控制权；要求提供只有数据主体本人才知道的交易或账户编号；或者使用既有的已验证登录。如果请求人是通过其此前使用过的同一认证渠道与你联系，该渠道本身通常就足够了。

如果仍无法确认身份，你可以拒绝采取行动——但必须明确告知，解释原因，并说明什么能够消除疑虑。这里与签署流程有一个平行参照：用于认证签署人身份的同一类核验技术，例如为签署人启用双因素认证（2FA），正是判断远程身份主张"多少保障才算够"的有益先例。

何时可以拒绝或限制删除请求

第 17 条第 3 款（Art. 17(3)）列出了删除权不适用的情形。下表映射了最常见的业务场景、拒绝是否通常站得住脚，以及应当写入记录的内容。

拒绝事由（第 17 条第 3 款）	能否拒绝？	应记录什么
行使言论与信息自由	可以，在适用范围内（对典型 SaaS 数据较为罕见）	公共利益依据及已执行的权衡测试
履行法律义务（欧盟或成员国法律）	可以——例如税务、会计、反洗钱的法定留存期限	具体法规条文、其留存期限，以及法律依据的对应关系
公共卫生领域的公共利益	可以，限于狭窄的健康数据场景	公共卫生事由及比例性评估
公共利益存档、科学/历史研究或统计	可以，前提是删除将严重损害该目的	为何该目的会受到损害；已采取的保障措施
法律主张的提起、行使或抗辩	可以——这是已签署协议最常用的例外	主张风险的性质、诉讼保全（litigation hold）状态及预计持续时长
履行合同仍然需要（第 17 条第 1 款 a 项事由不成立）	实质上可以——数据仍为必要	存续中的处理目的、为何仍然必要，以及复核日期

有两个习惯能让拒绝经得起检验。第一，能部分拒绝就部分拒绝：即便合同记录必须留存，营销数据和客服往来仍应删除。把数据最小化原则应用于拒绝本身，恰恰是监管者期待看到的。第二，永远要回应——拒绝也是一种回应，且必须援引所依据的例外条款，并告知请求人有权向监管机构投诉或寻求司法救济。

已签合同难题：删除权 vs. 签署证据

实务中最尖锐的张力出现在已签署协议上。一位前客户行使第 17 条权利，而他的姓名、邮箱、IP 地址和签署事件都嵌在已生效的合同与审计轨迹里。删掉它们感觉不对；全部保留又感觉是在无视请求。

通常的解法是分层处理。第一，记录双方义务的已签合同，一般落入"法律主张"例外或法定留存义务的范畴——你保留它们，并在回复中明说。签署证据存在的意义恰恰在于证明谁同意了什么；例如每个签署信封附带的完成证书（certificate of completion）这类电子签审计轨迹，正是为"防篡改地记录这一切"而设计的。

第二，对核心记录之外的一切应用最小化。与该人相关的营销画像、产品分析数据、客服对话、草稿或未签署文件，通常都可以删除。第三，当文件必须留存、但不再需要持续识别该人时，可考虑对非必要字段做匿名化或假名化（pseudonymization）处理——例如在保留已签署文书的同时隐去个人邮箱——而不是把日后争议中可能需要的证据整体删除。妥善匿名化的数据完全落在 GDPR 适用范围之外；但"妥善"的门槛很高，应把它当作法律判断，而非技术默认值。

这也是一堂采购课。评估平台时，签约前就要查清厂商如何处理留存、删除与数据驻留——诸如面向 Adobe Sign 用户的 GDPR 与 eIDAS 采购核查清单和eIDAS 合规电子签名指南，展示的就是成熟买家针对这类控制点会问的问题。

处理删除请求的分步工作流

把这份清单当作可重复执行的标准操作程序。

受理与登记。 请求到达当天，即在专用登记册中记录请求内容、收到日期、渠道和请求人信息，并指定负责人。
确认收到。 向请求人确认收讫，说明一个月期限，并管理预期。
核实身份。 执行合乎比例的核验。仅当核验确实失败时才暂停实质处理，并记录该疑虑。
圈定数据范围。 查询该人数据所在的每一个系统——CRM、计费、客服、营销、产品分析、电子签平台、数据仓库和备份。覆盖处理者与次处理者。
评估事由与例外。 对每个数据类别，记录删除事由、可能适用的第 17 条第 3 款例外、留存义务及诉讼保全状态。有争议的事项须取得法务签核。
执行。 删除必须删除的，适当进行匿名化，保留必须保留的。向处理者发出删除指令并确认完成。
回复。 告知请求人哪些已删除、哪些被保留、每项保留的法律依据，以及其向监管机构投诉的权利。
记录与复核。 将完整记录归档至登记册；注明是否启用过延期；为留存数据在其留存期届满时安排删除。

第 5 条第 2 款项下的记录与问责

第 5 条第 2 款（Art. 5(2)）——问责原则——意味着你必须能够证明合规，而不仅仅是做到合规。请求登记册是核心载体：每条记录应包含收到日期、身份核验方式、检索过的系统、各数据类别的处理决定、援引的例外、采取的行动、处理者确认、回复日期及回复内容。

有两项配套控制的回报远超投入。一是保持更新的数据地图，它能把工作流第 4 步从"取证式排查"变成快速查询。二是供应商尽调，确保你的处理者确实有能力执行删除指令——SOC 2 Type II 报告这类安全鉴证表明厂商的控制措施经过独立审查，而具备审计轨迹的电子签名解决方案这类平台能力，则让你记录中的证据部分始终保持可辩护性，即便你在其他地方不断压缩个人数据。

最后，把删除与欺诈风险放在一起考量：删除请求本身也是一种社会工程攻击载体，因此对异常请求要拿出你审视电子签名欺诈风险时同样的怀疑态度——先核实，再行动。

用 Nota Sign 简化合规工作流

要处理好删除请求，前提是清楚个人数据落在文档体系的哪个位置——并且所依托的平台能提供清晰的审计轨迹、留存控制和区域数据驻留选项。Nota Sign 是法大大（FaDaDa）旗下的全球电子签平台，正是为这样的运营环境而生：连续多年位居 IDC 中国电子签名软件市场份额第一，法律覆盖 100+ 国家和地区，并具备深厚的亚太合规能力，包括 iAM Smart、Singpass、SES/AES/QES 各级签名等级，以及区域数据中心。

Nota Sign 的定价模式对合规团队同样友好：无按席位收费，小团队推行受治理的签署流程不会随人数增长出现成本膨胀；中大型及企业客户则可根据数据驻留和工作流要求获得定制化方案。

如果你正在评估自家电子签体系如何处理审计轨迹、留存与跨境数据，欢迎联系 Nota Sign 团队，谈谈你的合规需求。