A practical check for UK ecommerce teams to reduce unnecessary personal data, clarify retention and secure information throughout the returns workflow.
Map the information behind each return
A return can spread customer information across more places than an ordinary order. The returns portal may hold contact details and a reason code, support may receive photographs, the warehouse may print a label, and finance may keep a refund record. Carrier systems, shared inboxes and exported spreadsheets can add further copies. Start the check by following one return from request to refund and listing every system, document, person and service provider that handles personal data.
The ICO describes data minimisation as keeping personal data adequate, relevant and limited to what is necessary for the stated purpose. Apply that test field by field. An order number and a method of contact may be needed to manage a return, while a free-text box can invite customers to disclose far more than staff require. Record the purpose of each field, who uses it and whether the same fact already exists in the order system. Removing an unnecessary field is usually safer than trying to protect another redundant copy forever.
Design evidence requests around the decision
Photographs and explanations can help a retailer assess damage, identify the product or choose a collection service, but a blanket request for extensive evidence may be disproportionate. Define what the team needs for each decision and ask only for that. Give customers clear prompts, discourage images containing people, addresses or unrelated household details, and avoid requesting identity documents unless there is a specific, justified need. These are practical controls; the appropriate lawful basis and transparency information depend on the organisation and purpose.
Free text deserves particular attention because it is difficult to predict, search and delete consistently. Prefer structured reason codes where they answer the operational question, with a short optional note for genuine exceptions. If staff copy customer messages into warehouse notes or carrier booking fields, decide which details are essential for the recipient. A collection driver may need an address and access instruction, but not the customer’s full complaint history. Test templates with realistic cases so the reduced form still lets teams resolve returns without repeatedly contacting the customer.
Set retention rules by record type
The ICO’s storage limitation principle says personal data should not be kept in identifiable form for longer than necessary for the purpose. That does not create one universal deletion period for every return record. Refund transaction records, support correspondence, parcel photographs and temporary export files may serve different purposes and therefore need different decisions. Establish a retention schedule that names the record, its purpose, where it is stored, the trigger that starts the period, the period itself and the owner responsible for review.
Make disposal part of the workflow rather than an annual hunt through old folders. Configure supported deletion or anonymisation controls, close shared links, clear local exports and include backups and processor-held copies in the assessment. Where information must be retained for another justified purpose, separate or restrict it instead of leaving the entire return case open to everyone. Periodically sample records beyond their expected date and investigate why they remain. The ICO also emphasises accountability, so document the reasoning and revisit it when systems, suppliers or purposes change.
Limit access and test the hand-offs
The ICO’s security guidance requires appropriate technical and organisational measures based on the risks of the processing; it does not prescribe one identical control set for every retailer. In a returns operation, a sensible review includes role-based access, individual staff accounts, prompt removal of access when roles change, protected exports, secure disposal of paper, and suitable arrangements with processors. Warehouse colleagues should see the information needed to receive and inspect goods, while payment or detailed support data should remain limited to the teams that use it.
Finish with a tabletop test of common hand-offs: a customer uploads an image, support escalates a case, a carrier collects the parcel, the warehouse records condition and finance issues the refund. At every step ask what data moves, whether the recipient needs it, how the transfer is protected and when the copy is removed. Record findings as owned actions with review dates. This operational check supports data protection work but is not legal advice; retailers should take appropriate professional advice for their processing, systems and contractual arrangements.
Practical next steps
- Map every system and hand-off that contains returns data.
- Justify each field before asking customers to provide it.
- Use structured reasons to reduce unnecessary free-text disclosures.
- Set retention periods separately for different record types.
- Restrict each team to the information it genuinely needs.
- Test deletion, exports and supplier hand-offs with real cases.
Primary sources
Back to News