Map Returns Records for Subject Access Requests

A practical way for UK ecommerce teams to locate, review and securely provide returns-related personal data when a customer makes a subject access request.

Treat returns data as part of the customer record

A return can create personal data in more places than the original order. A portal may hold the customer's stated reason, photographs, collection address and preferred refund route. Support conversations, warehouse inspection notes, carrier tracking events, fraud-review flags and payment records may add further information linked to the same person. An access request therefore should not be routed only to the team that owns the shopfront account. It needs a repeatable search across every system that contributes to the return journey.

Article 15 of the UK GDPR gives a person the right to confirmation about processing, access to their personal data and specified supporting information. The current text says the entitlement covers what the controller can provide following a reasonable and proportionate search. That is a legal requirement, not permission to search casually. An operator should be able to explain which repositories were considered, how identifiers were used and why the search was proportionate. This article offers operational guidance rather than legal advice; unusual or disputed requests may need specialist review.

Build a searchable returns data map

Start with a short register of the systems and processors involved in a return. For each one, record the useful search keys: customer email, order number, return authorisation number, tracking number, postcode and payment reference. Include the returns portal, ecommerce platform, helpdesk, warehouse or fulfilment system, carrier dashboard, payment provider, shared inboxes and any controlled spreadsheets. Name an owner for each repository and document how an authorised colleague can export relevant material without opening access more widely than necessary.

Test the map with a fictional order rather than waiting for a live request. Follow one return from initiation to refund and note where personal data appears, including free-text notes and attachments. Check whether internal identifiers can be traced back to the customer and whether deleted or archived material remains searchable under the organisation's retention arrangements. The aim is not to retain extra data for hypothetical requests. It is to understand the data already processed, apply the existing retention schedule consistently and avoid overlooking a system when a real request arrives.

Control the clock and the search

Article 12 requires controllers to facilitate data-subject rights and communicate in a concise, transparent and accessible way. Article 12A defines the applicable period as one month beginning with the relevant time, with detailed rules about identity information, fees and extensions. It also allows the clock to exclude a period when further information is reasonably required to identify the information or processing activities covered by an Article 15 request. Teams should record the received date immediately, assign an accountable owner and seek clarification promptly where the scope genuinely cannot be identified.

A simple case log can keep the work defensible. Record the request, identity checks, clarification, search terms, repositories checked, people consulted, material found, review decisions and response date. Do not demand identification by habit or collect more evidence than is necessary; Article 12 links additional identity information to reasonable doubts. If an extension is considered necessary because of complexity or the number of requests, Article 12A requires notice within the initial one-month period and reasons for the delay. Build reminders around the statutory timetable rather than an internal service target that may drift.

Review before releasing the response

Returns records frequently mix the customer's data with information about other people: support agents, gift recipients, neighbours, warehouse staff or carrier contacts. Article 15 says the right to a copy must not adversely affect the rights and freedoms of others. Route the assembled material through an authorised review before release, considering third-party information, security details and any applicable restriction or exemption. Preserve the meaning of the customer's data while applying only justified redactions, and keep a record of the reasoning rather than silently omitting inconvenient material.

Provide the customer's personal data in a secure, intelligible package, not as an unexplained dump of database tables. Article 15 also lists contextual information that must accompany access, including processing purposes, data categories, recipients, retention information and complaint rights. Where the request arrived electronically, the legislation generally points towards an electronic response unless the customer asks otherwise. Use a protected delivery method, verify the destination, separate large files sensibly and have a second person check the recipient and attachments before sending. A dry run will expose missing exports and unsafe hand-offs before the deadline is real.

Practical next steps