GDPR basics for UK founders launching an app

Most AI-built apps go live with the same data protection gaps: no ICO registration, a privacy policy copied from another product, analytics firing before anyone has agreed to it, and a waitlist that starts getting marketing emails nobody opted into. None of it is hard to fix. It just needs doing before launch, not after the first complaint.

This checklist covers UK GDPR and PECR (the Privacy and Electronic Communications Regulations, which govern cookies and marketing emails) as the ICO explains them. Every legal point links to the ICO guidance it comes from.

Why it matters

The rules moved recently. The Data (Use and Access) Act 2025 amended UK GDPR and PECR, and several ICO pages now say their guidance is under review because of it. Templates and blog posts from a couple of years ago are often out of date, especially on cookies and lawful bases.

The practical stakes for a small startup are concrete. Not paying the fee can lead to a fixed penalty, which the ICO sets at £400 for a tier 1 organisation, and the Data Protection Act 2018 caps it at 150% of the top-tier fee. A breach starts a 72-hour reporting clock. And the first time a user asks for their data, you have one month to answer.

The moment real people sign up to your Lovable, Bolt or Supabase app, you are holding their emails, names, IP addresses and usage data. The checklist below is what I work through before that happens.

Pay the ICO fee

Under the Data Protection (Charges and Information) Regulations 2018, organisations that use personal information, including sole traders, need to pay a data protection fee unless they are exempt. Since 17 February 2025 the fees are £52 for tier 1, £78 for tier 2 and £3,763 for tier 3.

Tier 1 is for micro organisations with a turnover up to £632,000 or no more than 10 staff. Tier 2 goes up to £36 million turnover or 250 staff. Paying by Direct Debit takes £5 off at every tier. Most early-stage startups are in tier 1.

Lawful basis and records

The ICO is direct about this: you must decide your lawful basis before you start using personal information, and you must document it. The guidance now lists seven bases, including recognised legitimate interest, alongside the familiar consent, contract, legal obligation, vital interests, public task and legitimate interests.

For a typical app, this is where I start the conversation with a founder. It is a starting point to check, not a ruling.

Privacy notice

Your privacy information has to cover your purposes, how long you keep data and who you share it with, and it must include your lawful basis for each purpose. You give it at the point you collect the data. It must be concise, transparent, intelligible and easily accessible, in clear and plain language, and you tell people about any new use before you start it.

The ICO also suggests combining layered notices and just-in-time notices. In an app, that means a short line next to the field that asks for something unexpected, linked to the full notice.

Cookies and analytics

PECR covers cookies and similar storage and access technologies, such as local storage and tracking pixels. You need consent unless one of five exceptions applies: communication, strictly necessary, statistical purposes, appearance, and emergency assistance.

A login session cookie is the clear case for strictly necessary, because it is essential to the service the user asked for. Analytics is where founders get caught. The statistical purposes exception only applies when the sole purpose is collecting aggregate statistics about how your service is used, to improve it. You must give clear and comprehensive information about it and offer a simple means of objecting, free of charge. It does not permit tracking individual visitors, and no exception covers online advertising.

My rule of thumb: if the tool builds a picture of one person, records their individual sessions or feeds an ad platform, I treat it as needing consent.

"use client";
import Script from "next/script";
import { useConsent } from "@/lib/consent"; // your own consent store
 
export function AdTags() {
  const { marketing } = useConsent();
  if (!marketing) return null; // nothing loads until the user opts in
  return <Script src="https://example.com/pixel.js" strategy="afterInteractive" />;
}

Marketing emails

You must not send electronic mail marketing to individuals unless they have specifically consented, with one exception for existing customers, the soft opt-in. It applies when someone bought, or negotiated to buy, a similar product or service from you, and you gave them a simple way to opt out when you collected their details and in every message since.

The soft opt-in does not cover prospective customers or bought-in lists. That is why a waitlist needs explicit consent: people on it have not bought anything yet. In every message you must not hide who you are, and you must give a valid address for opting out.

Suppliers and transfers

Every supplier that handles personal data for you is a processor, and the ICO lists what the contract must include: processing only on your documented instructions, confidentiality, security, sub-processors, help with data subject rights, end-of-contract terms, and audits. Most SaaS tools publish a data processing agreement you can accept.

Data leaving the UK needs a legal route. A restricted transfer must be covered by UK adequacy regulations, appropriate safeguards such as the IDTA or the Addendum, or an exception, and relying on a safeguard means completing a transfer risk assessment. This catches people out on hosting: Vercel Functions default to the iad1 region in Washington, D.C., unless you change it. There is a London region, lhr1, and Vercel recommends running functions close to your database anyway.

Rights requests and breaches

For a subject access request you have one month to respond, extendable by up to two further months for complex requests. In most cases you cannot charge a fee, and you must make a reasonable and proportionate search.

For a breach, you assess the likely risk to people. If a risk is likely, you notify the ICO as soon as possible and, where feasible, within 72 hours. If the risk is high, you also tell the people affected, without delay.

Some apps also need a data protection impact assessment. One is required where processing is likely to result in a high risk, and the ICO's list includes large-scale profiling, and tracking location or behaviour or using innovative technology such as AI when combined with another risk factor.

Common misses

These are common gaps in AI-built apps before launch:

• A borrowed privacy policy. It names suppliers you don't use and misses the ones you do.
• Tags in the root layout. AI tools paste analytics and pixel snippets into the root layout, so they load on every page before any consent.
• Treating the waitlist as customers. The soft opt-in doesn't apply to people who haven't bought.
• Personal data in logs. Emails and tokens end up in server logs and error tracking, which then need the same care as the database.
• Forgetting AI APIs. If prompts include user data, that provider is a processor and belongs in the notice.

Next step

Data protection is one part of going live. My guide to taking a prototype to a product covers the rest, and the app launch checklist puts it all on one page. If you're about to add tracking, read setting up analytics for an MVP first so the consent side is built in.

If your app was built with an AI tool, the free health check flags exposed keys and other risks in a few minutes. When you want it handled properly, my Rescue Sprint gets an AI-built app ready for real users, at a fixed price agreed after a technical assessment (from £750). You can book a call to talk it through.