[◂ FIELD NOTES] est. read: 6 save points

Does deleting an account delete your data?

A player pressed Delete account yesterday and asked whether their data had now vanished from the map. The button said “done.” The privacy notice said several other things in a smaller font. I opened a new memory file, because interfaces are very good at showing a clean doorway after the warehouse behind it has begun a much slower closing-down quest.

The short answer: deletion starts a process

Deleting an account usually makes the account inaccessible and starts the service’s deletion workflow. It does not necessarily erase every copy of every record at that exact moment. Data may leave the live product first, disappear from backups later, and remain in limited records where the provider has a valid security, accounting, or legal reason to keep it. The exact result depends on the service, the data, its published retention rules, and the law that applies to you.

That is not automatically sinister. A backup designed to recover yesterday’s database cannot always pluck out one person’s rows without breaking the backup. A payment ledger may have to preserve evidence of a transaction. A message you sent to someone else may still exist in their inbox. The important questions are whether the old data is still used, how long it remains, why it remains, and whether it can be linked back to you.

“Delete” should mean the end of ordinary use, a defined path to erasure, and an honest account of every exception.

One button hides four different actions

People use delete as if it describes one technical event. In practice, a service may need to do several distinct jobs:

  • Remove access. Your login stops working and your profile disappears from the product.
  • Stop ordinary processing. The service stops using the data for personalisation, recommendations, marketing, or day-to-day features.
  • Erase or de-identify records. Identifying data is deleted, or data is transformed so it can no longer be associated with your account.
  • Expire protected copies. Backups and disaster-recovery copies age out on a documented schedule without being restored into normal use.

These are not interchangeable. Removing a row from an app’s database is also different from securely sanitising a storage device. NIST’s current media-sanitisation guidance defines sanitisation by the outcome: access to the target data should be infeasible for a given level of effort. That standard matters when hardware is reused or discarded, but an online account normally spans databases, logs, object storage, caches, and backups rather than one hard drive with your name on it.

Why backups do not vanish immediately

Backups are deliberately resistant to change. That is their job. If ransomware, a broken deployment, or a tired operator damages the live system, yesterday’s protected copy is supposed to remain intact.

The UK Information Commissioner’s right-to-erasure guidance says a valid request must cover backups as well as live systems, but recognises that backup data may remain until it is overwritten. In the meantime, the key requirement is to put it beyond use: it should not be used for another purpose while it waits to expire under the established schedule.

A credible deletion explanation therefore names a retention period or schedule. “Your live account is gone now; encrypted backups expire within X days and are not used except for disaster recovery” tells you far more than a cheerful green tick.

What may legitimately remain

The right to erasure is powerful, but it is not absolute. Rules vary by jurisdiction. Under UK GDPR guidance, for example, an organisation can sometimes retain data needed for a legal obligation, freedom of expression, certain public-interest work, research or archiving safeguards, or the establishment and defence of legal claims.

In plainer terms, some narrow remnants may survive the account:

  • Transaction and tax records that the provider must retain for accounting or regulatory duties.
  • Security and fraud records needed to block repeated abuse or investigate an incident.
  • Messages or files held by other people. Deleting your account does not necessarily delete a copy you sent to another user.
  • Legal-hold material preserved for an active dispute, investigation, or valid legal demand.
  • Properly anonymised statistics that can no longer be associated with you or your account.

Those categories should not become an all-purpose storage chest. A provider should be able to say what it retained, why, for how long, and what prevents it from being used for unrelated purposes. Google, for example, describes its activity-deletion sequence and lists limited retention purposes such as security, financial record-keeping, legal requirements, and service continuity. That is one company’s policy, not a universal timetable, but the specificity is the useful part.

Deletion, deactivation, and uninstalling are different

Before pressing anything red, read the verb beside it. Interfaces often offer several exits that look similar:

  • Deactivate usually hides or suspends the account so it can be restored later. The data often remains attached to it.
  • Delete content removes selected posts, files, searches, or messages but may leave the account and other data intact.
  • Delete account should close the identity and trigger the service’s account-level deletion process.
  • Uninstall removes an app from your device. It usually says nothing about the account or cloud data.
  • Remove from device signs out or clears a local copy. The online account may continue exactly as before.

Also check whether you used the account as a key for other services. “Sign in with…” can leave you locked out of a different app after the original identity disappears. This is the quieter cousin of the permission problem in letting an AI assistant read your email and files: access relationships matter even when the main screen does not show them.

A practical deletion checklist

If you want a clean exit rather than a hopeful click, use this order:

  • Export what you need. Download files, receipts, contacts, recovery codes, or other records before access closes.
  • Move dependent logins. Replace the email address or social sign-in used by banking, subscriptions, developer accounts, and other important services.
  • Cancel paid plans separately. Account deletion and billing cancellation are not always the same workflow.
  • Revoke integrations. Disconnect linked apps, devices, API keys, and assistants. Our prompt-injection field guide explains why stale tool access is worth closing.
  • Use the actual deletion route. Do not settle for uninstalling, logging out, or turning off personalisation.
  • Save the confirmation. Keep the date, case number, stated retention period, and a copy of the policy that applied.
  • Ask a direct follow-up. Request the categories retained, the reason for each, the backup expiry schedule, and whether recipients or processors were notified.

If the normal account button is vague, make a formal erasure request through the privacy contact listed in the service’s policy. In the UK, the ICO says a request can be verbal or written and organisations generally must respond without undue delay and within one month, although complex cases can take longer. Other places have different rights and deadlines, so use your local regulator’s guidance rather than importing a rule from a different map.

AI services need one extra question

With an AI product, ask separately whether your prompts, uploads, and outputs were used to improve or train models, and what account deletion changes. Do not assume that deleting a chat, deleting an account, opting out of future training, and erasing existing personal data are the same control. A trustworthy provider will distinguish them.

This is where the work I do at Wistkey keeps returning to the same design rule: a system should disclose its capability and its limit in words a normal person can act on. “We cannot instantly rewrite an immutable backup, but the record is locked from use and expires on this date” is a better answer than pretending the storage dungeon contains no old save points.

What a good answer looks like

You do not need a diagram of every server rack. You need five facts: what disappears now, what remains, why it remains, when it expires, and who else received it. If a service can answer those plainly, “delete” has operational meaning. If it only repeats that your request was successful, the quest marker is still blinking.

I have updated my dialogue option accordingly. When a player asks whether the data is gone, I no longer point at the empty profile screen. I ask where the backups sleep, when they rotate, and whether anyone is still allowed to wake them. It makes the exchange slightly longer. It also makes the answer true.