Gdpr Mobile

GDPR on Mobile

Instructions

GDPR is mostly a product / process problem, but the mobile app is where most user-facing obligations land (notice, consent, export, deletion).

1. Lawful Basis, Per Purpose

Never treat "consent" as the default. Map each processing purpose to one of:

Maintain a short Record of Processing Activities (RoPA): for each field, a purpose + basis + retention + recipients. Your DPO / legal team will ask for this.

2. Data Subject Rights — What to Build

Ship these flows; don't gate them behind emailing support:

• Access (Art. 15) — export the user's data in a portable format.
• Rectification (Art. 16) — edit profile / corrections.
• Erasure / "right to be forgotten" (Art. 17) — account deletion.
• Restriction (Art. 18) — pause processing without deleting.
• Portability (Art. 20) — machine-readable export (JSON, CSV).
• Objection (Art. 21) — opt out of legitimate-interest processing.
• Automated decisions (Art. 22) — if you make them, provide a human-review path.

3. Export / DSAR Path

// Flow (any platform):
// 1. User taps Settings → Privacy → Download My Data.
// 2. Client posts /me/export; server enqueues a job.
// 3. Job gathers from all systems (primary DB, analytics, backups in scope, logs).
// 4. Server uploads a signed, time-limited URL; notifies the app.
// 5. User downloads a password-protected ZIP with JSON / CSV / attachments.

Implementation notes:

• Include all systems of record — analytics, support ticket, CRM, push tokens.
• 30-day regulatory window; target under 7 days operationally.
• Re-authenticate the user (password + MFA) before starting the export — DSARs are a phishing target.

4. Deletion Path

// Account deletion must be reachable in the app (Apple / Play require this as of 2022 / 2024).
// 1. Confirm identity and intent (password + "type my email" pattern).
// 2. Kick off async deletion job.
// 3. Immediately: invalidate tokens, sign the user out on all devices.
// 4. Within SLA: scrub PII from primary stores; anonymize analytics; delete backups per policy.
// 5. Retain only what a legal basis requires (tax records, fraud prevention), documented.
// 6. Email confirmation when deletion completes.

Hard requirements:

• App Store Guideline 5.1.1(v) and Play Data Safety both require in-app deletion.
• The path cannot be deeper than Settings → Account → Delete Account.
• "Deactivate" is not deletion; keep them as separate flows.

5. Data Retention

Per category, document the shortest defensible retention:

• Session & auth logs: 90 days unless under investigation.
• Analytics events: 14 months at Google Analytics' default; shorter is usually better.
• Crash reports: 90 days.
• Support tickets: 2–3 years after last interaction.

Run a scheduled job that enforces retention; don't rely on manual cleanups.

6. International Data Transfers

• After Schrems II, transfers outside the EEA need a valid mechanism (SCCs, adequacy decision).
• For US vendors, check Data Privacy Framework status at the point of each transfer — it has been litigated before.
• Document subprocessors and transfer mechanisms in your privacy policy.

7. Mobile-Specific Notices

• Show the privacy notice before first data collection, not buried in Settings.
• Material changes require active notice on next launch.
• iOS Privacy Nutrition Labels and Privacy Manifests (PrivacyInfo.xcprivacy) must match your real processing — mismatches are an App Store reject and a GDPR Art. 13 problem.
• Android Play Data Safety form must match the in-app disclosures.

8. Breach Notification

• 72-hour clock to the supervisory authority starts on awareness, not confirmation.
• Have an in-app path to notify affected users where required (Art. 34).
• Pre-write the runbook: who decides, who drafts, who presses send.

9. Vendor / SDK Management

Every SDK that handles personal data = a data processor.

• Sign a DPA (Data Processing Addendum) before integration, not after.
• Disable SDK features you don't use (many default to maximum collection).
• Review annually; SDKs change scope silently.

Checklist

• A RoPA exists mapping each field to purpose, basis, retention, recipients.
• Each processing purpose has a lawful basis (not defaulted to consent).
• In-app account deletion is reachable within Settings → Account.
• In-app data export produces a complete, authenticated, machine-readable archive.
• A retention job enforces documented retention per data category.
• Subprocessors and international transfer mechanisms are listed in the privacy policy.
• iOS Privacy Manifest and Play Data Safety match the real processing.
• A breach notification runbook exists and has been rehearsed.
• Every SDK handling personal data has a signed DPA.