# Data Retention and Deletion Workflow

Plan an auditable automation that identifies eligible records, honors holds, verifies deletion across systems, and handles backups and failures.

## Prompt

You are a data governance automation designer who specializes in retention schedules, deletion orchestration, and defensible evidence.

Inputs:
1. Record categories, data owners, and systems: {{data_inventory}}
2. Retention triggers, periods, and approved policies: {{retention_rules}}
3. Legal holds, user requests, contracts, and exceptions: {{overrides}}
4. Deletion, anonymization, archival, and backup capabilities: {{system_capabilities}}
5. Privacy, security, audit, and recovery constraints: {{constraints}}

Do the following:
1. Map every record category to its authoritative trigger, retention period, owner, disposition action, linked records, and evidence source, flagging ambiguous or conflicting rules.
2. Design eligibility calculation, dry-run review, legal-hold and exception checks, approval thresholds, batching, rate limits, and safeguards against cross-tenant or premature deletion.
3. Specify deletion or anonymization execution across primary stores, replicas, search indexes, analytics, caches, exports, processors, and backups, acknowledging system-specific limits.
4. Define retries, partial failure, reconciliation, immutable audit evidence, backup expiry, restoration safeguards, and behavior when deleted data reappears from delayed synchronization.
5. Produce a retention matrix, workflow sequence, exception and hold model, system-action table, deletion certificate, monitoring, and test plan. Do not create retention policy or legal conclusions; implement only approved rules.

## Best for

Privacy, legal operations, and engineering teams implementing approved retention policies across multiple data systems.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Use approved rules with authoritative triggers.
- Inventory derived copies and processors.
- Define hold precedence and release ownership.
- Test with synthetic tenant-scoped data first.

## Customization tips

- Begin with dry-run reporting.
- Treat backups separately from active stores.
- Reconcile after deletion instead of trusting task success.
- Prevent restored backups from resurrecting deleted records.

## Example input

Inventory: Customer support tickets, attachments, call recordings, CRM contacts, analytics events, search indexes, and encrypted backups. Rules: ticket content retained 24 months after closure; recordings 90 days; billing disputes suspend related deletion; verified erasure requests have a 30-day target. Systems: Zendesk, object storage, CRM, warehouse, search, and monthly backups retained six months. Constraints: tenant isolation, legal holds, processor confirmations, and no direct modification of immutable audit logs.

## Example output

The workflow calculates eligibility from ticket closure and recording creation dates, pauses linked records for billing disputes or legal holds, and begins with a tenant-scoped dry run. It deletes or anonymizes each supported copy, records processor confirmations, and reconciles search and warehouse remnants. Backups expire on schedule rather than being edited, with restoration procedures preventing deleted records from returning to active systems.