Article 5(1)(e) storage limitation: requirements and evidence

What Article 5(1)(e) storage limitation asks systems to do

Article 5(1)(e) asks you to keep personal data in identifiable form only for as long as the purpose of the processing requires. For a compliance lead or engineer, that means you must be able to show, for each data set, when it stops being needed and what happens to it then. The duty is not limited to the primary application database. It reaches file stores, exports, search indexes, application and audit logs, analytics copies and backups. If a record is still identifiable in any of these places beyond its justified period, the principle is engaged, even when the live system has already cleaned up. The exception for archiving, research and statistics under Article 89(1) is narrow and still depends on appropriate technical and organisational measures, so you should not assume it covers general retention.

The difficulty is practical. Many organizations have no written retention period for some categories of data, or have periods that are set in a policy but never mapped to tables, buckets or log sources. Data about the same person often sits in several systems, each with its own clock. Backups are the hardest case: most backup products restore whole sets or snapshots, and deleting one person's record from an existing backup is not a simple operation. The EDPB's 2025 coordinated enforcement action on the right to erasure, with findings announced on 18 February 2026, reported that controllers were struggling to determine retention periods and to delete personal data held in backups. Your task is to confirm which of these gaps applies to your environment before an assessor or supervisory authority asks.

No certificate covers this. The GDPR requires no audit, attestation or certification, and Article 42 certification, if you hold it, does not reduce your responsibility. The controller must therefore demonstrate enforcement itself, using retention schedules, deletion job logs, backup policies and restore tests as evidence. Start by asking each system owner for the retention rule, the job that enforces it, and the last time that job ran successfully. Confirm with your backup vendor how single-record deletion or expiry works in your setup, and document the answer even if the answer is that a backup must age out before data is gone.

Which systems, copies and teams fall under storage limitation

Article 5(1)(e) applies to every copy of personal data, not only the production database. The cards below cover the places personal data quietly accumulates, the teams that must agree on retention for each, and the third parties that hold copies on the organization's behalf.

Production databases and business records

Primary application databases are where retention periods are most often defined but not enforced. Each table or collection holding personal data needs a named owner, a documented purpose and a retention period that can be traced to the record of processing activities. Check whether closed accounts, expired contracts and inactive customers are purged by a scheduled job or only flagged as inactive, since a flag does not limit storage.

Object and file storage

Uploaded documents, exports, scanned forms and attachments often sit in buckets or shared file systems with no lifecycle rules. Files are commonly copied out of the application into these stores and forgotten. Confirm which buckets contain personal data, whether lifecycle or expiry rules exist, and whether deleting a record in the application also removes the linked objects.

Application and audit logs

Logs record user identifiers, IP addresses and request payloads, and they are rarely scoped in retention reviews. Audit trails may need to be kept for security or accountability, which justifies a defined period but not an open-ended one. Verify the log level that captures personal data, where logs are written, and how long each log stream is retained. For example, Nextcloud's admin_audit app writes to audit.log in the data directory unless a different path is set with logfile_audit, so that file needs its own retention rule.

Backups and archives

Backups are the copy most likely to hold data after its purpose has ended, because they are retained for recovery rather than for the business purpose. Decide how backup retention is set, how a deleted record is handled in older snapshots, and whether restores can re-expose deleted data. The EDPB's 2025 coordinated enforcement action on erasure found controllers struggling with personal data held in backups, so document the approach before an auditor or regulator asks.

Analytics, staging and test copies

Analytics warehouses, staging environments and test datasets are often refreshed from production and then left to accumulate. Each refresh creates a new copy with its own retention clock. Ask whether personal data is masked, pseudonymized or excluded before copying, who approves refreshes, and whether non-production copies are deleted on a schedule. Article 25(2) expects only the data necessary for each purpose to be processed, including for storage period.

Processor-held copies and third parties

Hosting providers, backup vendors, managed support providers and sub-processors may keep copies that the controller's own deletion jobs never reach. Review each processing agreement for retention and return or deletion obligations at the end of the service, and ask providers to confirm how long backup copies persist after deletion. Processor data is part of the controller's storage limitation picture even when another company runs the infrastructure.

