本文へ移動
cccskills
無料GitHub で公開

auto-deletion-workflow

Implements automated data deletion workflows for GDPR Article 17 right to erasure and retention period expiry. Covers cascading deletion across dependent systems, dependency handling for referential integrity, confirmation logging, and audit trail generation. Activate for automated deletion, erasure automation, data purge, retention expiry queries.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md17.4 KB
  • assets/template.md2.3 KB
  • references/standards.md1.8 KB
  • references/workflows.md3.4 KB
  • scripts/process.py9.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Automated Data Deletion Workflow

Overview

Automated deletion workflows ensure that personal data is removed from all systems when retention periods expire or when a valid erasure request is received under GDPR Article 17. Manual deletion at scale is error-prone and fails to meet the storage limitation principle consistently. This skill defines the architecture, logic, and operational procedures for building automated deletion pipelines that handle cascading dependencies, maintain referential integrity, produce audit-grade confirmation logs, and satisfy both scheduled retention expiry and on-demand erasure requests.

Legal Foundation

GDPR Article 17(1) — Right to Erasure

The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay, and the controller shall have the obligation to erase personal data without undue delay where one of the specified grounds applies.

GDPR Article 5(1)(e) — Storage Limitation

Personal data shall be kept for no longer than is necessary for the purposes for which the personal data are processed. Automated deletion is the primary technical measure for enforcing this principle at scale.

GDPR Article 25(1) — Data Protection by Design

The controller shall implement appropriate technical and organisational measures designed to implement data-protection principles, such as data minimisation, in an effective manner. Automated deletion is a core by-design control.

GDPR Article 30(1)(f) — Envisaged Time Limits for Erasure

Records of processing activities must include, where possible, the envisaged time limits for erasure of the different categories of data. Automated deletion systems operationalize these envisaged time limits.

Automated Deletion Architecture

Deletion Trigger Types

Trigger TypeSourceSLAPriority
Retention expiryRetention schedule metadata reaching calculated deletion dateWithin 30 days of expiryStandard
Data subject erasure requestVerified Art. 17 request via DSAR workflowWithin 30 calendar days of verified requestHigh
Consent withdrawalConsent management platform eventWithin 30 days (best practice: 72 hours)High
Account closureCustomer account termination eventPer retention schedule (post-closure retention period)Standard
Purpose completionProcessing purpose fulfilled, no further legal basisWithin 30 days of purpose completionStandard
Legal hold releaseLitigation hold lifted by Legal counselWithin 14 days of hold releaseStandard

System Architecture

┌─────────────────────────────────────────────────────────────┐
│                   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     │ │
│  └──────────────────────────┘  └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Deletion Workflow Procedures

Workflow 1: Scheduled Retention Expiry Deletion

[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]

Workflow 2: On-Demand Erasure Request Deletion

[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]

Workflow 3: Cascading Deletion Logic

When deleting a primary record, dependent records across related systems must also be deleted. The cascading deletion resolver handles referential integrity:

[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

Dependency Map Template

The following dependency map is configured for Orion Data Vault Corp:

Primary EntityDependent EntityRelationshipDeletion ActionRetention Override
CustomerOrders1:NCascade delete (after statutory retention)6 years — HMRC
CustomerSupport Tickets1:NCascade delete3 years — limitation period
CustomerConsent Records1:NCascade deleteRetain suppression record
CustomerMarketing Preferences1:1Cascade deleteRetain opt-out on suppression list
CustomerAccount Audit Log1:NAnonymize (nullify customer reference)7 years — audit retention
OrderOrder Lines1:NCascade deleteFollows order retention
OrderPayment Records1:NAnonymize6 years — financial records
OrderShipping Records1:NCascade deleteFollows order retention
OrderInvoices1:NAnonymize6 years — tax records
EmployeePayroll Records1:NCascade delete (after statutory retention)6 years — PAYE Regulations
EmployeePerformance Reviews1:NCascade deleteDuration of employment + 6 years
EmployeeAccess Logs1:NAnonymize2 years — security retention

Confirmation Logging

Deletion Confirmation Record Structure

Every deletion execution produces an immutable confirmation record:

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)

Audit Trail Requirements

  1. Immutability: Deletion confirmation records are written to an append-only audit log (write-once storage or blockchain-anchored hash).
  2. Retention of confirmation records: 3 years from deletion date (sufficient to demonstrate compliance if challenged).
  3. No personal data in logs: Confirmation records reference data subjects by pseudonymised identifier only — never by name, email, or other direct identifier.
  4. Searchability: Records must be searchable by deletion reference, data subject hash, trigger type, system, and date range.

