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 set the rule for each data category, align privacy notices and records of processing activities, handle erasure exceptions, and prove that systems and processors apply the rule.
Structured answer sets in this page tree.
Cited legal and guidance references.
Apply by recording, for each personal-data category, the purpose, legal basis, retention period or objective criterion, start event, expiry action, locations, owner, exceptions, and evidence. The GDPR does not supply one retention period for all personal data, so this artifact shows how to build and operate the schedule without inventing sector deadlines.
Article 5(1)(e) requires personal data to be kept in identifiable form no longer than necessary for the processing purpose. Start with a specific purpose and data category, then state the period or objective criterion, the event that starts the period, and the action at expiry.
A criterion such as 'while the account remains active, then for the applicable claims period' is more usable than 'keep as needed', but the actual claims period must come from the law that applies to that record and jurisdiction. Where longer storage is for archiving in the public interest, scientific or historical research, or statistical purposes, separate it from ordinary operational retention and record the Article 89(1) safeguards.
Deletion and anonymisation are different outcomes. Data is anonymous only when the person is no longer identifiable by means reasonably likely to be used, considering factors such as cost, time, and available technology. Pseudonymised data remains personal data and still needs a retention rule.
For controllers, Article 30 requires records of processing activities 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. A retention schedule can supply the erasure field and supporting detail, but it does not replace the rest of the RoPA.
Processor records under Article 30(2) have different required content and do not include the controller's envisaged erasure time limits. Controllers should put retention and deletion instructions in the Article 28 arrangement and verify that processors and sub-processors can apply them.
The exemption in Article 30(5) for an organisation employing fewer than 250 people is limited: it does not apply to processing that is likely to risk individuals' rights and freedoms, is not occasional, or includes Article 9 special-category data or Article 10 criminal-conviction and offence data. Even where the exemption applies, and other GDPR duties remain.
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 the rule. The schedule should be specific enough for a reviewer to understand the retention position.
Articles 13 and 14 require the controller to tell people the storage period or, when that is not possible, the criteria used to determine it. Article 15 requires the same type of information in an access response. The schedule, privacy notice, RoPA, processor instructions, and access-response material should therefore describe the same rule at the appropriate level of detail.
A schedule change can require more than an internal edit. If the controller plans further processing for another purpose, Articles 13(3) and 14(4) require information about that other purpose and the relevant further information before the further processing. The separate lawfulness and compatibility analysis still has to be completed.
Article 17 requires erasure without undue delay when one of its grounds applies: the data is no longer necessary for its purpose; consent is withdrawn and no other legal ground remains; an objection succeeds; processing was unlawful; Union or Member State law requires erasure; or the data was collected in relation to an Article 8(1) offer of information society services.
Article 17(3) exceptions are case-specific, not blanket excuses. Continued processing may be necessary for freedom of expression and information, a legal obligation or public task, specified public-health grounds, protected archiving or research, or legal claims. Record the provision relied on, why continued processing is necessary, the retained categories, permitted uses, access restrictions, and the event that ends the exception.
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 where necessary because of complexity and request numbers. EDPB access guidance says controllers should have measures that prevent short-lived data from being erased while an access request is being handled. That operational hold should be limited to the request and released when it no longer has a supported purpose.
Restriction is not erasure. When Article 18 applies, the controller generally stores the data but limits other processing to the grounds in Article 18(2). Article 19 requires the controller to communicate rectification, erasure, or restriction to each recipient unless this is impossible or involves disproportionate effort, and to identify those recipients to the data subject on request.
No. Article 5(1)(e) requires identifiable personal data to be kept no longer than necessary for its purpose, and Articles 13 to 15 require the period or criteria to be communicated in relevant notices and access responses. The actual period depends on the purpose, data category, applicable law, contracts, and documented necessity; Article 30 asks controllers to record envisaged erasure time limits where possible.
Not automatically. Personal data covered by a valid erasure ground must be erased without undue delay unless an Article 17(3) exception applies. A controller may keep a limited request record only when it has a legal basis and defined retention rule for that record. It should keep only what is necessary to show the request date, scope, decision, response, and recipient action without recreating the erased data.
No. Pseudonymised data remains personal data when the person can be identified using additional information. It still needs a purpose, legal basis, retention rule, security controls, and an expiry action. Data falls outside the GDPR only when it is anonymous under Recital 26's identifiability test.
Evidence should show that the retention rule is tied to the purpose, has an accountable owner, and operates across systems and processors. It should not preserve unnecessary personal-data copies merely to prove the data once existed.
Use the processing activity as the control point. When it changes, review the retention schedule, Article 30 entry, privacy notice, processor instructions, rights workflow, and deletion-test evidence 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 questions tied to cited sources 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"