关于 auto-deletion-workflow
面向设计个人数据删除流程的团队,提供 GDPR 保留期限到期和删除请求的自动化工作流指南。内容涉及依赖关系处理、删除确认审计记录、失败重试和监控报告。
主要功能
- 01覆盖保留期限与删除请求触发
- 02规划依赖关系和级联删除
- 03生成删除确认审计记录
- 04定义失败处理与重试流程
- 05提供监控指标和合规报告内容
适用场景
- 01设计 GDPR 删除请求处理流程
- 02按保留期限规划自动删除
- 03协调相关系统中的依赖数据删除
- 04审查删除失败和备份轮换状态
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ mukul975/ privacy-data-protection-skills --skill auto-deletion-workflow安装后在 Claude Code 中输入/auto-deletion-workflow确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
assets/template.mdreferences/standards.mdworkflows.mdscripts/process.py详细介绍
自动化数据删除工作流
概述
自动化删除工作流可确保在保留期限届满或收到符合 GDPR 第 17 条要求的有效删除请求时,从所有系统中移除个人数据。大规模手动删除容易出错,也无法始终如一地满足存储期限限制原则。本技能定义了构建自动化删除管道所需的架构、逻辑和操作流程,以处理级联依赖关系、维护引用完整性、生成符合审计要求的确认日志,并满足定期保留期限届满和按需删除请求的需求。
法律依据
GDPR 第 17(1) 条——删除权
数据主体有权要求控制者毫不迟延地删除与其有关的个人数据;在符合规定事由时,控制者有义务毫不迟延地删除个人数据。
GDPR 第 5(1)(e) 条——存储期限限制
个人数据的保存期限不得超过处理个人数据的目的所需的期限。自动化删除是在大规模场景下执行这一原则的主要技术措施。
GDPR 第 25(1) 条——通过设计实现数据保护
控制者应实施适当的技术和组织措施,以有效落实数据保护原则,例如数据最小化。自动化删除是设计阶段的核心控制措施。
GDPR 第 30(1)(f) 条——拟定的删除时限
处理活动记录必须在可能的情况下列明不同类别数据拟定的删除时限。自动化删除系统可将这些拟定时限付诸实施。
自动化删除架构
删除触发类型
| 触发类型 | 来源 | SLA | 优先级 |
|---|---|---|---|
| 保留期限届满 | 保留计划元数据达到计算出的删除日期 | 到期后 30 天内 | 标准 |
| 数据主体删除请求 | 通过 DSAR 工作流验证的第 17 条请求 | 验证请求后 30 个日历日内 | 高 |
| 撤回同意 | 同意管理平台事件 | 30 天内(最佳实践:72 小时) | 高 |
| 账户关闭 | 客户账户终止事件 | 按保留计划执行(关闭后的保留期限) | 标准 |
| 目的达成 | 处理目的已达成,且不存在其他法律依据 | 目的达成后 30 天内 | 标准 |
| 解除法律保留 | 法务顾问解除诉讼保留 | 解除保留后 14 天内 | 标准 |
系统架构
┌─────────────────────────────────────────────────────────────┐
│ DELETION ORCHESTRATOR │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ Trigger │ │ Dependency │ │ Execution │ │
│ │ Engine │ │ Resolver │ │ Engine │ │
│ │ │ │ │ │ │ │
│ │ - Scheduled │ │ - FK mapping │ │ - System agents │ │
│ │ - Event-driven│ │ - Cascade │ │ - API calls │ │
│ │ - On-demand │ │ rules │ │ - Direct DB ops │ │
│ │ - Hold check │ │ - Orphan │ │ - File system │ │
│ │ │ │ handling │ │ purge │ │
│ └──────┬───────┘ └──────┬───────┘ └────────┬─────────┘ │
│ │ │ │ │
│ └────────┬────────┘ │ │
│ ▼ │ │
│ ┌──────────────────────────┐ │ │
│ │ Deletion Job Queue │─────────────────┘ │
│ │ (Priority-ordered) │ │
│ └──────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────┐ ┌──────────────────────────┐ │
│ │ Confirmation Logger │ │ Audit Trail Generator │ │
│ │ - Per-system status │ │ - Immutable audit log │ │
│ │ - Completion timestamp │ │ - Deletion certificate │ │
│ │ - Verification hash │ │ - Regulatory report │ │
│ └──────────────────────────┘ └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
删除工作流流程
工作流 1:定期保留期限届满删除
[Daily Retention Scan — 02:00 UTC]
│
▼
[Query all records where calculated_deletion_date <= TODAY + 30 days]
│
▼
[For each record approaching expiry]
│
├── [Check: Active litigation hold?]
│ ├── Yes ──► [Skip — log hold reference, notify Legal]
│ └── No ──► Continue
│
├── [Check: Active regulatory investigation?]
│ ├── Yes ──► [Skip — log investigation reference]
│ └── No ──► Continue
│
├── [Check: Pending data subject request referencing this data?]
│ ├── Yes ──► [Coordinate with DSAR workflow]
│ └── No ──► Continue
│
├── [Check: Retention exception approved?]
│ ├── Yes ──► [Skip — log exception reference and expiry]
│ └── No ──► Continue
│
▼
[Add to deletion job queue with priority: STANDARD]
│
▼
[On calculated_deletion_date: Execute deletion]
工作流 2:按需删除请求
[Verified Art. 17 Erasure Request Received]
│
▼
[Data Discovery — Identify all instances of data subject's data]
│
├── Primary databases (CRM, ERP, HR system)
├── Data warehouse and analytics platforms
├── File storage (SharePoint, network drives, cloud storage)
├── Email and communication systems
├── Backup and archive systems
├── Third-party processor systems
└── Logs and audit trails
│
▼
[Generate Deletion Manifest]
Reference: DEL-YYYY-NNNN
Data Subject: [Pseudonymised reference]
Systems identified: [List with record counts]
Exceptions identified: [Any Art. 17(3) exceptions]
Estimated completion: [Date]
│
▼
[DPO Review and Approval]
├── Approved ──► [Add to deletion job queue with priority: HIGH]
└── Exceptions found ──► [Partial deletion — exclude excepted data]
│
▼
[Execute deletion across all identified systems]
工作流 3:级联删除逻辑
删除主记录时,还必须删除相关系统中的依赖记录。级联删除解析器负责处理引用完整性:
[Primary Record Identified for Deletion]
│
▼
[Load Dependency Map for Record Type]
│
▼
[Resolve Dependencies — Depth-First Traversal]
│
├── [Level 0: Primary record]
│ Example: Customer record in CRM
│
├── [Level 1: Direct dependents]
│ Example: Orders, support tickets, consent records
│
├── [Level 2: Secondary dependents]
│ Example: Order line items, payment records, shipping records
│
└── [Level 3+: Tertiary dependents]
Example: Invoice line items, refund records
│
▼
[For each dependent record]
│
├── [Shared dependency?]
│ (Record also linked to other primary records not being deleted)
│ ├── Yes ──► [Nullify foreign key — do NOT delete]
│ └── No ──► [Add to deletion manifest]
│
├── [Legal retention override?]
│ (Dependent record has its own statutory retention requirement)
│ ├── Yes ──► [Anonymize link to primary record, retain dependent]
│ └── No ──► [Add to deletion manifest]
│
└── [Aggregated/statistical record?]
(Record contributes to aggregated reporting)
├── Yes ──► [Anonymize — remove personal identifiers, retain aggregate]
└── No ──► [Add to deletion manifest]
│
▼
[Execute deletion in reverse order (deepest dependents first)]
Level 3+ ──► Level 2 ──► Level 1 ──► Level 0
依赖关系映射模板
Orion Data Vault Corp 配置了以下依赖关系映射:
| 主实体 | 依赖实体 | 关系 | 删除操作 | 保留期限覆盖 |
|---|---|---|---|---|
| 客户 | 订单 | 1:N | 级联删除(法定保留期结束后) | 6 年 — HMRC |
| 客户 | 支持工单 | 1:N | 级联删除 | 3 年 — 诉讼时效 |
| 客户 | 同意记录 | 1:N | 级联删除 | 保留抑制记录 |
| 客户 | 营销偏好 | 1:1 | 级联删除 | 在退订名单中保留退订记录 |
| 客户 | 账户审计日志 | 1:N | 匿名化(将客户引用置空) | 7 年 — 审计保留期 |
| 订单 | 订单明细 | 1:N | 级联删除 | 遵循订单保留期限 |
| 订单 | 付款记录 | 1:N | 匿名化 | 6 年 — 财务记录 |
| 订单 | 配送记录 | 1:N | 级联删除 | 遵循订单保留期限 |
| 订单 | 发票 | 1:N | 匿名化 | 6 年 — 税务记录 |
| 员工 | 薪资记录 | 1:N | 级联删除(法定保留期结束后) | 6 年 — PAYE Regulations |
| 员工 | 绩效评估 | 1:N | 级联删除 | 雇佣期限 + 6 年 |
| 员工 | 访问日志 | 1:N | 匿名化 | 2 年 — 安全保留期 |
确认日志记录
删除确认记录结构
每次执行删除都会生成一条不可变的确认记录:
DELETION CONFIRMATION RECORD — Orion Data Vault Corp
-----------------------------------------------------
Reference: DEL-2026-0142
Trigger: Retention expiry / Art. 17 request / Consent withdrawal
Data Subject Reference: DS-HASH-a3f8c2e1
Request Date: 2026-02-15 (if applicable)
Execution Date: 2026-03-14
Completed Date: 2026-03-14T14:23:07Z
SYSTEMS PROCESSED:
┌─────────────────────────┬──────────┬───────────────┬──────────────────┐
│ System │ Records │ Action │ Status │
├─────────────────────────┼──────────┼───────────────┼──────────────────┤
│ CRM (Salesforce) │ 1 │ Hard delete │ Confirmed │
│ ERP (SAP) │ 47 │ Hard delete │ Confirmed │
│ Data Warehouse (BQ) │ 312 │ Hard delete │ Confirmed │
│ Email (Exchange) │ 23 │ Hard delete │ Confirmed │
│ File Storage (S3) │ 8 │ Hard delete │ Confirmed │
│ Backup (Veeam) │ N/A │ Flagged │ Pending (cycle) │
│ Analytics (Mixpanel) │ 156 │ Hard delete │ Confirmed │
│ Support (Zendesk) │ 12 │ Hard delete │ Confirmed │
│ Audit Log │ 89 │ Anonymized │ Confirmed │
│ Payment (Stripe) │ 5 │ Anonymized │ Confirmed │
└─────────────────────────┴──────────┴───────────────┴──────────────────┘
THIRD-PARTY NOTIFICATIONS (Art. 19):
- Processor A (Analytics SaaS): Notified 2026-03-14, confirmed 2026-03-16
- Processor B (Email service): Notified 2026-03-14, confirmed 2026-03-15
- Processor C (Payment gateway): Notified 2026-03-14, pending
EXCEPTIONS APPLIED:
- Financial records (invoices): Anonymized, retained until 2032-03-14 (6-year statutory period)
- Audit log entries: Anonymized, retained until 2033-03-14 (7-year audit retention)
BACKUP DELETION:
- Backup system: Next full rotation cycle completes 2026-06-12
- Expected complete erasure from backups: 2026-06-12
VERIFICATION:
- Post-deletion scan completed: 2026-03-14T14:45:00Z
- Residual data found: None
- Verification hash: SHA-256:e3b0c44298fc1c149afbf4c8996fb924...
Executed by: Deletion Orchestrator v3.2 (automated)
Reviewed by: [DPO Name] (for Art. 17 requests only)
审计跟踪要求
- 不可变性:删除确认记录写入仅追加的审计日志(一次写入存储或以区块链锚定的哈希)。
- 确认记录的保留期限:自删除日期起保留 3 年(足以在遭到质疑时证明合规性)。
- 日志中不包含个人数据:确认记录仅通过假名化标识符引用数据主体,绝不使用姓名、电子邮件或其他直接标识符。
- 可搜索性:必须支持按删除引用、数据主体哈希、触发类型、系统和日期范围搜索记录。
错误处理与重试逻辑
删除失败处理
| 失败类型 | 操作 | 重试 | 升级处理 |
|---|---|---|---|
| 系统不可用 | 加入队列以重试 | 按 1 小时、4 小时和 24 小时间隔重试 3 次 | 失败 3 次后通知 IT Operations |
| 权限被拒绝 | 记录错误,标记为待人工审核 | 不自动重试 | 升级给系统管理员 |
| 违反引用完整性 | 转交依赖解析器处理 | 重新解析依赖项并重试 | 无法解析时升级给 DPO |
| 部分删除(部分记录删除失败) | 记录已成功删除的记录,重试失败项 | 重试 3 次 | 升级给 IT + DPO |
| 第三方处理方未响应 | 7 天后发送提醒 | 14 天后跟进 | 21 天后升级给 DPO + Legal |
| 备份系统 — 无法从活动备份中删除 | 标记为等待下一个轮换周期处理 | 监控备份轮换计划 | 90 天内未完成时发出提醒 |
回滚注意事项
删除本质上不可逆。因此:
- 删除前快照:对于 Art. 17 请求,创建待删除数据的临时加密快照。删除执行后保留 72 小时,以便更正错误。72 小时后自动销毁。
- 分阶段执行:对于大规模保留期限到期删除(>10,000 条记录),每批处理 1,000 条记录,并在批次间进行验证。
- 试运行模式:所有新的删除规则在启用前必须以试运行模式测试 30 天。试运行会生成删除清单和确认记录,但不会实际执行删除。
监控与报告
关键指标
| 指标 | 目标 | 衡量频率 |
|---|---|---|
| 保留期限届满后删除完成率 | 在届满后 30 天内达到 99.5% | 每月 |
| 第 17 条删除请求完成率 | 在 30 个日历日内达到 100% | 每个请求 |
| 平均删除执行时间 | < 4 小时(端到端,覆盖所有系统) | 每次执行 |
| 删除失败率 | < 0.5% | 每月 |
| 备份删除完成率 | 在备份轮换周期内达到 100% | 每次轮换 |
| 第三方处理者确认率 | 在 14 天内达到 100% | 每次通知 |
季度合规报告
自动化删除系统会生成季度报告,其中包含:
- 按触发类型统计的已删除记录总数(保留期限届满、第 17 条、撤回同意等)
- 删除完成率与 SLA 目标的对比
- 已适用的例外情况(按法律依据细分)
- 删除失败情况及其解决状态
- 第三方处理者合规率
- 备份删除状态及未完成事项
- 趋势分析(数据量增长、系统覆盖范围、性能)
评论
支持 Markdown