Parts 1 and 2 of this series covered the DSR lifecycle and data discovery. This part addresses the operation that most organizations get wrong: deletion.
Deletion appears simple. A person asks to be deleted. You delete their data. But deletion in a production enterprise is not a single operation. It is an orchestrated series of irreversible actions across live databases, analytical warehouses, backup systems, caches, event logs, derived datasets, machine learning training sets, and downstream consumers — each with its own retention rules, technical constraints, and failure modes.
Getting deletion wrong has two consequences, both severe. Incomplete deletion means the organization has failed to comply with the request and remains liable. Excessive deletion — removing data that should have been retained under a legal hold or regulatory mandate — destroys evidence and creates a different liability.
Soft delete vs hard delete
The first architectural decision is whether deletion means the data is marked as deleted or physically removed.
A soft delete sets a flag — is_deleted = true — and the application layer filters the record from all queries, views, and exports. The data remains in the database. A hard delete removes the row from the table. The data is gone, subject to database-level recovery windows and backup retention.
Soft delete is not deletion. If a regulator audits the system and finds that "deleted" records are still sitting in the database, flagged but fully readable by anyone with direct database access, the organization has not complied with the deletion request. Soft delete is a useful intermediate step — it prevents the data from being used while the full deletion pipeline executes — but it cannot be the terminal state.
The correct pattern is a two-phase approach. Phase one is soft delete: immediate, reversible, prevents further processing. Phase two is hard delete: scheduled, irreversible, executed after a confirmation window. The confirmation window — typically 7 to 30 days — exists to handle the case where a deletion request was made in error or where a retention conflict surfaces after the soft delete. Once the confirmation window closes, hard delete executes and the data is physically removed.
Both phases must be logged. The soft delete timestamp, the hard delete timestamp, the identity of the process that executed each, and the scope of what was deleted. These logs are the deletion receipt.
Retention conflicts
Not all data can be deleted. Every jurisdiction that grants the right to deletion also defines exceptions. GDPR Article 17(3) exempts data necessary for compliance with a legal obligation, for reasons of public interest in public health, for archiving in the public interest, or for the establishment or defense of legal claims. CCPA provides exemptions for completing transactions, detecting security incidents, complying with legal obligations, and internal uses aligned with consumer expectations. The DPDP Act similarly acknowledges retention for legal obligations.
In practice, the most common retention conflicts are financial record-keeping laws (tax authorities typically require seven years of transaction records), anti-money laundering regulations (which mandate retention of transaction monitoring data and suspicious activity reports), active litigation holds (where a legal team has placed a preservation order on data relevant to pending or anticipated litigation), and contractual obligations (where data must be retained to fulfill an active service agreement).
The deletion system must evaluate every data element against the applicable retention rules before deleting it. This is not a global check — it is per-record, per-field, per-system. A person's email address in the CRM may be deletable. Their transaction history in the billing system may be subject to a seven-year tax retention. Their support tickets may be under litigation hold. Their behavioral data in the analytics warehouse may have no retention obligation and should be deleted immediately.
The system must produce a deletion manifest: a record of what was deleted, what was retained, and the legal basis for each retention. This manifest is part of the DSR response. The requestor has the right to know not only that their data was deleted but also what was not deleted and why.
Cascading dependencies
Data in an enterprise does not exist in isolation. It is copied, transformed, aggregated, and derived. Deleting the source does not delete the copies. Deleting the copies does not delete the aggregations. The deletion system must trace and follow the cascade.
Consider a user record in a production database. That record is replicated to a read replica for reporting. A nightly ETL extracts it into a data warehouse. The warehouse feeds a BI dashboard. The same record is streamed to an event bus, consumed by a recommendation engine, and used to train a machine learning model. A customer support agent exported a list containing the record to a spreadsheet last month.
Deleting the production database record and declaring the deletion complete means the data still exists in the read replica (until the next replication cycle), the data warehouse (until a deletion job runs), the BI cache (until it expires), the event bus history (until retention expires or is purged), the recommendation engine's feature store (until it is rebuilt), the ML training set (until the model is retrained without that data), and the support agent's spreadsheet (which the system cannot reach at all).
The deletion architecture must model these dependencies explicitly. The service registry from Part 2 must include not just primary data stores but derived stores, replicas, caches, and known export destinations. Each downstream system must either receive a deletion signal and execute it, or the system must document the downstream copy as a known limitation with a remediation plan.
For derived and aggregated data, the question is more nuanced. If a person's data was aggregated into a statistical summary — average transaction value across 10,000 customers — deleting one person's data does not require recomputing the aggregate. The aggregate does not contain personal data. But if the aggregation is small enough that the individual could be re-identified from the aggregate, it may. The deletion system must evaluate the re-identification risk of derived data, which in practice means applying a threshold: aggregations below a minimum group size must be recomputed after deletion.
Backup purging
Backups are the most operationally difficult deletion target. Production databases can be queried and rows can be deleted. Backups are immutable snapshots. You cannot delete a single person's data from a database backup without restoring the entire backup, deleting the data, and re-creating the backup — a process that is impractical for daily backups retained over months or years.
Three approaches exist, each with trade-offs.
Crypto-shredding. The person's data is encrypted with a per-user key. When a deletion request is fulfilled, the key is destroyed. The data still exists in the backup, but it is unreadable. This is the most elegant solution but it requires encryption at the field or record level with per-user key management — an architectural decision that must be made before the first record is written, not after a deletion request arrives.
Backup expiry. The organization accepts that deleted data will persist in backups until the backup retention window expires. If backups are retained for 30 days, deleted data will be fully purged within 30 days. This is the most common approach and is generally accepted by regulators provided the organization can demonstrate that the data is not accessible through normal operations — the production record is hard-deleted, and the backup is not used for routine access. Documentation of the backup retention policy and a commitment that the data will not be restored except in disaster recovery scenarios is typically sufficient.
Selective backup reconstruction. The backup is restored to a staging environment, the target data is deleted, and a new backup is created. This is technically complete but operationally expensive, time-consuming, and error-prone. It is reserved for cases where a regulator explicitly requires immediate purging or where the backup contains highly sensitive data.
In practice, most organizations use backup expiry as the default and crypto-shredding for the most sensitive data categories. Selective reconstruction is used only under regulatory pressure.
Event logs and streaming systems
Event-driven architectures create a specific deletion challenge. Kafka topics, event stores, and streaming pipelines are designed to be append-only. Deleting a specific event from a Kafka topic is not a supported operation in the default configuration.
For Kafka specifically, log compaction can be configured to delete records with a specific key by publishing a tombstone — a null-value record with the same key. This triggers compaction to remove all prior records with that key. But compaction is not immediate; it runs on a schedule, and the timing is not guaranteed. The deletion system must track that a tombstone was published and verify, after the compaction cycle, that the original records are no longer present.
For event stores that do not support deletion, the same approaches that apply to backups apply here: crypto-shredding (encrypt events with per-user keys), retention-based expiry (configure topic retention to a bounded window), or reconstruction (replay the topic minus the deleted user's events into a new topic).
The broader principle is that any system designed for immutability — event logs, blockchain-based ledgers, append-only audit trails — is architecturally opposed to deletion. The DSR system must identify these systems during the scoping phase and have a documented approach for each. The worst outcome is discovering an immutable system during execution with no deletion strategy.
Deletion verification
Deletion without verification is an assertion, not a fact. The system must confirm that deletion occurred, not just that deletion was requested.
For each system, after the deletion task reports completion, a verification step should query the system for the deleted identifier. If data is returned, the deletion failed or was incomplete. If no data is returned, the deletion is confirmed. This verification query should be run by the DSR orchestrator, not by the system that performed the deletion — the verifier must be independent of the executor.
Verification must also check derived systems. If the production record was deleted but the warehouse copy was not, verification against the warehouse will catch it. This requires the verification step to run against all systems in the cascade, not just the primary.
For systems where verification is not possible — the support agent's spreadsheet, the third-party SaaS tool with no query API — the system must log the limitation. The audit trail should read: "deletion executed in systems A through G, verified in systems A through F, system G does not support verification, manual confirmation pending."
What comes next
This part covered the mechanics of deletion — the hardest operational problem in a DSR system. Soft and hard deletes, retention conflicts, cascading dependencies, backup strategies, event log handling, and verification.
Part 4 completes the series with audit, compliance reporting, and what happens when the volume of requests scales from dozens to thousands per month.