A contact form has been live for three years. Every submission is still in the tool, along with the attachments, the email notifications that went to three people, and two spreadsheet exports that somebody pulled for a report in 2024. Nobody has ever deleted anything, because nobody was ever told what to delete or when. The question that starts the search is usually simpler than the situation: how long is this allowed to sit here.
The answer that comes back from most pages is a table of months, presented as though the regulation contained one. It does not. Understanding what the GDPR actually asks for is what makes the rest of the decision possible, because the number has to be produced locally, and then defended.
The regulation sets a test, not a number
Article 5(1)(e) of the GDPR requires that personal data be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed. That is the storage limitation principle in full, as far as duration goes. There is no schedule attached to it, no default period for enquiry forms, and no figure that can be copied from a blog post and treated as compliance.
Two consequences follow, and they run in opposite directions.
The first is freedom. A period is defensible if the purpose still requires it. A support request that is still open is necessary. An application for a role that closed two years ago is harder to argue for.
The second is the burden. Article 5(2) makes the controller responsible for, and able to demonstrate compliance with, the principles in paragraph 1. Demonstrating means producing something: a written period, a reason for it, and evidence that it is enforced. An organisation that keeps everything forever has not failed a numerical limit. It has failed to show that keeping everything forever was necessary, which is a much harder position to hold in an argument with a regulator.
The practical reading is that a period you wrote down and can explain beats a shorter period you copied and cannot. A retention period of two years with a stated reason is in better shape than six months chosen because it looked cautious, if the six months was never recorded and the data is still there anyway.
Work out the purpose before the period
Retention is decided per purpose, not per tool. One form tool holding five forms usually holds five different clocks, and the clock that matters is the one attached to why the data was collected in the first place.
Three sources produce a period that can be defended, and it is worth knowing which one is being used:
A legal obligation to keep records. Tax, employment and accounting law in the relevant country sets minimum periods for certain documents. Where a submission is part of such a record, the period is not a judgement call, and it can be longer than anything the business would choose.
A limitation period for claims. Where a submission could become evidence in a dispute, keeping it until claims are time barred is a recognisable reason. The period comes from the applicable law on limitation, not from the form.
An operational need that can be described in a sentence. Repeat enquiries from the same person, a warranty window, an event that runs annually. This is the weakest of the three and the most common, which is why it has to be written as a sentence rather than assumed.
| Form | Why it was collected | What ends the purpose |
|---|---|---|
| Sales enquiry | To answer the question and follow up | The enquiry is closed and no relationship formed |
| Job application | To fill one specific role | The role is filled, unless the candidate agreed to be kept on file |
| Support request | To resolve a fault for a known customer | The fault is closed and the warranty or contract window has passed |
| Event registration | To run one event | The event has happened and any follow up has been sent |
| Expense or invoice submission | To pay and to keep an accounting record | The statutory record keeping period expires |
Anything that does not fit one of those rows is a signal, not an edge case. A field that nobody can attach to a purpose is usually a field that should not be on the form.
The kept on file case, which is a different purpose
Applications are the row where the purpose most often changes after collection. An application submitted for one role has a purpose that ends when the role is filled. Keeping the same application to consider the person for future openings is a second purpose, and it needs its own basis, which in practice means asking on the form and recording the answer.
That turns one retention rule into two running side by side in the same form. Applications with the box unticked follow the short period tied to the role. Applications with it ticked follow a longer period that was stated to the candidate at the time. A tool that stores the answer as one more column, with no way to act on it, leaves the distinction on paper. A tool where that answer can drive a status, and the status can drive deletion, makes it real. The same pattern applies to any form where a second use was offered as an option rather than assumed.
Three things the regulation expects you to produce
Retention is not only a deletion job. Three separate obligations touch it, and they fail in different places.
The person has to be told at collection. Article 13(2)(a) requires that the data subject be given the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period. The criteria wording is the useful part. A privacy notice that says responses are kept while the enquiry is open and for as long as any related claim could be brought is compliant. A notice that says nothing about duration is not, and the notice linked from the form is where a regulator will look first.
The internal record has to name the limits. Article 30(1)(f) requires records of processing activities to include, where possible, the envisaged time limits for erasure of the different categories of data. This is the document that turns a habit into a policy. It also exposes the forms nobody owns, because a category with no time limit next to it is a category with no owner.
Erasure has to be possible on request. Article 17(1)(a) gives the right to erasure where the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed. A tool that cannot locate every response from one email address cannot satisfy that, regardless of what the policy says.
Deletion, anonymisation, and the copies nobody counted
The wording in Article 5(1)(e) is about data kept in a form which permits identification. That is what makes anonymisation a real option and also what makes most attempts at it fail.
Removing a name from a row while leaving the email address, the phone number and the free text in which the person described their own situation does not remove identification. Aggregating a year of responses into counts does. The test is whether the remaining record can be tied back to a person, including by combining it with anything else the organisation holds. Where the answer is yes, the retention clock is still running, and the record has simply become harder to find when an erasure request arrives.
The larger problem is copies. A single form submission usually exists in more places than the tool it arrived in:
- the response itself, in the form tool
- an email notification, in the inboxes of everyone on the notification list
- file attachments, in whatever storage the tool uses for uploads
- any spreadsheet export somebody pulled, on a laptop or in a shared drive
- backups, which follow their own cycle
- the reply that was sent, if it was sent from a personal mail client
Deleting the first one and nothing else is the most common version of a retention policy in practice. It is also the version that comes apart under one question from an auditor. The honest response is to reduce the number of copies rather than to try to schedule deletion across all six. Turning full response content off in notification emails and keeping exports out of the workflow removes two of them outright, and every route that keeps the response and the reply in one place removes another. Tools built around response management rather than around downloading a spreadsheet are easier to hold to a schedule for exactly this reason.
A schedule that a form tool can actually run
A retention schedule is only real if something executes it. Four columns are enough, and the third one is where most drafts fall apart.
| Data class | The clock starts at | Period | Who or what deletes it |
|---|---|---|---|
| Enquiry responses, no relationship formed | Status set to closed | Stated period after closure | Scheduled deletion in the tool |
| Application responses | Role closed | Stated period, longer only with consent | Scheduled deletion in the tool |
| Uploaded files | Parent response deleted | Same as parent, immediate | Must be automatic, or it will be missed |
| Exports | Report delivered | Days, not months | A named person, with a reminder |
| Notification emails | Response handled | Not applicable if content is excluded | Mail retention policy |
Two rules make the difference between a schedule and a document. The clock has to start at an event the tool records, which in practice means a status field rather than a submission date, because a closed enquiry and a six month old open enquiry need different treatment. And the action has to be the tool's own, because any step that depends on a person remembering to run something quarterly is a step that stops happening within two quarters.
Withdrawal and erasure arrive through the same door
Retention is usually written as an internal scheduling problem, and then the first real test comes from outside. Article 7(3) gives the data subject the right to withdraw consent at any time, states that withdrawal does not affect the lawfulness of processing before it, and requires that it be as easy to withdraw as to give consent.
What that means operationally is that an inbound request has to be answerable in minutes. Somebody writes asking to be removed. The person handling it has to find every response from that address across every form, decide which ones are held on consent and can go, which ones are held under a legal obligation and cannot, and record what was done. None of that is possible in a tool where each form is a separate export and each response is an anonymous row.
This is where retention stops being a legal exercise and becomes a question about the shape of the tool. Responses keyed to a person, each with an owner and a status, can be found and acted on. A folder of exports cannot. The practical difference shows up on the day a request arrives, not on the day the policy is written.
What to change first
Pick the form with the most responses, write one sentence saying what ends its purpose and one number for how long after that the data is kept, and put that period into the privacy notice linked from the form. Then make the deletion automatic rather than a reminder, and check whether uploaded files and notification emails are covered by it, since those are the two copies that survive almost every policy. If the current tool cannot hold a status per response or delete on a schedule, that is the constraint to solve before the schedule is written, and comparing Halict or any tool with per response ownership against what is in use now is the shorter route.
Q1. How long does the GDPR say form responses can be kept?
The regulation does not name a period. Article 5(1)(e) requires that data not be kept in identifiable form for longer than is necessary for the purposes it was collected for, which means the period has to be set locally and justified. Any specific number of months presented as a GDPR requirement came from somewhere other than the regulation.
Q2. Is it enough to delete the responses from the form tool?
Usually not. The same submission normally also exists in notification emails, in uploaded file storage, in any spreadsheet export somebody pulled, and in backups. Reducing the number of copies, by excluding response content from notification emails and avoiding routine exports, is more effective than trying to schedule deletion across all of them.
Q3. Does anonymising responses stop the retention clock?
Only if the remaining record can no longer identify anyone, including by combining it with other data held. Removing a name while keeping an email address, a phone number or free text describing the person's own situation does not qualify. Aggregating responses into counts does.
Q4. What has to be in the privacy notice next to the form?
Article 13(2)(a) requires either the storage period or the criteria used to determine it. The criteria option is usually the workable one, so a sentence such as kept while the enquiry is open and for as long as a related claim could be brought is acceptable, while saying nothing about duration is not.
Q5. Can a period be extended if the data still looks useful?
Not on that basis alone. The period follows the purpose, so a longer period needs a different justification, such as a statutory record keeping obligation, a limitation period for claims, or fresh consent from the person. Keeping data because it might be useful later is the position Article 5(2) makes hardest to defend.