GDPR for apps: what you actually have to do

The seven obligations that apply to almost every UK app, what a DPIA is and when you need one, and the mistakes that cause most problems.

The App14 team1 min read

This is a practical guide, not legal advice. For anything high-risk, the ICO is the authoritative source and worth reading directly.

The short answer

If your app collects an email address, it processes personal data and UK GDPR applies. The obligations are not onerous for a typical business app, but two of them are launch blockers: a privacy policy and a lawful basis.

The seven obligations

  • Have a lawful basis for every piece of dataUsually contract, legitimate interests, or consent. Write down which applies to what.
  • Collect only what you needData minimisation. Every extra field is a liability with no upside.
  • Tell people what you do with itA privacy policy that describes your actual app, not a template describing something else.
  • Let people get their data out, and get it deletedSubject access and erasure. Build these in; retrofitting is painful.
  • Keep it secureEncryption in transit and at rest, access control, and no production data on anyone's laptop.
  • Get consent properly where consent is the basisOpt-in, unbundled, as easy to withdraw as to give. Pre-ticked boxes are not consent.
  • Have a data processing agreement with anyone handling data for youIncluding your developer, your hosting provider, and your analytics vendor.

This is where most apps go wrong, and it is entirely avoidable.

Analytics and marketing tracking need opt-in consent. Not a banner that says "by continuing you agree", and not a pre-ticked box. Nothing that stores or reads data for those purposes should fire before the user has said yes.

Our own site works this way: consent defaults are set before any tag loads, and the tracking scripts do not run until someone opts in. It is not difficult, it just has to be designed in rather than bolted on.

When you need a DPIA

A Data Protection Impact Assessment is required where processing is likely to result in high risk. In practice that usually means:

  • Special category data at scale: health, biometrics, ethnicity, religion.
  • Systematic monitoring, including location tracking.
  • Children's data.
  • Automated decisions with a significant effect on someone.

The ICO publishes screening criteria. If two or more apply, do one.

The mistakes that cause problems

Common questions

Does my app need a privacy policy?

If it collects any personal data, including an email address or an analytics identifier, yes. It also needs one to pass App Store and Play Store review, so it is a launch blocker regardless.

Do I need a DPIA?

You need one where processing is likely to result in high risk to individuals: large-scale special category data, systematic monitoring, or processing children's data. The ICO publishes the criteria and a screening checklist.

Who is the data controller for my app?

You are, in almost every case. Your developer is a processor acting on your instructions during the build. That distinction matters, and it should be written down in a data processing agreement.

Want to talk it through?

Tell us what you're trying to build and we'll tell you honestly whether a 14-day sprint is the right way to do it.

Free. No commitment. Just a conversation.

About the author

The App14 team · Design and engineering, Appetite Studio

App14 is the 14-day app sprint run by Appetite Studio, a London-registered design and engineering studio. We design, build, and ship production iOS and Android apps in two weeks, at a published fixed price. Everything we write here comes out of work we have actually delivered: the prices are our real prices, the timelines are our real timelines, and the limits are the ones we genuinely hold to.

Our articles are drafted with AI assistance and reviewed by the App14 team before publication. The prices, timelines, delivery record, and client outcomes described are our own.

Read next