A DSAR lands in your inbox on a Friday afternoon: someone wants a full copy of everything you hold about them, and you have a month to answer. If you cannot say where that data lives, the request turns into a scramble across departments and old backups nobody has opened in years. GDPR compliance is not really about avoiding a fine. It is about knowing your own data well enough that a request like this, an audit, or a new AI project does not catch you flat-footed.
We build data and AI systems at Shipshape Data, and GDPR shows up in nearly every engagement whether the client raises it or not. You cannot design a sensible pipeline, train a model, or build a customer-facing tool without knowing what personal data you are moving and on what basis. Since 2018, getting that wrong has carried real teeth: penalties run up to €20 million or 4% of global annual turnover, whichever is higher, and regulators across Europe have shown they will use that ceiling.
This is a working guide to what GDPR actually asks of your organisation: the principles behind it, the terms your legal and engineering teams need to share, the lawful bases you can rely on, and the documentation that proves you are doing what you say. It ends with a checklist you can run against your own operation.
Why this is not just a legal problem
Ignore GDPR and you are exposed on three fronts at once, and they compound. Financial penalties are the headline risk: British Airways was fined £20 million in 2020 after a breach exposed 400,000 customer records, and Google was fined €50 million in France over how it explained its data processing to users. Those are the cases that made the news; regulators issue smaller fines and formal warnings constantly, to organisations you have never heard of.
Reputational damage is slower and harder to measure, but it is real. A majority of consumers say they would stop using a service after a serious breach, and trust does not come back quickly once it goes. Competitors who can point to a clean record use it, quietly, in the tenders you are also trying to win.
Then there is the AI angle, where most of our clients actually feel the pressure. Automated decision-making has its own rules: you need to explain how a model reached a conclusion, keep a human in the loop where the outcome matters to someone's life, and give people a route to contest it. Purpose limitation and data minimisation bite here too, because you have to justify every field that went into training. Bolt this on after a model is live and you are looking at a rebuild, not a patch. Automated decision-making governance needs to be a design constraint from the first sprint, not a sign-off at the end.
The audit work GDPR demands and the readiness work an AI project needs overlap almost completely. Map your data flows, write down your retention rules, get clear on ownership, and you have done half the groundwork for an AI rollout as a side effect.
Who actually has to comply
The most common mistake we see is a UK or US company assuming GDPR is someone else's problem because their office is not in Europe. It is not about where you are based. It is about whose data you are processing.
You fall under GDPR if either of two things is true. First, if you have an establishment in the EU that processes personal data, even a small branch office, even if the processing happens elsewhere. Second, and this is the one that catches people out, if you offer goods or services to people in the EU, or monitor their behaviour, regardless of where your company is registered. There is no requirement for money to change hands. Pricing your site in euros, offering a French-language option, or running analytics that track EU visitors can be enough on its own.
Size does not get you out of it either. A five-person startup and a five-thousand-person enterprise face the same core obligations under Articles 5 and 6. What scales with size is the extras, like the requirement to appoint a Data Protection Officer, which kicks in above certain thresholds of scale or sensitivity rather than headcount alone.
If you handle data from UK residents as well as EU residents, you are dealing with two regimes, not one. UK GDPR became separate legislation after Brexit, sharing the same principles but enforced by a different body, the Information Commissioner's Office. Data transfers between the UK and EU currently run on adequacy decisions that could, in principle, be revisited, so watch that status rather than assuming today's arrangement holds indefinitely.
The words that actually matter
Legal and engineering teams talk past each other on GDPR more often than you would expect, usually because they are not working from the same definitions. Get everyone onto the same page before you build anything, not after.
Personal data is wider than most people assume. It is not just names and email addresses. It is any information that can be tied back to an identifiable person, including IP addresses, device fingerprints, location history and behavioural patterns, whether alone or combined with something else you already hold. This matters for AI teams, because a dataset you think is anonymised often is not, not if re-identification is technically feasible with the data sitting next to it.
A smaller category, special category data, carries tighter rules again: race or ethnicity, political opinion, religion, trade union membership, genetic and biometric data, health data, sex life and sexual orientation. Processing any of this needs an explicit lawful basis, usually consent, and your security around it has to be visibly stronger. Recruitment tools, health applications and financial risk models run into this constantly.
Then the roles. You are a controller when you decide why and how data gets processed, which is most organisations most of the time. A processor handles data on someone else's instructions, which is where your cloud provider, payroll vendor and most AI tools you buy off the shelf sit. Being a processor does not make you invisible: you remain accountable for a processor's failures, which is why your vendor contracts need proper GDPR clauses in them, not a boilerplate line buried in the terms.
The seven principles everything else hangs off
Article 5 sets out seven principles, and once you understand these properly, most of the rest of GDPR reads as detail rather than mystery.
- Lawfulness, fairness and transparency: you need a lawful basis before you touch any personal data, you cannot use it in ways people would find surprising or unfair, and you have to explain your processing in plain language, not legal jargon.
- Purpose limitation: state your purpose upfront and stick to it, unless you get fresh consent or can show a new use is genuinely compatible with the old one.
- Data minimisation: collect what you actually need, not what might be useful someday. Most organisations over-collect out of habit rather than genuine need.
- Accuracy: keep data current and correct errors promptly when someone flags them.
- Storage limitation: delete or anonymise data once the original purpose is done, with retention schedules that actually get enforced.
- Integrity and confidentiality: protect data with security measures that match the risk, and keep testing them as the threat picture changes.
- Accountability: prove all of the above through documentation and records, on an ongoing basis, including for every processor you rely on.
Transparency is worth dwelling on for AI specifically, because it is the principle that gets tested hardest. Explaining a marketing email is easy. Explaining why a model scored someone the way it did, in language a non-technical person can follow, is a genuinely hard design problem, and GDPR does not let you off the hook for it.
Picking a lawful basis, and where consent fits
Every processing activity needs a lawful basis under Article 6, from a newsletter signup to training a model on support transcripts. Get the basis wrong and the wrong obligations attach to it: the wrong privacy notice, the wrong rights available to the individual, the wrong rules for moving data abroad.
There are six bases to choose from: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Consent is the one everyone reaches for first, and it is often the weakest choice, because people can withdraw it at any moment. Contract works when processing is genuinely necessary to deliver what you promised someone, like fulfilling an order. Legitimate interests is more flexible but needs a documented balancing test, weighing your reason for processing against the impact on the person, and that document has to be honest. Legal obligation covers processing you have no real choice about; public task and vital interests apply in narrower situations most commercial organisations rarely hit.
Consent becomes mandatory, not optional, for special category data and for most direct electronic marketing. Valid consent means a clear affirmative action, not a pre-ticked box and not silence. It has to sit separately from your other terms, written so an ordinary person understands what they are agreeing to, and it needs to be just as easy to withdraw as it was to give.
Cookies deserve a mention because they are the most visible bit of GDPR to most users. Strictly necessary cookies do not need consent. Analytics, advertising and social sharing cookies do, and the implementation has to block them until someone actively opts in, with real category-level control rather than an all-or-nothing toggle. Cookie walls that force a choice between accepting tracking or leaving the site entirely are under increasing scrutiny across Europe.
Proving it: records, DPIAs, DPOs and vendor contracts
Accountability is the principle that turns GDPR from a set of beliefs into a paper trail, and this is where a lot of organisations quietly fall short, not because they are doing the wrong things but because they cannot show it.
Article 30 requires most organisations to keep a record of processing activities: what data you hold, why, who can see it, how long you keep it, and where it goes, including any transfers abroad. Build this as a live register that departments actually maintain, not a spreadsheet filled in once for an audit and never reopened. It pays for itself the day a DSAR arrives, because it tells you exactly where to look.
A Data Protection Impact Assessment becomes mandatory when processing is likely to create high risk: systematic monitoring, large-scale processing of special category data, or automated decisions with a legal or otherwise significant effect on someone. Run a DPIA before you build the thing, because its whole value is catching a design flaw while it still costs an afternoon to fix rather than a rebuild.
Data governance maturity and DPIA quality tend to move together in our experience. Organisations with a real governance function write DPIAs that actually change designs; organisations without one write DPIAs that describe a system nobody in the room is willing to question.
You need a Data Protection Officer if your core activity involves large-scale systematic monitoring or large-scale processing of special category data, and public authorities need one regardless of scale. A DPO has to be genuinely independent, with the time and resources to do the job properly.
Every processor you use, cloud host, AI vendor, payroll provider, needs a written contract with specific GDPR clauses: processing instructions, security requirements, sub-processor rules, and help responding to data subject requests. Read these contracts properly before you sign, because a vendor's failure becomes your liability, not theirs alone.
Data subject rights and the DSAR clock
Individuals get eight rights under GDPR: access, rectification, erasure, restriction, portability, objection, and rights around automated decision-making, plus the right to complain to a regulator. The one you will hear about most often is the Data Subject Access Request, someone asking for a copy of everything you hold on them.
You have one month to respond, extendable by two more if the request is genuinely complex and you tell the person that within the original month. Not knowing where the data lives is not an excuse, and neither is being unable to verify who is asking quickly enough. Both are workflow failures you can fix in advance, not on the day.
Erasure is not absolute. You can refuse it where you need the data for a legal obligation, to defend a legal claim, or to fulfil a contract, but you need to explain the refusal rather than ignore the request. Portability means handing over data in a structured, commonly used, machine-readable format if someone wants to move it to a competitor.
Automated decision-making rights matter more with every AI system you ship. If a model's output produces a legal effect, or something similarly significant for someone, they can ask for human review, put their case, and contest the result. Build that pathway into the system while you are designing it. Retrofitting a human review process onto a model never meant to have one is one of the more painful conversations we have with clients.
A workable DSAR process starts with identity verification that is proportionate rather than paranoid, then routes every request through one team so answers stay consistent across departments. Search has to cover backups and archives, not just the live database, and your processors need to be part of that search too. Redact any third party's personal data that shows up in someone else's file before you hand it over, and keep a note of why.
Security and the 72-hour breach clock
Article 32 asks for security measures that match the risk you have actually assessed, not a generic checklist bought off a shelf. Pseudonymisation, encryption and access controls built on least privilege are the baseline for most organisations. Test these measures regularly: what counted as adequate protection two years ago is not automatically adequate today.
Cloud providers and other processors need to meet an equivalent standard, and you stay accountable when they get breached, so due diligence before you sign with a vendor is not optional. Build audit rights into the contract so you can actually check, rather than trusting the sales deck.
The 72-hour clock starts the moment you become aware of a breach, not once you have finished working out what happened.
Once you know you have had a breach, you have 72 hours to tell your supervisory authority, unless you can genuinely show the risk to people's rights is low. You do not need every detail on day one; you can give an initial report and follow up in phases, but that first notification has to land inside the window regardless. Where the risk to individuals is high, you also have to tell them directly, in plain language, explaining what happened and what they should do about it.
A breach is not just a hacker in your systems. An email sent to the wrong recipient, a lost laptop, a member of staff looking at records they had no reason to see, all of these count, and your incident response process needs to catch them just as reliably as it catches a ransomware attack.
A practical GDPR compliance checklist
Run through this in order. Skipping the first stage is how organisations end up patching compliance forever instead of actually having it.
Start with an honest audit. Map every system that touches personal data: what you collect, where it sits, who can reach it, how long you keep it, and which third parties receive it. This is where shadow IT and half-forgotten databases turn up, and it is the record everything else on this list depends on. While you are at it, check the lawful basis behind every processing activity you find; it is common to discover activities running on consent that should really sit on legitimate interests, or on nothing documented at all.
- Update privacy notices so they explain your actual processing in plain language, not a generic template
- Deploy a cookie consent tool that blocks non-essential cookies until someone opts in, with real category-level control
- Build a DSAR workflow with identity verification, centralised handling and a search process that covers backups and processors
- Put encryption and least-privilege access controls in place, scaled to the sensitivity of what you hold
- Write retention schedules and automate deletion wherever you can, rather than relying on someone remembering
- Set up breach detection and an escalation path that can realistically hit the 72-hour notification deadline
- Review every vendor contract for the GDPR clauses it actually needs, not just a nod to "applicable law"
- Run DPIAs on high-risk processing before you build it, especially anything involving AI or automated decisions
Regulatory guidance shifts, your data estate grows, and the AI systems you build next year will ask new questions of a compliance programme designed for last year's processing. Treat GDPR as something you maintain, not something you finish and file away.
Where this leaves you
GDPR compliance, underneath the terminology, comes down to knowing your own data: what you hold, why you hold it, who can reach it, and how long it stays. Everything else, the DPIAs, the DSAR workflows, the breach procedures, is built on top of that knowledge. Organisations that skip the mapping step tend to do this work twice: once badly under pressure during an audit, and once properly afterwards.
If you are building AI systems or modernising your data infrastructure, this is not a separate workstream to bolt on later. The mapping, retention and governance work GDPR asks for is largely the same groundwork your AI initiatives need to be trustworthy in the first place.
We help organisations do exactly this kind of groundwork before it becomes urgent. If you want a clear picture of where your compliance gaps actually sit, rather than a generic audit report, talk to us.