ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
RoPA retention periods are among the most common weak points in a record of processing activities. Article 30(1)(f) of the GDPR asks controllers to record, where possible, the envisaged time limits for erasure of the different categories of data. In practice many records answer with “as long as necessary” or “per policy”, which tells a regulator nothing and suggests that nobody has decided how long the data should be kept.
This guide explains what Article 30 requires for retention, how to set defensible limits, how to link the record to a retention schedule and how to keep the entries accurate over time.
Article 30(1)(f) requires the controller’s record to contain, where possible, the envisaged time limits for erasure of the different categories of data. The words “where possible” matter: they acknowledge that for some processing an exact date cannot be given, for instance where the period depends on an event. They do not excuse leaving the field blank. You can read the article on the GDPR text site. Processors do not have to record retention in their own record under Article 30(2), but their contracts with controllers will normally set out deletion and return terms.
The requirement connects to the storage limitation principle in Article 5(1)(e): personal data must be kept in a form that permits identification for no longer than necessary for the purposes for which it is processed. The RoPA is where you show that the principle has been applied. Our overview of records of processing sets out the other fields.
A defensible period is tied to a purpose and a reason. Work through three questions for each category of data.
Then record the answer in a form a reader can test: a fixed period, or a fixed period from a defined trigger, plus the basis.
| Weak entry | Better entry |
|---|---|
| As long as necessary | 6 years after the end of the customer contract (limitation period for contract claims) |
| Per company policy | 12 months after the recruitment decision for unsuccessful candidates (retention schedule item 4.2) |
| Indefinite | Deleted on request or after 24 months of account inactivity |
| Not applicable | Deleted within 30 days of call-recording review, unless flagged for a complaint |
The figures above are illustrative. The correct period depends on your jurisdiction, sector and circumstances, so set your own with legal advice.
Many periods are set by law: tax and accounting records, employment and payroll records, health and safety records, anti-money-laundering records and sector rules. Cite the source in the record, for example the national tax code section or the employment regulation, so a reviewer can check it. Where several laws apply, use the longest that is genuinely applicable, but record why.
Some data may be kept to defend or bring legal claims. The limitation period for such claims varies by country and type of claim. Keep only the data relevant to the potential claim, not everything about the person, and put restricted access around it.
Operational needs can justify retention, but they need a reason that stands up. “We might use it one day” does not. A concrete need, such as warranty support for a stated period or fraud prevention for a set window, does. Where you rely on consent or legitimate interests, the period should reflect the expectations of the individuals; see our guide to the legitimate interests balancing test for how expectations are weighed.
The record should not be the only place retention lives. Keep a separate retention schedule listing record types, periods, triggers, legal sources and disposal methods, and reference it from the RoPA. Two benefits follow: the schedule can be maintained by records management and legal, while the RoPA stays readable, and changes to a period need to be made in one place. Where the RoPA field says “see schedule item 7”, the item must exist and match.
Make sure that systems can apply the schedule. A period that cannot be executed because the system has no deletion function is a gap to record and remediate, not an entry to hide. Note it in the risk assessment and plan a fix, such as a scheduled purge job or replacement of the tool. Our guide to the RoPA review process explains how such gaps are caught in reviews.
Free ROPA template and builder
Could you hand your records of processing to a regulator tomorrow?
Check whether Article 30 applies to you, add your processing activities from a library organized by department, complete every Article 30 content, and see which activities are missing a lawful basis, a transfer safeguard, a DPIA or an LIA. Free, with a record score and findings.
Some periods run from an event: end of the contract, closure of the account, termination of employment, end of the claim. State the trigger clearly, and confirm that your systems capture it. If the end of the relationship is not recorded, the clock never starts, and the data is kept for ever by default. Where a period is genuinely open, such as archives held in the public interest, record the safeguards and review interval instead of a date.
A retention period only means something if deletion happens. The record should indicate what happens at the end and who is responsible. Anonymisation can be an alternative to deletion if it is irreversible in practice, but it needs to meet the standard for anonymous data, not just removal of names. Backups are a common difficulty: data deleted from live systems may remain in backups until they rotate. Record the backup cycle, ensure deleted data is not restored into production without reapplying deletions, and keep backup periods proportionate.
The following is a hypothetical example invented for illustration. A training company reviews its RoPA and finds that nine of its twelve entries say “as long as necessary”. The privacy lead works with finance, HR and the learning team. For course bookings the team decides on seven years from the end of the tax year for invoices, and two years from course completion for attendance records used for certificates and complaints. For marketing subscribers, the period is until the person unsubscribes, plus a suppression record with the email address only.
They add the legal source to each line, reference the new retention schedule and set an owner for each purge. During the exercise they discover that old course feedback forms containing names are stored in a shared drive with no deletion process. They add a task to remove them and a quarterly purge date. The RoPA now gives a regulator specific, testable answers.
Each activity owner should confirm the RoPA retention periods for their data at every review, because they know how long the data is really used. The privacy team checks the reasoning and the legal source, and records management or IT confirms that deletion can be carried out. Where owners disagree with a proposed period, escalate the question to legal or the DPO so that the outcome is recorded, not left as a silent workaround. Clear ownership is the surest way to keep RoPA retention periods accurate.
Common problems include vague phrases, one period applied to every category, periods longer than any stated reason justifies, no legal source, no trigger, periods that do not match the privacy notice, systems that cannot delete, backups ignored, and no review after a change of law or process. Another is recording the period in the RoPA only, so that the actual owner of the data never sees it.
Individuals have a right to be told the retention period or the criteria used to set it. Your privacy notice, the RoPA and the retention schedule should therefore agree. Compare them whenever one changes. A mismatch between what you told people and what your records say is easy for a regulator to spot. If you carry out impact assessments, check that retention there matches too; our guide to DPIA residual risk shows how retention limits can lower risk.
A structured record with fields for period, trigger, legal source and disposal method makes the entries easier to write and to review. The RoPA Report and Workbook provides an Article 30 record layout you can adapt. Whichever template you use, keep the same fields for every activity so that retention can be compared across the organisation.
Article 30(1)(f) requires it where possible. That means you should record a period or, where none can be fixed, the criteria and safeguards that apply.
It is not enough on its own. Regulators expect a specific period or clear criteria that someone could test, along with a reason.
Article 30(2) does not require it in the processor’s record, but processors must follow deletion or return instructions in their contract with the controller.
Record the backup cycle and make sure deleted data is not restored into live systems. Keep backup retention proportionate and documented.
Review them in the regular RoPA review, and whenever a law, contract, system or purpose changes. Assign an owner to each period.
September 30, 2026
