Run a PECR Audit on Returns Portal Tracking

UK ecommerce teams should identify every storage and access technology in the returns journey, separate necessary functions from optional tracking, and document the correct user controls.

Treat the returns portal as part of the website audit

Returns portals often sit on a subdomain, use a third-party platform or open from a link in an order email. That separation can make them easy to miss during a cookie review. Yet the journey may still store or access information on a customer's phone or computer through cookies, local storage, software development kits, pixels or comparable technologies. Start the audit at the policy or help page, then follow a real return through order lookup, authentication, reason selection, label creation, status checking and support escalation.

The Information Commissioner's Office finalised its guidance on storage and access technologies on 29 April 2026, following earlier consultation and changes to the Privacy and Electronic Communications Regulations. The guidance is broader than conventional browser cookies. For an operator, the sensible response is a technology inventory covering the full journey and every supplier involved. This is an operational guide rather than legal advice; whether a particular use is permitted depends on its precise purpose and implementation.

Record purpose before deciding which rule applies

For every technology detected, record its name, provider, purpose, information stored or accessed, where it activates, duration, recipients and the control presented to the user. Test before any choice is made, after each available choice, and after the user revisits the portal. Browser developer tools and a tag-management inventory can help, but they should be checked against a real network trace because a configuration list does not prove what the live journey actually loads.

Do not classify a technology as necessary merely because the business values the resulting data or a supplier installs it by default. Schedule A1 to regulation 6 includes an exception where storage or access is strictly necessary to provide an online service requested by the user. Its examples include protecting information connected with the requested service, preventing or detecting fraud or technical faults, authenticating identity automatically, and maintaining selections or information entered on a website where necessary to provide that service. Document the link between the feature and the customer's requested return task.

Apply the newer exceptions carefully

The current Schedule A1 also contains an exception for certain statistical uses. It is conditional, not a general permission for analytics. Among other requirements, the sole purpose must be collecting statistical information about use of the service or website with a view to making improvements; information may only be shared to assist those improvements; clear and comprehensive information must be provided; and the user must receive a simple, free means of objecting and must not object. Check every condition against the actual configuration, including any onward use by an analytics provider.

A separate exception covers certain storage or access used solely to adapt or enhance a website's appearance or functionality. It too requires clear and comprehensive information plus a simple, free means of objecting. Avoid stretching this category to cover advertising, cross-site profiling or a mixed-purpose tag. If one technology serves several purposes, assess each purpose and consult the ICO's current guidance rather than assigning the most convenient label to the whole package. Where an exception does not fit, Schedule A1 provides for consent after clear and comprehensive information has been supplied.

Check choices, disclosures and failure paths

Review the portal's first load in a clean browser. Confirm that technologies which rely on consent do not activate before the relevant positive choice, and that refusing or withdrawing consent does not block the core return service without a justified reason. Information should describe purposes in language a customer can understand, identify meaningful third-party involvement and remain easy to find inside the journey. A generic banner inherited from the main shop may be inaccurate if the returns platform uses a different set of suppliers.

Test the objection mechanism for uses relying on an applicable objection-based exception. It should be simple and free, and the resulting preference should work on later portal pages. Also test guest orders, mobile browsers, expired sessions, failed order lookups and links opened inside email applications. These routes can load different scripts or send the user through another domain. Record evidence of the test, the date, the build or configuration examined and any limitation, so a later supplier or tag change can be compared with a known state.

Build review into releases and supplier management

Give the inventory a named owner across ecommerce, privacy and engineering rather than leaving it solely with marketing. Require a review when the portal provider, consent tool, analytics setup, fraud service or customer-support widget changes. Supplier documentation is useful evidence, but verify live behaviour and make sure contracts and internal records match the purposes actually in use. Remove dormant tags and duplicate technologies; an unused integration can still create risk if it continues loading.

Finish with a short decision record for every item: the assessed purpose, applicable rule or exception, required information or control, technical owner, evidence link and next review date. Recheck after releases and at a sensible periodic interval. The objective is not a banner that merely looks compliant. It is a returns journey whose storage and access behaviour is understood, whose controls work as described, and whose essential customer functions remain usable when optional tracking is declined or objected to.

Practical next steps

Include hosted and third-party returns portals in technology audits.
Record each technology's real purpose before classifying it.
Treat statistical exceptions as conditional, not blanket permission.
Test consent and objection controls in a clean browser.
Verify live behaviour instead of relying only on supplier documents.
Repeat the audit after portal, tag or supplier changes.