In short
GDPR applies to any organisation processing personal data of people in the EU, regardless of where the organisation is. In practice it requires knowing what data you hold and why, having a lawful basis for each purpose, telling people plainly in a privacy notice, keeping data no longer than necessary, and being able to provide, correct or delete someone's data on request. This is general information, not legal advice.
What counts as personal data
Broader than most people assume. Anything relating to an identifiable person: name, email, phone, address — and also IP address, device identifiers, cookie identifiers, location, and any identifier that can be linked back to someone.
That last group is why analytics, error tracking and server logs are in scope, and why teams who think they hold no personal data usually do.
Special categories — health, biometrics, political opinions, religion, sexual orientation, trade union membership — carry stricter requirements and should generally be avoided unless the product genuinely needs them.
Lawful basis comes first
You need a lawful basis for every purpose you process data for, decided before you start rather than justified afterwards.
Consent. Freely given, specific, informed, unambiguous, and withdrawable as easily as given. Required for non-essential cookies and marketing email. Note that consent obtained through an interface making refusal harder than acceptance is not valid — which is why most cookie banners fail.
Contract. Processing necessary to deliver what someone signed up for. This covers most core product functionality, and it is the basis teams underuse — you do not need consent to send an order confirmation.
Legitimate interests. A flexible basis requiring you to balance your interest against the person's rights, and to document that assessment. Often appropriate for security and fraud prevention.
Legal obligation. Retaining invoices for tax purposes, for instance.
The practical error is defaulting to consent for everything. It is the most fragile basis, since it can be withdrawn, and it is frequently the wrong one.
The rights you must be able to honour
People can ask, and you generally have a month to respond.
Access — a copy of their data and information about how it is used.
Rectification — correcting inaccurate data.
Erasure — deletion, where no overriding basis to keep it exists.
Portability — their data in a machine-readable format, where processing is based on consent or contract.
Objection — particularly to direct marketing, which must be honoured absolutely.
Restriction — pausing processing while a dispute is resolved.
The practical implication: you need to be able to find everything about one person across every system. Analytics, support tool, email platform, backups, logs, spreadsheets. Teams discover on the first request that they cannot, which is when this becomes urgent rather than theoretical.
The privacy notice
A genuine requirement, and one that is usually copied from elsewhere and therefore wrong.
It must say who you are, what data you collect, why, on what lawful basis, who you share it with, how long you keep it, what rights people have, and how to complain to a regulator.
Written plainly. A notice nobody can understand does not satisfy the requirement to inform, and the substance of yours will differ from whoever you copied — different tools, different retention, different processors.
Processors and transfers
Every third party handling personal data on your behalf is a processor: your host, analytics, email platform, error tracker, CRM, support tool, payment provider.
You need a data processing agreement with each. Most major providers publish one that forms part of their terms, so this is often a matter of confirming rather than negotiating.
Where data leaves the EU, transfers need an appropriate safeguard — standard contractual clauses or an adequacy decision. Check where your providers actually process data, since it is frequently not where you assumed.
Retention
Data may be kept only as long as necessary for the purpose.
This means having a documented retention period for each type, and actually deleting when it expires. "Keep everything indefinitely" is not a policy, and it is the most common gap on small sites.
Remember backups. A deletion request that leaves data in backups for another year is worth deciding about deliberately — the usual approach is documenting that backups are deleted on a defined cycle and are not restored selectively.
Where small sites usually fall short
Analytics loading before consent. The banner appears after tracking has already fired, which makes the consent meaningless.
Contact form data with no retention policy, accumulating for years in an inbox.
A copied privacy policy describing tools they do not use and omitting ones they do.
No process for a request. No documented route, nobody responsible, no ability to search across systems.
Embedded third-party content — fonts, video, maps, social embeds — loading before consent and sending IP addresses to a third party.
Newsletter signups with a pre-ticked box, or bundled into another action.
None of these require expensive remediation. They require someone spending a day working out what is actually happening.
A practical starting point
List every system holding personal data and what each holds. Write down why you hold it and the lawful basis. Set a retention period for each and implement the deletion. Rewrite the privacy notice to describe what is actually true. Confirm processing agreements with your providers. Fix consent so nothing non-essential loads first. Decide who handles a request and how you would find someone's data.
That sequence is achievable in a couple of days for a typical small site, and it addresses most of the realistic exposure.
One caveat worth stating plainly: this is general information, not legal advice. For anything with meaningful risk — health data, financial data, large-scale processing, or an actual complaint — talk to a lawyer.
If you want an outside read on what your site is actually collecting, book a call.
Common questions
Does GDPR apply to my small website?
If you process personal data of people in the EU, yes, regardless of where your organisation is based. Personal data is broader than most assume — it includes IP addresses, cookie identifiers and device identifiers, which is why analytics, error tracking and server logs are in scope.
Do I always need consent to process personal data?
No, and defaulting to consent is a common mistake since it is the most fragile basis and can be withdrawn. Contract covers core product functionality — you do not need consent to send an order confirmation. Legitimate interests often covers security and fraud prevention, with a documented balancing assessment.
What rights do people have over their data?
Access to a copy, rectification of inaccuracies, erasure where no overriding basis exists, portability in a machine-readable format, objection — absolute for direct marketing — and restriction during a dispute. You generally have a month to respond, which means being able to find someone's data across every system.
What do most small sites get wrong about GDPR?
Analytics loading before consent so the banner is meaningless, contact form data accumulating for years with no retention policy, a copied privacy notice describing tools they do not use, no process for handling a request, and embedded fonts, maps or video sending IP addresses to third parties before consent.
How long can I keep personal data?
Only as long as necessary for the purpose you collected it for, with a documented retention period per data type and actual deletion when it expires. 'Keep everything indefinitely' is not a policy. Decide deliberately how backups are handled, since deletion requests interact with them.
