Storage limitation: turn retention periods into a working control
A practical GDPR guide to setting purpose-linked retention periods, handling backups and exceptions, and proving that deletion or anonymisation actually happened.
A team is about to set the retention period for a customer dataset. The easy answer is a number copied from the last product, the vendor's default, or a broad policy category. The harder question is the one that matters: what purpose still requires these records to remain identifiable, and what event will end that need?
Storage limitation is the GDPR principle that forces an answer. It is not a command to delete everything quickly. It is a requirement to connect identifiable retention to a real purpose, justify the period, review the decision, and dispose of or transform the data when the reason ends. 1
The legal boundary: identifiable data has an expiry problem
Article 5(1)(e) says personal data must be kept in a form that permits identification of data subjects for no longer than necessary for the purposes for which it is processed. The same provision permits longer storage when the data is processed solely for public-interest archiving, scientific or historical research, or statistical purposes, with appropriate safeguards under Article 89(1). 2
That wording creates two boundaries that are easy to blur:
- Identifiable retention: the organisation can still connect the record to a person and use it for an operational purpose.
- Longer safeguarded retention: the organisation has a distinct permitted purpose, appropriate measures, and no excuse to reuse the data for an unrelated decision about an individual.
The GDPR does not provide one universal duration for customer accounts, CCTV, recruitment files, support tickets, or analytics data. The ICO says the period depends on the organisation's purposes, and that the organisation must be able to justify how long it needs personal data in identifiable form. 2
The practical consequence is uncomfortable but useful: "we may need it later" is not a retention rationale. A possible future use may be a prompt to design a new, separately assessed processing activity. It is not, by itself, a reason to keep the original dataset identifiable indefinitely.
Build the period from the purpose and its end event
A retention schedule should answer more than "keep for seven years." The ICO describes a retention policy or schedule as a record of the information held, what it is used for, and how long the organisation intends to keep it. It also recommends a system that makes the organisation follow and review those periods, while allowing early deletion when a record is no longer needed. 2
For each data set and purpose, write the decision in this order:
- Purpose: What action or service does the identifiable record support?
- End event: What changes when the active need ends — account closure, case resolution, contract termination, employee departure, a review date, or another defined event?
- Period: How long after that event is identifiable retention still necessary?
- Reason: Which legal, operational, safety, accounting, claims, or other requirement supports the period?
- Review: Who checks the decision, and how often, especially before a long period expires?
- Disposition: What happens at expiry — deletion, irreversible anonymisation, suppression, or a restricted preservation state?
- Evidence: What proves that the rule ran, what it changed, and what exceptions were approved?
This separates a duration from its justification. It also exposes where a product has one data table serving several purposes. A customer account might need contact details while the account is active, a limited suppression record after marketing consent is withdrawn, and a separate financial record for a legally required period. One product-wide deletion date hides those different decisions.
The ICO gives the same pattern in practical examples. A bank may retain account information while an account is open and keep some information for a further period for legal or operational reasons after closure. A CCTV period may be longer where a suspicious transaction takes time to surface, while a different setting may be sufficient for a venue where incidents are discovered quickly. If an incident is reported to police, the relevant footage may need to be retained until it can be collected. 2
The point is not that these examples create standard durations. They show why the trigger and the operational context belong in the record.
Keep longer only for a named reason, and change the access model
A longer period can be justified. A tax or audit obligation, a limitation period for a possible claim, a safety need, or another legal or operational requirement may mean that some data remains necessary after ordinary business use ends. The retention record should name that reason rather than placing the whole dataset into a vague "legal" category.
The access model should change with the purpose. A record retained only to meet an obligation should not automatically remain searchable, editable, or available to the same product teams that used it for active service delivery. Restrict it to the people and systems that need it for the preservation purpose, prevent secondary use, and set a date or event for review.
This is a control decision, not a claim that the GDPR imposes one universal architecture. Article 5(1)(e) governs the duration of identifiable processing; the organisation still has to design a proportionate way to preserve what it genuinely needs. Article 5(2) places responsibility on the controller to demonstrate compliance with the principles. 1
The same discipline applies to public-interest archiving, research, and statistics. The ICO says longer or indefinite retention under these purposes must be genuinely limited to that purpose and protected with appropriate safeguards. It warns that data retained on this basis cannot later be used for another purpose, particularly a decision affecting a particular individual. 2
That makes aggregation or anonymisation an important design question. If the business only needs population-level statistics, it may be possible to remove the need for identifiable records. But a label such as "de-identified" does not answer whether people can still be identified. The ICO distinguishes anonymisation from pseudonymisation and says pseudonymised, key-coded data will usually still permit identification, so storage limitation continues to apply. 23
Deletion is a lifecycle test, not a database command
A retention rule fails if it exists in a policy but not in the systems that hold the data. The ICO recommends regular review and says organisations should erase or anonymise personal data when they no longer need it. It also notes that automated systems can flag records or delete them after a predetermined period, especially where many records share the same category. 2
Test the rule across the full data path:
- the primary database and search index;
- exports, reports, spreadsheets, and case files;
- application logs and event records;
- replicas, archives, and backups;
- processors, sub-processors, and other recipients; and
- derived profiles, scores, or model features that remain linked to a person.
The right of erasure makes this operational. Article 17(1)(a) includes the case where personal data are no longer necessary for the purposes for which they were collected or otherwise processed, subject to the exceptions in Article 17(3). 1
The correct response is not to promise that every technical copy disappears at the same instant. It is to define what the organisation means by deletion, how it puts data beyond ordinary use, and how it handles copies that cannot be changed immediately. The ICO says archived and backed-up records are not exempt from information-rights obligations, and organisations should have defined retention periods for them. It also says that if data is deleted from a live system, it should also be deleted from backups of that system where appropriate. 24
For backups that cannot be selectively edited, a defensible design may require restricted access, no restoration into active use except under controlled conditions, a documented expiry point, and deletion when the backup cycle reaches it. That is a design choice to test against the organisation's systems and risk; it is not a technology exemption.
Keep the adjacent principles separate
Storage limitation sits close to several concepts already used in privacy reviews, but each asks a different question:
- Purpose limitation: Why is the data being used, and is a new use compatible with the original purpose?
- Data minimisation: Which fields and level of detail are necessary for that purpose?
- Storage limitation: How long must the data remain identifiable for that purpose?
- Accuracy: Does keeping old information increase the chance that an outdated record will be used incorrectly?
- Security: What protects the data while it remains in the organisation's possession?
- Anonymisation: Can the data be changed so that people are no longer identifiable, allowing a different retention analysis?
The distinction matters in project reviews. Encryption can reduce unauthorised disclosure while leaving an unjustified retention period untouched. Pseudonymisation can reduce exposure while leaving the data personal. A deletion workflow can shorten retention while failing to address an inaccurate record that should be corrected earlier.
The ICO ties storage limitation to data protection by design and by default. Its guidance says the default settings must address the period of storage as well as the amount of data, extent of processing, and degree of accessibility. It recommends mapping what information is used and why, considering anonymisation or pseudonymisation, and deleting information that is no longer needed through a register or retention schedule. 5
That is why retention belongs in architecture and product design, not only in records-management policy. The chosen period affects database schemas, deletion APIs, backup schedules, vendor contracts, access roles, analytics pipelines, and test data.
Failure modes to catch before sign-off
One period for an entire product
Different purposes often have different end events. Split the processing activity and the data fields before assigning periods.
"Keep for seven years" with no rationale
A number without a purpose, trigger, or source of necessity cannot explain why the data remains identifiable. Record the reason and review it.
Treating a policy promise as enforcement
If a policy says data is deleted but no system owner, job, exception path, or evidence exists, the organisation cannot show that the control operates.
Calling pseudonymisation anonymisation
If a key, additional information, or a realistic combination of information can reconnect the record to a person, the data may still be personal. The retention rule has not disappeared.
Leaving copies outside the main application
A database deletion that leaves exports, logs, vendor copies, or searchable backups can close one surface while leaving the lifecycle open.
Turning preservation into active use
A legally or operationally preserved copy should not quietly remain available for the original product purpose or become a convenient source for a new one. Record the restricted purpose and reassess any later use.
Reviewing only when someone complains
The ICO says retention should be reviewed at the end of a standard period and regularly before then where the period is lengthy or the potential impact is significant. 2
The retention record a reviewer can use
A workable record should let someone outside the original project reconstruct the decision:
- Processing boundary: purpose, people, fields, systems, recipients, and lifecycle.
- Active-use end event: the event that ends the ordinary business need.
- Identifiable retention period: duration after that event, with the reason it is necessary.
- Legal or operational constraint: the named obligation, risk, or requirement supporting any longer period.
- Review rule: owner, review date or trigger, and criteria for continuing or ending retention.
- Disposition action: deletion, suppression, irreversible anonymisation, or restricted preservation.
- Copy map: primary systems, replicas, exports, backups, and processors covered by the action.
- Evidence: execution logs, exception approvals, sampling results, and the date the action completed.
The final test is simple: can a new reviewer see why the record remained identifiable, when that reason ended, what happened to each important copy, and who can prove it? If the answer is only a policy paragraph or a single database timestamp, storage limitation has not yet become a working control.
References
- 1Regulation (EU) 2016/679, Article 5
data.europa.eu
- 2ICO, Principle (e): Storage limitation
ico.org.uk
- 3ICO, Anonymisation
ico.org.uk
- 4
- 5
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.