2026 Edition · Sources checked August 19, 2026 · Independent educational resource · Not legal advice
Home › LGPD for Mobile Apps
LGPD for Digital Products

LGPD for Mobile Apps and Digital Platforms: A Practical Compliance Guide

Mobile privacy is more than a privacy-policy screen. An app can collect account data, device identifiers, location, push tokens, photos, contacts, crash logs, behavioral events, advertising IDs and data generated by third-party SDKs. Each permission, SDK, API call, backend service and advertising integration can create a separate LGPD purpose, recipient, legal-basis decision or international transfer.

Published: August 19, 2026Last reviewed: August 19, 2026Reading time: ~24 minutesBy LGPD Brazil Editorial Team

Quick Answer: What does LGPD compliance look like for a mobile app?

Start with the app's real data flows rather than the App Store or Google Play listing. Identify every category of personal data collected by the app, backend and embedded SDKs; define each purpose; assign an Article 7 or Article 11 legal basis where applicable; minimize device and permission access; document vendors, advertising and analytics SDKs; map international transfers; provide an accurate privacy notice; support data-subject rights and deletion; secure the app and backend; and create an incident process. Operating-system permission is not the same thing as LGPD consent. Apple ATT, App Store privacy disclosures and Google Play Data Safety are separate platform requirements that can support transparency, but they do not replace the LGPD analysis.

Key Takeaways

  • A foreign app can be subject to the LGPD. Territorial scope can apply even when the developer is outside Brazil.
  • Permissions are not legal bases. Camera, location, microphone or ATT permission is one technical layer; LGPD lawfulness is another.
  • SDKs are part of your privacy architecture. Crash, analytics, ad, authentication and AI SDKs can add new recipients and transfers.
  • Device identifiers can be personal data in context.
  • Precise location can be highly intrusive even though location is not automatically an Article 5 sensitive-data category.
  • Biometric and health data require Article 11 analysis.
  • Children are a major 2026 priority. LGPD Article 14 and the ECA Digital create an additional layer for apps likely accessed by minors.

Does the LGPD Apply to a Foreign App?

It can. Article 3 applies regardless of the medium used for processing, the country where the organization is headquartered, or the country where the data is located when one of the law's territorial triggers is present.

For mobile and digital platforms, common triggers include processing aimed at offering or providing goods or services to individuals located in Brazil, processing personal data of individuals located in Brazil, and collecting personal data when the person is located in Brazil.

App-store availability alone is not the only question. Analyze whether the product is actually offered to people in Brazil, whether Brazilian users are onboarded, whether Brazil is a target market and where relevant collection occurs.

A U.S. SaaS app, European subscription app or Asian mobile game can therefore require a Brazilian privacy analysis even without a Brazilian subsidiary.

Map the App Data Journey, Not Just the Database

A typical mobile-app privacy journey

Install → Device / App Instance → Permissions → Account → SDK Events → Backend → Push / Email → Payments → Support → Advertising / Analytics → Vendors → International Processing → Retention / Deletion

Mobile teams often know which database tables they control but not which data leaves the device through third-party libraries. Your processing inventory should cover both first-party code and embedded dependencies.

App layerExamplesLGPD question
Installation/deviceIP, device model, OS version, app instance, identifiers.Which identifiers are needed, linked and retained?
PermissionsLocation, camera, microphone, contacts, photos.Is access necessary for the feature and supported by an LGPD purpose/basis?
AccountName, email, phone, login IDs, profile.Which fields are necessary to create or operate the account?
BehaviorScreen views, taps, searches, sessions, feature usage.Analytics, personalization or profiling? Is the person reasonably informed?
MarketingPush token, advertising ID, audience membership, campaign events.What legal basis, opt-out and platform tracking requirements apply?
Sensitive featuresBiometrics, health or other Article 5 sensitive data.Which Article 11 hypothesis applies?
Backend/vendorsCloud, analytics, crash, support, AI, payments.Roles, contracts, security, retention, subprocessors and transfers.

What Counts as Personal Data in a Mobile App?

The LGPD defines personal data broadly as information related to an identified or identifiable natural person. An app should therefore not limit its inventory to obvious fields such as name and email.

Device and app identifiers

