Right to Erasure: Real Cascading Deletion
The right to erasure requires real deletion, not a deleted=true flag.
Framework / standard: GDPR Art. 17 · Art. 12(3)
The right to erasure requires real deletion, not setting deleted = true. Unlike most governance, which is an auditable record, Linedat actually executes here.
An erasure request goes through a cooling-off window and, once expired, a process performs the cascading deletion.
Execution, not a flag
Once the cooling-off window expires, the process anonymises the subject's User row (email, name, identifiers), unlinks their AI usage logs and syncs the deletion with the authentication provider, leaving a record of each step.
With a receipt
The outcome documents every action taken, so you can demonstrate compliance with Art. 17 — not just declare it.
The limits (what we do not claim)
The deletion operates on the subject's platform account (anonymisation of the User row + unlinking of their AI logs + removal from the authentication provider), not on the data subject's PII spread across catalogue assets. The cooling-off window is fixed (not configurable today) and the cascade is not idempotent: a failure stops the process and requires a manual retry. Synchronisation with the authentication provider is out-of-band. It is real execution with manual retry, not a self-healing pipeline.
How Linedat helps
Linedat makes the right to erasure an execution with a receipt, not a checkbox — real account deletion, documented step by step.
Related capabilities
Citizen rights are not managed by email: with the Art. 12 clock and data location via the RoPA.
RoPA: Record of Processing ActivitiesA RoPA that points to the real tables — not a disconnected spreadsheet.
Audit Chain: Verifiable Cryptographic IntegrityOther catalogues store logs. Linedat stores proof — verify it with a button.