A right-to-erasure request lands in the support inbox. The sender wants every trace of themselves removed from your systems. The legal team forwards it to engineering. The engineer looks at the database and notices that the email address shows up in twelve places — submissions, autoresponder logs, webhook delivery records, derived analytics, the marketing CRM that the form integration pushes to. Where does the erasure obligation begin and end? What happens if the data is also in a nightly backup? What if the request is ambiguous about which products it covers?

This is the practical workflow for handling Article 17 erasure requests when the affected data is form submissions. Verification, scope, deletion, backup handling, and the exceptions worth knowing — written for the engineer who has to actually run the process, not the lawyer who writes the policy.

What does the right to erasure actually require?

GDPR Article 17 gives data subjects the right to obtain "erasure of personal data concerning them" when one of several conditions applies — the data is no longer necessary, consent was withdrawn, the data was unlawfully processed, or the subject objects and there is no overriding legitimate ground.

The wording is broader than "delete this row from your database". The obligation extends to every place the personal data exists in your processing — primary database, derived aggregates, logs, backups within reason, and the records held by your processors. If you exported the submission to a CRM under a processor agreement, the erasure obligation flows through to that CRM. The data subject does not need to file separate requests with each of your sub-processors.

The other piece worth being precise about: erasure means erasure, not anonymisation. Replacing the email address with a hash, or stripping the name from the row while keeping the rest, is not erasure if the result is still linkable to the individual. The bar to clear is that the resulting record can no longer reasonably identify the person. In practice, for form submissions, this means the row is either deleted outright or all identifying fields are nulled while the row is kept for aggregate counting purposes.

The 30-day clock starts the moment you receive a verifiable request. You can extend by two months if the request is complex, but you must notify the requester of the extension within the first 30 days, with the reasons. Silent delay is not an option.

How do you verify the requester is who they claim to be?

Article 12(6) explicitly permits — and often requires — the controller to confirm identity before acting on a request. Skipping verification is bilateral risk: erasing data for an impersonator is unauthorised destruction; refusing a legitimate request is an Article 17 violation.

The pattern that holds up:

  • Email-driven requests: send a confirmation to the address on the original submission with a one-time link. Require confirmation from that mailbox.
  • Web-form requests: require information only the real subject would know — recent submission ID, the email used, the submission date.
  • High-stakes data (financial, medical): additional verification is appropriate. Government ID is permissible under 12(6) but must be deleted once identity is confirmed.
  • Do not require disproportionate verification. Asking for a passport scan to delete a newsletter signup is itself a violation.

In our experience, fraudulent erasure attempts are rare but non-zero — disgruntled ex-employees, competitive intelligence, harassment. The verification step is what prevents them. Document what you did; the log is part of the erasure record.

What counts as "the scope" of an erasure request?

The default: the request covers every piece of personal data the controller holds about the requester, across every form, every product, every integration. The data subject is not expected to enumerate the rows.

For a form environment, that breaks down to:

  • Submissions table: every row tied to the requester's identifiers.
  • File uploads: attached files in object storage need to be deleted, not just the database reference.
  • Autoresponder and notification logs: log rows are themselves personal data. Erase or anonymise.
  • Webhook delivery logs: payloads contain the full submission. Erase the payload, not just metadata.
  • Derived analytics: aggregate counts are fine; per-row analytics with identifying fields are not.
  • Backups: see the next section.
  • Processor-held copies: every CRM, email service, webhook destination. Cascading is the controller's responsibility.

The trap: declaring erasure complete after only deleting the primary row. The peripheral logs are often where the bulk of the personal data lives.

How do you handle backups?

The simple answer ("delete from backups too") is operationally impossible; the realistic one ("delete from primary, leave backups alone") looks like non-compliance. The position that has emerged from EDPB guidance:

  • The controller is not required to mutate backups. Doing so would itself create operational risk.
  • The controller IS required to ensure that if a backup is restored, the erased data does not reappear. The standard pattern is a deletion log that the restore process consults to re-apply pending erasures.
  • Backups must be deleted on a defined retention schedule. Backups beyond their retention are themselves a violation.

