O1.07.4Right to erasuredesignresearch

Erasure is an assertable legal right, not an optional feature

Aliases: right to be forgotten · deletion right · data subject request

What it is

The right to erasure, also called the right to be forgotten, is an enforceable request right under applicable data-protection law rather than an optional account-cleanup feature. Under the EU GDPR, for example, erasure duties can arise when data are no longer necessary, consent is withdrawn without another legal ground, a qualifying objection succeeds, or processing was unlawful. The right has grounds and exceptions; it is not an unconditional promise that every record must disappear on demand.

Why it happens

A product preference leaves provision to the firm, whereas a legal right changes decision authority and accountability. An organization must receive, identify, assess, execute, and answer a request even if a settings button is absent. Handling spans identity verification, legal-basis assessment, data discovery, and technical deletion; a missing stage makes the visible feature superficial. Assertability also requires a reasoned refusal and information that supports challenge or regulatory remedy.

Studying it

Mystery-shopper audits can submit requests through multiple account states and channels, measuring discoverability, verification burden, status communication, specificity of reasons, and eventual data outcomes. Institutional studies can map interfaces and workflows to applicable provisions and interview requesters at comprehension and abandonment points. Completion rate alone is inadequate: excessive verification filters valid requests, while automatic approval can create account-security risk.

Where it stops holding

The “right to be forgotten” is not globally uniform; this account uses GDPR erasure as its main legal and design anchor. Scope, grounds, time, and remedies differ elsewhere. Search-result delisting, source deletion, and account closure are distinct operations. Teams must establish jurisdiction and organizational role rather than exporting one regional workflow globally or using product terms to narrow statutory request channels.

Applying it

  • Model erasure as a rights request with a discoverable route that does not require prior account closure or guessing a support category, while retaining alternative submission channels.
  • Use risk-proportionate identity verification, avoid collecting more sensitive evidence than the account originally required, and support people who cannot sign in.
  • Track intake, assessment, execution, refusal grounds, and escalation as states jointly owned by legal and engineering teams.
  • Exercise the full path with test accounts, checking that every refusal maps to a concrete basis and every approval invokes the complete deletion workflow; review by applicable jurisdiction periodically.

Related

  • Same group: O1.07.1 Deletion must cover backups and derived data · O1.07.2 Deletion scope and timing must be stated · O1.07.3 Disappearance from the interface is not backend deletion · O1.07.5 Deletion requests must propagate to downstream recipients · O1.07.6 Public-interest and retention exceptions can justify refusal · O1.07.7 Completion needs verifiable evidence, not a verbal promise
  • Adjacent: O1.10 Consent granularity and withdrawal · O2.04 Privacy dashboard
  • Search terms: right to erasure · right to be forgotten · data subject request

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O1.07.4