For anyone hiring the development of an app or system, few things are as scary as two headlines: a data breach with your company's name on it and a fine from Brazil's data protection authority (ANPD). In 2026, these two risks stopped being a distant hypothesis and became a real part of the math on any software project.
Security is no longer a technical detail; it has become a buying objection. Before signing a contract, the client asks how data will be protected, where it is stored and what happens if there is an incident. Answering these questions well is what separates a trustworthy vendor from a legal liability.
This guide takes the builder's angle. It is not a generic legal read: it is the step-by-step of how to turn the requirements of Brazil's data protection law (LGPD) and mobile app security best practices into architecture, code and process, from the first sprint to post-launch.
In this article
- The LGPD and ANPD Landscape in 2026
- OWASP Mobile Top 10 and Secure by Design
- Data Encryption: at Rest and in Transit
- Authentication and Access Control
- Privacy by Design in the Development Cycle
- Sensitive Data: Health and Finance
- Compliance Checklist
- How FWC Builds with Security
- Frequently Asked Questions
- Next Step
The LGPD and ANPD Landscape in 2026
The educational phase of the LGPD is over. For years, the ANPD acted as a market educator, publishing guides and opening public consultations before punishing anyone. That tolerance period has ended, and the authority has shifted into enforcement mode.
In 2026, the ANPD consolidated as a regulatory agency, with reinforced technical, administrative and financial autonomy. In practice, that means more structure, more sanctioning power and an enforcement agenda with clear targets for the 2026-2027 period.
The authority's priority map concentrates on four fronts: data subject rights with a focus on biometric, health and financial data; protection of children and adolescents in the digital environment; data processing by public bodies; and artificial intelligence. Teams building apps in these areas are on the front line.
Fines follow the legal cap: up to 2% of the company's revenue in Brazil, limited to R$ 50 million per infraction. The final amount is set by a dosimetry analysis that weighs severity, good faith, cooperation and the security measures the company adopted -- or failed to adopt.
| Sanction | What it is | Note |
|---|---|---|
| Warning | Notice with a deadline to correct | First measure in milder cases |
| Simple fine | Up to 2% of revenue, capped at R$ 50M per infraction | Set by dosimetry |
| Daily fine | Amount per day until the irregularity stops | Subject to the same cap |
| Public disclosure | Public announcement of the penalty applied | Direct reputational damage |
| Blocking or deletion | Suspension or removal of the data involved | Immediate operational impact |
Another practical change hits the development team directly: incident notification. Faced with a breach that may pose relevant risk to data subjects, the company must notify the ANPD and those affected within a reasonable window, detailing what happened and the measures taken. Without logs, monitoring and a response plan already in place, meeting that duty in the heat of an incident is nearly impossible.
Two new points deserve a developer's attention. The first is AI transparency: Article 20 of the LGPD gives the data subject the right to request a review of decisions made solely through automated processing. The second is the reinforced protection of minors' data, which the ANPD adopted as a regulatory priority.
The legal basis for all of this is Article 46 of the LGPD, which requires processing agents to adopt technical and administrative security measures from the product design phase. For the legal and general overview, read our articles on LGPD rules and data security and on the LGPD in the world of applications. Here, the focus is the technical implementation of those requirements.
For official guidance and applied sanctions, the primary source is the ANPD portal.
OWASP Mobile Top 10 and Secure by Design
Secure by design is the idea that security is not a layer applied at the end, but an architecture decision from the start. Every screen, endpoint and table is born already considering who can access it, how data travels and what happens if something fails.
The best public map for this discipline on mobile is the OWASP Mobile Top 10, whose 2024 version is the first major revision since 2016. It reorganizes the most critical mobile app risks and works as a mandatory checklist for any serious team.
The gain from secure by design is economic, not only technical. Fixing a security flaw in production costs many times more than preventing it at design time, and it carries the risk of a leak and a fine along the way. Pulling security to the start of the project -- the so-called shift-left -- is the engineering decision with the best return on any app that handles personal data.
The table below summarizes the ten categories and the corresponding mitigation in development.
| Code | Risk (2024) | Mitigation in development |
|---|---|---|
| M1 | Improper Credential Usage | Never hardcode secrets; use a secrets vault and rotation |
| M2 | Inadequate Supply Chain Security | Audit dependencies and SDKs, keep an inventory, verify integrity |
| M3 | Insecure Authentication/Authorization | OAuth 2.0/OIDC, MFA and validation always on the server |
| M4 | Insufficient Input/Output Validation | Validate and sanitize all data on the server side |
| M5 | Insecure Communication | TLS 1.2 or higher required, with certificate pinning |
| M6 | Inadequate Privacy Controls | Data minimization and granular consent (LGPD) |
| M7 | Insufficient Binary Protections | Obfuscation, anti-tamper and root/jailbreak detection |
| M8 | Security Misconfiguration | Hardening, remove debug and apply least privilege |
| M9 | Insecure Data Storage | Keychain/Keystore and local encryption, never plaintext |
| M10 | Insufficient Cryptography | AES-256, TLS 1.3 and proper key management |
The Top 10 shows what to avoid; the OWASP MASVS (Mobile Application Security Verification Standard) defines the verifiable security baseline, and the MASTG describes how to test each control. Together they form the technical base we use in regulated verticals, such as the fintech app App da Renda.
Data Encryption: at Rest and in Transit
Encryption is the last line of defense. If everything else fails and data leaks, what decides between a contained incident and a catastrophe is whether that data was encrypted with a strong algorithm.
For data at rest (stored in databases, files, cache or the device itself), the market standard is AES-256, adopted by financial and healthcare institutions worldwide. On mobile, sensitive data should never sit in plaintext: use Keychain on iOS and Keystore on Android.
For data in transit (any network call between app, API and services), the acceptable minimum is TLS 1.2, with TLS 1.3 as the recommended standard. In high-sensitivity apps, certificate pinning is added to prevent interception via fraudulent certificates.
Key management is where most projects fail. A key never lives in the source code or repository: it lives in a dedicated vault (KMS or HSM), with controlled access and periodic rotation. This directly addresses OWASP risks M9 (insecure data storage) and M10 (insufficient cryptography).
| Aspect | At rest | In transit |
|---|---|---|
| Goal | Protect stored data | Protect data in motion |
| Recommended standard | AES-256 | TLS 1.2 or higher (prefer 1.3) |
| Where it applies | Database, files, cache, device | APIs, network calls, webhooks |
| On mobile | Keychain (iOS), Keystore (Android) | Certificate pinning and HSTS |
| Key management | KMS or HSM, with periodic rotation | Valid certificates and auto renewal |
It is worth remembering that encryption does not cover everything on its own. Backups also need to be encrypted and tested, the same sensitive data should not travel in logs or URLs, and the difference between pseudonymization (reversible) and anonymization (irreversible) changes how the LGPD applies. Truly anonymized data stops being personal data; merely pseudonymized data remains protected by the law.
Beyond good engineering, strong encryption is a direct reading of Article 46 of the LGPD, which requires technical measures proportional to the nature of the data. For sensitive data, it stops being a recommendation and becomes a regulatory expectation.
Authentication and Access Control
Weak authentication is the most common entry point for incidents. It is no coincidence that improper credential usage (M1) and insecure authentication (M3) lead the OWASP Mobile Top 10 2024.
The first pillar is multi-factor authentication (MFA). Relying only on SMS-OTP is risky, because SMS can be intercepted or redirected; the safe path is authenticated push inside the app or hardware-backed factors.
The second pillar is the use of mature authorization standards. OAuth 2.0 and OpenID Connect for access delegation, with short-lived tokens (JWT), controlled refresh and validation always on the server -- never trusting the client alone.
Biometrics (Face ID, Touch ID, Android biometrics) must use the platform's native APIs, without storing raw biometric data. It authenticates locally and unlocks a securely stored secret, following MASVS best practices.
Finally, role-based access control (RBAC) and the principle of least privilege: each user and each service sees only what it needs. On platforms handling sensitive data, such as Cota AI (health plan quotation), this segregation is non-negotiable.
The final layer is session management. Tokens with clear expiration, logout that actually invalidates the session on the server, brute-force protection with rate limiting and progressive lockout, and re-authentication for critical actions. These controls are cheap to implement and expensive to ignore, because they close the gaps automated attacks probe first.
Privacy by Design in the Development Cycle
Privacy by design is the principle of embedding data protection into the architecture from conception, rather than patching it later. Paragraph 2 of Article 46 of the LGPD is explicit: security measures must be observed from the product design phase through execution.
In practice, it starts with data minimization: collecting only what is necessary for the stated purpose. Less data collected means less attack surface, less compliance cost and less exposure in case of an incident.
Consent must be specific, granular and revocable, with a documented legal basis for each processing activity. For sensitive data or large-scale processing, a Data Protection Impact Assessment (DPIA) and the oversight of a DPO come into play.
Privacy by design also means turning data subject rights into features. Access, correction, portability and deletion of data cannot depend on a manual email: they need a flow built into the product, with deadlines and traceability. Teams that only think about this after launch end up rebuilding screens and endpoints under pressure.
On the engineering side, privacy by design materializes as a secure development lifecycle: threat modeling in design, security-focused code review, static and dynamic analysis (SAST/DAST) in the pipeline and penetration testing before go-live.
All of this has a cost, and it should be in scope from the start -- not as an optional extra. We detail how security and compliance enter a project's budget in the guide on how much custom software costs.
Sensitive Data: Health and Finance
Not all data carries the same weight. Health and financial data are classified as sensitive (or high-risk) and demand an extra layer of technical, contractual and operational care.
In health apps, data reveals clinical conditions, treatments and the subject's history. Platforms like Cota AI handle health information for plan quotation, which requires strong encryption, access segregation and minimal retention. For the digital health context, see how to build a telemedicine app and the healthtech in Brazil 2026 overview.
In fintechs, financial data attracts fraud and direct attacks. Apps like App da Renda and Desconto Premiado handle information that calls for tokenization, audit trails and, when cards are involved, PCI DSS compliance. We gathered this sector's requirements in the guide on how to build a fintech app.
In the financial sector, consent also shapes the product. Models like Open Finance only work with sharing that is authorized, granular and revocable by the data subject, which requires fine-grained control of each permission's scope and duration. In health, beyond the LGPD, there is a duty of confidentiality and, when the software influences clinical decisions, registration as a medical device with the health regulator.
For sensitive data, extra care applies: pseudonymization and anonymization where possible, tokenization of identifiers, short retention policies with secure disposal and segregation between environments and purposes.
Most leaks originate in poorly protected integrations. APIs, webhooks and ERP connections need authentication, encryption and strict validation -- a topic we go deeper into in the guide on system integration via API, ERP and webhooks.
Compliance Checklist
Use this list as a starting point to assess an app or system project through the lens of security and the LGPD. It does not replace legal counsel, but it covers the technical essentials.
- Mapping of all personal data collected, with documented purpose and legal basis.
- Minimized collection: only the data necessary for the stated purpose.
- Specific, granular and revocable consent, when that is the legal basis.
- A clear and accessible privacy policy in the app and on the website.
- AES-256 encryption for sensitive data at rest.
- TLS 1.2 or higher (prefer 1.3) across all network traffic.
- Secrets and keys outside the source code, in a dedicated vault with rotation.
- Multi-factor authentication available, without relying only on SMS-OTP.
- Role-based access control (RBAC) and the principle of least privilege.
- Audit logs for access to sensitive data.
- Third-party dependencies and SDKs audited and up to date.
- Static/dynamic analysis and penetration testing before launch.
- Incident response plan and a communication channel with data subjects.
- DPIA prepared for high-risk processing or sensitive data.
- A designated and accessible DPO (data protection officer).
- A data retention and secure disposal policy.
How FWC Builds with Security
At FWC Tecnologia, security and privacy enter the project at sprint zero, not at the end. Before writing the first screen, we map the data the product will process, define legal bases and design the access and encryption architecture.
Our experience comes from verticals that do not forgive security mistakes: fintech (App da Renda, Desconto Premiado), health (Cota AI) and complex integrations with third-party systems.
The process combines secure by design, the OWASP Mobile Top 10 checklist, strong encryption at rest and in transit, robust authentication and security-focused code review on every delivery.
Security also does not end at deploy. We monitor dependencies, apply fixes continuously, keep logs and alerts active and prepare the product to respond to incidents quickly. LGPD compliance is a living process that follows the app for as long as it exists, not a badge earned once at launch. That ongoing care is what sustains user trust over time.
If you are going to build a product that handles sensitive data, start by sizing the investment with our app price calculator and then request a tailored quote. We treat security and compliance as part of the scope, never as an optional cost.
Frequently Asked Questions
What is app security and why does it matter for my business?
App security is the set of practices that protects an app against unauthorized access, leaks and fraud. It matters because an incident triggers ANPD fines, loss of trust and brand damage. In 2026, clients assess security before signing a contract, so it has become a sales factor.
How do you build an app compliant with Brazil's data protection law (LGPD)?
Start by mapping the personal data you process, with a purpose and legal basis for each item. Minimize collection, use granular consent and strong encryption, adopt role-based access control and keep logs. Handle privacy from conception, with a DPIA for sensitive data and a designated DPO.
What is the OWASP Mobile Top 10?
It is the list of the ten most critical risk categories in mobile applications, maintained by OWASP. The 2024 version is the first major revision since 2016 and puts improper credential usage and supply chain security at the top. It serves as a mandatory checklist for secure development.
What encryption should you use to protect data in apps?
For data at rest, the standard is AES-256, with keys stored in a dedicated vault and never in code. For data in transit, use TLS 1.2 or higher, preferably TLS 1.3, with certificate pinning in sensitive apps. On mobile, store secrets in Keychain (iOS) or Keystore (Android).
How does secure authentication work in apps?
Secure authentication combines multi-factor (MFA) without relying only on SMS, standards like OAuth 2.0 and OpenID Connect, and short-lived tokens validated on the server. Biometrics use the platform's native APIs, without storing raw biometric data. All of it with role-based access control and least privilege.
What extra care do sensitive health and financial data require?
Health and financial data require strong encryption, access segregation, audit trails and minimal retention. Apply pseudonymization and tokenization, and for card payments, follow PCI DSS. Document legal bases and processor contracts with every partner that receives this data.
How much are LGPD fines in 2026?
A simple fine can reach 2% of the company's revenue in Brazil, capped at R$ 50 million per infraction. There is also a daily fine and sanctions like public disclosure and data blocking. The final amount is set by dosimetry, weighing severity, good faith and the security measures adopted.
Next Step
Security and privacy are no longer a differentiator; they are an entry requirement. A product that handles data without technical care is a legal liability waiting to happen, and the end client already notices it.
If you want to build an app or system with security from conception, talk to us. Request a tailored quote and bring to your project the experience of 30+ apps shipped in regulated verticals.