How long to keep form submissions

Nobody ever decided to keep every contact form submission indefinitely. It happened because deleting data requires a decision and keeping it requires nothing at all.

There is also a plausible-sounding argument for hoarding: you never know when an old enquiry might be useful. In practice, if you sort any long-running submissions archive by date, the portion anyone has looked at in the last year is small and recent.

Meanwhile the archive is an obligation. Every row is data you must secure, disclose on request, correct when asked, and delete when someone exercises their rights. The cost of storage is nothing; the cost of custody is not.

It is also the part of the regulation with the widest gap between what sites believe about themselves and what is true. Almost every business will tell you it keeps data only as long as necessary. Almost none of them can say what that period is, and fewer still have anything that enforces it.

This is a working explanation for people who run websites, not legal advice. If your processing is unusual or high-risk, take proper advice.

A single submissions table usually contains three different categories that deserve different treatment.

There are enquiries that went nowhere: a question, an answer, no further contact. There are enquiries that became customers, where the data has since acquired a commercial and often a statutory life of its own. And there is spam, which was never a person in any meaningful sense.

Once separated, the decision gets easy. The customer records follow whatever your accounting and contractual obligations require. The spam can go quickly. The genuinely difficult category, unconverted enquiries, turns out to be the only one you actually have to think about, and it is the one where a short period is easiest to defend.

The legal test is necessity for the purpose, which sounds vague until you write down the purpose. If the purpose is answering an enquiry and following up, the necessary period is roughly the length of your sales cycle plus a margin.

For most businesses that produces something between six and twenty-four months. A trade with long lead times can justify longer; a shop answering delivery questions cannot justify two years.

What matters more than the exact figure is that you can say where it came from. Twelve months because our typical enquiry-to-order cycle is under four months and we want two full quarters of margin is a defensible sentence. Twelve months because it seemed reasonable is not, and neither is no answer at all.

Write the sentence down at the same time as you pick the number, because the justification is the part that decays. Two years later nobody remembers why it was twelve months, and the temptation is to quietly extend it rather than revisit the reasoning. A single line in the privacy notice fixes both problems, since it records the decision and publishes it in the same stroke.

Automated junk contains personal data too, sometimes real addresses harvested from elsewhere. It has no purpose beyond the immediate one of not being delivered to you, so it should have the shortest life of anything in the system.

A short window is worth keeping rather than deleting instantly, because quarantined submissions are exactly where false positives hide. A fortnight is usually enough for a real person's misclassified message to be noticed and rescued.

After that it is pure liability. If you are keeping three years of spam because deleting it never came up, that is the easiest and largest reduction available to you today.

The same logic covers whatever your screening layer rejects outright. Rejected submissions that are logged for tuning are still records about people, and they deserve the shortest life of anything you hold.

Retention is not all or nothing. Frequently the useful part of an old submission is not personal at all.

You may genuinely want to know how many enquiries arrived each month, which campaigns produced them, and what people asked about. None of that requires the name, the email address or the message body. Stripping the identifying fields and keeping the counts preserves the analysis while ending the custody obligation.

This is the compromise that satisfies both instincts. The marketing report keeps working, and the archive of people stops growing.

A retention policy that depends on somebody remembering is not a policy. The whole value comes from it running whether or not anyone is paying attention.

In a spreadsheet workflow this is straightforward. Every row carries a submission timestamp, so a filter on date produces the deletion candidates and a monthly reminder produces the trigger. It is a five-minute recurring task rather than a project.

The reason it works is that everything is in one place. When the same enquiry exists in a plugin database, two inboxes and a CRM, the concept of a retention period stops being enforceable at all, which is a strong argument for consolidating where submissions live in a single destination rather than accumulating copies.

Before congratulating yourself on a clean archive, list the copies. Notification emails in several inboxes. A CSV export from a quarterly report. A downloaded backup on a laptop. A cloud backup of that laptop. A shared folder from the time somebody covered for a colleague.

Every one of those is the same personal data, and a deletion request covers all of them.

You will not get this to zero, and you are not expected to. What you can do is reduce the number of routine copy-making habits: export less, share views instead of files, and keep the number of places a submission lands as close to one as the business allows.

The habit worth breaking first is the ad-hoc export. A CSV made for one meeting has no owner, no retention rule and no access control once it is on somebody's laptop, and it is the copy most likely to still exist in three years. Sharing a filtered view of the live sheet does the same job and leaves nothing behind.

The policy itself can be three sentences. Unconverted enquiries are deleted after twelve months. Quarantined spam is deleted after fourteen days. Records relating to customers are retained under the customer records policy.

Put that in your privacy notice, because retention periods are one of the things people are entitled to be told, and a specific answer is far better than the widespread formula about keeping data as long as necessary.

Then put a note in the same document saying who runs the deletion and how often. That sentence is what turns a claim into a control.

Someone will say that an old enquiry occasionally resurfaces and having the history is valuable. That is true, and it happens.

The honest response is that it happens rarely, that the person will usually re-explain their situation anyway, and that the value of those occasional cases is small next to the cost of holding everything. If a particular class of enquiry genuinely does have a long tail, carve that class out with a longer period and a stated reason. That is a policy decision, not a reason to keep everything forever.

Blanket retention is not caution. It is an unmade decision that quietly transfers risk to a future incident.

1. Sort the archive by date and see how old the oldest row is.
2. Split enquiries from customers from spam.
3. Pick a period for unconverted enquiries you can explain in one sentence.
4. Delete the spam beyond a short review window today.
5. Put the periods in the privacy notice and a recurring reminder in a calendar.

That is the whole project, and it removes more risk than any amount of consent-banner refinement.

Is there a legally required retention period for enquiries?

Can I keep an anonymised version indefinitely?

What about notification emails in my inbox?

Should the retention clock start at submission or last contact?

How do I delete rows without breaking my spreadsheet?

Does deleting data hurt my ability to report on trends?

What if I am not sure whether a record is a customer?