Teams that own retention decisions

Storage limitation fails when no one owns the decision. Data owners set purposes and retention periods, legal confirms legal retention duties and the criteria for setting them, platform engineering implements deletion and backup rules, and security reviews logging and access to retained data. Assign a single accountable owner for each category of data and record who signed off each period.

Article 89(1) archiving and research exceptions

Article 5(1)(e) allows longer storage only for archiving in the public interest, scientific or historical research, or statistical purposes under Article 89(1), and only with appropriate technical and organizational measures. Retaining data for these purposes is not a general reason to keep it. Confirm with legal whether any dataset actually qualifies, then document its separate safeguards such as pseudonymization, access restriction and a stated review date. Treat ordinary business or convenience retention as outside this route.

How retention periods get set and written down

Storage limitation cannot be tested until each category of personal data has a stated retention period or a documented criterion for setting one. Article 30(1)(f) asks the record of processing activities to state the envisaged time limits for erasure of the different data categories where possible, and Articles 13(2)(a) and 14(2)(a) require privacy notices to state the storage period or the criteria used to determine it. An assessor will compare these three places against each other and against the systems. If the record says seven years, the notice says "as long as necessary" and the CRM deletes nothing, the gap is visible on day one. Before any system work starts, the controller should confirm that every processing purpose has a row in the record with a period or criterion, and that the privacy notice wording matches it.

Article 25(2) adds a design duty. By default, only the personal data necessary for each specific purpose may be processed, and that necessity extends to how long data is stored. In practice this means a retention period should be a default setting in the system, not an optional clean-up task. A retention schedule is a document the controller owns and approves, usually with legal, privacy and business input. It is not an IT artifact. Each line of the schedule should name a single accountable system owner who can implement the period, run or approve the deletion job, and report on it. Without a named owner, the schedule describes intent but nothing enforces it. Ask the owner to confirm, in writing, which fields, tables, buckets and backup sets their system holds for each category, because that inventory is what deletion jobs and backup policies must be built from.

How an assessor tests storage limitation in systems

This table lists the test steps an assessor typically performs on Article 5(1)(e), the evidence each step requests, and the findings that most often come up. Read it as a checklist for your own readiness review, working from the retention schedule outward to the systems that hold the data.

Test step	Evidence requested	Common findings
Compare the retention schedule with the record of processing	Retention schedule, record of processing activities, privacy notices showing storage periods or criteria	Retention periods missing for some categories, or periods in the schedule that do not match the record of processing
Sample data stores for records older than their period	Read-only queries or reports against production databases, file stores and SaaS tools, with record dates	Records held well beyond the defined period in systems nobody listed as in scope
Inspect deletion job configuration	Job definitions, schedules, filters, owner assignments and change history	Jobs that filter on the wrong date field, or deletion logic that skips related tables and copies
Review deletion job run history	Run logs, alerting configuration and records of failed or skipped runs	Jobs that fail silently, with no alert and no one reviewing the log
Check log retention settings	Log retention configuration for application, audit and infrastructure logs, with the defined period for each	Logs kept indefinitely by default, or personal data in logs with no defined period
Check backup retention and expiry	Backup policy, retention rules and expiry settings, and the process for removing data from older backups	Backups with no expiry, or no documented rule for how personal data is handled when restored
Review exceptions and legal holds	Register of exceptions, legal hold approvals with reasons and end dates, and reviews of open holds	Holds that never end, exceptions approved without a stated reason, or no periodic review
Walk through one record's lifecycle	A selected sample record traced from creation through storage, use, archive, deletion and any backup copies	The record cannot be found in all copies, or its deletion is not recorded anywhere

Sequence to make retention rules enforceable

This sequence turns the Article 5(1)(e) principle into a schedule that systems follow, from the first inventory of stores through recurring review. Each step produces a record that a controller can show to an assessor or supervisory authority. The order matters because later steps depend on the categories and criteria set earlier.

