An account-deletion request may be a request to close the service account, an exercise of the right to erasure, or both. The right to erasure under UK data-protection law is qualified rather than absolute and applies only in specified circumstances. A SaaS business therefore needs a documented process that identifies the requester, determines which organisation is responsible for the decision, and responds without undue delay and normally within one month when the request is being handled as a right-to-erasure request.

The first distinction is between deactivation, suspension, account closure and erasure. Deactivation or suspension restricts access while leaving the underlying records in place. Closing an account ends the product relationship. Erasure is the data-protection decision about which personal data should be removed, anonymised, retained under a justified exception or placed beyond use until a backup cycle removes it. Treating these outcomes as interchangeable creates both operational and compliance errors.

Erasure does not always mean immediately overwriting every copy in every system. Some information may need to be retained for a documented legal, contractual or claims-related reason, while backup data may need to be placed beyond use until it is removed through an established deletion cycle. These decisions should be made by data category and purpose, not through a blanket rule that either keeps everything or deletes everything.

From a technical standpoint, account deletion touches more than a single database table. A user's personal data may exist in the primary user record, activity logs, audit trails, uploaded documents, cached search indexes, integration payloads sent to third-party services and backup snapshots. A robust deletion process accounts for all of these locations, or at minimum documents which ones it cannot reach and why.

An account-closure request and a valid right-to-erasure request are not automatically the same thing. The system should separate product access, contractual record-keeping and personal-data rights, then document the lawful reason for deleting or retaining each data category.

Verifying the requester

Before acting on a deletion request, you need reasonable confidence that the person making it is the account holder. In a B2B SaaS product, this is usually straightforward because the user is already authenticated. If the request arrives by email or support ticket, you may need an additional verification step, such as replying from the registered email address or confirming details only the account owner would know. The verification method should be proportionate: excessive friction can itself become a complaint, while no verification at all opens the door to malicious requests.

Multi-tenant and organisational accounts

In a multi-tenant SaaS product, deletion becomes more complex when an account belongs to an organisation rather than a single individual. If a team member leaves and requests deletion of their personal data, you need to separate their personal information from the work they produced on behalf of the organisation. Documents, comments, task assignments and workflow records may belong to the business, not the individual. Your data model should ideally separate user identity data from contribution data at the point of design, but many systems require a migration step at the point of deletion to reassign or anonymise contributions.

If the organisation itself requests account deletion, the scope widens. You are now dealing with all users under that tenant, all organisational data, and potentially outstanding subscription commitments. The deletion of an entire tenant should trigger a separate process that addresses billing closure, data export if requested, and confirmation that no sub-accounts will continue to function.

Handling data in backups

One of the most frequently raised practical problems is backup retention. If you take nightly database backups and retain them for 30 days, a deletion request executed today will not remove the user's data from backups taken before the deletion. The Information Commissioner's Office acknowledges this constraint but expects you to have a policy: backups should be overwritten in the normal cycle, and you should not restore a backup to recover deleted personal data unless there is a separate lawful basis for doing so. Documenting this approach is more practical than attempting to surgically edit backup files.

Third-party integrations and logs

Personal data may also have been sent to analytics platforms, email providers, customer relationship management integrations or other service providers. The response process should map those recipients, determine whether the SaaS business is acting as controller or processor for the relevant data, and follow the applicable instructions and contracts. Where another processor holds the data, the deletion workflow should include a documented request, confirmation or API action rather than assuming that deleting the primary account removes every downstream copy.

Confirmation and record-keeping

After deletion, the user should receive confirmation that their request has been completed. You may also need to retain a minimal record that the deletion took place, when, and on what basis, for your own audit purposes. This record should not contain the personal data that was deleted; it should simply evidence that you fulfilled the request. How long you keep that log depends on your own compliance and operational needs, and should be discussed with your data protection adviser.

Making deletion hard to find

Users need a clear and workable channel for closing an account or exercising data-protection rights. Self-service deletion can be appropriate for a straightforward consumer product, while business accounts, shared tenant data or regulated records may require a controlled support process. The important point is that the route is explained, requests are recognised even when they do not use legal terminology, and the organisation does not add unnecessary friction to delay a valid request.

Confusing deletion with cancellation

Cancelling a subscription stops future billing. Deleting an account removes personal data. These are separate actions, and conflating them causes confusion. A user who cancels may reasonably expect their data to persist in case they return. A user who deletes their account expects the data to go. If your system only offers cancellation, you are not meeting the deletion requirement. If it only offers deletion, you may be losing data that users intended to keep. Both options should exist and be clearly labelled.

Forgetting about derived and cached data

Even after the primary database records are removed, personal data can linger in search indexes, materialised views, caching layers, session stores and application logs. A practical check is to walk through every system component that touches user data and confirm whether it holds copies. For each component, decide whether it can be purged immediately, overwritten in the normal cycle, or requires a manual step.

Deleting data you are obliged to retain

Some SaaS products handle regulated activities where records must be kept for defined periods: financial transactions, compliance-critical communications, or health-related data. Deleting these on request without understanding your retention obligations can create a separate problem. The correct approach is to identify those obligations before building the deletion flow, document them, and either exclude that data from the deletion scope with a clear explanation to the user, or retain it under a different lawful basis with appropriate access restrictions.

Key checks before going live

  • Can a logged-in user find the deletion option without assistance?
  • Does the deletion process cover all known locations of personal data, including logs, caches and integrations?
  • Is there a documented policy for data in backups that cannot be immediately purged?
  • Does the system distinguish between individual user deletion and organisational tenant deletion?
  • Are there data categories that must be retained, and is the legal basis for retention recorded?
  • Does the user receive confirmation once deletion is complete?
  • Have you reviewed your data-sharing agreements with third-party processors to confirm they support deletion?
  • Has the process been reviewed by a current data protection specialist against the UK GDPR and the Data Protection Act 2018?

Account deletion is a feature that reveals the quality of your data architecture. Systems designed with clear separation between identity data, activity data and business data handle deletion cleanly. Systems where personal information is scattered across loosely coupled services face a more involved process. Building the deletion flow early, rather than retrofitting it after a compliance query, avoids both technical debt and regulatory risk.