How to handle GDPR in your UK consumer app

Most founders meet GDPR as a document they are told to buy. That is the wrong end of the problem. Handling GDPR in a UK consumer app is really six practical jobs the product has to do: know what data you hold, pick a lawful basis for each use of it, ask permission properly for anything that tracks people, let users get their data out and delete their account, know what you will do in the first hours of a breach, and write the whole thing down. A privacy policy is the output of that work, not a substitute for it. This guide walks through each job in the order we tackle them when we build.

Two quick points of framing. First, the law that applies to you is the UK GDPR sitting alongside the Data Protection Act 2018, regulated by the Information Commissioner’s Office. Second, we build software, we are not your solicitors, and anything with real regulatory exposure deserves proper legal review. What follows is the engineering and product view of what compliance actually looks like in a shipped app.

What does GDPR mean for a UK consumer app in practice?

For a UK consumer app, GDPR means you need a documented reason for every piece of personal data you process, genuine consent before any non-essential tracking runs, working routes for users to access and delete their data, a breach plan that meets the reporting deadline, and a written record of all of it. Almost none of that is legal drafting. Most of it is product work.

That reframing matters because it changes who owns the task. If compliance is a document, it belongs to a lawyer you email once. If compliance is a consent screen, a delete account button, an export route, and a data map, it belongs to your backlog, and it needs to be scoped and costed like any other feature. In practice we treat it as a feature set, which is why it shows up in our breakdown of how much an app costs to build in the UK in 2026 rather than in a footnote.

Job one: map the data before you write anything

You cannot apply a rule to data you have not listed. So the first pass is a plain inventory: every field the app collects, every event you log, every third-party kit in the build that sends something off the device, and where each of those things ends up.

The part founders underestimate is the third-party list. A typical consumer app ships with an analytics kit, a crash reporter, a push notification service, an authentication provider, and often an attribution or advertising kit, and every one of them is processing personal data on your behalf. Each needs a contract, each needs to appear in your privacy policy, and each is a decision you can reverse cheaply now and expensively later. We have seen a single advertising kit added in week two turn into the reason a launch slipped, because nobody had asked what it collected.

Do this in a spreadsheet. Columns for the data, the purpose, the lawful basis, the retention period, the processor, and the country the data sits in. That sheet is the source of every later answer, including your record of processing activities.

Job two: pick a lawful basis, and do not default to consent

UK GDPR gives you six lawful bases for processing personal data, and you need at least one for every purpose. The ICO’s guide to lawful basis walks through all six. The common instinct is to reach for consent for everything, and that instinct is usually wrong.

Consent is the most demanding basis to hold up. It has to be freely given, specific, informed, unambiguous, and as easy to withdraw as it was to give, and if the user withdraws it you have to stop. For the core of a consumer app, the processing you need in order to deliver the service the user signed up for usually sits better under contract, and analytics or product improvement often sits better under legitimate interests with a documented balancing test. Reserve consent for the things that genuinely require it, most obviously tracking.

Getting this right early saves a specific and painful class of bug: a product built on the assumption that consent covers everything, then discovering that a user who declines analytics has also, structurally, declined the thing that makes the app work.

Job three: consent for trackers, under PECR not GDPR

Here is the rule that catches mobile teams. The consent requirement for cookies, software development kits, and anything else that stores or reads information on a user’s device comes from the Privacy and Electronic Communications Regulations, not from GDPR itself, and it applies to apps as much as to websites. The ICO’s guidance on cookies and similar technologies is the reference.

Practically, that means three things in the build. Anything not strictly necessary to provide the service the user asked for must not run until the user has agreed. Refusing has to be as easy as accepting, so no prominent Accept button next to a buried link to a settings page. And the choice has to be changeable later, which means a real privacy screen in the app, not a one-time modal on first launch.