Advertising identifiers, user IDs, account IDs, installation identifiers, push tokens and similar values can become personal data when they are linked or reasonably linkable to an identifiable person or persistent profile.

The correct question is not “does this look like a person's name?” It is whether the identifier participates in identifying, linking, singling out or profiling a natural person within the processing context.

Location data

Location can clearly be personal data and can reveal highly intimate patterns—home, work, clinics, schools, religious sites or daily routines. However, location is not automatically listed among the sensitive personal-data categories in Article 5(II).

“Not statutorily sensitive” does not mean “low risk.” Continuous or precise location can justify stronger necessity, transparency, retention and security safeguards because of its real-world impact.

Biometrics and health

Biometric data linked to a natural person and health data are expressly sensitive under the LGPD. An app using face recognition, biometric templates, health tracking or medical information should stop the ordinary Article 7 analysis and determine which Article 11 hypothesis applies.

Crash logs and telemetry

Crash reports can contain device identifiers, IP addresses, account IDs, URLs, filenames, screen state or user-provided content. Do not assume “diagnostics” means anonymous data. Review the actual SDK payload and configuration.

App Permission Is Not the Same as LGPD Consent

This distinction is one of the most important practical rules for mobile teams.

OS Permission

iOS or Android allows or denies access to a protected resource such as location, camera, microphone or contacts.

LGPD Legal Basis

Explains why the controller is legally permitted to process personal data for a specific purpose.

Transparency

Explains purpose, controller, sharing, duration, rights and other material information to the user.

If an app asks iOS for location permission, that does not itself determine whether the LGPD basis is consent, contract, legitimate interest or another applicable hypothesis. Likewise, another LGPD legal basis does not entitle the app to bypass an operating-system permission requirement.

Apple App Tracking Transparency (ATT)

Apple says developers must obtain permission through App Tracking Transparency for data collected in the app and used to track the user across apps or websites owned by other companies under Apple's tracking definition.

That is a platform rule. An ATT “Allow” response should not automatically be treated as a complete LGPD consent record for every advertising, analytics or data-sharing purpose. LGPD consent has its own requirements, including being free, informed, unequivocal and tied to determined purposes.

ATT ≠ automatic LGPD consent, and LGPD legal basis ≠ permission to ignore ATT. Treat the two layers separately and design the flow so both are satisfied where applicable.

Request permissions at the right moment

Privacy-friendly app design asks for access when the feature actually needs it. Apple's current App Review Guidelines also say apps should respect permission settings, avoid manipulating users into unnecessary access, and offer alternatives where possible—for example, manual address entry when location is declined. That design approach aligns well with LGPD necessity and minimization.

Third-Party SDKs: The Hidden Privacy Supply Chain

Many mobile apps send more data through SDKs than through their own explicitly written network code. Common SDK categories include analytics, crash reporting, advertising and attribution, push notifications, authentication, payments, customer support, fraud/security, maps/location, A/B testing, feature flags and AI functionality.

For every SDK, document what data it receives, why, whether data is linked to a user, whether the vendor uses data independently, how long it retains data, which subprocessors are involved, which countries receive the data and how incidents and rights requests are handled.

App-store responsibility for SDKs

Apple requires App Store privacy answers to account for relevant data practices of third-party partners whose code is integrated into the app. Apple also uses privacy manifests and required-reason API declarations for specified SDK and API scenarios.

Google Play's User Data policy similarly says developers are responsible for user-data handling by third-party code, including SDKs and third-party AI integrations, and the Data Safety section must account for data collected or shared by those libraries.

“The SDK vendor handles privacy” is not a defensible app-governance model. Your app team still needs to understand what the dependency does inside your product.

Read LGPD Vendor Compliance.

Analytics, Attribution, Advertising and Profiling

Product analytics

Measuring feature adoption, crashes or aggregate usage can be materially different from cross-app advertising profiling. Start by defining the exact event stream and whether the data is linked to an account or persistent identifier.

Legitimate interest can be considered for some lower-risk analytics when the Article 10 balancing analysis supports it, but the label “analytics” is not a legal basis.

Advertising IDs and attribution

Advertising identifiers and attribution SDKs can support campaign measurement and remarketing, but they can also create persistent or cross-context profiles. The app should document the purpose, recipient, legal basis, platform permission, retention and opt-out behavior.

