GDPR Compliant Mobile App Development: What You Actually Need to Build In

When EU and UK founders ask us about GDPR, they usually ask the wrong question first. They ask "do we need to be GDPR compliant?" The answer is almost always yes — if you process personal data of EU or UK residents, GDPR applies to you regardless of where your company is incorporated.

The better question is: what does GDPR compliance actually require at the engineering level?

Most of what's written about GDPR for mobile apps is written by legal teams, not software engineers. It gives you principles without implementation. This guide does the opposite — it tells you specifically what you need to build into your app, at the architecture level, before you write a line of production code.

Why GDPR is an architecture decision, not a legal checkbox

What it costs to retrofit GDPR compliance vs build it in from day one

We've done both, and the difference is stark. Building GDPR compliance into a new app from scratch adds roughly 15–20% to the initial development cost. Retrofitting it onto an existing app — rewriting data models, untangling spaghetti database relationships to make user deletion possible, rebuilding consent flows — typically costs 3–5x that amount, and usually requires taking the app offline for a period.

The financial case for building it correctly from day one is overwhelming. The regulatory case is even clearer: GDPR fines can reach 4% of global annual revenue or €20 million, whichever is higher. The Irish DPC fined Meta €1.2 billion in 2023. These are not theoretical numbers.

The specific mobile app features that create GDPR obligations

If your app does any of the following, you have GDPR obligations:

• Collects a name, email address, or phone number at registration
• Tracks location (even approximately)
• Uses analytics tools like Firebase, Mixpanel, or Amplitude
• Sends push notifications (which require a device token tied to a user)
• Stores any behavioural data (what screens users visit, what they tap, how long they stay)
• Integrates with advertising platforms or attribution tools

In practice, this means virtually every consumer mobile app has GDPR obligations.

The 6 GDPR requirements that directly affect how you build your app

1. Establishing lawful basis for processing (consent vs legitimate interest)

Before collecting any piece of data, you need a documented lawful basis for it. For most mobile apps, the two relevant options are:

Explicit consent: The user actively agrees to a specific, clearly worded request. This is required for marketing communications, non-essential analytics, and third-party data sharing. Critically, consent must be unbundled — you can't bury it in a 40-page terms of service. Each processing purpose needs its own consent toggle.

Legitimate interest: You can process data without explicit consent if you have a genuine legitimate business reason and it doesn't override the user's rights. Account security, fraud prevention, and core functionality delivery typically qualify. Marketing and behavioural analytics typically do not.

Engineering implication: Your database needs a consent record table that logs exactly what each user has consented to, when, and which version of the privacy policy was in effect at that time. Every data processing operation needs to be traceable back to one of these records.

2. Data minimisation: only collect what you demonstrably use

GDPR's data minimisation principle says you should collect only what is "adequate, relevant and limited to what is necessary." In practice, many apps collect far more than they need — residual fields from API responses, analytics events that were "nice to have", third-party SDKs that silently harvest data in the background.

Engineering implication: Before your first sprint, map every data point your app will collect. For each one, document: what it is, why you need it, which feature depends on it, and what happens if you don't collect it. Remove anything that doesn't have a clear, specific answer. This process is called a Data Protection Impact Assessment (DPIA) and it's legally required for high-risk processing.

3. The right to erasure: can your database actually delete a user completely?

This is where most apps fail technically. The right to erasure means a user can request that you delete all personal data you hold about them, and you must do so within 30 days.

That sounds simple until you look at how most apps are architected. Data is spread across a relational database, a caching layer (Redis), an analytics platform (Firebase, Mixpanel), a CRM (HubSpot, Salesforce), an email platform (Mailchimp, SendGrid), and potentially a data warehouse (BigQuery, Snowflake). A deletion request needs to cascade across every one of those systems.

Engineering implication: Design your deletion architecture before you build. Create a user deletion service that is aware of every system holding personal data and can trigger deletion in all of them with a single API call. Test it early and often. Many teams discover at launch that deletion is impossible without manual intervention because data is stored in immutable audit logs or third-party systems that don't support deletion APIs.

4. Data portability: building the export functionality

Users have the right to receive a copy of their personal data in a commonly used, machine-readable format (typically JSON or CSV). They also have the right to have that data transferred directly to another service if technically feasible.

Engineering implication: Build a data export endpoint as a first-class feature, not an afterthought. It should compile every piece of personal data associated with a user account — profile data, behavioural history, transaction records, preferences — and return it as a downloadable file. Don't require users to email a support address and wait three weeks.

5. Data residency: EU data staying within EU infrastructure

If you process data from EU residents, that data generally must stay within the EU or be transferred to countries with an adequacy decision. This has major implications for infrastructure choices.

Engineering implication: Deploy your backend infrastructure in EU regions — AWS eu-west, GCP europe-west, Azure West Europe. If you use third-party services (Stripe, Twilio, SendGrid), verify that they offer EU data residency options and that you've configured them correctly. This isn't automatic. Using a global CDN without configuring EU routing can result in EU user data touching US servers, which creates a compliance gap.

