Retention schedule design: what the decision maker looks at
A retention schedule sets out how long each category of personal and business data is kept, who approves exceptions, and when deletion becomes mandatory rather than optional. The decision maker reviews the underlying processing purpose, the retention trigger tied to that purpose, and the point at which continued storage stops being justified. Design work starts with an inventory, not a deadline.
What the schedule changes in practice
Before a schedule exists, deletion is discretionary. Someone decides, case by case, whether a folder, a mailbox, or a database table can be cleared. That approach works while volumes are small and staff turnover is low. It stops working once the organisation has several data categories, several storage systems, and more than one person who can authorise disposal.
Once a schedule exists, deletion becomes a routine event tied to a trigger rather than a judgement call. The trigger might be the end of a contract, the closure of an employment relationship, or the expiry of a statutory limitation period relevant to a specific claim. The practical effect is that storage cost and legal exposure both fall, because data is no longer held past the point where holding it serves any purpose.
The same logic applies to data used to train or operate an AI system, though the operational detail there differs enough that it sits on a separate track within the same programme.
Steps in practice
- Inventory. The data owner compiles a register of every data category currently held, listing source, format, and storage location, including backups.
- Assign a trigger. The compliance lead attaches a retention trigger to each category — contract end, relationship closure, or a fixed statutory period.
- Draft the matrix. The compliance lead builds the schedule as a table: category, trigger, retention period, disposal method, and the person who authorises disposal.
- Confirm technical enforceability. The IT security lead checks that disposal can actually be executed across all systems that hold the category, not only the primary database. Where a third-party platform holds part of the data, disposal has to be coordinated with the vendor exit plan; see How exit and transition planning technology contract what the for how that coordination is typically sequenced.
- Approve and set a review date. The person with sign-off authority — usually the data protection lead or an equivalent decision maker — adopts the schedule and fixes a date for its next review.
- Deploy and monitor. The records team applies the schedule going forward, and internal audit samples compliance at each review cycle.
Who decides and when
| Decision point | Who decides | Typical timing |
|---|---|---|
| Adoption of the schedule | Data protection lead or board delegate | Once the matrix is drafted and technically checked |
| Exceptions and litigation holds | Legal counsel handling the matter | Ad hoc, as soon as a hold trigger arises |
| Disposal execution | IT operations, on instruction from records team | At the trigger date set in the schedule |
| Periodic review | Data protection lead, with input from business owners | Fixed interval set at adoption, typically annual |
Common branches
If the data set was acquired through a corporate transaction, retention design has to account for how the underlying rights moved with it. Where the transaction included an assignment of intellectual property alongside the data, map the schedule to the same continuity logic used in Assignment and novation, so obligations attached to the data do not get treated as if they started fresh.
If a former employee's departure has become linked to a dispute over who invented something, personnel records connected to that period may need to be held past the ordinary trigger. The approach set out in When an ex-employee appears as an inventor elsewhere: when describes how that kind of hold is usually assessed before any deletion decision is made.
If part of the data set is tied to a token issuance, disposal timing has to respect how the underlying ledger entries are structured, since some entries cannot be unwound the way a database row can. Where that applies, the boundary is described in Secondary market arrangement token issuance what the decision maker.
What this page does not cover
This page describes the sequence an organisation follows to design and adopt a retention schedule. It does not set a specific retention period for a specific data category in a specific jurisdiction, and it does not resolve a dispute about whether a hold should apply to a particular record. Those questions depend on facts the decision maker has to review case by case, with input from whoever holds legal responsibility for the category in question.
Verified
Reviewed: November 2025. This page describes an internal procedural sequence. It does not cite statutory provisions, because retention schedule design as a process is not fixed by a single national act; the trigger for any given category depends on the underlying obligation attached to that category, which is assessed separately.
Related reading
For the equivalent process applied to AI systems rather than general data holdings, see How AI obligation mapping data protection what the decision.
Frequently asked questions
How long does retention schedule design take in practice?
For a single business unit with a modest number of data categories, the inventory and drafting stages typically take a few weeks. Timing extends when data is spread across several systems or several jurisdictions, since each system needs its own technical check before the schedule can be adopted.
Which documents are needed to start?
Start with an existing data map or asset register if one exists, a list of active contracts that reference data handling, and a list of storage systems, including backups and any third-party platforms. Without these, the inventory stage has to be built from scratch, which extends the timeline.
What happens if the vendor or counterparty does not respond during the disposal step?
Where disposal depends on a third party — a SaaS provider, a processor, or a counterparty holding a copy of the data — the schedule should include an escalation point and a fallback date. If the third party does not confirm disposal by that date, the matter typically moves to whoever manages the underlying contract, so the delay is tracked rather than left open.