Error Handling and Retry Logic

Deletion Failure Handling

Failure TypeActionRetryEscalation
System unavailableQueue for retry3 attempts at 1h, 4h, 24h intervalsAlert IT Operations after 3 failures
Permission deniedLog error, flag for manual reviewNo automatic retryEscalate to system administrator
Referential integrity violationRoute to dependency resolverRe-resolve dependencies, retryEscalate to DPO if unresolvable
Partial deletion (some records failed)Log successful deletions, retry failed3 attemptsEscalate to IT + DPO
Third-party processor non-responseSend reminder at 7 daysFollow up at 14 daysEscalate to DPO + Legal at 21 days
Backup system — cannot delete from active backupFlag for next rotation cycleMonitor backup rotation scheduleAlert if not completed within 90 days

Rollback Considerations

Deletion is inherently irreversible. Therefore:

  1. Pre-deletion snapshot: For Art. 17 requests, take a temporary encrypted snapshot of the data to be deleted. Retain for 72 hours after deletion execution to allow for error correction. Auto-destroy after 72 hours.
  2. Staged execution: For large-scale retention expiry deletions (>10,000 records), execute in batches of 1,000 with verification between batches.
  3. Dry-run mode: All new deletion rules must be tested in dry-run mode for 30 days before activation. Dry-run produces the deletion manifest and confirmation record without executing actual deletion.

Monitoring and Reporting

Key Metrics

MetricTargetMeasurement
Retention expiry deletion completion rate99.5% within 30 days of expiryMonthly
Art. 17 erasure request completion rate100% within 30 calendar daysPer request
Average deletion execution time< 4 hours (end-to-end across all systems)Per execution
Failed deletion rate< 0.5%Monthly
Backup deletion completion rate100% within backup rotation cyclePer rotation
Third-party processor confirmation rate100% within 14 daysPer notification

Quarterly Compliance Report

The automated deletion system generates a quarterly report containing:

  1. Total records deleted by trigger type (retention expiry, Art. 17, consent withdrawal, etc.)
  2. Deletion completion rates against SLA targets
  3. Exceptions applied (with legal basis breakdown)
  4. Failed deletions and resolution status
  5. Third-party processor compliance rates
  6. Backup deletion status and outstanding items
  7. Trend analysis (volume growth, system coverage, performance)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Implements 42 CFR Part 2 protections for substance use disorder patient records. Covers written consent requirements stricter than HIPAA, re-disclosure prohibition, court order procedures, qualified service organization agreements, and 2024 amendments aligning Part 2 with HIPAA. Keywords: 42 CFR Part 2, substance use disorder, SUD records, re-disclosure, consent, Part 2 amendments.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Guides assessment of third-country adequacy decisions under GDPR Article 45 for international data transfers. Covers the current EC adequacy decisions list, adequacy assessment criteria, partial adequacy handling, and monitoring of adequacy decision reviews. Keywords: adequacy decision, Article 45, third country, adequate protection, EC adequacy list.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Implements age-gating mechanisms for online services to restrict access based on user age. Covers hard gates versus soft gates, neutral age prompts, re-verification triggers, circumvention prevention, and regulatory requirements under GDPR, COPPA, UK Online Safety Act, and DSA. Keywords: age gate, age restriction, neutral prompt, children, online services, access control.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Evaluates and implements age estimation and verification technologies for online services. Covers facial age estimation, digital ID verification, self-declaration with risk assessment, AI-based age estimation, and the accuracy versus privacy tradeoff. Includes ICO guidance and euCONSENT framework. Keywords: age verification, age estimation, facial analysis, digital ID, children, online safety.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Preparing EU AI Act compliance documentation for high-risk AI systems. Covers Annex III classification, technical documentation under Art. 11, conformity assessment, risk management systems, and CE marking requirements. Keywords: EU AI Act, high-risk AI, Annex III, conformity assessment, CE marking.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Implements GDPR Art. 22 automated decision-making and AI Act Art. 14 human oversight requirements for AI systems. Covers identification of solely automated decisions, meaningful human intervention design, logic explanation mechanisms, and contestation procedures. Keywords: Art. 22, automated decision, human oversight, AI Act, profiling, contestation.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

mukul975 のスキルをすべて見る

このスキルの問題を報告する