Inventory data categories and storage locations
The privacy or data owner lists each category of personal data and every store that holds it, including production databases, file shares, object storage, analytics copies, exports, logs and backups. Engineering confirms the list against infrastructure inventories and identifies which stores hold identifiable data. The step closes when the inventory is linked to the record of processing activities and an owner is named for each store.
Set and approve retention periods with stated criteria
For each category, the controller sets a retention period tied to the processing purpose, or documents the criteria used where a fixed period is not practical, as Article 30 and the privacy notice rules expect. Legal, compliance and the business owner review the proposed periods, and the approver signs the schedule. The output is an approved retention schedule with a rationale column that states the purpose, the basis for the period and any legal hold or statutory exception.
Map each period to an owner and mechanism
Each retention rule is assigned a system owner and one mechanism: deletion, anonymization or aggregation. Deletion removes records, anonymization removes identifiability, and aggregation keeps only statistical results. The mapping shows how each store will meet its period and where a mechanism cannot yet be applied. The output is a control register that ties every schedule line to a store, an owner and a method.
Build and test deletion jobs
Engineers implement scheduled jobs that apply the mapped mechanism, with selection logic that matches the schedule and tests run first against a non-production copy. Reviewers confirm that the job removes or anonymizes the intended records, does not touch records under legal hold, and logs what it did without writing identifiers into the log. The step closes with tested jobs and retained run logs that show record counts and outcomes for each run.
Align log and backup retention with the schedule
Application logs, audit logs, and backup sets are assigned retention settings that match the schedule and are configured in the systems themselves, not only in policy text. For backups, the team documents how an erased record is handled, including when it persists in backup sets until they expire and what restore procedures must not reintroduce it. The output is a documented backup expiry policy and configuration evidence for log and backup tools, which the team should confirm against each product's current documentation.
Run a first verification cycle
Before the schedule is treated as operating, an independent reviewer samples records in each store and checks that data past its period has been removed, anonymized or aggregated, and that exceptions are recorded with reasons. Findings are logged with owners and fixed or accepted by the approver. The output is a dated verification report with sample results, exceptions and remediation actions, which supports the evidence an assessor will ask for.
Set a recurring review
The schedule, control register and job list are reviewed on a fixed cycle that the controller sets, and also after new processing, new stores or a change in legal requirements. Each review repeats sampling, checks job run logs for failures and confirms that backup expiry still matches the policy. The step closes when the review record, approved changes and updated schedule are filed with the accountability documentation.

Evidence that shows retention rules are enforced

A retention rule only counts when a regulator can trace it from a written decision to a running system and back. The artifacts below form that chain, and each one covers a different gap, so an assessor who sees only one of them will still have questions about the others.

Approved retention schedule with owners

The schedule lists each category of personal data, the period it is kept, the trigger that starts the clock (for example, end of contract or last customer activity), the legal or business criteria behind the period, and a named owner accountable for it. Approval should be recorded by someone with authority over the processing. Review it on a set cadence and whenever a new system or purpose appears, and keep each version with its approval date so you can show which rule applied at a given time. Check that the owner can explain every period without relying on a default.

Record of processing with time limits

Where possible, the record of processing activities must state the envisaged time limits for erasure of each data category, and privacy notices must state the storage period or the criteria used to set it. These entries should match the retention schedule exactly. Mismatches between the record, the notice and the live system are a common finding. Update the record through change tickets whenever a processing activity or system changes, and compare it with the schedule during each periodic review.

Deletion job definitions and run logs

Deletion jobs are the mechanism that turns the schedule into action. Keep the job definitions under version control, with the data store, selection criteria, schedule and owner for each job. Run logs should show when each job ran, how many records it selected and removed, and any errors or skipped records. An assessor will look for gaps, such as a job that stopped running months ago without anyone noticing. Set alerts for failed or missed runs and record how each failure was resolved.

Sample-based deletion test results

Run scheduled tests that pick records past their retention period, confirm they are gone from the primary store, search indexes, caches and exports, and record the result. Logs show that a job ran, but only a test shows that the data is actually gone. Keep the sample method, the population tested, the records checked and any exceptions in a dated test report. Repeat the tests between audits, and link each failed test to a change ticket and a retest.

Backup and log retention configuration

