Form data retention schedule: a practical template

Stable definition and boundary

A form-data retention schedule is a versioned set of executable rules that says which form-derived data is kept, where each copy exists, why it is needed, when its retention clock starts, what ends the period and how the final action is proved.

This guide owns the lifecycle rule after collection. The CRM-ready data model owns stable fields and write behavior, the consent-record checklist owns purpose evidence, and the suppression checklist explains why a minimal stop record may need a different lifecycle from marketing content.

Twelve-field retention schedule

Split records when their purposes or end actions differ. A single submission can contain a short-lived uploaded brief, a contact identity used for an active service request, a longer-lived contract record and a minimal suppression event. One account-wide number cannot describe those lifecycles accurately.

Copy inventory

Inventory the copy, not merely the vendor. A single platform may hold a submission object, contact profile, file, automation log and backup on different clocks. Conversely, one exported file may contain records from several systems and require its own owner and end action.

Disposition matrix

Make the action observable. A successful job should identify the policy version, targeted population, processed count, failures, downstream instructions and next retry. Avoid logging the deleted payload itself as evidence.

Worked consultation example

A consultation form creates a submission, contact profile, uploaded brief, internal notification and routing event. The policy separates four classes instead of assigning one blanket period.

The example deliberately contains no universal number of days or years. The owner records the real legal and operational basis, applies the shortest justified period, and schedules a review when the purpose cannot be expressed as a fixed duration.

Implementation method

1. Map every copy.Trace a synthetic form record through the builder, contact store, files, email, integrations, exports, logs and backups.
2. Classify by purpose.Separate data that serves different operational, legal or evidential needs.
3. Choose the trigger.Use a reproducible event such as closure, contract end or withdrawal, including a timezone and source.
4. Justify the period.Record the shortest necessary duration or review condition and the policy evidence behind it.
5. Specify disposition.Name deletion, anonymisation, restriction, return or aggregation and define what completion means.
6. Bound exceptions.Require a reason, approver, affected scope and review or expiry for every hold.
7. Automate and reconcile.Execute the rule across destinations, record failures and retry without recreating deleted data.
8. Test restoration.Prove that a backup restore does not make disposed records available for ordinary use.

Current source boundary

As checked October 18, 2026, the ICO's storage-limitation guidance says personal data should not be kept longer than needed, organisations should justify retention periods, document them in a policy, review data and erase or anonymise it when no longer needed. It also recommends retention schedules and automated review or deletion where appropriate.

The same page says parts of the guidance are under review following the Data (Use and Access) Act. The ICO's erasure guidance also makes clear that the right is not absolute, addresses recipients and backups, and says backup data that cannot be erased immediately should be put beyond use until overwritten.

The official GDPR text provides the underlying EU storage-limitation principle in Article 5(1)(e), the right to erasure and exceptions in Article 17, and processor deletion-or-return terms in Article 28. This article turns those source concepts into a testing framework; it does not determine which law applies or replace jurisdiction-specific advice.

Ten-case deletion proof test

1. Normal expiry.The scheduled action targets the intended class and leaves unrelated records untouched.
2. Early valid request.The workflow applies the allowed action across every in-scope copy and records any exception.
3. Active legal hold.Ordinary use stops where required; only the named scope is preserved; owner and review date remain visible.
4. Expired hold.The original disposition resumes automatically or enters a bounded review queue.
5. Processor copy.The downstream instruction reaches the correct record and produces a receipt or reconcilable failure.
6. Offline export.The named owner can locate and dispose of the file without relying on deletion from the source system.
7. Workflow queue and log.Pending payloads, dead letters and debug copies follow their own short lifecycle.
8. Backup restore.A restored environment replays tombstones or otherwise keeps disposed data beyond ordinary use.
9. Anonymisation boundary.The remaining aggregate cannot be relinked through retained keys or rare combinations.
10. Partial failure.The run reports the missed copy, retries idempotently and never marks the case complete early.

Run the cases with synthetic records and the same integrations used in production. Record results through the end-to-end form testing checklist, and report source or factual corrections through the corrections policy.

Evidence and limitations