Someone emails your support inbox asking for every piece of data you hold on them. Or asking you to delete their account, permanently, today. Or asking why an algorithm turned down their loan. Whatever the wording, they are exercising a legal right, and the clock on your response started the moment the message landed.
Those rights sit under GDPR and, since Brexit, under UK GDPR too. Eight of them, spelled out in Articles 12 to 22 of the regulation, and every organisation that holds personal data on someone in the EU or UK has to be able to answer them, properly, inside a month. We build data foundations for AI at Shipshape Data, and this is one of the first things we check when we look at a client's architecture: can you actually find, produce, correct or delete one person's data on demand, or would that request currently mean three engineers and a week of grep?
This article covers what the eight rights are, how each one plays out in practice, what you have to do when a request lands on your desk, and where the lines sit on refusing one. It is written for anyone responsible for handling these requests, not just lawyers, because in most organisations the person who actually fulfils a data subject request is an engineer, a support lead, or whoever drew the short straw.
What the rights are for
The General Data Protection Regulation came into force across the EU in May 2018. After Brexit it was carried into UK law as UK GDPR, largely unchanged. Both versions rest on the same idea: personal data belongs, in a legal sense, to the person it describes, not to whoever happens to be storing it. Collecting someone's email address does not make it yours to do whatever you like with.
Articles 12 to 22 turn that idea into eight enforceable rights. Anyone can invoke them by contacting an organisation directly, with no lawyer and, in almost every case, no fee. The organisation then has a fixed window, one month as standard, to respond properly or explain why it cannot.
GDPR treats your data as something you control, not something a company owns simply because it collected it.
Who the rights apply to
Anyone whose personal data an organisation processes is a data subject: customers, employees, newsletter subscribers, website visitors, job applicants who never got hired. Nationality is irrelevant. What matters is whether the processing happens in the EU or UK, or whether the organisation is offering goods or services to someone who is. Children hold the same rights as adults, usually exercised by a parent or guardian on their behalf. The one clear exclusion is the deceased; GDPR stops applying at death, though other rules can still cover their data.
Personal data itself is defined broadly on purpose: anything that identifies you, or could identify you when combined with something else. Name, email, phone number, obviously. Also IP addresses, device identifiers, location history, an online username, a photo with your face in it. A lot of organisations assume that stripping out a name is enough to escape GDPR. It usually is not, if there is a reasonable way to re-link the record back to a person, the protection still applies.
The eight rights, one by one
Eight rights, and they cluster naturally into four pairs: telling you and showing you, fixing and removing, pausing and moving, refusing and appealing.
Being told, and seeing what's held
The right to be informed means an organisation has to tell you, up front, what data it is collecting, why, who it shares it with, and how long it plans to keep it. This lives in the privacy notice, and it has to be written in plain language rather than buried in legal boilerplate. Every other right depends on this one existing properly; you cannot ask to correct or delete data you do not know exists.
The right of access, sometimes called a subject access request or SAR, lets someone ask for a full copy of the personal data an organisation holds on them, plus an explanation of how it is being processed. This has to be free in almost every case and delivered in a format the person can actually use. A SAR often turns up more than the requester expected, including who the data was shared with and where it originally came from.
Fixing what's wrong, removing what shouldn't be there
The right to rectification covers correcting inaccurate data or completing incomplete records, and organisations have to act without undue delay once the error is demonstrated. This matters most when a wrong figure or a wrong flag is quietly shaping a decision: a credit score, a job application, an insurance premium.
The right to erasure, the "right to be forgotten," requires deletion in specific situations: the data is no longer needed for the purpose it was collected for, consent has been withdrawn, someone has objected to processing with no overriding legitimate reason to continue, or the data was collected unlawfully in the first place. It is not absolute. If an organisation has a legal duty to keep something, tax records are the obvious example, erasure does not override that duty.
Pausing processing, moving your data elsewhere
The right to restrict processing is the middle option between doing nothing and deleting everything. Someone might use it while disputing whether their data is accurate, or when processing turns out to be unlawful but they would rather freeze the data than have it destroyed, or when they need it preserved for a legal claim even though the organisation itself no longer needs it.
The right to data portability lets someone take data they provided to one organisation and hand it to another, in a structured, machine-readable format. It only applies where processing rests on consent or contract and happens by automated means, which in practice makes it most relevant to switching banks, cloud storage, or any service where years of your own activity has piled up somewhere you would rather leave.
Objecting, and challenging a machine's decision
The right to object stops processing outright in certain cases, direct marketing above all: there is no override available there, an objection to marketing has to be honoured, full stop. For processing based on legitimate interests or research, the organisation has to show compelling grounds that outweigh the individual's interest before it can keep going.
The final right covers automated decision-making and profiling. Nobody should have a decision made about them purely by an algorithm when that decision carries legal or similarly serious weight, a credit refusal, an automated dismissal, a benefits rejection, without the chance to have a human look at it, say their piece, and contest the outcome.
Why this gets harder once AI is in the stack
None of the eight rights were written with machine learning in mind, and that shows. A deletion request is straightforward against a customer record in a single table. It gets murkier once that record has fed a training set, because "delete the data" and "delete its influence on a model" are not the same operation, and most organisations have no clean way to do the second one.
The right to object to automated decision-making runs into the same wall from the other direction. Explaining a decision made by a well-documented rules engine is manageable. Explaining a decision made by a large model with millions of parameters is a genuinely open problem, and regulators are not going to accept "the model said no" as a full answer for much longer.
We see this pattern constantly in our own client work: organisations move fast on AI and only notice the data subject rights gap once someone actually files a request against an AI-touched system, at which point it is a scramble rather than a design decision. Structuring lineage and retention properly before the AI system goes live is a lot cheaper than retrofitting it once regulators, or a determined customer, come asking. If your data governance function cannot currently trace a single person's data through every system, including the AI ones, that gap needs closing before it becomes the thing an audit finds.
Handling a request that lands on your desk
The obligations here are not optional and there is no grace period for "we're a small team." The moment a request arrives, however it arrives, email, a web form, a tweet if that is genuinely how your organisation normally talks to customers, the clock starts.
The one-month deadline
Organisations have one calendar month to respond, starting from the day the request was received, not the day someone got round to reading it. That can stretch by up to two further months for requests that are genuinely complex or numerous, but the extension has to be communicated within the first month, with a reason attached. Asking for ID to verify identity is fine, and it is the one thing that can legitimately pause the clock, but only if the original request genuinely did not contain enough to identify the person. Using ID checks as a stalling tactic is not.
What a proper response contains
For an access request specifically, the organisation has to hand over everything: the data itself, why it was collected, who it has been shared with, how long it will be kept, and where it came from if it was not collected directly from the person. Selective extracts are not good enough unless the request itself was narrowed to a specific type of processing. The response also has to explain the person's other rights and their route to complain to the Information Commissioner's Office, or the equivalent body outside the UK.
Format matters more than it sounds like it should. Plain language, not legal phrasing. A structured, commonly used format, PDF or CSV rather than something proprietary. For a portability request specifically, it needs to be machine-readable, JSON or XML, something the next provider can actually ingest rather than re-key by hand.
Verification and cost
Asking for extra information to confirm identity is reasonable, particularly for sensitive data, but it has to be proportionate. Demanding a passport, a utility bill and a signed statement for a routine request is not proportionate, it is obstruction dressed up as caution. Charging a fee is the exception rather than the rule: it is only permitted where a request is manifestly unfounded, excessive, or repeated without a sensible gap, and even then the charge has to reflect real administrative cost rather than being set as a deterrent.
When you can say no, or at least not yet
None of these rights are unconditional. GDPR builds in specific, named grounds for refusing, delaying, or narrowing a response, and the exemptions exist to balance individual privacy against other things that also matter: other people's rights, legal duties, the public interest.
Requests that are manifestly unfounded or excessive can be refused, though the burden is on the organisation to show why, not just to assert that it is a lot of work. Legal retention duties override erasure requests; you cannot ask a company to delete records it is legally required to keep for a set period, tax filings and employment records being the standard examples. Data needed to establish, exercise or defend a legal claim can be held onto until that claim resolves.
Certain categories of processing get broader carve-outs. National security and law enforcement processing can restrict access rights where disclosure would compromise the activity itself. Journalism, academic research, and artistic or literary expression get protection under freedom of expression, weighed case by case against the privacy interest at stake. Medical research can resist an erasure request where deleting the data would genuinely undermine the research. None of these are blanket exemptions from every right; each one applies to a specific right in a specific context, and organisations that wave "research exemption" at every request tend not to survive a regulator's scrutiny of the claim.
What this looks like in practice
A rejected loan application is the classic access-request trigger: the applicant asks to see exactly what data fed the decision, and it turns out a database error merged their record with someone who shares their surname and postcode. That kind of identity mix-up shows up more often than most organisations would like to admit.
An old employer's file says someone was dismissed for misconduct when they actually resigned. That is a rectification case, and one where the correction genuinely matters, because a wrong entry like that can quietly follow someone through reference checks for years.
Someone closes a social media account and later discovers the platform kept every post, message and photo anyway. If consent was the basis for holding that data and it has been withdrawn, with no other legal ground to keep it, that is a straightforward erasure case, at least on paper; in practice it is often the request that reveals how tangled a company's own data map has become.
Marketing emails that keep arriving after multiple unsubscribes are a right-to-object case with essentially no wriggle room. Direct marketing has no override; the request has to be honoured immediately, and repeated failures here are one of the more common sources of ICO complaints.
Switching banks without wanting to re-key years of transaction history is what data portability was actually built for: request the data in a structured format, hand it to the new provider, done, instead of starting a financial history from zero.
Building this into the architecture rather than bolting it on
The organisations that handle these requests well share one trait: they know where personal data lives before the request arrives. Not "we could find out with enough time," but a genuine, current map connecting each system, each pipeline, and increasingly each model, back to the individuals whose data flows through it. Everyone else finds out how disorganised their data estate is at the worst possible moment, with a regulatory clock already running.
This is exactly the kind of gap we look for at Shipshape Data when we assess a client's customer data architecture. A request-handling process is only as good as the underlying data quality and lineage beneath it. If personal data is scattered across systems that do not talk to each other, no amount of process documentation will get you to a complete response inside a month. Fix the architecture first, and requests stop being fire drills.
The same applies with more force once AI enters the picture. A model trained on personal data needs a way to trace, and where necessary unwind, that influence if a training set included data someone later asked to delete. Building that traceability in from the start, rather than trying to reconstruct it after a regulator asks, is the difference between a manageable compliance function and a permanent liability sitting under your AI programme.
If you want a clear answer on where your own gaps sit, that assessment is what we do. Talk to us and we will tell you straight whether your data foundation could actually produce, correct or delete one person's record on demand, and what it would take to get there if it cannot yet.