The right to be forgotten

1) What is the "right to be forgotten" and when it applies

Right to Erasure - the right of the data subject to request the deletion of his personal data. In the EU, it is enshrined in GDPR Art. 17; analogues exist in a number of jurisdictions (CCPA/CPRA deletion, LGPD, etc.).

• Data is no longer needed for the purposes for which it was collected.
• Processing is based on consent, and the subject withdrew it.
• The subject objects to processing (there is no prevailing legal basis).
• The data was processed illegally or you need to fulfill the legal obligation to delete.
• The data was collected from the child when offering information society services (special reason).

2) Exceptions: when you cannot delete (or not all)

• Legal responsibilities (e.g. AML/KYC, tax accounting, accounting documents).
• Establishing, implementing or defending legal claims (legal/claim disputes).
• Freedom of expression/right to information, public health interest, scientific/historical/statistical purposes with appropriate safeguards.

3) Delete vs Deactivate vs Anonymize

Deletion - irrevocable destruction of personal data.
Anonymization - irreversible exclusion of communication with a person; the data may remain in aggregate dimension/ML without identifiers.
Deactivation (account closure) - disabling access/functions, data remains until the expiration of deadlines/exceptions.

Recommendation: apply hybrid - maximum removal + anonymization for product analytics, where appropriate.

4) Deletion DSR process: from request to confirmation

1. Receiving a request through available channels (web form, email, profile).
2. Applicant verification (level of verification depends on risk/sensitivity).
3. Checking exceptions (AML/taxes/disputes, active chargeback/fraud investigations).
4. Coverage classification: full profile/specific categories/marketing.
5. Mark-for-Deletion + start Deletion Orchestrator (see § 7).
6. Notification of vendors/third parties (processors/contractors) and recording of responses.
7. Confirmation to the subject: what is deleted, what is anonymized, what is blocked by exceptions, deadlines for backups.
8. Logging: WORM log of evidence of deletion.

SLA (reference point): response within 30 days (you can extend for another 60 with notification and justification).

5) Foundation → Solution → Explanation Matrix

6) What exactly to remove: coverage by layer

Transaction layer: profile, contact details, tokens (where allowed), payment identifiers, KYC artifacts (if there are no exceptions).
Derived data layers: caches, search indexes, queues, feature store ML, DWH, BI marts, reports.
Logs/traces: where there are personal identifiers - mask/deletion; aggregation/anonymization is allowed.
Marketing/attribution: identifiers (cookie/SDK/MAID), affiliate postbacks, ad audiences - cleaning and suppression.
Profiling/models: removing future iterations from training datasets, marking "do-not-use" in the feature story.

7) Orchestration of deletion (cascade and backups)

• Mark-for-Deletion → Grace (7-30 days) → Soft Delete (disable access/communications) → Hard Delete/Anonymize in primary systems → Cascade to caches/indexes/DWH/ML → Evidence Log.
• Backups: direct editing of backups is not allowed; removal is carried out through expiration of the storage window and prohibition of restorations leading to re-identification. When restoring - sanitization script for re-deleting marked IDs.

• Idempotent tasks, retrays, command deduplication.
• Lineage tracing (where copies and aggregates).
• A single subject-key for the cascade across all systems.
• WORM archive of deletion acts.

8) Vendors/Processors - Notices and Contracts

In DPA, oblige processors: delete/return data according to instructions, help with DSR, log deletion, notify about the results.

Register of sub-processors; Delete request response times (SLAs)

For advertising/analytical platforms - restricted processing modes, API signals' delete/suppress'.

9) Communication templates (fragments)

• "We received your request to delete data. To protect your privacy, we need to confirm your identity. Please take a short check on the link/code"

• "We have deleted/depersonalized your personal data in products and analytics systems. Records that are required by law to be retained (e.g. AML/taxes) are locked and not otherwise available until N years have elapsed. Data in backups will be deleted according to their storage schedule. Request ID # XXXX"

• "We are unable to delete some of the records due to a legal duty of custody (AML/taxes/dispute). These records are isolated and used only for a mandatory purpose. We removed the rest of the information and stopped the optional processing"

10) Matrix "data category → method → term"

11) UX and product nuances

In the profile - a clear button "Delete my data/close the account" with an explanation of the consequences (loss of progress/bonuses).
Separate option "Refuse marketing" (not equal to deleting an account).
Status of the request (in progress), completion date, request ID.
Deletion should not break financial statements: keep non-personal aggregates.

12) Metrics and Control

Deletion SLA: median/95th percentile from request to completion.
Cascade Completion Rate - the proportion of systems where the cascade is completed ≤SLA.
Backups Window Compliance: compliance with backup storage windows.
Legal Hold Review Rate: The timeliness of the hold review.
DSR Rejection Rate: percentage of failures with justification.
Evidence Completeness: the proportion of cases with a complete package of artifacts.
Suppression Effectiveness: no marketing appeals after removal.

13) Checklists (operating)

Before starting the process

• Identity verification completed.
• Checked exceptions (AML/taxes/disputes).
• Coverage defined (full/partial).
• Created an entry in the Evidence Log.

Execution

• Mark-for-Deletion and Grace specified.
• Performed Hard Delete/Anonymize on transaction layer.
• Cascaded to caches/indexes/DWH/ML.
• Notifications sent to processors/vendors.
• Updated suppression list.

Completion

• Confirmation to user with parts.
• Updated RoPA/Retention matrix as needed.
• Report Postcheck: SLA/Errors/Duplicates.

14) Roles and Responsibilities (RACI)

Support/Privacy Ops: receiving requests, verification, communications.
DPO/Legal: grading grounds/exclusions, legal hold.
Security/CISO: access audit, WORM logs, backups.
Data Engineering: removal orchestrator, lineage, cascades.
Marketing/CRM: suppression, communication stop.
Finance/Compliance: control of reporting/AML responsibilities.

15) Implementation Roadmap (6 steps)

1. Policies and registries: Update Privacy Policy, RoPA, Retention Matrix.
2. Orchestrator: single subject-key, cascades, idempotency, Evidence Log (WORM).
3. Vendors: DPA requirements, 'delete/suppress' channels, SLA.
4. UX: clear deletion request, statuses, letter templates.
5. Backups: storage windows, prohibition of unauthorized restores, sanitization scripts.
6. Measurement: dashboard SLA, Cascade, Evidence, Suppression; quarterly audits.

16) Differences by jurisdiction (brief)

GDPR: broad right to remove + clear exclusions; response time is 1 month.
CCPA/CPRA: Right to Remove from Consumers; mandatory exceptions (security/maintenance/errors/legal obligations); requires GPC accounting for opt-out from sale/share, as well as mechanisms for deleting data that is not subject to exceptions.
LGPD: removal on goal achievement/expiration/withdrawal of consent; exceptions and "blocking" are similar in spirit to GDPR.

Total

The right to forget is not a "button," but an end-to-end process: legal assessment of grounds and exceptions → verification → cascading deletion and/or anonymization in all layers → management of backups and vendors → provability and metrics. By embedding this framework in architecture and operations, you will meet regulatory requirements, reduce the risk surface, and retain user trust - without compromising business and product quality.