--- title: "Form Data Retention: A Policy You Can Actually Run" slug: form-data-retention-policy description: "Retention policies fail at deletion, not at drafting. How to set the clock, choose a period per form, find the forgotten copies and make removal routine." publishedAt: "2026-10-08" author: "Instaform Team" tags: ["forms", "compliance", "how-to"] locale: en --- Most retention policies fail in the same place. Someone writes "enquiries are kept for 24 months" into a document, files it, and nothing downstream changes. Two years later the inbox still holds every enquiry since launch, plus a spreadsheet on a laptop and a folder of CVs in shared storage. Drafting the policy is the easy half. The half that decides whether it is real is whether you can find every copy of a submission and remove it without someone losing a day to it. ## Start with the clock, not the period "Twelve months" means nothing until you say twelve months from what. Three clocks are common and they behave very differently. *From submission* is the simplest, and the right one for enquiries that went nowhere. The record ages out on a fixed schedule regardless of what happened afterwards. *From last contact* suits anything that might become a relationship. A lead you spoke to in March should not disappear because they first enquired fourteen months ago. This clock resets, which means the last-contact date has to be stored somewhere you can filter on, not inferred from an email thread. *From end of relationship* is what accounting and contractual records need. The obligation normally runs from the end of the financial year in which the relationship ended, not from the date of any individual form. Pick one per form type and write the trigger next to the number. Most arguments about retention are actually arguments about the clock. ## A period per form beats a period per company A single global rule ends up either too short for the records you need or too long for the ones you do not. Reasonable starting points: general enquiries that never converted, twelve months. Quote requests, twelve to twenty-four months, because customers come back. Job applications, six to twelve months unless the candidate agrees to stay on file. Support tickets, twenty-four months, because they are your history of what went wrong. Newsletter signups, until unsubscribe, plus a suppression record kept indefinitely, because you need to remember not to email someone. Customer and financial records follow whatever your tax authority requires, and that requirement overrides your preference in both directions. ## The copies you will forget Deleting the submission from the form tool is the part everyone remembers. The copies are the part that fails an audit. Email notifications that included the full submission body sit in every recipient's mailbox, on their phone, and in whatever archive their mail provider keeps. This is the most common leak by a wide margin, and it is the reason notification emails should say "a new enquiry arrived" with a link rather than reproducing the answers. CSV exports live on laptops and shared drives with no expiry. Every export is a new copy outside your retention system, ageing on its own schedule. File uploads are frequently stored separately from the record that points at them. Deleting a submission can leave an orphaned CV in object storage indefinitely. Backups hold the data after deletion by design. That is usually acceptable if backups roll over on a known cycle and are never used for lookups. Write the cycle down, because "we delete on request" and "our backups keep it for 90 days" both need to be true and both need to be stated. ## Anonymise where deletion loses something useful You often want the shape of the data without the person. Delete a year of submissions and you also delete your view of which channels produced enquiries, which weeks were quiet, and which questions people asked. Stripping identifiers keeps the answer. Remove name, email, phone, IP, free text and uploads; keep the timestamp, the source and the structured choices. The record stops being personal data and stays useful for [survey analytics](/survey-analytics) and volume planning. Do it deliberately. Anonymisation that can be undone by joining two tables is not anonymisation. ## Make removal a job, not an intention Policies that get executed have three things: a named owner, a recurring date, and a saved filter that produces the list. Quarterly is enough for most businesses. The owner opens the filter, checks the count looks sane, deletes, and notes the date and the number somewhere. That note is the evidence the policy runs, and it takes about ten minutes when the data is structured. If producing the list takes longer than a few minutes, the data model is the problem rather than the discipline. An inbox cannot be filtered by "last contact before X and never converted". Structured records can. ## Give deletion requests their own route Separately from your schedule, people will ask you to delete their data. Send that somewhere other than a person's inbox. A short form asking for the email address they used, what they want removed and a confirmation step is faster to service and leaves you proof that you acted. Our [data deletion request template](/templates/data-deletion-request) is that form. In Instaform a submission becomes a structured record with a source, a timestamp and a last-contact date, so a retention run is a filter and a bulk delete rather than an archaeology project. The same structure is what makes the [CRM pipeline](/crm-pipeline) work at all. Retention is less a compliance feature than a side effect of not keeping customer data in an inbox.