The Deletion Request That Touched the Wrong Tables
Under a data subject request, a customer asks a travel company to delete all their personal data. The instance stores the person in nms:recipient, their bookings in a custom cus:booking schema (with a foreign key to recipient), their email interaction history in nms:trackingLog and nms:deliveryLog, and a marketing consent record in cus:consent. The practitioner runs a delete on the recipient record. The delete succeeds, but afterwards the cus:booking rows remain (the FK was not configured with cascade delete), the tracking and delivery logs remain, and a nightly workflow re-imports the customer from an upstream system because the deletion wasn't propagated there. The customer's email address still appears in a previously sent delivery's log. The DPO asks why the deletion was incomplete and whether the logs must be purged.
1. Explain why deleting the recipient record did not achieve deletion of the customer's personal data, referencing schema relationships and log tables.
Read the worked answer
Deleting the nms:recipient row removes only that table's row. Personal data is spread across several stores with different lifecycles:
cus:booking: the foreign key to recipient was not set to cascade delete, so booking rows (which contain the person's name, contact, and travel details) survive as orphans. Orphaned rows are still personal data and are arguably worse because they're now unlinked and hard to find.nms:trackingLog/nms:deliveryLog: these record opens, clicks, and sends tied to the recipient. They are typically retained for reporting and are often not deleted by a recipient delete. The email address in the delivery log is personal data.- Upstream re-import: deletion is only effective if it propagates to every system of record. The nightly import recreated the recipient because the upstream CRM still holds them - so the deletion is undone within 24 hours.
cus:consent: consent history may need to be retained to demonstrate compliance, but it must be handled deliberately, not left by accident.
So the delete was incomplete at the data-model level (no cascade), at the log level (logs retained), and at the system level (no upstream propagation).
2. Design a complete deletion procedure and state what must be retained versus purged, with justification.
Read the worked answer
Procedure (orchestrated, not a single delete):
- Suppress upstream first so the nightly import cannot resurrect the record. Mark the customer as deleted/opted-out in the CRM and confirm the import respects that flag (or exclude them from the import query).
- Handle dependent schemas explicitly. Either configure cascade delete on
cus:booking.recipientId(and other dependent FKs) or run an ordered deletion: bookings → consent (per policy) → recipient. Audit every custom schema with an FK to recipient to find all dependents. - Purge or anonymize logs. Tracking and delivery logs tied to the recipient should be purged or the identifying fields (email) anonymized, subject to any legal retention obligation. If logs must be kept for aggregate reporting, anonymize rather than delete so aggregates survive without personal data.
- Consent record. Retain a minimal record that consent was withdrawn/deletion was honored, if needed to demonstrate compliance - but strip other personal data.
- Verify and document. After the run, query each table for the customer's identifiers to confirm zero rows remain (or only the permitted retention record). Log the deletion with date, scope, and operator for the DPO.
Justification: 'delete' in a relational, multi-system environment means deleting or anonymizing every copy, blocking re-creation, and keeping only what a legal basis requires - with evidence. A single recipient delete satisfies none of those on its own.