Patterns
If you collect personal data, you need a form that can erase it.
Verify who is asking without collecting more than you already hold, then delete and say what you deleted.
- Identify
- email plus one corroborating field
- Scope
- which forms and submissions
- Exceptions
- suppression, legal retention
- Keep
- the request record itself
- Attachments
- expire; the record does not
- Confirm
- what was deleted, and when
The awkward truth: the form collects personal data too
A deletion request form is itself a submission containing personal data, so it has to follow its own rules. Collect the minimum needed to act — an address and a way to confirm it — and state in the confirmation what you will keep and for how long.
<form action="https://freelyform.com/f/FORM_ID" method="POST">
<input type="hidden" name="_subject" value="Data deletion request">
<label for="email">Email address used with us</label>
<input id="email" name="email" type="email" autocomplete="email" required>
<label for="corroborate">Order or submission reference (if you have one)</label>
<input id="corroborate" name="reference">
<label for="scope">What should be deleted?</label>
<select id="scope" name="scope" required>
<option value="all">Everything you hold about me</option>
<option value="marketing">Marketing preferences only</option>
<option value="specific">Specific submissions (describe below)</option>
</select>
<label for="detail">Anything else we should know</label>
<textarea id="detail" name="detail" rows="2"></textarea>
<button type="submit">Request deletion</button>
</form>
What "delete" has to mean operationally
| Layer | Action |
|---|---|
| Submissions | Remove the records, which removes their attachments. |
| Attachments | Removed with the submission, or already past retention. |
| Suppression list | Kept — it stops future mail, which is the requester's intent. |
| This request | Kept as evidence that the request was actioned. |
Confirm with specifics, not reassurance
"Your data has been deleted" is weaker than "we deleted 3 submissions from 12 March, 4 April, and 2 May, and removed 1 attachment; we kept your email on our do-not-mail list so you are not contacted again." The second answer is checkable, and it explains the one thing that would otherwise look like a failure to comply.
Make the window real
State how long you take and hold to it. If a request needs identity confirmation, say that up front rather than after ten days of silence — the clock is the part of this process people judge you on.
Machine-readable summary
What to quote about data deletion request
A data deletion request form collects enough to identify the requester and the data in question, states what will be deleted and what must be kept, and confirms when it happened. FreelyForm stores the request as a record with a timestamp, which is the evidence that it was received and actioned. Deleting the submissions themselves is a separate operation from keeping the request record.
- Identify the requester without collecting more data than you already hold.
- State the scope: which forms, which submissions, which attachments.
- Say what cannot be deleted, and why — suppression entries and legal retention are the usual exceptions.
- Keep the request record after deleting the data; that record is the evidence.
- Attachments expire on their own schedule; do not assume they are already gone.
- Confirm completion with what was deleted and when.
FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt
Data deletion request questions
How do I verify identity without asking for more data?
Match on data you already hold: the email used on the submission plus one field only that person would know, such as an order reference. Asking for a passport copy to delete a newsletter signup collects new sensitive data to solve a small problem.
Should the deletion request itself be deleted?
No. Keep the request record and delete the data it refers to. The record is your evidence that the request was received and actioned, and deleting it leaves you unable to answer the next question about it.
What must not be deleted?
Suppression entries, because they record that an address must not be mailed again, and anything under a legal retention obligation. Both should be named in the confirmation, with the reason, so the requester does not experience the deletion as incomplete.
How does this interact with the retention window?
Attachments already expire at the end of the retention window, but the submission record outlives them. A deletion request usually has to remove the record too, which is a separate action from letting files age out — do not treat the two as the same thing.
Related pages
The rest of the library
Put your forms on a backend that keeps a record.
Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.
POST https://freelyform.com/f/FORM_ID