mcpField
A
auto-deletion-workflow

auto-deletion-workflow

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

关于 auto-deletion-workflow

面向设计个人数据删除流程的团队,提供 GDPR 保留期限到期和删除请求的自动化工作流指南。内容涉及依赖关系处理、删除确认审计记录、失败重试和监控报告。

主要功能

  1. 01覆盖保留期限与删除请求触发
  2. 02规划依赖关系和级联删除
  3. 03生成删除确认审计记录
  4. 04定义失败处理与重试流程
  5. 05提供监控指标和合规报告内容

适用场景

  1. 01设计 GDPR 删除请求处理流程
  2. 02按保留期限规划自动删除
  3. 03协调相关系统中的依赖数据删除
  4. 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.md
references/
standards.md
workflows.md
scripts/
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)
审计跟踪要求
  1. 不可变性:删除确认记录写入仅追加的审计日志(一次写入存储或以区块链锚定的哈希)。
  2. 确认记录的保留期限:自删除日期起保留 3 年(足以在遭到质疑时证明合规性)。
  3. 日志中不包含个人数据:确认记录仅通过假名化标识符引用数据主体,绝不使用姓名、电子邮件或其他直接标识符。
  4. 可搜索性:必须支持按删除引用、数据主体哈希、触发类型、系统和日期范围搜索记录。

错误处理与重试逻辑

删除失败处理
失败类型操作重试升级处理
系统不可用加入队列以重试按 1 小时、4 小时和 24 小时间隔重试 3 次失败 3 次后通知 IT Operations
权限被拒绝记录错误,标记为待人工审核不自动重试升级给系统管理员
违反引用完整性转交依赖解析器处理重新解析依赖项并重试无法解析时升级给 DPO
部分删除(部分记录删除失败)记录已成功删除的记录,重试失败项重试 3 次升级给 IT + DPO
第三方处理方未响应7 天后发送提醒14 天后跟进21 天后升级给 DPO + Legal
备份系统 — 无法从活动备份中删除标记为等待下一个轮换周期处理监控备份轮换计划90 天内未完成时发出提醒
回滚注意事项

删除本质上不可逆。因此:

  1. 删除前快照:对于 Art. 17 请求,创建待删除数据的临时加密快照。删除执行后保留 72 小时,以便更正错误。72 小时后自动销毁。
  2. 分阶段执行:对于大规模保留期限到期删除(>10,000 条记录),每批处理 1,000 条记录,并在批次间进行验证。
  3. 试运行模式:所有新的删除规则在启用前必须以试运行模式测试 30 天。试运行会生成删除清单和确认记录,但不会实际执行删除。

监控与报告

关键指标
指标目标衡量频率
保留期限届满后删除完成率在届满后 30 天内达到 99.5%每月
第 17 条删除请求完成率在 30 个日历日内达到 100%每个请求
平均删除执行时间< 4 小时(端到端,覆盖所有系统)每次执行
删除失败率< 0.5%每月
备份删除完成率在备份轮换周期内达到 100%每次轮换
第三方处理者确认率在 14 天内达到 100%每次通知
季度合规报告

自动化删除系统会生成季度报告,其中包含:

  1. 按触发类型统计的已删除记录总数(保留期限届满、第 17 条、撤回同意等)
  2. 删除完成率与 SLA 目标的对比
  3. 已适用的例外情况(按法律依据细分)
  4. 删除失败情况及其解决状态
  5. 第三方处理者合规率
  6. 备份删除状态及未完成事项
  7. 趋势分析(数据量增长、系统覆盖范围、性能)

评论

支持 Markdown