mcpField
R
right-to-erasure

right-to-erasure

github.com/mukul975安全32341 次安装32 周前更新
代码仓库

关于 right-to-erasure

right-to-erasure 是指导组织处理 GDPR 第 17 条删除请求的操作流程技能,涵盖受理、评估、执行和确认。它说明删除依据与例外,并纳入向接收方通知及过程记录。

主要功能

  1. 01登记请求并核验身份
  2. 02评估删除依据与法定例外
  3. 03执行删除或匿名化流程
  4. 04通知第三方接收方
  5. 05验证结果并向数据主体确认
  6. 06保留删除处理记录

适用场景

  1. 01处理个人提出的删除请求
  2. 02判断请求是否适用删除例外
  3. 03协调处理者和接收方执行删除
  4. 04记录执行情况并回复请求人

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill right-to-erasure

安装后在 Claude Code 中输入/right-to-erasure确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

详细介绍

实施删除权工作流

概述

《通用数据保护条例》(GDPR)第 17 条规定的数据删除权,允许数据主体请求删除其个人数据。此项权利并非绝对权利——删除需符合特定条件,并受一系列例外情形限制。本技能提供了接收、评估、执行和确认删除请求的完整操作流程。

法律依据

GDPR 第 17 条——删除权(“被遗忘权”)
第 17(1) 条规定的六项删除依据

在符合以下任一依据的情况下,数据主体有权要求删除:

  1. 第 17(1)(a) 条——目的已实现:就收集或以其他方式处理个人数据的目的而言,这些数据已不再必要。
  2. 第 17(1)(b) 条——撤回同意:数据主体撤回了其依据第 6(1)(a) 条或第 9(2)(a) 条所作出的同意,且不存在其他处理的法律依据。
  3. 第 17(1)(c) 条——反对成功:数据主体依据第 21(1) 条提出反对,且不存在凌驾于其上的处理正当理由;或者数据主体依据第 21(2) 条反对将其个人数据用于直接营销。
  4. 第 17(1)(d) 条——非法处理:个人数据已被非法处理。
  5. 第 17(1)(e) 条——法律义务:为遵守对控制者具有约束力的欧盟或成员国法律规定的法律义务,必须删除个人数据。
  6. 第 17(1)(f) 条——儿童数据(信息社会服务):个人数据是在提供第 8(1) 条所指的信息社会服务时收集的。
第 17(3) 条规定的五项例外

在为以下目的而必须进行处理的范围内,不适用删除权:

  1. 第 17(3)(a) 条——言论和信息自由:行使言论和信息自由权。
  2. 第 17(3)(b) 条——法律义务:遵守对控制者具有约束力的欧盟或成员国法律规定的处理义务,或者执行为公共利益或行使赋予控制者的官方职权而开展的任务。
  3. 第 17(3)(c) 条——公共卫生:依据第 9(2)(h) 条和第 9(2)(i) 条以及第 9(3) 条,为公共卫生领域的公共利益处理数据。
  4. 第 17(3)(d) 条——归档/研究:依据第 89(1) 条,为公共利益进行归档、科学或历史研究,或统计处理,但仅限于删除权可能导致无法实现或严重妨碍该处理目标的情况。
  5. 第 17(3)(e) 条——法律请求:确立、行使或抗辩法律请求。
GDPR 第 19 条——通知义务

控制者应将任何个人数据删除情况通知每位已接收披露数据的接收方,除非这样做无法实现或需要付出不成比例的努力。如果数据主体提出请求,控制者应将这些接收方告知数据主体。

删除处理工作流

步骤 1:接收并记录删除请求
  1. 使用唯一编号记录请求(格式:ERA-YYYY-NNNN)。
  2. 记录请求渠道、时间戳(UTC)以及请求者身份。
  3. 在 3 个工作日内发送确认通知。
  4. 按照处理数据主体访问请求(DSAR)时采用的相同分级方法(低/中/高风险)核验身份。
步骤 2:确定删除依据
  1. 审查请求,确定数据主体援引了第 17(1)(a) 至 (f) 条规定的哪项删除依据。
  2. 如果数据主体未说明依据,则根据实际情况评估适用的依据。
  3. 在处理记录中记录确定的依据。
第 3 步:检查是否适用例外情形

针对已识别的每项依据,评估《条例》第 17(3)(a)-(e) 条规定的五项例外情形是否适用:

