GDPR Delete Request for a Small SaaS: A Runbook

A GDPR delete request is a rights workflow, not a command to remove one account row. First determine your role and the law that applies. Then verify the requester proportionately, assess whether a ground for erasure applies, check exceptions, act across the relevant systems and processors, and document the response.

Under EU GDPR Article 17, the right to erasure applies in specified circumstances and has exceptions. Under Article 12, the controller generally responds without undue delay and within one month of receiving the request. A two-month extension may be available because of complexity or the number of requests, provided the person is told within the first month and given reasons. The European Commission’s guide to individual requests summarizes those obligations.

This is an operational template, not legal advice. Coverage, deadlines, exemptions, and required communications depend on the jurisdiction and facts. Ask privacy counsel to approve the decision rules before a contested or high-risk request arrives.

How do you handle a GDPR deletion request?

Use this sequence:

1. Log the request and preserve the original message.
2. Identify the controller, processor, or joint-controller role for the requested data.
3. Verify identity only to the degree reasonably needed.
4. Map the request to accounts, identifiers, systems, recipients, and processors.
5. Assess Article 17 grounds, exceptions, and any restriction or legal-hold requirement.
6. Preview and approve the technical action.
7. Delete, effectively anonymize, restrict, or retain each category according to the approved decision.
8. Verify live systems, processor actions, and restore controls.
9. Respond to the person and retain proportionate evidence of the handling decision.

The requester does not need to cite an article number or use a special form. Train whoever monitors support, privacy, and account channels to route a request promptly. Do not ask for more identity data by default. The Commission says additional information may be requested when needed to confirm identity; the check should be proportionate to the risk of giving an attacker control over someone else’s data.

The safe unit of work is the request record, data map, legal decision, execution evidence, and response. One database delete is only a possible step inside it.

Controller or processor: who makes the decision?

The controller determines the purposes and means of processing and is responsible for handling the person’s rights request. A processor handles personal data on the controller’s behalf and must assist the controller under the applicable contract and GDPR rules. The EDPB’s small-business rights guide states that the controller must respond and the processor must assist.

If your SaaS receives a request about data it processes for a business customer, do not independently erase that customer’s end-user records without checking your role, contract, and documented instructions. Authenticate and route the request to the controller using the agreed process, preserve the deadline signal, and provide the tools or evidence your contract requires. Your SaaS may still be a controller for separate data, such as its own billing contacts or direct marketing records, so one email can create more than one workstream.

Map every place the person’s data may live

Search by all verified identifiers, including account ID, workspace membership, email aliases, external auth ID, billing-customer ID, and storage prefixes. Avoid broad searches with an unverified identifier that could expose another person’s records.

1. 01 Primary account, authentication, profile, and membership records
2. 02 Related business records such as content, comments, orders, settings, and uploaded files
3. 03 Soft-deleted or archived rows that remain identifiable in the live database
4. 04 Application, security, webhook, and model request logs with identifiers or payloads
5. 05 Analytics, support, email, CRM, and billing systems
6. 06 Processors and subprocessors that received the relevant personal data
7. 07 Generated exports, replicas, warehouses, backups, and restore paths

The inventory should name the system owner and explain how each record links to the person. A data-flow map is stronger than a remembered list of tables because it captures copies made by webhooks, sync jobs, support tools, and failed workflows.

If the app was AI-scaffolded, assume the map is longer than it looks. The same schema habits that leak personal data also scatter it. Across the audits AxonBuild ran in June and July 2026, at least 5 of the 21 third-party apps had confirmed PII or PHI exposure, and the pattern behind the exposure is the same one behind a failed erasure. One app kept a user’s email in a table with no row-level security at all. On a Q&A platform I audited, I didn’t need an exploit to harvest every signed-up user’s email: the profiles table’s RLS policy read SELECT USING (true), so one query with only the public API key returned all of them. Two other apps copied tokens and storage keys into plaintext columns while the schema still claimed “stored encrypted.” A copy existed somewhere the generator never treated as sensitive, because writing that column never felt like a decision. If your app has already made three or four unplanned copies of someone’s email, deleting the row you can see removes one of them and leaves the rest sitting exactly where a second erasure complaint will eventually find them.

Decide what erasure means for each category

Article 17 is not an unconditional instruction to delete every record. A controller must determine whether an erasure ground applies and whether an exception supports continued processing. Examples in Article 17 include legal obligations, public-interest grounds, and establishing, exercising, or defending legal claims. Exact application depends on the facts and applicable law.

For each category, record one approved outcome:

Pseudonymization is not automatically anonymization. Replacing an email with a stable customer ID can leave the person identifiable through another table. Counsel should approve the legal classification, while engineering proves what the transformation actually leaves behind.

Preview the deletion before changing production

A safe erasure worker separates discovery from execution. The discovery stage returns a manifest without modifying data:

{
  "request_id": "dsr_2026_014",
  "subject_key": "verified-internal-id",
  "policy_version": "erasure-v3",
  "actions": [
    { "system": "app-db", "category": "profile",
      "action": "delete", "candidates": 1 },
    { "system": "billing", "category": "invoice",
      "action": "retain-minimized", "candidates": 4 },
    { "system": "analytics", "category": "events",
      "action": "anonymize", "candidates": 218 }
  ]
}

Keep personal payloads and secrets out of the manifest. Require an authorized reviewer to approve the policy version, identifier resolution, candidate counts, exceptions, and processor instructions. Then run bounded, idempotent actions so a retry does not delete more than the approved list.