Backups and logs often hold personal data long after the primary record is deleted, and the EDPB's 2025 coordinated enforcement action on erasure found controllers struggling to delete data held in backups. Document the retention and expiry settings for each backup set and log source, such as Bareos job retention or the audit.log retention in Nextcloud. Keep configuration exports and evidence that expired backups were removed, and state how a deleted record is handled if it exists in a backup that has not yet expired.

Exception and legal hold records

Some data must be kept longer than the schedule allows, such as data under a legal hold, a regulatory retention duty or an approved research exception. Each exception needs a recorded reason, the approver, the scope, the review date and the date it ends. Include the Article 89(1) archiving or research basis where it applies. Without this record, extended retention looks like a failure to enforce the rule. Review open exceptions at each cycle and close those that no longer apply.

Self-hosted open-source tools that produce retention evidence

Bareos is an open-source backup system licensed under AGPL-3.0-only. Its Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of the files it has backed up. That catalog is the starting point for retention evidence, because it records which copies exist and lets you show when each copy was made and when it is due to expire.

Catalog as an inventory: The catalog lets you answer which backup copies contain a given category of personal data and how long those copies have been held.
Restore by point in time: Bareos can restore files from the current backup or from one taken before a given date and time, which helps show what a restore would bring back from an older copy.
Verify and archive jobs: Verify jobs and archive jobs are scheduled and logged by the Director, giving you job records that can be exported for review.
Expiry and pruning settings: Retention periods for volumes and jobs are set in the Bareos configuration. Confirm the exact expiry and pruning settings in your own client environment before you cite them.

Before relying on Bareos for evidence, confirm that job retention, file retention and volume recycling match the periods in your retention schedule, and test that expired copies are actually pruned.

What meeting storage limitation costs in money and effort

This table compares the main cost components of enforcing Article 5(1)(e) in systems, who typically pays for each, whether it is one-time or recurring, and what moves it up or down. Use it to scope internal work and to frame what to ask for in a written quote, since no supplied figures exist for any of these items. The main takeaway is that backups and logs usually drive the largest share of effort, so schedule and scope them early.

Component	Who pays and what they do	One-time or recurring	What drives it up	How to keep it down
Retention analysis and schedule approval	Legal, DPO and data owners set retention periods per data category and purpose	One-time, with periodic review	Many purposes, unclear legal bases, data flowing between systems without documented owners	Start from the record of processing activities, reuse existing categories, and limit the number of distinct periods
Deletion and anonymization engineering per system	Internal engineers or an implementation partner build deletion jobs or anonymization routines for each store	One-time per system, plus changes when schemas change	Number of systems holding personal data, tightly coupled schemas, data copied into analytics or search indexes	Reduce the number of stores holding personal data, use self-hosted open-source platforms with documented retention settings, and standardize a deletion pattern
Backup and log retention redesign	Platform and security teams reconfigure backup catalogs, retention policies and audit logs, often with a backup administrator	One-time redesign, often the largest item, then recurring operation	Long backup chains, restore points kept for purposes unrelated to retention, personal data inside logs, immutable or archival storage	Separate short-lived operational logs from long-term audit records, minimize personal data in logs, and set backup retention that matches the schedule
Ongoing job monitoring and exception handling	Operations staff monitor deletion and backup jobs, investigate failures and handle legal holds or exceptions	Recurring	Frequent job failures, manual exception requests, many legal holds, unclear ownership of alerts	Alert on failed jobs, document exception criteria in advance, and assign a named owner for each retention job
Periodic evidence testing	Internal compliance or an assessor samples systems to confirm retention rules run as designed and records of deletion exist	Recurring, at a cadence set by the organization	Number of systems in scope, missing deletion logs, backups that cannot be checked for specific records	Keep machine-readable job logs, test restores and sample deletions on a fixed schedule, and automate the evidence where the tooling allows
External review or testing	Independent reviewers or testers, if the organization chooses to buy them; no external review is required by the GDPR	Optional, one-time or periodic	Scope size, number of systems, need for technical testing of deletion in backups	Define scope in writing, limit it to the highest-risk stores first, and ask for a fixed-scope quote that lists deliverables

Who owns retention, who can help, and where the auditor stops