The engineering consequence is that your analytics and advertising kits cannot initialise at app start. They have to be gated behind the consent state, which is a genuine architectural decision and one of the reasons retrofitting consent into a shipped app is more expensive than building it in. On iOS this sits alongside, and is separate from, Apple’s own App Tracking Transparency prompt and the privacy questions you answer at submission, which we cover in the App Store review preparation guide.

Job four: build deletion and export as product features

Users have rights to see their data, correct it, delete it, and take it elsewhere. You have one month from receipt to respond to a request, extendable by up to two further months for complex or numerous requests provided you tell the person inside the first month. That is set out in the ICO’s guidance on the right of access.

The cheap way to meet that deadline is to never handle it by hand. Two features do most of the work. An in-app delete account flow that genuinely removes the account and cascades through your backups and your processors, and an export route that assembles everything you hold about a user into a file. Both app stores expect account deletion from any app that offers account creation anyway, so you are building it regardless. Building it once, properly, converts a legal obligation with a clock on it into a button.

The word “genuinely” is doing work in that sentence. Deletion has to reach the analytics platform, the crash reporter, the email tool, and the backups, not just the row in your main database. Map that path while you are still designing the account system, because unpicking it later means touching every service the account touched. It is the same lesson that makes account linking the expensive part of social login: the account is never only in one place.

Job five: have a breach plan before the breach

If a personal data breach happens and there is a risk to people’s rights and freedoms, you have to report it to the ICO without undue delay and within 72 hours of becoming aware of it, and if the risk is high you also have to tell the affected people without undue delay. The ICO sets out the process in its personal data breaches guidance.

Seventy two hours is not long once you factor in a weekend and the time it takes to understand what actually happened. So decide the answers now, while nothing is on fire. Who makes the call on whether it is reportable. Who has the ICO reporting form and the account details. How you reach every affected user quickly, which usually means checking that you can email your entire user base without asking an engineer to write a script. And a log of incidents, because you have to record breaches even where you decide they are not reportable.

Two more items belong in this section. Fines under UK GDPR reach up to £17.5 million or 4% of total annual worldwide turnover, whichever is higher, which is the number that concentrates minds, though for a small consumer app the realistic risk is a reputational one and an ICO investigation that eats months. And if you use processors outside the UK, which almost every app does, you need a valid transfer mechanism such as the UK International Data Transfer Agreement or the UK Addendum to the EU standard clauses, plus a transfer risk assessment. Your cloud provider and analytics vendor will publish theirs.

Job six: write it down and keep it current

The last job is the least loved and the easiest to fake. You need a record of processing activities, a privacy policy that matches what the app actually does, a data protection impact assessment where processing is likely to be high risk, and, for most organisations, payment of the ICO data protection fee. The ICO publishes a self assessment that tells you whether the fee applies and which tier you fall into.

There is one more category worth flagging early. If your consumer app is likely to be accessed by children in the UK, the ICO’s Age Appropriate Design Code applies, and it is genuinely prescriptive about defaults, profiling, and nudge techniques. That is a scoping decision, not a policy tweak, so establish it before design rather than after.

Finally, note that UK data protection law was amended by the Data (Use and Access) Act 2025, and the ICO has been updating its guidance to match. If you are reading a compliance checklist written before then, check it against current ICO guidance rather than taking it at face value. This is the part of compliance that decays, and the reason we revisit the data map at each significant release instead of once at launch.

What to do next

Handling GDPR in a UK consumer app is a build problem wearing a legal costume. Map the data, choose a lawful basis per purpose, gate every non-essential tracker behind real consent, ship deletion and export as features, agree the breach plan while it is still theoretical, and keep the records current. Do those six and the privacy policy writes itself from the spreadsheet you already have.

If you would rather have the consent layer, the deletion path, and the data map designed into the product from the first sprint instead of retrofitted after a review, send us a project brief and we will scope it with the rest of the build. And if you are still deciding what the app is made of, our guide to choosing a tech stack for an MVP covers the platform choices that quietly determine how hard all of this is.