The honest answer to the requester: "Your data has been removed from active systems. It may persist in disaster-recovery backups for up to N days, after which the backup is purged. If we restore before that, your erasure will be re-applied automatically." Defensible, and in our experience accepted by both supervisory authorities and most data subjects.

Which Article 17 exceptions are worth knowing?

Article 17(3) lists exceptions. The two that come up most in a form context:

Legal claims (17(3)(e)). Data needed for establishment, exercise, or defence of legal claims may be retained. The exception is narrow — it does not cover "we might need this someday". The dispute has to be identifiable.

Freedom of expression (17(3)(a)). If the submission is itself expressive content (a public comment, a review), erasure may not apply. Rare for contact forms; relevant for public feedback.

The exception engineers most often want and that does not exist: "we need it for our own records". Internal record-keeping is not a basis. If you invoke an exception, document the legal basis in the response. "Retained under 17(3)(e) for legal matter XYZ" is defensible; "we need it" is not.

What does the workflow shape look like end to end?

The repeatable pattern for handling an erasure request:

  1. Intake. Log the request with timestamp, requester identifier, channel (email, web form, dashboard). Start the 30-day clock.
  2. Verify. Confirm identity through a proportionate mechanism. Log the verification method and outcome.
  3. Locate. Run a discovery query across every system that might hold the requester's data. Email match, phone match, name plus secondary identifier match. Produce a list of records.
  4. Scope decision. For each located record, decide: erase, retain under exception, or out of scope. Document the reasoning.
  5. Cascade to processors. Notify every processor (CRMs, email services, integration destinations) that received the data. Track their confirmation of erasure.
  6. Erase. Delete or anonymise according to the scope decision. Run the deletions in a transaction where possible.
  7. Confirm to requester. Reply within the 30-day window. List what was erased, what was retained and why, and the timeline for backup expiry if applicable.
  8. Log the completion. Maintain an erasure log with the request, verification, scope decision, processor confirmations, and completion timestamp.

The whole workflow takes a few hours of human work for a typical request, longer if multiple processors are involved. The most time-consuming step is almost always the processor cascade — every downstream CRM and email tool needs to be contacted and tracked.

For form environments with many submissions per requester, a queued deletion job that fans out across systems is the operational shape that scales. Every delete goes through the same job class, the same logging, the same verification — there is one path for erasure and it is auditable end to end.

What do you keep as proof of erasure?

You cannot keep the erased data, but you can keep a record that erasure happened. The minimum useful record: the request itself, the verification step taken, a list of record identifiers that were erased (row IDs, object keys, CRM contact IDs — not themselves personal data once the underlying data is gone), processor confirmations, and the completion timestamp.

This log is your defence if a supervisory authority asks what happened. In our experience, a three-to-five-year retention on the log itself is defensible — long enough to handle regulatory action, short enough not to become a privacy concern in its own right.

When the requester says "all my data" — what counts?

The requester probably means every record across every product. But they might mean only the specific form they remember submitting. The safe default is broad: search every system, present a complete list, confirm before deletion if any of the scope is non-obvious. "We located records in: contact form, newsletter signup, support ticket history. We will erase all three unless you tell us otherwise within five business days" protects everyone.

The pattern that fails is silently erasing only the obvious record. EU-hosted form processing makes the cascade simpler because the supervisory authority is the same across all processing, but it does not change the substance of the obligation.

The shape of the function

Right-to-erasure handling is not an exotic compliance function. It is a workflow that fires a handful of times a year for most form environments, more often for higher-traffic ones. Treating it as routine — with a documented procedure, a discovery query that covers every system, a queued deletion job that handles the cascade, an erasure log that proves what happened — turns each request from a fire-drill into a half-hour task.

The controllers that struggle with erasure requests are the ones who treat each one as bespoke. The controllers who handle them cleanly built the process once and now run it on autopilot. In 2026 with EDPB enforcement attention squarely on data-subject rights, the autopilot is the position worth being in.

Related from this desk