Most vibe-coded apps ship one delete mechanism, and it’s built for hiding, not erasing: a deleted_at timestamp that the app filters on. That’s a reasonable default for accidental deletes and the wrong tool for an approved erasure action, because it satisfies the UI without touching the data:

-- Hide: the row is still there, and every join that forgot
-- "where deleted_at is null" can still surface it.
update users set deleted_at = now() where id = $1;

-- Erase: the row and its dependents are actually gone.
delete from user_uploads where user_id = $1;
delete from support_tickets where user_id = $1;
delete from users where id = $1;

Foreign keys need explicit review. A cascade may destroy records that must remain, while a restrictive key may leave eligible child records untouched. Exercise the workflow against synthetic fixtures representing shared workspaces, billing records, third-party content, legal holds, and partially failed processor calls. Data-loss failure patterns cover the separate risk of an overbroad delete.

Handle other people’s data and shared records

One user’s content can contain another person’s personal data, and one workspace record can belong to several users. An export, post, payment, or support thread cannot always be deleted as a whole. Decide whether to remove the requester’s fields, detach an identifier, redact a segment, restrict access, or retain a record under an applicable exception.

This step needs legal and product judgment. A blanket cascade can affect other people’s rights or a customer’s records. The technical workflow should expose shared ownership and third-party fields for review rather than hiding them inside one automatic transaction.

What should happen to processors and recipients?

The data map should list every processor and recipient relevant to the request. Send instructions through authenticated channels, track partial failures, and store a receipt or ticket reference. Confirm whether the contract provides an API, dashboard action, support process, or scheduled deletion behavior.

Article 19 can require a controller to communicate erasure to recipients, subject to its own conditions. Article 17 also includes circumstances involving public disclosure and links or copies. Do not reduce these rules to “delete from every vendor.” Counsel should decide which notification duties apply, and the request record should show what was sent, to whom, and when.

How do backups affect a GDPR delete request?

Erase eligible data from live use and document how backup copies expire under the established rotation. The UK ICO’s right-to-erasure guidance says backup data may remain until overwritten when it is put beyond use and is not used for another purpose. That is UK-specific regulator guidance, currently marked for review following UK legislative changes. Confirm the rule for the jurisdictions and systems in your case.

The operational control is straightforward: a restore must not silently reactivate erased data. Maintain a protected erasure ledger containing only what is necessary to reapply valid deletions after a restore, and test that procedure. Do not restore a backup merely to search it during routine handling unless counsel and the approved runbook require that step. The Supabase backup guide explains why provider plan and restoration behavior must be verified rather than assumed.

Routine expiry is the cheaper half of this problem. A data retention policy that actually deletes on a schedule means fewer systems still hold the person’s data by the time an erasure request arrives, which shortens every step above and narrows what a restore can bring back.

A repeatable GDPR erasure runbook

The EDPB advises organizations to document requests, responses, and reasoning. If you refuse to act, EU GDPR transparency rules generally require reasons and information about the right to complain and seek a judicial remedy. If an extension is justified, communicate it inside the initial month rather than waiting for the original deadline to pass.

The same system map supports a user-data export that covers the systems the person actually touched, while the legal and technical actions remain separate.

Common questions about GDPR deletion requests

What is a GDPR deletion request?

It is a person asking a controller to erase personal data held about them, under the Article 17 right to erasure. There is no required form and no article number to quote: a GDPR request to delete data can arrive as a support ticket, a reply to a marketing email, or one sentence in a chat window. The ask makes it a request, not the wording.

Does GDPR require account deletion?

Not as a product feature. GDPR gives a person the right to have personal data erased where an Article 17 ground applies, which is not the same as an obligation to ship a self-service delete button. A reviewed manual workflow meets the right, provided it runs inside the response deadline and reaches every system holding a copy.

Does GDPR require data to be deleted?

Only where an erasure ground applies and no exception covers the data. The EDPB’s small-business guidance lists grounds such as the data no longer being necessary for the purpose it was collected for, alongside exceptions including freedom of expression and information, a legal obligation, and the establishment, exercise or defence of legal claims. Decide category by category and record the reason.

Can I request that data be deleted?

Yes, where EU or UK GDPR covers the processing. Send a GDPR request to delete personal data to the company holding it, through any channel it monitors. The controller then answers within one month in principle, and it may refuse in part where an exception applies, but it has to give reasons and tell you how to complain.

How long do I have to respond to a GDPR delete request?

Under EU GDPR Article 12, a controller generally responds without undue delay and within one month of receipt. A two-month extension may be available because of complexity or number of requests if the person is informed within the first month and given reasons. National rules and current regulator guidance should be checked with counsel.

Can I ask for proof of identity?

If there are reasonable doubts about identity, additional information may be requested to confirm it. Keep the request proportionate. Collecting a passport for an account that can be verified safely through an authenticated session may create unnecessary risk.

Can you refuse a GDPR request for erasure?

Sometimes. The right is not absolute, and Article 17 contains grounds and exceptions. Record the category-level reasoning and provide the required explanation and rights information. Get counsel involved where the basis is disputed or sensitive.

Do I have to delete backup copies immediately?

The answer depends on applicable law and backup architecture. UK ICO guidance allows established overwrite cycles in specified conditions when data is beyond use. Whatever rule applies, remove eligible data from live use, document the backup schedule, and prevent an authorized restore from silently reactivating it.

What if my SaaS is only a processor?

Route the request to the controller and assist under documented instructions and the data-processing contract. Do not assume processor status for every system: your company may be a controller for separate account, billing, security, or marketing data.