Two of the most common ways an online retailer interacts directly with UK GDPR in practice are a customer's subject access request and a data breach requiring notification. Both come with statutory deadlines that catch unprepared businesses out.
What a subject access request actually entitles a customer to
A subject access request (SAR) is a customer's statutory right to ask what personal data you hold about them, why you hold it, who you share it with, and to receive a copy of that data. It can be made verbally or in writing, doesn't need to mention 'GDPR' or 'subject access request' by name, and doesn't need to be sent to a specific department — a customer emailing 'send me all the data you have on me' to your general enquiries inbox is a valid SAR that starts your statutory clock.
You must respond within one calendar month of receiving the request, extendable by a further two months for genuinely complex or numerous requests, provided you notify the individual of the extension and the reason within the original month.
Building a practical SAR response process
Name a specific person or role responsible for recognising and handling SARs, since the biggest risk is a request going unrecognised by a staff member who doesn't realise an informal-sounding email triggers a legal deadline. Map out where customer data actually lives across your business — your e-commerce platform, email marketing tool, customer service software, accounting system and any spreadsheets — because a SAR response needs to cover data held anywhere in the organisation, not just your primary database.
- Verify the identity of the requester before releasing any data, proportionate to the sensitivity of the data held.
- Search every system that might hold personal data about that individual, not just your main customer database.
- Redact or exclude data belonging to or identifying other individuals where it appears in the same records.
- Provide the data in a clear, commonly used format, free of charge in most cases.
- Log the request and your response for your own compliance records.
When you can refuse or charge for a request
You can refuse a manifestly unfounded or excessive request, or charge a reasonable administrative fee for it, but this is a narrow exception, not a general escape route, and the burden is on you to justify the refusal or charge if challenged by the ICO. Simply finding a request inconvenient or time-consuming to fulfil is not grounds for refusal — the right exists precisely because compiling this information takes effort.
The 72-hour breach notification deadline in practice
As covered in more detail in our incident response planning article, a personal data breach likely to risk individuals' rights and freedoms must be notified to the ICO within 72 hours of your organisation becoming aware of it. In an SAR and breach-notification context specifically, this means having a clear internal escalation path so that whoever first notices a possible breach — a developer, a customer service agent, a supplier — knows immediately who to tell, rather than the report sitting unactioned while the clock runs.
Notifying individuals directly when risk is high
Separately from ICO notification, UK GDPR requires you to inform affected individuals directly, without undue delay, when a breach is likely to result in a high risk to their rights and freedoms — for example exposed passwords, payment details, or data that could enable identity theft. This notification must be in clear, plain language, describe the nature of the breach, and give practical advice on steps the individual should take, such as changing a password used elsewhere.
Keeping records the ICO expects to see
Whether or not a breach meets the notification threshold, UK GDPR requires you to keep an internal record of every personal data breach, including its facts, effects and the remedial action taken — this internal record must exist even for breaches you conclude don't need to be reported externally. Similarly, keep a log of SARs received and how they were handled. Both records demonstrate to the ICO, in the event of an investigation, that you take these obligations seriously on an ongoing basis rather than only when something goes visibly wrong.
Related Considerations for UK Retailers
It's rarely useful to treat handling subject access requests and statutory data breach notifications under UK GDPR as a standalone decision — the strongest results tend to come from lining it up with the rest of your operation. It's worth reading this alongside Building a Data Breach Incident Response Plan for UK Online Retailers before making a final decision.
Most of the practical risk in this area comes from basic gaps rather than sophisticated attacks or edge cases — a missed policy update, an unpatched plugin, a staff member without the right training, or a document that was never actually reviewed by someone qualified to check it. A simple annual checklist covering the fundamentals catches the majority of exposure far more cheaply than reacting after an incident.
For related reading: Many of the same principles come up again in Reporting Dashboards for Data-Driven Retail Decision-Making in UK E-Commerce, which is worth bookmarking for later. It's worth reading this alongside Building a Data Room and Preparing Management Accounts for Sale before making a final decision.