MAP · CONTROL · RECONCILE
Privacy engineering failure: deleted data returns
Follow actual fictional records through primary storage, a backup, an export and a restore.
Scroll the diagram horizontally to inspect every label. The panels below give the same state as text.
Your experiment
The opening restore brings deleted records back. Enable tombstones and repeat. This tests a concrete technical failure; passing it does not certify compliance with any jurisdiction.
Play takes one minute at 1×. Pause, step or scrub the computed history. Input changes reset the experiment without autoplay. Red cards identify a previously deleted record that returned from backup.
Export snapshot
An export already copied to another destination is not automatically revoked by erasing the source.
Decision trace
Complete record and tombstone inventory
Technical teaching fixture, not legal advice, a GDPR/DPDP compliance assessment or an operational data-deletion service. All records and identities are fictional. The modeled policies are explicit choices, not statutory deadlines or legal bases. Verification and consent are switches, not identity checks or valid consent collection. Retention runs at days 9 and 20. Requested deletions schedule one backup purge; retention-expired backup copies remain visible and require a separate real-world policy. Tombstones block restoration; they are not anonymization. Holds are a fixture exception, not a legal determination. Real systems also need authorization roles, downstream deletion, backup lifecycle, notices, audit protection and jurisdiction-specific review. No personal information or external service is accessed. Official AICassindra learning resources.
An erasure request has to reach every copy
GDPR Article 17 gives a data subject a right to erasure without undue delay, and the Indian Digital Personal Data Protection Act, 2023 gives a Data Principal an erasure right (section 12) and limits retention to the purpose (section 8(7)); both allow retention that law requires. For engineering this means a primary delete is not erasure if a backup can put the record back. Here subject s1 of tenant alpha asks for an export on day 2 and deletion on day 3. a1, a2 and a4 are exported and removed from primary storage, and the backup purge is scheduled fourteen days later, day 17.
Watch the restore win the race
The day 10 restore brings back three records and the day 11 check reports Failure case: 3 deleted records are back in primary storage. The day 17 purge then removes them from the backup, but they are already live, so the run ends at Primary 7 · backup 3 · export 3 · tombstones 3. Set Backup purge after deletion (days) to seven: the purge lands on day 10, ahead of the restore, and nothing returns. At eight it lands on day 11 and all three come back. Block restoration of deleted IDs instead stops the return at any delay by recording three deleted records blocked.
Exceptions and retention windows
Clear Block restoration of deleted IDs and enable Hold billing records against deletion. a4, the billing record, stays in primary storage as one held record and only a1 and a2 return: a crude model of a legal-obligation exception, not a legal determination. Restore the hold to off and set Retention window (modeled days) to thirty. The day 9 sweep removes b2, the day 10 restore returns four records including b2, and the day 20 sweep removes a2, a4 and b2 again while a1 stays revived. The backup purge covers only requested deletions, so retention-expired data needs its own backup rule.
Who may ask, and what was copied
Requested tenant and Actor tenant must match and Identity verified by the fixture must be on; otherwise export, deletion and the late write are denied and nothing changes. Requested subject s2 reaches only a3. Request scope Whole tenant / offboarding erases a1 to a4 and denies the day 12 late write. Personalization purpose consent changes only the day 1 purpose check; withdrawal does not trigger erasure here. Minimize export fields drops tenant, subject and age from exported copies, and the export snapshot keeps a1, a2 and a4 after deletion: copies already delivered need their own erasure, and GDPR Article 19 expects recipients to be told.
Inspection and limits
Ten modeled days replay over sixty seconds, six seconds per event, so the restore appears at thirty seconds and the failure check at thirty-six. Play, Pause, Next event, Restart, Speed and Inspection step through the record inventory and decision trace; edits recompute and rewind. Records are fictional. There is no crypto-shredding, notice, deadline or downstream deletion. This is not legal advice or a compliance assessment.