Right-to-Delete Enforcement Prompt for Storage Tools

This prompt is designed for privacy engineers and platform operators who must automate the discovery and deletion of a data subject's information across a heterogeneous set of storage tools. It produces a cascading deletion plan that identifies primary records, backups, logs, and derived datasets, with explicit verification steps for each target. Use this prompt when an agent has access to multiple storage backends and must execute a right-to-delete request under GDPR, CCPA, or internal data retention policies. The prompt assumes the agent has tool access to list, search, and delete operations across the connected storage systems, and that the data subject identifier is known and verified before invocation.

Do not use this prompt for single-database cleanup scripts or when the storage topology is fully known and static; those cases are better served by deterministic code. This prompt is also inappropriate when the agent lacks delete permissions on all target systems, when data subject identity verification has not been completed, or when legal holds, regulatory retention obligations, or litigation preservation requirements are active on the subject's data. In those scenarios, the prompt must be paired with a human approval gate and a legal hold check before any deletion plan is generated. The prompt is not a substitute for a data inventory or data mapping exercise—it operates on systems the agent can already reach and interrogate.

Before deploying this prompt, ensure the agent's tool definitions include explicit dry_run parameters for every destructive operation, and that the deletion plan output is routed through a human review step before execution. The prompt includes verification steps, but production deployments should also log the full plan, tool calls, and confirmation responses to an immutable audit trail. If your storage systems include append-only or immutable backends, the prompt should be adapted to produce a deletion-or-suppression plan that accounts for those constraints rather than assuming all targets support physical deletion.

This prompt instructs the model to act as a privacy enforcement engine that produces a structured, verifiable deletion plan. It is designed for privacy engineers who need to map all locations of a data subject's information across connected storage tools—primary records, backups, logs, and derived datasets—before executing a right-to-delete request. The template uses square-bracket placeholders that must be replaced with concrete values from your environment before sending to the model.

textCopy
You are a data deletion enforcement agent operating within a governed storage environment. Your task is to produce a cascading deletion plan for a data subject exercising their right to deletion. You must identify every storage location containing the subject's data and define verification steps for each deletion target.

## Input
- Data Subject Identifier: [SUBJECT_ID]
- Deletion Request Scope: [DELETION_SCOPE]
- Connected Storage Tools: [TOOL_LIST]
- Data Classification Taxonomy: [CLASSIFICATION_TAXONOMY]
- Retention Policy Rules: [RETENTION_POLICY]
- Regulatory Framework: [REGULATORY_FRAMEWORK]

## Constraints
- Do not delete data required for legal holds, regulatory retention, or active disputes.
- Flag any record that cannot be deleted and provide the specific exemption reason.
- For each deletion target, include a verification method that confirms the data is irrecoverable.
- Respect data residency boundaries: [DATA_RESIDENCY_RULES]
- Log every deletion action with timestamp, target, and outcome for audit purposes.

## Output Schema
Return a JSON object with the following structure:
{
  "deletion_plan_id": "string",
  "subject_id": "string",
  "generated_at": "ISO8601 timestamp",
  "targets": [
    {
      "target_id": "string",
      "storage_tool": "string",
      "storage_path": "string",
      "data_category": "string",
      "record_type": "primary | backup | log | derived",
      "deletion_method": "string",
      "verification_steps": ["string"],
      "exemption": null | {
        "reason": "string",
        "policy_ref": "string",
        "review_required": boolean
      },
      "estimated_completion": "ISO8601 timestamp"
    }
  ],
  "orphan_record_check": {
    "detected_orphans": ["string"],
    "resolution_plan": "string"
  },
  "audit_log_reference": "string"
}

## Instructions
1. Parse the connected storage tools and identify all locations where [SUBJECT_ID] appears.
2. Classify each location by record type: primary, backup, log, or derived.
3. For each location, determine the appropriate deletion method (hard delete, overwrite, crypto-shred, or logical delete with tombstone).
4. Check each target against the retention policy and regulatory framework. Flag exemptions explicitly.
5. Define verification steps that confirm deletion, such as query-after-delete, checksum comparison, or access audit.
6. Run an orphan record check: identify any references to [SUBJECT_ID] that remain in indexes, materialized views, or join tables after primary record deletion.
7. Generate a unique audit log reference for this deletion plan.

Replace each placeholder with values from your environment before execution. The [TOOL_LIST] placeholder should contain structured descriptions of each connected storage tool, including its type, access method, and data categories it holds. The [DELETION_SCOPE] should specify whether this is a full deletion, partial deletion, or deletion with retention exceptions. After generating the plan, validate the output against the schema before passing it to any execution harness. For high-risk deletions involving financial, health, or legal data, route the plan through a human approval step before any destructive action.

This prompt is not a standalone chatbot interaction; it is a structured reasoning step inside a deletion orchestration pipeline. The application layer must first collect the data subject's identifier, the applicable regulation (e.g., GDPR, CCPA), and a list of connected storage tools with their capabilities. The prompt then produces a cascading deletion plan, but the application is responsible for executing each step, verifying completion, and maintaining the audit trail. The model's output is a plan, not an action. Treat it as a high-stakes instruction set that requires deterministic enforcement.

To integrate this prompt, build a service that constructs the [CONTEXT] object by querying your data catalog or configuration management database for all systems that could contain the subject's data. This includes primary databases, read replicas, backup snapshots, log aggregators, and derived datasets. The service should then call the LLM with the prompt template, parse the JSON output against the [OUTPUT_SCHEMA], and validate that every target in the plan maps to a known, accessible tool. Before any deletion command is issued, the plan must be presented for human approval through a review queue. After approval, the application executes each deletion step sequentially, recording the tool name, arguments, timestamp, and response code in an immutable audit log. Any failure must halt the pipeline and trigger an alert, never silently skipping a target.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set the temperature to 0 to maximize determinism. Implement a retry loop with a maximum of 2 attempts if the output fails schema validation. For the evaluation layer, build a test harness that injects known data subjects with synthetic records across mock storage tools and verifies that the generated plan includes every expected target and no false positives. Common failure modes include the model hallucinating storage systems not provided in the context, omitting backup or log-derived copies, and generating unverifiable deletion confirmation steps. Each of these must be caught by the validation layer before the plan reaches the approval queue. Do not allow the model to directly invoke deletion APIs; the application must mediate every tool call.