Returns Data Retention Periods Under GDPR

Every returns platform quietly becomes a data warehouse: RMA numbers, refund amounts, customer addresses, photos of damaged goods, chat transcripts, and fraud-scoring flags all pile up in one place. Most merchants never ask the question that actually matters — how long are we legally allowed to keep this? Treat 'keep everything forever, just in case' as the default and you are sitting on a growing liability, not an asset. Under GDPR, storage without a time limit is itself a violation, independent of whether the data was ever misused.

The rule is short but easy to violate in practice: personal data must be kept 'in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed' — GDPR Article 5(1)(e). That single clause, known as the storage limitation principle, is the backbone of any defensible returns data privacy compliance program. It does not give you a number. It gives you an obligation to justify a number, purpose by purpose, and to delete or anonymize once the purpose expires.

Why returns teams over-retain by default

Returns data is unusually sticky compared to other commerce data because it touches three separate business functions with three separate time horizons: customer service (short), accounting and tax (medium, statutory), and fraud/serial-returner scoring (long, but narrower in scope). When these functions share one database table and nobody owns the retention schedule, the default becomes indefinite retention because deleting feels riskier than keeping. That instinct is backwards under GDPR — indefinite retention is the riskier posture, not the safer one.

The practical failure mode we see most often in merchant audits: a returns platform stores full RMA records — name, address, order history, reason codes, uploaded photos of the defect — with no expiry, because the original schema was built for operational visibility, not compliance. Two years later, that same table is powering a serial-returner score, a customer-service search index, and an accounting export, and nobody can say which fields are needed for which purpose anymore. Untangling that after the fact is far more expensive than designing retention tiers up front, which is also why RMA data quality work and retention policy should be scoped together, not sequentially.

A retention schedule you can actually defend

There is no single GDPR-mandated number of days or years — retention periods are purpose-bound and often anchored to a parallel statutory requirement (tax law, consumer protection law, warranty periods) rather than to GDPR itself. GDPR's job is to force you to pick a period and stop hoarding past it. The table below is a starting schedule most merchants can adapt; treat the specific durations as a template to validate against your local tax and consumer-protection statutes, not as legal advice.

Storage limitation is not a deletion deadline you hit once a year. It is a design constraint that should shape your schema, your indexes, and your fraud-scoring pipeline from day one.

Where fraud scoring and storage limitation collide

The hardest tension in returns compliance is that serial-returner scoring genuinely improves with more history — a customer's return pattern over three years is a stronger signal than three months. But GDPR does not grant fraud prevention an exemption from storage limitation; it grants a narrower allowance to keep processing data as long as it is necessary and proportionate to that specific purpose, which usually means keeping a derived score or aggregate rather than the full identifiable record. Retail bodies have flagged returns fraud as a multi-billion-dollar drag on margins — the National Retail Federation estimates return fraud and abuse cost US retailers tens of billions annually — so the pressure to retain is real. The resolution is architectural, not legal: separate the identifiable RMA record (short retention) from the risk score itself (which can be retained longer once it no longer requires the underlying personal detail to function).

Practical separation pattern

1. 1Store the full RMA record with personal identifiers for the operational window only (return processed + short buffer).
2. 2Compute a fraud/risk score from that record before deletion and persist the score with a pseudonymous or hashed customer key.
3. 3Purge or anonymize the identifiable fields on schedule; retain the score and aggregate statistics for trend analysis.
4. 4Re-link the score to a live customer identity only at the moment of a new transaction, via a lookup — not by keeping the old PII around.

Building the policy into your platform, not a spreadsheet

A retention schedule that lives in a compliance spreadsheet and not in the database schema will not survive contact with a real migration, a new integration, or a busy Q4. The durable version is enforced at the platform level: TTL fields on records, scheduled anonymization jobs, and an audit log of what was deleted and when — the same audit trail regulators ask for during a Data Protection Impact Assessment. McKinsey's research on data governance maturity consistently finds that automated policy enforcement outperforms manual review cycles, and returns data is a good example of why: volume is high, records are personal by nature, and the people closest to the data (support agents, ops managers) are the least likely to remember a retention clock buried in a policy document.

• Tag every returns table and field with a data category and a default retention period at the schema level, not in documentation alone.
• Automate anonymization/deletion jobs rather than relying on manual quarterly cleanups.
• Keep a deletion log — proof of compliance matters as much as compliance itself in a regulator inquiry.
• Review retention periods annually against changes in local tax and consumer-protection law.
• Separate identifiable records from derived scores so fraud prevention can outlive individual RMA records without keeping PII.

What this means for merchants right now

If your returns platform cannot answer 'why do we still have this record' for data older than 24 months, that is the audit finding waiting to happen. Start with an inventory: list every table touching returns data, assign a purpose and a retention period to each, and confirm the period is enforced automatically rather than aspirationally. This is not a one-time compliance exercise — it is infrastructure. Merchants that build retention limits into the platform from the start avoid the expensive retrofit, and they end up with cleaner, more trustworthy data for fraud scoring precisely because the noise of ancient, purposeless records has been cleared away.