Three data protection authorities, CNIL, the California attorney general, and the FTC, are ramping up enforcement against mobile apps. If your team manages a mobile app that processes personal data, you're now facing a decision: how aggressively should you invest in compliance infrastructure?
This isn't just about doing nothing or overhauling everything. The right path depends on your app's data practices, user base, and risk tolerance. Here's how to choose.
The Decision You're Facing
You need to determine your compliance posture for mobile app data protection. Three factors drive this decision:
- Processing scope: What categories of personal data does your app collect, and how much control do third parties have over that data?
- Jurisdictional exposure: Where are your users, and which regulatory regimes apply to your processing?
- Consent architecture: Does your app rely on consent as its legal basis for processing, or do you process under other grounds like contract or legitimate interest?
Choosing incorrectly creates two types of risk. Underinvest, and you're exposed to enforcement action from regulators who now view mobile apps as a priority target. Overinvest, and you'll waste engineering resources on compliance measures that don't materially reduce your risk.
Key Factors That Affect Your Choice
Before you select a path, assess these variables:
Data collection volume and sensitivity
Mobile apps typically collect location, contacts, messages, and device identifiers. CNIL explicitly views device identifiers as personal data, which means even apps that think they're collecting "anonymous" data may be processing personal information under GDPR. If your app collects biometric data, health information, or children's data, your risk profile shifts immediately into the high-compliance category.
Third-party data sharing
Count how many third parties receive data from your app: advertisers, analytics providers, social networks, and attribution platforms. Each relationship creates a compliance obligation. If you share data with partners who make independent processing decisions, you need data processing agreements that meet GDPR Article 28 standards. If those partners operate outside the EEA, you also need transfer mechanisms like Standard Contractual Clauses.
Consent mechanism quality
Many mobile apps fail to obtain valid consent because they use pre-ticked boxes, bury consent requests in privacy policies, or bundle consent for multiple purposes into a single yes/no prompt. Under GDPR, valid consent requires a clear affirmative action, granularity by purpose, and easy withdrawal. If your current consent flow doesn't meet those standards, you're already non-compliant.
App store requirements
Google Play now offers voluntary security assessments that let compliant apps display a trust mark. Apple's App Tracking Transparency framework requires explicit consent before accessing the Identifier for Advertisers. These platform-level requirements create a compliance floor regardless of what data protection law requires.
Path A: Baseline Compliance (Low Data Sharing, Established Legal Basis)
Choose this path if:
- Your app collects only data necessary for core functionality
- You process under contract or legitimate interest, not consent
- You share data with fewer than five third parties
- Your users are primarily in jurisdictions with mature enforcement (EU, California, Japan)
What you implement:
Conduct a streamlined Data Protection Impact Assessment focused on identifying high-risk processing. You don't need a 50-page DPIA for a simple utility app, but you do need a documented risk analysis that covers data minimization, storage limitation, and security measures.
Update your privacy policy to meet GDPR Article 13 disclosure requirements. This means explaining what data you collect, why you collect it, who receives it, and how long you retain it. Write in plain language, "we collect your location to show nearby restaurants" beats "geolocation data is processed for service optimization purposes."
Implement storage limitation by setting retention periods for each data category. If you collect email addresses for account recovery, delete them 90 days after account closure. If you log IP addresses for fraud prevention, delete them after 30 days. Document these periods in your DPIA.
Secure personal data with encryption in transit and at rest. For mobile apps, this means HTTPS for all API calls and encrypted local storage for any cached personal data.
When this path fails:
If your app monetizes through Behavioural Advertising or shares data with ad networks, you can't rely on legitimate interest as your legal basis. You'll need to move to Path B.
Path B: Consent-Driven Compliance (Ad-Supported Apps, Broad Data Sharing)
Choose this path if:
- Your app shares data with advertisers or analytics platforms
- You monetize through Behavioural Advertising
- You process device identifiers for cross-context tracking
- You operate in multiple jurisdictions with different consent standards
What you implement:
Everything from Path A, plus:
Build a consent mechanism that meets GDPR's requirements for valid consent. This means:
- No pre-ticked boxes or implied consent
- Granular choices by purpose (analytics separate from advertising)
- Equal prominence for "accept" and "reject" options
- A mechanism for withdrawal of consent that's as easy as granting it
If you use third-party SDKs for advertising, you need to control when those SDKs initialize. Don't let the ad SDK fire before the user grants consent. This requires technical integration work, you can't just drop an SDK into your app and assume it's compliant.
Implement just-in-time consent requests. Instead of asking for location permission on first launch, ask when the user triggers a feature that needs location. This improves consent rates and demonstrates purpose limitation.
Establish data processing agreements with every third party that processes user data on your behalf. These agreements must specify the subject matter, duration, nature, and purpose of processing. They must also require the processor to implement appropriate security measures and assist you with data subject requests.
If you share data with partners outside the EEA, implement transfer mechanisms. Standard Contractual Clauses are the most common approach, but you'll need to conduct a transfer impact assessment to verify that the destination country provides adequate protection.
When this path fails:
If you collect sensitive categories of data (health, biometric, children's data), or if you process data for high-risk purposes like automated decision-making, you need Path C.
Path C: High-Risk Compliance (Sensitive Data, Automated Decisions, Children)
Choose this path if:
- Your app processes special categories of data under GDPR Article 9
- You make automated decisions that produce legal or similarly significant effects
- Your app targets children under 16 (or under 13 in the U.S.)
- You've already received a regulatory inquiry or user complaint
What you implement:
Everything from Paths A and B, plus:
Conduct a comprehensive DPIA that involves your data protection officer, legal counsel, and app developers. For high-risk processing, GDPR Article 35 requires you to consult your supervisory authority before you begin processing if the DPIA shows high residual risk.
Implement Data Protection by Design and Data Protection by Default. This means building privacy controls into your app architecture from the start, not bolting them on later. For children's apps, this means age verification before data collection and parental consent mechanisms.
If you make automated decisions, implement the right to human review under GDPR Article 22. Users must be able to contest the decision and obtain human intervention.
For sensitive data, you need explicit consent, a higher standard than the unambiguous consent required for regular personal data. This typically means a separate, clearly-worded consent request that explains why you need the sensitive data.
Establish a process for handling data subject requests (access, deletion, portability, restriction). For mobile apps, this often means building an in-app mechanism for users to download or delete their data, not just an email address they can contact.
Summary Matrix
| Factor | Path A | Path B | Path C |
|---|---|---|---|
| Data sharing | <5 third parties | Ad networks, analytics | Sensitive data processors |
| Legal basis | Contract, legitimate interest | Consent | Explicit consent, legal obligation |
| Consent mechanism | Not required | Granular, prior consent | Explicit consent with enhanced disclosure |
| DPIA requirement | Streamlined assessment | Standard DPIA | Comprehensive DPIA with authority consultation |
| Data categories | Functional data only | Device IDs, behavioral data | Special categories, children's data |
| Withdrawal mechanism | Not applicable | Easy withdrawal, equal prominence | Enhanced withdrawal with confirmation |
| Third-party governance | Basic agreements | Data processing agreements with transfer mechanisms | DPAs plus subprocessor controls and audit rights |
| Typical enforcement risk | Low (if legal basis is solid) | Medium (consent quality scrutinized) | High (priority enforcement target) |
The regulatory focus on mobile apps isn't temporary. CNIL is considering drafting specific guidelines for mobile app privacy compliance, which signals that enforcement will intensify. Choose your path based on your actual data practices, not your comfort level with compliance work. The cost of getting this wrong isn't just a fine, it's the engineering time you'll spend rebuilding your data architecture under regulatory pressure.