Google Play currently requires developers using the Android Advertising ID for advertising-related purposes to comply with its Advertising ID rules, and its User Data policy restricts inappropriate linking of persistent device identifiers with resettable advertising identifiers or personal and sensitive data.

Cross-app or cross-site tracking

Cross-context tracking increases privacy impact because it combines behavior beyond the user's direct relationship with one app. On iOS, ATT is a separate platform control for Apple's defined tracking activities. Under LGPD, the controller still needs purpose, legal basis, necessity, transparency and rights analysis.

Automated profiling

Article 20 can become relevant when decisions are made solely on automated processing of personal data and affect the person's interests, including decisions intended to define personal, professional, consumer or credit aspects or personality characteristics.

Not every recommendation algorithm is automatically an Article 20 decision. Document what the model or rules actually decide, whether there is a meaningful effect on the user, and what information can be provided about the criteria and procedures subject to trade and industrial secrecy.

Push Notifications: Small Token, Large Privacy Impact

Push notification systems often use device or app tokens and a vendor push service. A push token may be personal data in context when it is linked to an account, device or identifiable profile.

Separate at least three purposes: security and account alerts; service or transactional notifications; and promotional or behavioral marketing.

Also review notification content. Sensitive health, financial or account information displayed on a locked screen can create a privacy risk even when the backend processing is otherwise lawful.

App Store and Google Play Privacy Disclosures

Store disclosures can help create discipline, but they do not replace the LGPD privacy notice or processing inventory.

Apple App Privacy

Apple currently requires developers distributing on the App Store to explain data-handling practices in App Store Connect and to include relevant practices of integrated third-party partners. Apple also requires a privacy-policy URL for iOS apps.

Google Play Data Safety

Google Play requires developers to provide accurate Data Safety information and states that this includes data collected or processed by third-party SDKs. Google Play also requires a comprehensive privacy policy in Play Console and within the app.

Consistency is a compliance control. Your App Store privacy details, Google Play Data Safety form, in-app disclosures, public privacy policy, SDK inventory and actual network traffic should tell the same story.

A release-management process should therefore include privacy review whenever a new SDK, permission, identifier, AI feature, advertising integration or data field is added.

Account Creation and Account Deletion

LGPD rights and app-store policies now overlap operationally in a useful way.

Apple's current App Review Guidelines say apps supporting account creation must also offer account deletion within the app. Apple says deletion should remove the account and associated personal data that the developer is not legally required to retain.

Google Play's User Data policy similarly requires apps that allow account creation to provide a clear account-deletion path, including an in-app path and an external web resource, subject to the policy's scope and exceptions.

Platform account deletion is not identical to every LGPD erasure request. The LGPD may permit or require retention in specific circumstances. Your workflow should distinguish data that can be deleted, data that must be retained lawfully, data held by vendors and data associated with subscriptions or legal claims.

See LGPD Data Subject Rights.

Children, Adolescents and the ECA Digital: A Major 2026 Update

Mobile apps directed to or likely accessed by children or adolescents need more than an ordinary privacy checklist.

Article 14 of the LGPD requires personal-data processing involving children and adolescents to be carried out in their best interests. ANPD Enunciado No. 1/2023 says Article 7 or Article 11 legal bases can be used as applicable, provided the child's or adolescent's best interests are observed and prevail in the concrete case.

The ECA Digital is now in force

Brazil's Law No. 15,211/2025—the ECA Digital—creates a separate digital-child-protection framework. ANPD states that the law has been in force since March 17, 2026 and applies to technology products and services directed to children and adolescents in Brazil or likely to be accessed by them, regardless of where the provider is located.

The framework includes obligations relating to age assurance, parental supervision, protective design, games and commercial advertising, among other matters.

Age assurance is still being further regulated

ANPD published preliminary age-assurance guidance in March 2026 and ran a further public input process from May to July 2026. The current Regulatory Agenda still lists the age-assurance regulation as in progress.

In June 2026, ANPD also began monitoring major app stores and operating systems—including Apple, Google and Microsoft—regarding age-assurance and age-signal obligations under the ECA Digital.

Do not assume an App Store or Google Play age rating alone satisfies the Brazilian framework. The ECA Digital creates legal obligations beyond ordinary store metadata, and detailed ANPD regulation is still evolving.

