Most small websites collect personal data long before anyone writes a privacy notice. A contact form, an analytics snippet, a newsletter signup, a booking widget. UK GDPR governs how you handle what comes in, and for a developer building or maintaining a modest site, the real duties are narrower than the horror stories suggest.

Here is what actually matters day to day, and where to start.

Where UK GDPR sits, and what it covers

UK GDPR is the retained version of the EU regulation, read alongside the Data Protection Act 2018 and enforced by the Information Commissioner's Office. It applies whenever you process personal data: anything that identifies a living person, directly or indirectly. Names, email addresses, IP addresses and cookie identifiers can all count.

You need a lawful basis for each thing you do with that data. Six exist, but most small sites rely on three: consent, contract and legitimate interests. A newsletter needs consent. Delivering an order needs contract. Basic security logging might sit under legitimate interests, provided you have written down your reasoning.

You also have to tell people what you are doing. That is the privacy notice: what you collect, why, how long you keep it, who you share it with, and how to complain. Write it in plain English and keep it current. Templates are a starting point, not a finish line.

Cookies are a PECR question, not a GDPR one

This trips people up. Cookie consent in the UK comes from the Privacy and Electronic Communications Regulations, not UK GDPR. The two work together, but the trigger is different: PECR applies to storing information on someone's device, whether or not it counts as personal data.

The shape of the rule is simple. Set a cookie that is not strictly necessary, and you need consent first. The exempt category covers things like a session cookie keeping a shopping basket working, or one that remembers cookie preferences. It does not cover analytics, advertising or most marketing pixels, whatever an old blog post told you.

So the sequence matters: no non-essential cookie should be set until the user has actively agreed to it.

Building a cookie banner that holds up

Consent has a high bar. It must be freely given, specific, informed and unambiguous, and withdrawing it must be as easy as giving it.

• Do not pre-tick boxes or imply consent through inaction. Scrolling is not consent.
• Offer "Accept all" and "Reject all" at the same level. Burying the reject option behind three clicks does not count.
• Break consent down by purpose. Analytics and advertising are separate choices.
• Keep a way to change the decision later. A persistent "Cookie settings" link in the footer is the usual answer.
• Name the cookies, or at least the categories, and say what each one does.

Technically, the banner has to gate the script. Load analytics only after someone opts in, and make sure your tag manager respects the same state. A banner that hides the visual cookie but fires the script anyway is worse than no banner at all: it is a documented false statement.

Where someone withdraws consent, delete any cookies you have already set.

Keep a record of what people agreed to

If someone asks you to prove consent, "they clicked the banner" is not evidence. You want a timestamp, an identifier for the user or session, and the exact wording and version of the banner they saw.

Store this server-side rather than only in the cookie, and version your banner text so you can tell which wording applied at the time. It is a small amount of engineering that saves a lot of awkwardness later.

Handling data requests without panic

Individuals have rights, and the ones you will meet most are access, rectification, erasure, restriction, objection and portability. An access request is usually called a subject access request.

You have one month to respond, starting the day you receive it. You can extend by up to two months for complex requests, but you must tell the person why within that first month. Responses are normally free. You can charge a reasonable fee only where a request is manifestly unfounded or excessive, and you should be ready to justify that.

1. Verify identity if you have genuine doubts, but do not use verification as a delay tactic.
2. Search everywhere: the main database, the support inbox, backups you can reasonably query, and third-party tools with an export function.
3. Redact other people's data before sending anything.
4. Reply in a portable format, such as CSV or PDF.
5. Log the request date and your response.

If part of a request cannot be fulfilled, for example data you are legally required to keep, explain the reason plainly and mention the right to complain to the ICO.

The quieter obligations

• Data minimisation. Do not collect a date of birth if you only need to confirm someone is over 18.
• Retention. Decide how long each type of data lives and actually delete it. An automated job beats a good intention.
• Security. Encryption in transit, sensible access controls, and no personal data in log files you keep forever.
• Processors. If a third party handles data on your behalf, you need a written agreement. Most providers publish a data processing addendum you can sign.
• Breaches. If a breach is likely to risk people's rights, report it to the ICO within 72 hours of becoming aware. Keep an internal log of every breach, minor ones included.

A starting point for this week

Pick one page of your site and trace the data. Where does it go when someone submits a form? Which scripts load on page view, and do they set anything before consent? Write the answers down.

Then fix the obvious things: gate your non-essential scripts, make rejecting as easy as accepting, publish a privacy notice that matches what the code actually does, and start logging consent and requests properly. Document the decisions you make along the way, including why you chose a particular lawful basis.

None of this has to be perfect on day one. It has to be accurate, and it has to be improvable. Data protection is a maintenance job, not a launch task. For anything involving health data, children, or large-scale profiling, bring in a professional adviser rather than guessing.

Photo: Sabrina_Ripke_Fotografie / Pixabay