Your organization is the controller, so it owns the decision about how long each category of personal data may be kept. That decision sits with the business owner of each processing purpose, is reviewed by privacy and legal staff, and is recorded in a retention schedule. Article 5(1)(e) ties storage to the purpose, so the team must be able to say why a period is necessary and when the purpose ends. Exceptions, such as legal holds or statutory archiving, also need a named approver and an end date.

Retention schedule: Periods or criteria per data category, system and purpose, aligned with the record of processing activities.
Approvals: Named sign-off from the business owner and the privacy function before any period changes.
Exceptions: Documented legal holds and archiving decisions, each with a review date.
Privacy notices: Storage periods or the criteria used to set them, kept consistent with the schedule.
Enforcement owner: A person accountable for confirming that deletion jobs, backup expiry and log rotation match the schedule.

Confirm with your legal counsel which statutory retention duties in your sector override the GDPR periods, since those rules are outside this page.

Where backups and logs quietly defeat retention

Most storage limitation failures do not come from a missing policy. They come from copies of personal data that sit outside the main deletion job, in backups, logs, and side environments nobody revisits. The cards below cover the gaps assessors most often find and a practical fix for each.

Data categories with no stated period

Article 5(1)(e) and the record of processing expect a time limit for each category of data, or the criteria used to set one. A schedule that says "retain as needed" fails that test. Check that every system holding personal data appears in the retention schedule with a period or documented criteria, and that privacy notices state the same periods. Ask the owner of each system to justify its period in writing.

Deletion jobs that skip secondary copies

A deletion job that clears the production database often leaves the same records in exports, reporting tables, search indexes, file shares and document stores. The EDPB's 2025 coordinated enforcement action found controllers struggling to delete personal data across their systems. Map each data store the job should reach, and test deletion by searching for a known test record after the job runs.

Backups that retain deleted records

Backups keep copies of data long after the live system has deleted it, and a restore can bring deleted records back. Define a backup retention period that matches the schedule, and confirm that expired snapshots are actually pruned. Where a record must be removed from backups, document how restores are handled so deleted data is not reinstated. Bareos lets administrators select restores by date and time, which helps reason about what a restore would bring back.

Application and audit logs without limits

Application, access and audit logs often record usernames, IP addresses, request bodies or identifiers without any rotation rule. Nextcloud's admin_audit app writes event detail to audit.log in the data directory, and that file grows unless it is rotated or purged. Set a log retention period for each log source, configure rotation, and confirm that old files are deleted. Check that logs do not capture more personal data than the purpose needs.

Analytics and staging copies outside the schedule

Test environments, analytics extracts and ad hoc exports are usually created by hand and never added to the retention schedule. They often hold full production data for years. Keep an inventory of non-production copies, require pseudonymized or masked data in staging, and set an expiry date on every extract when it is created. Ask the engineering lead to name each environment that received production data in the last year.

No evidence that jobs ran

A retention policy is only as strong as the proof that its jobs ran and succeeded. Scheduled deletions can fail silently, and a backup verification that is never run tells you nothing about the stored data. Keep job logs with timestamps and results, alert on failures, and run periodic checks. For backups, restic's check command with read-data options can confirm that stored pack files are intact and unmodified. Keep these outputs as dated evidence.

Storage limitation questions buyers ask before hiring help

How much effort does a storage limitation program take, and what drives it?

The effort depends mainly on how many systems hold personal data, how well those systems are already documented, and how many retention rules have to be agreed with data owners before anything is built. A team with a short inventory of stores and clear legal retention periods can move quickly. A team with dozens of applications, shared file stores, analytics copies and years of unmanaged exports will spend most of its time on discovery and decisions, not on writing deletion jobs. Ongoing effort is smaller but recurring: new systems need retention rules, and deletion jobs and backup expiry need periodic checks. The cost table on this page breaks these components down, and the evidence section lists what a reviewer will expect to see once the work is done.

Can our team handle storage limitation without outside help?

Often yes, provided someone owns the retention decisions and has time to build and test the mechanisms. The hard parts are rarely technical alone. Teams usually need a single accountable owner, a retention schedule approved by the business and legal function, and engineers who know where every copy of the data lives, including logs, caches, exports and backups. An outside implementation partner is most useful when the environment is self-hosted, spans several platforms, or needs deletion and backup expiry built into tooling that the internal team has not run before. DeployOpen prepares systems, controls and evidence for assessments, but the organization keeps ownership of its retention rules and decisions, and only an independent auditor or assessor issues any report.

