A GDPR retention schedule should identify each personal-data category, why it is kept, when it is erased or anonymised, and how erasure requests are handled without inventing one-size-fits-all retention periods.
Use it to connect storage limitation, Article 17 erasure, Article 19 recipient notices, and Article 30 records of processing activities.
Structured answer sets in this page tree.
Cited legal and guidance references.
This artifact turns GDPR retention and erasure obligations into a schedule structure. It does not assign sector retention periods. Instead, it shows the fields and checks needed to justify how long personal data stays identifiable, when erasure is due, when an Article 17 exception may preserve processing, and what evidence should be retained for accountability.
Article 5(1)(e) requires personal data to be kept in identifiable form no longer than necessary for the processing purpose. A useful schedule therefore starts with the purpose and data category, then states the erasure or anonymisation trigger for that category.
Where a longer period is needed for archiving in the public interest, scientific or historical research, or statistical purposes, the schedule should separate that longer-use scenario from ordinary operational retention and identify the safeguards relied on under the GDPR.
Article 30 requires controller records to include purposes, categories of data subjects and personal data, recipients, transfers where applicable, envisaged erasure time limits where possible, and a general description of security measures. Those fields are the minimum structure for a retention schedule that also supports a RoPA.
The Irish Data Protection Commission guidance warns against vague RoPA references such as pointing to an unavailable retention policy or saying data is kept under a policy without stating what the retention rule actually is. The schedule should be self-contained enough for an external reviewer to understand the retention position.
Article 17 requires erasure without undue delay where one of its grounds applies, including where the data is no longer necessary for the original purpose, consent is withdrawn with no other legal ground, the data subject successfully objects, the data was unlawfully processed, erasure is required by Union or Member State law, or the data was collected from a child in relation to information society services.
The schedule should also preserve the Article 17(3) exceptions as decision fields, not as blanket excuses. If continued processing is necessary for a legal obligation, public-interest task, public-health reason, protected archiving or research purpose, or legal claims, record the exact basis, the data categories retained, and the restricted use that remains allowed.
Article 12 requires controllers to provide information on action taken on Articles 15 to 22 requests without undue delay and in any event within one month, with a possible two-month extension for complexity or number of requests. The retention schedule should therefore flag data categories with very short retention windows so rights teams can preserve enough data to handle a request received before routine erasure completes.
Article 19 also requires communication of rectification, erasure, or restriction to recipients unless impossible or involving disproportionate effort. A retention schedule should identify recipient categories and processors so the rights team can decide who must be notified after an erasure action.
No. The GDPR uses storage limitation and requires data to be kept no longer than necessary for the processing purpose. Article 30 also asks for envisaged erasure time limits where possible, but the specific period depends on the purpose, data category, and a documented source outside this generic schedule.
Not automatically. The personal data covered by a valid erasure ground should be erased without undue delay, but the team may keep a minimal accountability record showing the request date, scope, decision, response, recipient notifications, and the lawful reason for any data category that was not erased.
The evidence record should prove that the retention rule exists, is tied to the processing purpose, has an accountable owner, and is implemented in systems and processors. It should not preserve unnecessary copies of personal data simply to show that personal data once existed.
Use the RoPA as the control point: if a processing activity changes, the retention schedule, Article 30 entry, processor instructions, rights workflow, and deletion test evidence should be reviewed together.
Sorena can help map processing activities to retention triggers, Article 17 decision records, recipient notifications, and evidence needed to show that deletion controls work.
Ask source-linked questions about storage limitation, Article 17 erasure, Article 30 RoPA fields, and evidence records using the cited sources on this page.
Review your retention schedule fields, erasure workflow, and evidence gaps with Sorena.
"living, dynamic, document"
"able to demonstrate compliance"