If your business commissions or runs a mobile app that handles personal data of people in the UK, UK GDPR applies from the first workshop to the last update. In practice that means five things: decide what data you need and why, choose a lawful basis for each use, tell users clearly, build security and user rights into the app, and have a breach plan ready before launch. This guide walks through each one in the order a project meets them.
TL;DR
- Treat data protection as a design input. The ICO expects it to be considered from kick-off through to post-launch, not added at the end.
- Collect only what the app needs. Document a lawful basis for every processing activity, and ask for device permissions only when a feature requires them.
- Get consent right for non-essential tracking and analytics, and give users an easy way to exercise their rights, including deletion.
- Check every third-party SDK, encrypt data in transit, and complete a DPIA where the risk to people is high.
- If a breach occurs, you may have 72 hours to report it to the ICO, so write the response plan before launch.
Table of Contents
- What UK GDPR asks of an app owner
- Start at discovery: map the data before you design screens
- Choose and document a lawful basis
- Keep permissions and data collection to what the app needs
- Privacy information, consent and tracking
- Managing developers, SDKs and data leaving the UK
- Security: what "appropriate measures" looks like in an app
- User rights: build them into the app
- If a breach happens
- A pre-launch checklist
- Perspective
- Getting help with your app
- FAQ
- Sources
What UK GDPR asks of an app owner
Most of the confusion comes from one point: the law does not regulate "apps". It regulates the use of personal information. An app is simply one of the places where that use happens, and it tends to be a busy one. Accounts, location, contacts, photos, push tokens, device identifiers and analytics events can all be personal data.
The ICO's guidance on data protection by design and by default says the UK GDPR requires you to embed data protection practices into every aspect of your use of personal information. At each stage of the product lifecycle you must apply appropriate technical and organisational measures so the data protection principles work in practice and people's rights are protected.
The ICO has also published guidance written specifically for the people who build products. Its privacy in the product design lifecycle pages address product and UX designers, software engineers, QA testers and product managers. They assume your organisation is the data controller, which means you are the party responsible for complying. They also say data protection should be considered at kick-off, research, design, development, launch and post-launch.
Two practical consequences follow:
- You carry the responsibility, even when an agency builds the app. If your organisation decides why and how users' data is used, you are the controller. Your development partner builds what you specify, so your brief needs to specify privacy.
- Compliance is a project workstream. It needs an owner, a budget line and a place in the plan, in the same way testing does.
Start at discovery: map the data before you design screens
The cheapest time to make a privacy decision is before anything is built. A short data-mapping exercise during discovery should answer these questions for every feature:
- What personal data does this feature collect or generate?
- Why do we need it, and what would the feature lose without it?
- Where is it stored, who can access it, and which third parties receive it?
- How long do we keep it, and how will a user delete it?
This is the exercise that exposes the surprises: an analytics SDK that quietly collects device identifiers, a marketing tool that receives email addresses, a "nice to have" location request that no feature depends on. It also feeds your privacy notice, your records of processing and, where needed, your impact assessment.
At Pocket App we build this thinking into our Discover, Design, Develop and Deploy process, so questions about data sit alongside questions about users and features rather than arriving in the final week.
Choose and document a lawful basis
Every use of personal data needs a lawful basis. UK law firm Harper James advises app developers to consider and document a valid basis for processing user data. The available bases are consent, contractual necessity, legal obligation, vital interests, public task and legitimate interests, and each processing activity has to be justified under one of them.
For a typical commercial app, the choices often look like this:
| What the app does | Basis often considered | Practical note |
|---|---|---|
| Creates an account and delivers a paid service | Contractual necessity | Limit it to data the service genuinely needs |
| Sends order or booking updates | Contractual necessity | Keep service messages separate from marketing |
| Marketing emails or push notifications | Consent or legitimate interests, depending on the channel and rules | Take specific advice on electronic marketing rules |
| Non-essential analytics and advertising tracking | Consent | Do not start tracking before the user chooses |
| Fraud prevention and security logging | Legitimate interests | Record your reasoning |
The table is a starting point, not a legal opinion. The right basis depends on your context, and choosing it is a decision for your data protection lead or legal adviser. The point for a project team is that the decision is made, written down and reflected in the product. A basis chosen after launch is usually a basis that does not match what the app already does.
Keep permissions and data collection to what the app needs
Mobile apps have a feature that websites lack: operating-system permissions for camera, microphone, location, contacts and more. Requesting them is a data collection decision, and the UK government has set out an expectation here.
The GOV.UK Code of Practice for app store operators and app developers says developers should not request permissions and privileges that are not functionally required by the app. A functional requirement is one necessary for the user-facing operation of the app. It does not include background operation that gives the user no feature or improved experience. The same code says the primary function of an app should keep working if a user disables optional functionality and permissions.
In design terms, that gives you a simple set of rules:
- Ask for a permission at the moment the user reaches the feature that needs it, with a short explanation of why.
- Never gate the whole app behind a permission that only one feature uses.
- Design a graceful fallback for users who say no, such as typing a postcode instead of sharing location.
- Review the permissions list before every release, because features and SDKs change it.
Privacy information, consent and tracking
Users should be able to see, in plain language, what you collect and why. Harper James notes that privacy policies must be fully compliant with the UK GDPR, which often requires a range of details to be disclosed, and that getting this right can be particularly challenging for certain apps, such as those aimed at children. If your audience includes children, take legal advice early, because it affects design as well as wording.
For delivery, layer the information. Put a short, specific notice at the point of collection, and link to the full privacy notice from the sign-up screen and from a settings page.
Analytics, advertising and the cookie rules
Apps often feel exempt from cookie rules because there is no browser. They are not. PECR, the Privacy and Electronic Communications Regulations, contains specific requirements on cookies and on the use of personal data for electronic marketing, and the same logic reaches similar technologies used in apps.
UK legal commentary from Sprintlaw says consent for non-essential cookies and similar technologies generally needs to be freely given, specific, informed and given through a clear positive action. It adds that pre-ticked boxes, vague wording, or forcing users to accept tracking to use a standard feature can cause problems. It also says the main risk is starting non-essential tracking before the user has made a real choice, and that the strictly necessary exception is read narrowly, with analytics or convenience features often wrongly labelled "essential".
The build implications are concrete:
- Initialise analytics and advertising SDKs only after consent, not at app launch.
- Make "accept" and "reject" equally easy to reach.
- Store the user's choice and let them change it from settings at any time.
- Keep a list of what is genuinely essential, such as session security, and be able to justify each item.
These are the rules most often discovered late, because the analytics SDK was added in week two and nobody asked when it starts running.
Managing developers, SDKs and data leaving the UK
A modern app is built partly from other people's code. Each SDK for analytics, crash reporting, payments, maps, push notifications or advertising may receive personal data, so each belongs in your data map.
The GOV.UK code says developers should have a process to update and monitor their software dependencies for known vulnerabilities in all published versions of their app. That has a cost implication: dependency monitoring continues after launch, so it belongs in your maintenance arrangement, not only in the build.
A workable checklist for third parties:
- List every SDK and backend service, and what data each receives.
- Record whether each acts as a processor on your instructions or as a controller in its own right.
- Have written contract terms in place with your development partner and with service providers that process data for you.
- Establish where each provider stores and processes data, and take advice on the safeguards needed if data leaves the UK.
- Remove anything that no longer earns its place.
Step 4 depends on the facts of each provider and is a point for your legal adviser, not something to settle in a sprint planning meeting.
Security: what "appropriate measures" looks like in an app
Security is part of data protection by design, and the GOV.UK code gives usable detail. It requires developers to use industry standard encryption in their apps, specifically for data in transit and where an app needs to encrypt data locally.
Beyond encryption, a pre-launch security review normally covers authentication and session handling, secure storage of tokens on the device, API access controls, logging that does not capture personal data unnecessarily, and penetration testing. We cover these in more depth in our guides on mobile app security best practices for UK businesses and security considerations for app development.
When you need a DPIA
The ICO's guidance says that under Article 25(1) you must consider the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risks to people's rights and freedoms. It also says that if your use of personal information is likely to result in a high risk to those rights and freedoms, you must complete a data protection impact assessment.
Apps that handle health information, children's data or precise location, or that profile users at scale, are the ones to look at first. Do the DPIA during design, when its findings can still change the product. Our article on four things to consider before you launch a secure mobile app is a useful companion at this stage.
User rights: build them into the app
Users can ask what you hold about them, ask for it to be corrected or deleted, and object to certain uses. The ICO says you must have accessible, clear, easy-to-use, documented and evidenced methods to facilitate and respond to rights requests. It suggests considering the easiest route for people, for example through a product's accompanying mobile app or online account.
Two rules deserve a specific mention in your requirements:
- Objection. Under Article 21, individuals can object to processing at any time, and the ICO says the right is absolute for direct marketing, including online advertising that involves personal data processing.
- Deletion. The GOV.UK code says developers shall provide users with a mechanism to request deletion of personal data gathered by an app.
In product terms, that means a settings screen with "Download my data" and "Delete my account" options, a marketing preferences panel, and a back-office process that finds the user's data in every connected system. If deletion only works in the app database but not in your CRM or analytics tool, the feature is not finished. Our guide to data privacy best practices for app developers covers the engineering side.
If a breach happens
The ICO's guide to personal data breaches says the UK GDPR places a duty on all organisations to report certain breaches to the ICO within 72 hours of becoming aware of them, where feasible. If a breach is likely to result in a high risk of adversely affecting individuals' rights and freedoms, you must also inform those individuals without undue delay. You must keep a record of every breach, whether or not you notify, documenting the facts, the effects and the remedial action taken.
A 72-hour clock leaves no time to work out who does what. Before launch, agree:
- who can declare an incident, and who is on call;
- how your development partner alerts you and how fast;
- how you can revoke keys and sessions, or push an emergency update;
- who drafts the ICO report and the user message;
- where the breach log lives.
Run the plan through once as a tabletop exercise. It takes an hour and usually finds two gaps.
A pre-launch checklist
| Area | Question to answer before release |
|---|---|
| Data map | Do we know every data item, purpose, recipient and retention period? |
| Lawful basis | Is a basis documented for each purpose? |
| Permissions | Does every permission map to a user-facing feature? |
| Consent | Does non-essential tracking wait for a clear choice? |
| Notices | Is the privacy information specific, layered and current? |
| Third parties | Are SDKs and processors listed, contracted and monitored? |
| Security | Is data encrypted in transit, and has the app been tested? |
| DPIA | Have we assessed whether one is needed, and acted on it? |
| Rights | Can users access, delete and object from within the app? |
| Breach | Is there a tested 72-hour plan? |
Perspective
Privacy problems in apps are rarely caused by bad intent. They come from decisions made quickly: an SDK added for a demo, a permission requested on first launch because it was easier, a deletion route nobody scoped.
After more than 300 projects for brands across retail, charity and healthcare, our view is that the answer is process, not paperwork. We run strategic discovery before design begins, and we use it to map data, challenge permissions and agree the technical approach with you. We are technology agnostic, so we recommend the platform that suits the project, and that includes how it handles data.
The result we aim for is an app your users trust and your data protection lead can sign off without a scramble the week before launch. Privacy done at the start costs less, and it makes a better product.
Paul
Getting help with your app
If you are planning a new app or want an existing one reviewed, we can help you build these decisions into the project. Our Discover, Design, Develop and Deploy process starts with strategic discovery, where data, permissions and technical choices are agreed before build. For apps already live, our Mobile App Clinics are a way to have an expert look at what you have. You can also see how we approach mobile app development more broadly.
To talk through your project, get in touch via Pocket App.
FAQ
Does UK GDPR apply to my app if I am not based in the UK?
It can, if you offer the app to people in the UK or monitor their behaviour. The rules depend on where users are, not only where you are. If you serve users across several countries, take legal advice on which regimes apply.
Who is responsible for compliance, my business or the agency that builds the app?
Usually the business that decides why and how users' data is used, the controller. The ICO's product design guidance assumes your organisation is the controller. Your agency should build in line with your requirements, and your contract should set out each side's role.
Do I need consent for analytics in my app?
Non-essential analytics and advertising tracking generally need a clear, informed, positive choice from the user before they start, according to UK legal commentary on cookie notices for apps. Strictly necessary functions are treated differently, but that exception is read narrowly. Your legal adviser can confirm how it applies to your setup.
When must I report a data breach?
Certain breaches must be reported to the ICO within 72 hours of becoming aware of them, where feasible. If the breach is likely to put individuals at high risk, you must tell them without undue delay. You must record every breach, whether or not you report it, as the ICO's breach guide explains.
Do I need a DPIA before launching?
You must complete one if your use of personal information is likely to result in a high risk to people's rights and freedoms. Health data, children's data and large-scale profiling are common triggers. Do it during design so the findings can shape the product.
Sources
- ICO: Data protection by design and by default
- ICO: Privacy in the product design lifecycle
- ICO: How do we help people exercise their rights?
- ICO: Right to object
- ICO: Personal data breaches, a guide
- GOV.UK: Code of practice for app store operators and app developers
- Harper James: GDPR for apps, legal guidance for UK app developers
- Sprintlaw: Cookie notice requirements for UK mobile app developers
- Multilaw: Data protection guide, England and Wales