例外情形评估问题Meridian Analytics Ltd 的常见情形
言论自由 (a)这些数据是否作为新闻报道或公共讨论的一部分发布?已发布的研究报告、面向公众的分析内容
法律义务 (b)是否存在法定的留存要求?根据《2006 年公司法》留存财务记录(6 年);根据 HMRC 要求留存税务记录(6 年);根据《2017 年反洗钱条例》(MLR 2017)留存反洗钱记录(5 年)
公共卫生 (c)这些数据是否为公共卫生目的所必需?少见——适用于健康数据处理者
存档/研究 (d)删除是否会使研究无法进行或受到严重损害?用于已发表研究的匿名化数据集
法律主张 (e)是否存在涉及这些数据的待决或预期法律诉讼?正在处理的争议、监管调查、诉讼保留数据
第 4 步:删除与匿名化决策树
[Erasure Ground Established & No Exception Applies]
         │
         ▼
[Can data be permanently deleted from all systems?]
   │
   ├── Yes ──► [PERMANENT DELETION]
   │            - Remove from primary databases
   │            - Remove from backup systems within next backup cycle
   │            - Remove from third-party processors (Art. 19)
   │            - Purge from caches, logs, and temporary storage
   │            - Verify deletion across all systems
   │
   └── No ──► [Assess why deletion is not possible]
               │
               ├── Technical constraint (embedded in backup tapes)
               │     └── [ANONYMIZE + schedule deletion at next backup rotation]
               │         [Maximum retention of backup: 90 days at Meridian Analytics Ltd]
               │
               ├── Partial exception applies (some data needed for legal obligation)
               │     └── [PARTIAL DELETION + ANONYMIZATION]
               │         [Delete data not subject to exception]
               │         [Retain excepted data with restricted access]
               │         [Anonymize where possible]
               │
               └── Data is intermingled with other subjects' data
                     └── [TARGETED ANONYMIZATION]
                         [Replace identifiers with irreversible pseudonyms]
                         [Remove all direct identifiers]
                         [Verify re-identification risk < 0.05%]
第 5 步:执行删除
  1. 主系统:在所有已识别的数据存储中执行删除查询/命令。
  2. 备份系统:标记数据,以便在下一次备份轮换周期删除(记录预计完成日期,最长为 90 天)。
  3. 第三方处理者:根据第 28 条协议向所有处理者发出删除指示。记录指示日期,并要求确认已完成删除。
  4. 缓存和临时存储:清除应用程序缓存、CDN 缓存和临时文件。
  5. 搜索引擎取消索引:在个人数据已公开的情况下(第 17(2) 条),向搜索引擎提交取消索引请求。
第 6 步:通知第三方接收方(第 19 条)
  1. 找出所有曾披露个人数据的接收方(参照第 30 条处理活动记录)。
  2. 向每位接收方发送删除通知,内容包括:
    • 数据主体的参考信息(已匿名化)
    • 要删除的具体数据
    • 删除请求的法律依据
    • 确认删除的截止日期(14 个日历日)
  3. 记录每项通知及接收方的确认。
  4. 如果数据主体提出请求,提供已通知接收方的名单。
第 7 步:核实并确认
  1. 在所有系统中执行核查,确认数据已删除或匿名化。
  2. 获取所有第三方处理者的确认。
  3. 汇总删除完成记录。
  4. 在 30 天答复期限内向数据主体发送确认,内容包括:
    • 确认已完成删除
    • 已适用的任何部分例外(及其法律依据)
    • 备份系统数据的预计删除完成日期(如适用)
    • 已通知的第三方名单(如有请求)
第 8 步:记录留存
  1. 将删除处理记录(请求详情、评估、执行日志、确认)留存 3 年。
  2. 记录不得包含已删除的个人数据本身——只能包含有关删除过程的元数据。
  3. 在适当情况下,存储一条抑制记录(仅保留识别同一人员未来请求并防止重新收集所需的最低限度标识信息)。

答复时限

  • 标准期限:自收到请求之日(或完成身份验证之日)起 30 个日历日。
  • 延期:对于复杂请求,可额外延长最多 60 天(第 12(3) 条),并须在最初的 30 天期限内通知数据主体。
  • 备份删除:必须在下一个完整的备份轮换周期内完成(Meridian Analytics Ltd 最长为 90 天),并在答复中记录。

评论

支持 Markdown