How long does storage limitation work take, and what does the timeline depend on?

No general duration can be given without knowing the environment, so treat any single number you see elsewhere with caution. The timeline is driven by three factors: the number of stores that hold personal data, the design of backups and logs, and how quickly approvals come through. Each store needs its retention period confirmed, a deletion or expiry mechanism built, and a test that shows it works. Backup design often takes the longest because it determines whether individual records can be removed or whether expiry is handled by retiring whole backup sets over time. Approval speed matters because retention periods are business and legal decisions, and engineering cannot finish until they are settled. Ask any implementation partner for a timeline built from a written list of stores and decisions, with milestones for each approval.

What do we need to provide to start a storage limitation engagement?

The engagement needs time from several people and access to the systems involved. The most important input is data owner time, because someone who understands each data set must confirm what it is for and how long it is needed. Engineers must provide access to applications, databases, file stores, log pipelines and backup servers, ideally in a test environment first. Change approvals are also required, since deletion jobs and backup policy changes affect production and often need a review board sign-off. Legal or privacy staff should confirm legal retention obligations that override a default period. Agree these inputs in the written scope before work starts, so that delays are visible early and do not appear as surprises halfway through the project.

Do backups have to be purged record by record to meet storage limitation?

Not necessarily, but the answer depends on your backup design and on what your retention rules say. Article 5(1)(e) asks that personal data not be kept in identifiable form longer than needed, so a backup that keeps data past its purpose needs a documented answer. Many organizations manage this by setting backup retention so that data expires as older backup sets age out, and by documenting that restoring old data is restricted and that restored records are then deleted again. Tools such as Bareos keep a catalog of backed-up files and can restore from a chosen point in time, which helps define and enforce expiry, while restic's check options confirm that stored backup data is intact. Confirm with your legal and privacy team what expiry window is acceptable for each data category before choosing a design. Record-level purging of backups is usually costly and hard to verify, so it is rarely the first choice.

What will an assessor ask for first when reviewing storage limitation?

An assessor usually starts with the written rules and then asks how those rules are enforced in systems. Expect requests for the retention schedule, the record of processing activities with its time limits, and the privacy notices that state storage periods or the criteria used to set them. Next they will look for proof that enforcement works: deletion job configurations, run history, backup retention settings, and test results showing that expired data is actually removed. Logs of administrative actions, such as an audit log from Nextcloud or an OpenBao audit device, help show who changed retention settings and when. The evidence section on this page lists these items in order, so you can check your readiness before an assessment begins. Remember that a regulator's expectation is an operating control, not a document alone.

How DeployOpen prepares storage limitation controls and evidence

DeployOpen works on Article 5(1)(e) storage limitation as part of a fixed-scope implementation inside your own infrastructure. We prepare the retention rules, deletion jobs, backup and log settings and the evidence that shows they run, while your organization keeps ownership of its retention decisions and controls.

How we scope

The written scope lists each personal data category, system and backup or log store that needs a retention period.
Retention periods come from your documented purposes and legal requirements, which your team confirms before build starts.
Scope names which systems are in and out, including backup copies, logs, analytics exports and third-party processors.

How we build

We configure deletion or anonymization jobs in the source systems so that expired records are removed on a defined schedule.
We set backup retention in Bareos or restic so that copies expire, and document how deleted records age out of backup sets.
We tune log retention and audit log settings, such as Nextcloud audit logging or OpenBao audit devices, so logs do not outlive their stated purpose.

How we hand over

We deliver a retention schedule mapped to systems, job configurations, and the owner responsible for each setting.
We provide test records showing that deletion jobs ran, backup expiry worked, and log rotation held as documented.
We hand over runbooks so your team can change periods, rerun jobs and produce the evidence an assessor will ask for.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retention rules change when purposes change, so we can review schedules and job configurations on a set cadence you agree.
Ask any provider to confirm which retention checks are repeated after each system upgrade or new data source is added.