What a GDPR data retention policy and retention schedule must cover
GDPR has no certificate, audit or attestation for retention, so the question a customer, contract or regulator is really asking is whether you set retention periods, wrote them down and enforce them. Under Article 5(1)(e), personal data may be kept in identifiable form only for as long as necessary for the purpose of the processing. The controller owns that judgment. The periods must then appear in the record of processing activities, where Article 30(1)(f) asks for the envisaged time limits for erasure of each category of data where possible, and in the privacy notice, where Articles 13(2)(a) and 14(2)(a) require the storage period or the criteria used to set it. A retention schedule is the working document that ties these together: one row per data category, the purpose, the period or trigger that starts the clock, the legal basis for any longer period, the system of record, and the owner who approves it.
The effort to produce this depends on how many data categories you hold, how many systems store each one, and how many copies exist in backups, logs, exports and test environments. Each row needs a decision that a lawyer or data protection lead must make, so the schedule is partly a legal exercise and partly a technical inventory. Your organization owns the schedule and the decisions. An implementation partner can prepare the system inventory, configure automated deletion or expiry where the platform supports it, and assemble the evidence, such as job logs and deletion reports. Ask any partner to confirm, in writing, which of your systems can actually enforce a period, which cannot, and what manual procedure covers the gap. Confirm your own legal retention duties with counsel before writing them into the schedule, since Article 17(3) exceptions and statutory retention periods may justify longer storage in specific cases.
What drives the cost of a retention schedule and deletion program
No price list or supplied figure exists for this work, so the cost depends on the written scope. The cards below cover the components buyers pay for: internal decision time, technical build work, and outside help, along with the factors that expand or shrink each one. Ask for a scope that names the systems, backup designs and processors in play before comparing any quotes.
Internal legal and data owner time
Someone accountable must set each retention period, name the legal duty behind any longer period, and sign off on the schedule. Legal, data owners and the DPO spend time here, and it recurs whenever a new processing activity or statute changes the answer. Ask who inside your organization owns each decision and how many categories of data the schedule must cover before you estimate this effort.
Number of systems holding personal data
Each system that stores personal data needs a deletion or expiry rule, a tested method to apply it, and a log showing it ran. The count of applications, databases, file shares and SaaS tenants is the largest driver of build effort. Ask the implementation partner to list every system in the record of processing activities and mark which ones can enforce deletion natively and which need custom jobs.
Backup architecture and expiry
Backups are where deletion programs most often fail, and the EDPB's 2025 coordinated enforcement action on the right to erasure identified deletion of personal data in backups as a recurring challenge. Cost rises when backups are full copies with long fixed retention, when restores are not tested against deletion, or when backup tooling cannot expire individual records. Ask how backup sets are scheduled, how long they persist and how a restored system will re-apply erasures.
Third-party processors and sub-processors
Retention in SaaS tools, analytics services, email platforms and managed hosting is set partly by contract, and each processor may keep data on its own schedule. Cost grows with the number of processors, the difficulty of obtaining deletion certificates and the need to align processor settings with your periods. Ask for a list of processors with their configurable retention options and the contractual deletion terms that apply to each.
Legacy and unstructured data
Old archives, spreadsheets, exported reports and mailboxes often have no owner, no index and no documented purpose, so finding and classifying them takes discovery work before any deletion starts. The effort depends on how much unstructured data exists and whether it can be tagged by source or date. Ask for a discovery phase in the scope with a stated output, such as an inventory of locations and a decision for each.
Automation and ongoing enforcement
A schedule that is written once and never run is a common audit finding. Deletion jobs, expiry policies, evidence logs and periodic reviews carry a recurring operating cost, while the initial build is one-time. Ask the quote to separate build work from run work, state who monitors job failures, and define how often periods are reviewed against the storage limitation principle in Article 5(1)(e).
How legal retention duties override erasure without open-ended keeping
Some personal data must be kept after its operational purpose ends, but only because a specific law or legal claim requires it, and only for a fixed period. Article 17(3) lists the exceptions to the right to erasure, including compliance with a legal obligation or public task, archiving and research, and the establishment, exercise or defence of legal claims. These exceptions let a controller refuse an erasure request or keep a category of data after its ordinary purpose has lapsed. They do not create a general permission to keep data indefinitely. For every category that you retain on one of these grounds, the retention schedule should name the duty or claim, the reason the data is needed for it, and the period it runs for, so that the exception can be defended to an authority.
Each retained category needs its own row in the schedule. Illustrative example: a payroll record kept because a national tax rule requires employers to retain wage records for a stated number of years should show the statute, the period it sets, the system holding the record and the date on which deletion is scheduled once that period ends. Customer contract data kept to defend a possible claim should record the limitation period that applies in the relevant jurisdiction and the trigger that starts it. Confirm each period with your legal counsel against the law in each country where you operate, because the periods differ by country and by data type, and a period cited from memory is a common audit finding.
Where no duty or claim justifies a category, the default is erasure or anonymisation at the end of its purpose, not retention until someone decides otherwise. Ask for a named owner to sign off each legal-basis entry, a review date for each one, and a list of the systems and backups where the category lives, so that the legal hold ends when the duty does. Assessors often find legal-duty labels attached to whole datasets with no fixed end date, and that pattern is harder to defend than a short, precise list of exceptions.
How to build and enforce a retention schedule step by step
This sequence turns the retention periods a controller has chosen into a schedule with owners, legal exceptions and system-level deletion, so each category of personal data has a documented end point that can be tested.
Inventory data categories from the record of processing
Start from the record of processing activities and list every category of personal data each activity holds, such as recruitment files, payroll, training records, badge and access data and prospect lists. The record is where the Article 30 time limits for erasure belong, where possible, so the schedule should reuse its activity names rather than invent a parallel list. The output is a draft schedule with one row per activity and data category, and the check is that every row in the record appears once and no system holding personal data is left out.
Assign a named owner to each entry
Give each row a business owner who answers for the purpose, and a technical owner who answers for the system where the data lives. The business owner decides whether the purpose still exists, while the technical owner confirms what the system can actually delete. Record both names in the schedule. The output is an owner column with no blank cells, and the check is that each owner has accepted the entry in writing.
Set a period or criteria for each purpose
For each entry, set either a fixed retention period or the criteria that end it, such as account closure, completion of a contract or the last interaction with a prospect. Article 5(1)(e) limits storage to what is necessary for the purpose, and Article 25(2) expects the storage period to be limited by default. Where a period is set, record the reason it is needed. The output is a schedule entry with a period or criteria, a stated purpose and a reason, and the check is that the privacy notice wording matches these entries.
Document legal retention duties and exceptions
Identify where a statute or regulator requires you to keep specific records, and note the source of each duty beside the entry. Keep these separate from business reasons so that the reason for holding data is traceable. Article 17(3) lists exceptions to erasure, including compliance with a legal obligation and the establishment, exercise or defence of legal claims, and any exception used should point to a specific duty rather than a general wish to keep data. The output is a legal basis column in the schedule, and the check is that counsel or the DPO has reviewed each cited duty.
Map systems, copies and backups to each entry
For each entry, list every system, export, log, archive and backup copy that holds the data, along with the vendor or processor that hosts it. Backup copies are where the EDPB's 2025 coordinated enforcement action found controllers struggling, so the map must show how long each backup generation persists and whether an individual record can be removed from it. The output is a system map that links each schedule entry to its locations, and the check is that no location is marked as unknown.
Configure deletion, expiry and backup rules
Implement the schedule in each system using the mechanism that system supports, such as scheduled deletion jobs, automatic expiry on records, lifecycle policies on storage or purge routines in the database. Where a system cannot delete individual records, document the compensating design, such as restoring from backups only with a re-deletion step. Anonymisation is not a substitute for deletion when the data remains identifiable, which the EDPB action also identified as a recurring problem. The output is a configuration record for each system, and the check is a change ticket or runbook that names the job and its owner.
Test deletion and record the results
Run controlled tests in a non-production copy and, where safe, in production: create sample records, let the rule run or trigger it, then check that the data is gone from the primary system, the logs and the backups within the design you documented. Record the test date, the scope, the result and any gap, and assign a fix for each gap. The output is a test record for each entry, and the check is that no entry is marked as deleted until its test has passed or its gap is accepted in writing.
Review the schedule on a set cycle
Set a review cycle for the schedule and trigger an earlier review when a new system is added, a purpose ends or a new legal duty appears. Each review confirms owners, periods, legal duties and the system map, and it reruns the deletion tests for changed systems. The output is a dated review record with the changes made, and the check is that the record of processing and the privacy notice reflect the updated schedule. Ask any outside adviser to show how their review cycle links to your change management process.
Why backups and deletion keep failing in audits
The EDPB's 2025 coordinated enforcement action on the right to erasure, covering 32 data protection authorities and 764 responding controllers and announced on 18 February 2026, found that controllers struggle with two things that a retention schedule is supposed to settle: deciding how long data may be kept, and actually deleting it. Two of the recurring problems matter most for this section. The first is deletion of personal data held in backups. The second is the use of anonymisation as a substitute for deletion, where data is altered so that it appears to be no longer personal but remains in place and can still be re-identified. Both failures usually trace back to design decisions made years earlier, not to a missing policy line.
Backup design determines whether erasure is possible at all. If a backup set mixes data from many retention periods, no single record can be removed without restoring and rewriting the whole set. Ask your backup owner to confirm three things in writing: how long each backup tier is kept, whether backups are grouped by retention class, and how a deleted record is prevented from reappearing after a restore. The usual answer is a documented expiry rule that ages backups out on a fixed cycle, combined with a restore procedure that re-applies pending erasures before users regain access. Regulators will look for that procedure, not for a promise that backups are eventually overwritten.
The evidence an assessor expects is concrete and repeatable. Keep the backup expiry rule, the schedule for each system, a log of erasure requests applied after restores, and test records showing that a restored environment was checked against the erasure register. Where a team argues that data is anonymised, it should hold the anonymisation method, a reasoned assessment of re-identification risk, and proof that the process holds over time. Treat every exception as a decision to record, with its legal basis and an end date. An illustrative example: a restore of a customer database from a backup taken before a deletion request should trigger a documented re-deletion step, and the log of that step is what an auditor will ask to see.
Who owns the schedule, who configures systems, and who assesses it
The organization is the controller, so it owns the retention schedule and the decisions behind each period. Legal and the data owners set the purpose, the legal retention duties that apply, and the criteria for ending retention. The data protection officer, where one is designated, advises on the schedule and checks that it matches the record of processing and privacy notices. IT confirms what systems actually hold, how long backups persist, and who can approve exceptions.
- Legal and compliance: Identify statutory retention duties, such as tax or employment record rules, and document the basis for each period.
- Data owners: Set the period for each category of data in their processing activities and state the trigger that starts the clock.
- Data protection officer: Review the schedule against Article 5(1)(e) and the time limits recorded under Article 30(1)(f).
- IT and system owners: Confirm which stores, logs and backups hold each category of data and report any gaps.
- Sign-off: Record who approved each period, when, and when it will next be reviewed.
Check that every data category in the schedule has a named owner and an approval record.
An implementation partner can map where personal data sits across self-hosted platforms, configure automated deletion and archiving jobs, and produce the logs that show those jobs ran. The partner works from the schedule the controller has approved and does not choose the retention periods. Its deliverables are configuration, documentation and evidence, which the controller then reviews and owns.
- System mapping: Trace each data category to databases, object stores, search indexes, queues, logs and backup sets inside the client's infrastructure.
- Deletion configuration: Set retention jobs, lifecycle rules and purge procedures that implement the approved periods.
- Backup design: Define backup retention and expiry so that erased data does not persist beyond the documented window, and document any restore-time handling.
- Evidence production: Capture job logs, configuration exports and test deletion results that the controller can present to an assessor.
- Handover: Deliver runbooks and a documented scope so the internal team can operate and audit the setup.
Ask for the written scope, the list of systems in it, and who signs off the configuration before work starts.
The GDPR requires no audit, attestation or certificate. Supervisory authorities enforce the regulation and can investigate retention practices on complaint or on their own initiative. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's responsibility. Some organizations also commission an independent auditor to test retention as part of wider assurance work, but that report is a voluntary input, not a GDPR requirement.
- Supervisory authority: Can ask for the schedule, the record of processing, deletion logs and the reasoning behind each period.
- Independent auditor: Tests the schedule and deletion evidence against the controller's own stated periods, and issues its own report.
- Certification body: Issues an Article 42 certificate only where a scheme exists and the body is accredited.
- Partner limits: No implementation partner issues reports, attestations or certificates, and none of them can stand in for the controller's accountability.
- Evidence trail: Keep documentation ready for any of these parties, so they can test the claims the organization makes.
Confirm with your legal team which regulator is competent for your establishment and whether any voluntary assurance you commission will be shared externally.
What must exist before a regulator or customer reviews your retention
A regulator or customer reviewing retention will test whether the stated periods match what systems actually hold. The cards below are the artifacts that must exist and agree with each other, and each one includes a way to verify it before the review starts.
Current record of processing with time limits
The Article 30 record must list envisaged time limits for erasure for each category of data, where possible. Check that every activity in the record has a period or a stated criterion, that the owner signed off on it, and that its date is later than the last system change. A record without periods is the first gap an assessor finds.
Privacy notices stating storage periods
Articles 13(2)(a) and 14(2)(a) require notices to state the storage period or the criteria used to set it. Compare each published notice with the approved schedule. Any period in the notice that the systems do not enforce is a transparency problem that will surface in a complaint or customer audit.
Approved retention schedule with owners
The schedule should list each data category, its period or trigger event, the legal basis for keeping it, and a named owner who approves changes. Confirm that the schedule was approved by an accountable person, that it covers legal retention duties separately from erasure, and that exceptions under Article 17(3), such as legal claims, are written down with the reason.
System inventory mapped to periods
Every system holding personal data needs an entry showing which schedule lines apply, where the data sits, and what job or setting removes it. Verify this by picking three categories from the schedule and tracing them into production, analytics, email, logs and vendor tools. Any copy without a mapped period is a deletion gap.
Backup retention settings
Backups are where erasure most often fails. Document the backup retention period, the rotation method and how a restored system is re-checked for records that should already be gone. Confirm with the backup platform owner that the settings in the configuration match this document, and that restores run deletion checks before data returns to live use.
Deletion and anonymisation logs
Logs should show when records were deleted, which job or person ran the deletion, which schedule line applied and whether the action covered backups. Ask for a sample of logs from the last review period and confirm that anonymised data is not being presented as deleted, since the EDPB's 2025 erasure action found ineffective anonymisation used instead of deletion.
Retention policy questions buyers ask before hiring outside help
How much effort does a GDPR retention schedule take to build?
The effort depends mainly on how many systems hold personal data and how well those systems are documented today. The work has three parts: listing each category of personal data and where it lives, deciding a storage period or the criteria used to set one for each category, and recording the legal basis for any retention longer than the business purpose needs. Organizations with a current record of processing activities usually start further ahead than those without one, because Article 30(1)(f) already asks for envisaged erasure time limits where possible. Ask any partner to show how it will divide the inventory, the legal review and the technical deletion work, and which of those steps depend on your staff's time.
Can our team write and enforce a retention policy without outside help?
Yes, many organizations do. The policy itself is an internal document, and no regulator certifies it. The harder part is enforcement: deleting data in production databases, file stores, SaaS tools and backups on a schedule, and proving that deletion happened. Teams that lack engineers who can write deletion jobs, or lawyers who can confirm statutory retention duties in each EU country where they operate, often bring in help for those specific gaps. A fixed-scope engagement can cover only the systems you name, so define in writing which platforms, data categories and jurisdictions are included.
How long does it take to set and enforce retention periods?
The duration depends on scope: the number of systems, the number of data categories, how much of the deletion logic must be built, and how many internal approvals the schedule needs. A small organization with a single HR system and a short list of categories has a very different workload from a group running dozens of platforms across several countries. Agree on milestones in writing before work starts, and ask any partner to state which items depend on your legal, HR and engineering teams so you can plan their availability.
What does the work need from our staff?
The work needs named owners from several functions. Business owners must state why each category of data is kept and for how long. Legal or privacy staff must confirm where a statute requires keeping records and must sign off on exceptions under Article 17(3), such as legal claims. Engineers must identify where data is stored, which fields can be deleted or anonymised, and how backups are restored. Ask for a clear list of decisions each owner must make and the date each is needed, because most delays come from unanswered approval questions rather than technical complexity.
Do backups have to be purged immediately after an erasure request?
The GDPR does not set a specific purge time for backups in the text of the regulation, and the EDPB's 2025 coordinated enforcement action on the right to erasure found controllers struggling to delete personal data held in backups. The practical expectation is that backup design should make deletion and restoration both workable. Document the backup retention period, how erased records are excluded if a backup is restored, and how the controller will re-apply deletions after a restore. Confirm your approach with your data protection officer or supervisory authority guidance rather than assuming a single standard.
Can an implementation partner decide our retention periods for us?
No. The controller must decide the purposes of processing and the periods for keeping personal data, and that responsibility cannot be transferred. An implementation partner can prepare the inventory, draft options, configure deletion jobs, test them and document the evidence. An independent auditor or certification body can test the result, but it does not issue a GDPR certificate for your retention decisions. The organization remains accountable for any retention period it chooses and for explaining it to a supervisory authority.
What should a partner not do on our behalf?
A partner should not sign off legal retention decisions, approve exceptions to erasure, or certify compliance on your behalf. It also should not replace your data protection officer where one is required, or treat anonymisation as a substitute for deletion without a documented assessment. Ask any partner to confirm in writing which decisions stay with your staff, which evidence it will produce for your records, and which items require an independent assessor or legal advice from your own counsel.
How DeployOpen scopes retention work and prepares the evidence
DeployOpen plans and implements retention and deletion configuration inside the self-hosted open-source platforms that hold the client's personal data, and it prepares the evidence an assessor or supervisory authority would ask to see. Work starts from a written, fixed scope that names the systems in question, the data categories each one holds, the retention periods the controller has approved, and the deletion mechanisms that will be configured, tested and documented. Typical items in that scope include scheduled purge jobs, lifecycle rules on object storage, database retention settings, log rotation, and the backup rotation and expiry settings that determine how long copies survive. Each item is tied to a line in the retention schedule so the reader can trace a stated period to a working control.
The controller keeps ownership of the retention schedule. DeployOpen does not decide how long data should be kept, does not interpret legal retention duties, and does not guarantee that any assessment, regulator or data subject will accept the outcome. Those decisions sit with the controller, usually with its data protection officer or legal counsel where one is appointed. DeployOpen does not issue audit reports, attestations or certificates. An independent auditor, assessor or certification body would have to make any such determination. Ask any provider to confirm this division of responsibility in writing before work begins, and ask who signs off each approved period.
At handover, the client receives the configuration of each system as deployed, the test records showing that scheduled deletion ran against sample data and that expired backup copies were removed, and a mapping from each schedule entry to its technical control. The package also includes the operating runbook, the change history for retention settings and a list of open items where a period could not yet be enforced, such as a system that cannot delete individual records. Those open items are the ones to resolve first, because the 2025 EDPB coordinated action on the right to erasure found that retention and backup deletion were among the recurring weaknesses. Confirm the exact handover format, test method and acceptance criteria in the written scope.
