Deletion scope and timing must be stated

What it is

Deletion service-level disclosure states what a request covers, what remains, the expected duration of each stage, and data status while waiting. “Delete account” alone does not distinguish hiding public material, disabling login, clearing online replicas, backup expiry, and processor action. A clear commitment uses observable milestones so a person knows when cancellation ends, routine use stops, technical work completes, and exceptions remain.

Why it happens

Distributed deletion is asynchronous; stores and processors cannot all finish at one instant. One interface label applied to several backend states creates a false mapping between user time and system time. People may believe data vanished immediately or mistake a cooling-off period for execution failure. Disclosed scope and transitions calibrate expectations and turn delay, exception, and failure into accountable states rather than retrospective explanations.

Studying it

Participants can read disclosures of varying granularity, draw expected data-state timelines, and have those predictions compared with actual system states. Outcomes include scope recognition, completion-time error, understanding of reversibility, correct action after failure, and calibrated trust. Production audits should compare promised percentiles with the full latency distribution rather than averages; a small long-stuck tail is precisely the risk a service statement should reveal.

Where it stops holding

Timing depends on system design and applicable obligations, so one jurisdiction's deadline is not a universal product value. Investigation holds, dispute preservation, and backup rotation may create different stages, but “may be retained” cannot be an indefinite blank clause. Infrastructure detail can create security risk; disclosure should name user-verifiable data classes and states rather than server topology.

Applying it

• On confirmation, enumerate profile data, public content, messages, transaction records, derived profiles, backups, and external recipients.
• State milestones for receipt, end of routine use, online completion, and backup expiry, including when the request is reversible.
• For retained classes, identify the class, basis, permitted use, and expected end condition rather than saying only “as required by law.”
• Maintain stage-latency distributions and an overdue queue from real requests; set interface promises against the observed tail and proactively expose status and remedy after timeout.

Related

• Same group: O1.07.1 Deletion must cover backups and derived data · O1.07.3 Disappearance from the interface is not backend deletion · O1.07.4 Erasure is an assertable legal right, not an optional feature · 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: O2.04 Privacy dashboard · O2.02 Explaining data use
• Search terms: deletion timeline · erasure scope · deletion SLA