A data retention policy for a web application is a documented set of rules that states how long different categories of data are kept, why they are kept, and what happens when that period ends. It is not a technical configuration on its own, but a business decision that then gets enforced through the application's design and infrastructure.
Decision summary: Create a policy that explains why each data class is kept, which event starts the period, and how holds, deletion and backups are handled.
In the UK, the starting point for most businesses is the UK GDPR and the Data Protection Act 2018, which require that personal data is not kept longer than necessary for the purpose it was collected. However, the exact retention period is not prescribed in legislation for most business data — it is for the organisation to justify based on the purpose, contractual obligations, regulatory requirements in its specific sector, and legitimate interests. Because these rules and their interpretation change over time, any policy should be checked against current ICO guidance and, where relevant, sector-specific regulation rather than relying on memory or outdated advice.
The policy needs to cover every type of data the application handles: user accounts and profile information, transaction records, documents uploaded by users, system-generated logs, communication histories, and any data pulled in from integrations. Each category can have a different retention period and a different disposal method. Some data might be deleted, some anonymised so it can still be used for reporting, and some archived in a separate system with restricted access.
Creating the policy is a joint exercise. Operations and compliance teams define the business and legal reasons for keeping data. Technical teams then assess what is feasible to implement, where data actually resides — including in backups, caches, and third-party services — and what the cost implications are of different approaches. A policy that cannot be technically enforced is of limited practical value.
| Decision area | Why it matters | Evidence to retain |
|---|---|---|
| Categorising data by purpose | The first practical step is to list every data type in the application and group it by purpose. | Retain the role, data flow, decision owner and review date. |
| Choosing between deletion, anonymisation and archiving | When a retention period expires, the default assumption under UK GDPR is deletion. | Record purpose, legal position, user choice, evidence and review date. |
| Enforcement through application design | A policy document sitting in a shared drive does not reduce risk. | Retain the role, data flow, decision owner and review date. |
| Backups and replicas | Backups present a particular complication. | Retain the role, data flow, decision owner and review date. |
There is no universal retention period for web-application data
Retention periods must be justified by purpose, legal or regulatory duties, limitation risk, contracts and operational need. “Keep everything for six years” is not a general data-protection rule. Some financial records may have six-year requirements, while other data should be deleted much sooner or may need to be retained longer for a documented reason.
The policy should distinguish deletion, irreversible anonymisation, restricted archive and backup expiry. A retention schedule is useful only when the application, connected services and operational teams can enforce it consistently.
Categorising data by purpose
The first practical step is to list every data type in the application and group it by purpose. A customer portal, for example, might hold account credentials (purpose: access control), order history (purpose: fulfilment and warranty), support tickets (purpose: service delivery), and uploaded documents such as proof of identity (purpose: regulatory compliance). Each of these purposes can justify a different retention period.
For a CRM system, contact records might need to be retained for the duration of the commercial relationship plus a period dictated by tax or contract law. Marketing consent records have their own requirements under privacy regulations. Activity logs used for debugging or security investigation may have a short operational retention window that is entirely separate from the retention of the business data they relate to.
Choosing between deletion, anonymisation and archiving
When a retention period expires, the default assumption under UK GDPR is deletion. But in practice, businesses often need to keep aggregated or anonymised data for reporting, or retain certain records in an archive with strict access controls to meet regulatory obligations. The policy should specify which method applies to each data category and what "anonymised" actually means in that context — genuine anonymisation, where the individual cannot be re-identified, is distinct from simply removing a name from a record that still contains other identifying details.
Enforcement through application design
A policy document sitting in a shared drive does not reduce risk. The application needs mechanisms to act on it: scheduled processes that flag or delete records past their retention date, user-facing controls that allow data subjects to request deletion in line with the policy, and admin interfaces that make retention status visible. The technical team needs to understand whether deletion means a hard remove from the database, a soft delete that hides the record but keeps it for a recovery window, or something else — and the policy must be explicit about this, because soft deletes that never become hard deletes undermine the entire exercise.
Backups and replicas
Backups present a particular complication. Data deleted from the live application typically remains in backups until those backups are overwritten or purged. The policy should address this gap by stating the backup retention cycle and acknowledging that there is a window during which deleted data may still be recoverable. For some organisations, this is acceptable. For others, particularly those handling sensitive personal data, it may require a different backup strategy or additional controls.
Integrations and third-party data
If the web application sends data to other systems — a payment processor, an email service, an analytics platform, or another internal system — the retention policy needs to account for those copies. The application may delete a record on schedule, but copies may persist elsewhere. The policy should identify where data is replicated and either ensure those systems have aligned retention practices or document the discrepancy as a known limitation.
Keeping everything “just in case”
The most common mistake is retaining data indefinitely because it might be useful later. This directly conflicts with the principle of storage limitation, increases the scope of any data breach, and creates a growing liability. If there is no documented justification for keeping a data category beyond a specific date, the default should be to set a retention period and stick to it.
Setting arbitrary periods without justification
Equally problematic is picking a round number — six years, three years, twelve months — without linking it to a specific legal, contractual or operational reason. A retention period that cannot be justified if challenged by a regulator or a data subject is a weak point in the policy. Every period in the document should reference the reason, even if that reason is simply "operational need for X months after account closure."
Confusing retention with backup recovery
Some businesses treat their backup retention window as their data retention policy. These are different things. A 30-day backup rotation is a disaster-recovery measure, not a business decision about how long customer data should be kept. Conflating the two leads to either keeping data too long or, more dangerously, assuming data is being managed when it is not.
Writing a policy and never reviewing it
Business processes change, regulations change, and the application itself evolves. A retention policy written at launch will become inaccurate as new data types are added, new integrations are connected, or new regulatory guidance is issued. The policy should have a scheduled review cadence — typically annual — and a trigger that initiates a review when significant changes are made to the application.
Key checks before finalising the policy
- Does every data category in the application have a stated retention period and disposal method?
- Is each period linked to a specific justification — legal, contractual, regulatory or operational?
- Have backups, caches, logs and replicas been included, or is the gap explicitly documented?
- Does the technical team have a clear implementation plan, or are there categories where enforcement is not yet possible?
- Have third-party services and integrations been checked for data copies that fall outside the policy?
- Is there a review schedule and an owner responsible for keeping the policy current?
- Has the policy been checked against current ICO guidance and, where applicable, sector-specific requirements?
Questions to put to a supplier or development team
- How will the application flag records that have reached their retention date?
- Does the proposed approach use hard deletion, soft deletion, or anonymisation, and can you explain the difference in this context?
- How will data in backups be handled — is there a separate purge cycle?
- Can the admin panel show retention status so the operations team can verify compliance?
- What happens to data sent to integrated services — can you map where copies exist?
- How will we test that retention rules are working correctly after each release?
A data retention policy is not a one-time compliance exercise. It is an operational document that only has value when it is specific enough to implement, honest about its limitations, and kept aligned with the application as it changes.
Checks before relying on the system
- Document the precise processing scenario and who is authorised to approve exceptions.
- Design a workable complaints, rights-request and evidence process rather than relying on a privacy notice alone.
- Confirm the organisation’s role for each processing activity rather than labelling every supplier a processor.
- Record the purpose, lawful basis, data categories, recipients, retention rule and international-transfer position.
Primary guidance checked for this edition
Sources for “How to Create a Data Retention Policy for a Web App” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.