Form Data Retention — How Long Should You Really Keep Submissions?

Most organisations think hard about how to collect form data, much less about when to delete it. The result is a quiet accumulation: thousands of submissions sitting in form tools, sometimes for years past their useful life, often forgotten, occasionally surfaced by a breach or a subject access request. This article is a practical guide to retention periods for form submissions — what the law expects, how to set sensible defaults, and how zero-knowledge tooling changes the maths.

The Default Most Organisations Run On

Open the dashboard of a typical form tool that has been in use for two or three years. You will usually find every submission ever received, complete and readable, with no scheduled deletion in sight. The reasons are familiar: nobody owns the retention question, the tool does not nudge you to set a limit, and the marginal cost of one more row in a database approaches zero. So the data stays.

This default has a specific cost. Under GDPR (Art. 5(1)(e), storage limitation) and nFADP (Art. 6 para. 4, proportionality and necessity), personal data must not be kept longer than necessary for the purpose for which it was collected. "Indefinite by default" is not a defensible answer — it is the absence of an answer, and regulators increasingly treat it as such.

What the Law Actually Requires

Both GDPR and nFADP take the same fundamental position: keep personal data only as long as you need it for the purpose you collected it for. Neither sets a single concrete deadline that applies across all forms; both require you to set deadlines that fit your purposes and to be able to defend them.

GDPR — storage limitation principle

Article 5(1)(e) requires personal data to 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". Recital 39 reinforces this: time limits for erasure or periodic review should be established. EU supervisory authorities expect you to document a retention schedule, not just a vague principle.

nFADP (Switzerland) — proportionality and necessity

The revised Swiss Federal Act on Data Protection imposes the same logic: data may be processed (including stored) only to the extent necessary for the stated purpose. Where a controller cannot justify continued storage, deletion or anonymisation is required. The FDPIC has signalled that retention schedules will be a standard inspection item.

Sector overlays

On top of the general principles, sector-specific rules set minimum and maximum retention windows that you cannot freely adjust:

• Healthcare: medical records often have long minimum retention (Switzerland: ~10 years post-treatment for adults; longer for minors and certain specialties)
• Finance and KYC: AML legislation typically requires 5 to 10 years' retention of customer due-diligence records
• Tax and accounting: many jurisdictions require commercial documents kept for 7 to 10 years
• Employment: payroll, contracts, and HR files have varying minimums (typically 5 to 10 years post-termination)
• Research and clinical trials: ICH-GCP and EU Clinical Trials Regulation require 25 years for trial master files

A Practical Framework for Setting Retention

The framework that works for most form-driven processes has four steps: identify the purpose, identify the longest applicable obligation, set a single retention period, and document it.

Sensible Defaults to Start From

These are starting points — not legal advice — that work for many small-to-mid organisations and that can be tightened or extended once a DPO or counsel reviews them.

Why Most Form Tools Make Deletion Harder Than It Should Be

If you have ever tried to operationalise retention in Google Forms, Microsoft Forms, or Typeform, you will recognise the friction: there is no automatic deletion. You have to remember to clean up, on a schedule you set yourself, in a UI that nudges you to keep data, not delete it. And when you do delete, the deletion is a soft operation — gone from your view, but the provider's backups still hold a copy for a window you cannot fully see.

Worse: even a deletion you have made is reversible by the provider, because they hold the keys. "We deleted it" is, technically, "we marked it deleted in our application database". The plain-text data continues to exist on the provider's storage and backups for some retention period — typically 30 to 90 days — that is governed by their internal policy, not yours.

How Zero-Knowledge Architecture Changes the Maths

When data is encrypted in the respondent's browser before transmission, the provider stores ciphertext only. The keys live with the form owner — the organisation. That changes what "deletion" means in two important ways.

• Deletion is cryptographically final. When the form owner deletes a submission, the ciphertext is removed from the active database. The provider has no plain-text copy anywhere — no "hidden" backup, no support-team access, no recovery path. The data is gone.
• Retention boundaries are honoured by physics, not policy. A retention schedule on a conventional tool is a promise; on a zero-knowledge tool, it is a property. There is no plain-text copy that can quietly outlive your schedule.
• Subject access and erasure requests are easier. When a respondent asks for deletion (GDPR Art. 17, nFADP equivalent), "we have deleted it" is technically and demonstrably true.

Common Mistakes to Avoid

Mistake 1: Setting a single retention period for all forms

A KYC form and a newsletter sign-up have different obligations. A blanket "7 years for everything" is too long for the newsletter and possibly too short for the KYC. Per-form retention is the right grain.

Mistake 2: Confusing retention with archive

If you need long-term storage for compliance reasons, the form tool is rarely the right place for it. Move the data to a system designed for archive (CRM, EHR, case-management), with its own retention controls, and let the form tool's retention sit at "long enough to process".

Mistake 3: Treating deletion as a manual cleanup task

Manual cleanup does not happen reliably. Pick a tool that supports automatic deletion at the retention horizon, then verify it works.

Mistake 4: Not documenting the why

If a regulator asks why you keep applicant data for nine months, "because that's what we picked" is not enough. "Because that matches our anti-discrimination defence window under [jurisdiction] employment law" is. Write the reason next to the number.

Mistake 5: Forgetting downstream copies

Form data ends up in CRMs, ticketing systems, email threads, and spreadsheets. Your retention policy has to follow the data, not just the original form. Document the propagation; align the schedules.

A Minimum Workable Retention Policy

If you have nothing in place today, you can ship a workable retention policy in an afternoon. Here is a skeleton:

1. List every active form (or every form that has received a submission in the last 12 months)
2. For each, write a one-line purpose, the longest applicable mandatory floor, and a chosen retention period
3. Set the form tool to enforce that period automatically — or, if the tool cannot, schedule a recurring calendar task with named owners
4. Add the table to your record of processing activities and link it from your privacy notice
5. Schedule an annual review

How to Communicate It to Respondents

Both GDPR and nFADP require you to tell respondents how long you intend to keep their data. The phrasing does not have to be complicated:

We will keep the information you provide on this form for [X months/years] after [trigger event], after which it will be automatically deleted from our form system. If you have asked to be contacted about a service, we will retain a record of that consent for [Y months] beyond unsubscribe.

Place the wording inside the form's privacy notice, link to a fuller privacy policy from the consent box, and reference the table from your record of processing activities. Respondents who care will look; regulators who care will find it.

The Bottom Line

Retention is the quiet half of data protection. Most organisations are fine on collection, weak on deletion. The fix is mechanical, not philosophical: document a per-form schedule, enforce it automatically, and prefer tools that make deletion final.

Schweizerform was designed with retention in mind. Encryption in the browser, ciphertext-only storage, configurable retention with cryptographic deletion — together they shift retention from a promise the provider makes about its own behaviour to a property of the system itself. That is the kind of guarantee a DPO can put on the desk of a regulator without flinching.