ANPD's 2026–2027 enforcement priorities also include children and adolescents in the digital environment, targeted commercial advertising, protective design and defaults, artificial intelligence and emerging technologies.

Data Subject Rights Inside an App Architecture

A rights workflow should reach all systems, not just the user-profile table.

RequestApp systems to checkCommon failure
AccessAccount DB, analytics, support, subscriptions, vendors.Export includes profile data but ignores tickets or behavioral records.
CorrectionProfile, CRM, support, downstream vendors where applicable.Corrected value is overwritten by an old integration.
DeletionAccount, content, vendors, marketing audiences, backups and retention logic.UI says “deleted” but SDK or vendor copies remain active.
Consent withdrawalFeature flags, SDK initialization, marketing and permissions as relevant.Consent record changes but processing continues.
OppositionNo-consent processing where LGPD requirements are challenged.No internal owner can review the legal-basis decision.

International Transfers in Mobile Apps

Mobile architecture is frequently global by default: analytics in one country, crash reporting in another, cloud backend in another and support staff accessing data remotely elsewhere.

Map the exporter, importer, destination, purpose and Article 33 mechanism for relevant Brazil-originating international transfers. Resolution No. 19/2024 remains the central ANPD regulation for international transfers.

As of August 2026, ANPD lists the European Union as adequate under Resolution No. 32/2026. Do not assume another destination is adequate unless ANPD has made that determination or another valid Article 33 route applies.

See LGPD International Data Transfers.

Security and Incident Response for Apps

Article 46 requires appropriate technical and administrative measures. For mobile products, security should cover the app, APIs, cloud, admin tools and the dependency chain.

  • secure authentication and session management;
  • least-privilege API and administrator access;
  • secure local storage and secret management;
  • TLS and secure backend transport;
  • dependency and SDK review;
  • logging without unnecessary sensitive content;
  • rate limiting and abuse controls;
  • secure development and vulnerability remediation;
  • backup and recovery planning; and
  • rapid vendor incident escalation.

See LGPD Data Breach Notification.

20-Point LGPD Checklist for Mobile Apps and Digital Platforms

1. Confirm territorial scope. Document how Article 3 applies to Brazil-facing users and processing.
2. Build an app data map. Device, account, permissions, SDKs, backend, vendors, marketing and retention.
3. Inventory every SDK. Analytics, crash, ads, attribution, push, AI, payments, support and authentication.
4. Classify data. Ordinary, sensitive, children-related, biometric, health, location and identifiers.
5. Define each purpose. Do not combine security, analytics, advertising and personalization into one vague purpose.
6. Assign the legal basis. Use Article 7 or Article 11 as applicable and document the reasoning.
7. Separate OS permission from legal basis. Design both the technical permission flow and LGPD analysis.
8. Minimize permissions. Request protected resources only when the feature actually needs them.
9. Review ATT and advertising tracking. Where relevant, meet Apple's tracking requirements separately from LGPD.
10. Validate App Store privacy disclosures. Include relevant third-party SDK practices and keep answers current.
11. Validate Google Play Data Safety. Ensure declarations reflect first-party and third-party SDK behavior.
12. Publish an accurate privacy notice. Explain material app data, purposes, sharing, retention, transfers and rights.
13. Review push notifications. Separate security/service alerts from promotional messaging and avoid exposing sensitive content.
14. Review profiling and automated decisions. Determine whether Article 20 applies to consequential automated decisions.
15. Map children and adolescent access. Apply Article 14 and assess separate ECA Digital obligations where relevant.
16. Build access and deletion workflows. Reach account data, SDKs, vendors, audiences and retention exceptions.
17. Map international transfers. Cloud, SDKs, support and AI services frequently process data abroad.
18. Secure the full architecture. Mobile client, APIs, admin systems, cloud and dependency chain.
19. Create an incident process. Vendor escalation, risk assessment, records and notification if required.
20. Add privacy review to release management. New SDKs, permissions, AI features, data fields or countries should trigger reassessment.

Common Mobile-App LGPD Mistakes

“The user allowed location, so we have LGPD consent.”

Not necessarily. Platform permission and LGPD legal basis are separate questions.