6. Privacy by design: what it means at the code architecture level

Privacy by design requires privacy to be considered from the beginning of the design process, not added later. At the engineering level:

• Default to minimum data collection — your app should work with the least amount of data possible by default
• Encrypt personal data at rest and in transit — AES-256 at rest, TLS 1.2+ in transit, as a baseline
• Separate personal identifiers from behavioural data — pseudonymisation. Your analytics database shouldn't contain email addresses
• Access control — apply the principle of least privilege. Only roles that genuinely need access to personal data should have it

The Data Processing Agreement: what it is, when you need one, what to put in it

If you use any third-party service that processes personal data on your behalf — cloud hosting, analytics, email, payments — you need a Data Processing Agreement (DPA) with that vendor. A DPA is a contract specifying exactly how the vendor will handle the data, what their security obligations are, and how they'll respond to a data breach.

Most major vendors (AWS, Google Cloud, Stripe, Mailchimp) have standard DPAs available in their compliance documentation. You need to sign them — having the DPA available isn't sufficient. Keep a record of every DPA you've signed, with whom, and when.

GDPR requirements by app category

Healthcare apps handling patient data

Healthcare apps are among the highest-risk categories under GDPR because health data is classified as "special category" data, which triggers stricter obligations. You cannot rely on legitimate interest for special category data — explicit consent is almost always required. You also need a Data Protection Officer (DPO) if you process health data at scale.

Fintech apps processing payment or financial information

Financial data is sensitive but not automatically "special category" under GDPR. However, it's almost always high risk enough to require a DPIA. PCI-DSS compliance (for payment card data) runs alongside GDPR — the two frameworks are complementary, not interchangeable.

Consumer apps with location tracking or behavioural analytics

Location data is treated as sensitive under GDPR because precise location can reveal information about religious practice, health conditions, political views, and domestic situations. Real-time location tracking requires explicit, granular consent — a consent that can be withdrawn at any time.

Children's apps and the extra requirements under UK GDPR

Under the UK's Age Appropriate Design Code (AADC), apps likely to be accessed by children must apply the highest privacy settings by default and not use design nudges or dark patterns to obtain consent. The ICO actively enforces the AADC and has fined TikTok and others.

How Ortem handles GDPR on every EU and UK project

What is included in our standard EU project delivery

Every EU and UK project we deliver includes:

• A Data Protection Impact Assessment (DPIA) completed during discovery
• A data flow map documenting all personal data processing activities
• A consent management architecture with version-controlled consent records
• A complete user deletion service tested across all integrated systems
• EU-region infrastructure configuration by default
• Third-party SDK audit with DPA documentation for every vendor

DPA template and signing process

We sign a mutual DPA with every EU client as standard. Our DPA template has been reviewed by EU-qualified data protection counsel and covers: data categories, processing purposes, security obligations, sub-processor disclosures, breach notification timelines, and data subject request handling.

---

GDPR compliance isn't a legal hurdle to clear before launch — it's a foundation that protects your users and your business. Build it in correctly from day one, and it costs a fraction of what it costs to fix later.

If you're planning an EU or UK mobile app and want to make sure the architecture is GDPR-compliant before your first sprint, book a free GDPR compliance consultation with our team. Our cybersecurity team can also review your data handling architecture end-to-end.

Frequently asked questions

Does my mobile app need to be GDPR compliant? If your app processes personal data of EU or UK residents — which includes names, email addresses, location data, device identifiers, and behavioural data — then yes, GDPR applies regardless of where your company is based. Even a US-registered startup with EU users must comply.

What is a GDPR-compliant consent mechanism for a mobile app? A compliant consent mechanism must be: freely given (not required to use the app for core functionality), specific (separate consent for each processing purpose), informed (plain-language explanation of what you're collecting and why), and unambiguous (an active opt-in action, not a pre-ticked box). It must also be as easy to withdraw as it was to give.

What happens if my app is not GDPR compliant? Regulatory fines can reach €20 million or 4% of global annual revenue, whichever is higher. Beyond fines, enforcement can include orders to cease data processing, mandatory audits, and significant reputational damage.

Does GDPR apply to apps built by non-EU companies? Yes. GDPR has extraterritorial scope. If you process personal data of EU or UK residents — even from a US or Australian entity — GDPR applies. You are also required to appoint an EU Representative if you regularly process EU personal data without an EU establishment.

What is the difference between GDPR and UK GDPR for app developers? UK GDPR is the version of the EU regulation retained in UK law after Brexit. For most practical purposes, the requirements are identical. The key differences: UK GDPR is enforced by the ICO (not EU national DPAs), UK adequacy decisions are separate from EU decisions, and the UK's Age Appropriate Design Code creates additional requirements for apps accessible to children.