“ATT consent means our ads are LGPD compliant.”

No. ATT addresses Apple's tracking rules; LGPD still requires purpose, legal basis and the other statutory requirements.

“The analytics SDK only collects technical data.”

Verify the payload. Device identifiers, IP addresses, account IDs and event histories may make telemetry personal data.

“Precise location is not sensitive under Article 5, so it is low risk.”

Incorrect. The statutory category and real privacy risk are different questions.

“The SDK vendor is responsible for its own privacy.”

Your app still needs vendor and role analysis, disclosure, contractual controls, transfer mapping and accurate store declarations.

“Deleting the account deletes everything.”

Not unless the workflow reaches vendors, analytics profiles, user-generated content, audiences and other relevant systems while respecting lawful retention.

“Children can just self-declare age.”

Do not rely on that assumption for the new ECA Digital framework. Age-assurance requirements are now a live 2026 regulatory issue and ANPD guidance is still evolving.

Turn Your Mobile Privacy Stack Into a Documented LGPD Process

The Brazil LGPD Compliance Playbook — 2026 Edition includes a Data Mapping Worksheet, Processing Inventory / ROPA, Legal-Basis Decision Record, Legitimate Interest Assessment, Vendor Privacy and Security Review, Cookie and Tracking Inventory, Data-Subject Request tools, International Transfer Review, Security Incident Assessment, Retention Schedule, 100-point audit and 30-day implementation roadmap.

Get the Brazil LGPD Compliance Playbook · $47

Frequently Asked Questions

Does the LGPD apply to a foreign mobile app available in Brazil?

It can. Article 3 applies regardless of headquarters country when relevant processing occurs in Brazil, is aimed at offering or providing goods or services to individuals located in Brazil, involves personal data of individuals located in Brazil, or data is collected in Brazil under the statutory conditions.

Is an iOS or Android permission the same as LGPD consent?

No. OS permission controls access to a device resource. LGPD consent is a legal basis with its own conditions. An app may need both a platform permission and a separate LGPD legal-basis analysis.

Does Apple ATT automatically satisfy LGPD consent?

No. ATT is an Apple platform requirement for defined tracking activities. It does not automatically establish every element of LGPD consent or another lawful basis. Likewise, an LGPD basis does not remove Apple's ATT requirements.

Are mobile SDKs part of LGPD compliance?

Yes when they process personal data. Map what each SDK collects, purpose, role, retention, security, subprocessors and international transfers.

Is precise location sensitive data under the LGPD?

Location can be personal data and highly intrusive, but location is not automatically one of the sensitive-data categories listed in Article 5(II). Context can still justify strong safeguards.

Are biometrics sensitive personal data?

Biometric data linked to a natural person is expressly included in the LGPD's sensitive personal-data definition and requires Article 11 analysis.

Does Google Play require a privacy policy and Data Safety disclosure?

Yes. Google Play currently requires a privacy policy and accurate User Data and Data Safety disclosures, including relevant data handling by integrated SDKs.

Does Apple require account deletion?

Apple's current App Review Guidelines require apps that support account creation to offer account deletion within the app, subject to Apple's detailed policy and lawful retention requirements.

Does Google Play require account deletion?

Google Play's current User Data policy requires apps that allow account creation within the app to provide a clear account-deletion path, including an in-app route and an external web resource, subject to the policy's scope and exceptions.

What changes for children's apps in Brazil in 2026?

LGPD Article 14 remains relevant, and the ECA Digital is now in force. It creates additional obligations for technology products and services directed to or likely accessed by children and adolescents, including age-assurance and protective-design requirements that ANPD is continuing to regulate and monitor.

Do app SDKs create international transfers?

They can. If Brazilian personal data is transferred to a foreign SDK provider, cloud service or other recipient, map the flow and identify an applicable Article 33 mechanism under the current ANPD framework.

Official Sources Used for This Guide

Editorial note: This article is an independent educational resource, not legal advice. It was reviewed against the current compiled LGPD, official ANPD materials and current public Apple and Google developer policies available on August 19, 2026. Apple and Google platform rules are contractual and platform requirements and should not be confused with Brazilian law. The ECA Digital age-assurance framework remains under active ANPD regulatory development, so child-focused and age-assurance implementations require a fresh source check before deployment.