Pentesting and Brazil's LGPD for e-commerce and healthtech

The breach happens. Then the regulator asks what you were doing before

Online store, digital clinic, health app: anyone who handles customer or patient data in Brazil will eventually face a security incident. Once it becomes a notification to ANPD, Brazil’s data protection authority, the question stops being "what happened" and becomes "what was the company already doing to prevent it". That is where a penetration test changes role: from a technical exercise to evidence of due diligence.

This guide shows how pentesting connects to articles 46, 48 and 52 of the LGPD (Brazil’s General Data Protection Law), what ANPD’s incident regulation requires, what changes for e-commerce and healthtech, and what to put on the table when insurers, investors and large customers assess your risk. It is written for companies operating in Brazil or processing data of people in Brazil; where useful, we note how it compares with GDPR.

This article is informational and is not legal advice. Confirm deadlines and interpretations with your legal counsel or DPO.

What the LGPD requires on security (article 46)

Article 46 requires processing agents to adopt technical and administrative security measures able to protect personal data from unauthorized access and from accidental or unlawful destruction, loss, alteration, disclosure or any form of improper or unlawful processing. Two paragraphs complete the rule:

§ 1: ANPD may set minimum technical standards, taking into account the nature of the information, the characteristics of the processing and the state of the art, especially for sensitive data.
§ 2: the measures must be observed from the design phase of the product or service through its operation. This is privacy by design in practice.

The law lists no controls and never uses the word "pentest". It speaks of measures that are apt (adequate for the risk), and "apt" is something you have to be able to demonstrate. A written policy proves intent; a test proves the control works. A pentest with proof of exploitation, remediation and retest shows that the company looked the way an attacker would, found real flaws and closed them. The closest GDPR parallel is article 32, which asks for a process for regularly testing the effectiveness of security measures.

Pentest versus vulnerability scanner: why the difference matters under the LGPD

Many companies answer "we run automated scans" when asked about testing. Scanners are useful, cheap and should run continuously. But they have limits that matter exactly in personal data breaches:

They do not understand business logic. A scanner does not know that customer A must not see customer B’s order. That kind of flaw (BOLA/IDOR) is the most common cause of data exposure in APIs.
They do not chain findings. A "medium" user enumeration issue plus a weak password reset becomes account takeover. The scanner lists them separately; a pentester connects them.
They do not measure impact on personal data. A report useful for LGPD says which fields were reached and how many data subjects would be affected. That feeds directly into incident risk assessment.

Practical recommendation: continuous scanning for hygiene, manual pentest to prove the measures are apt. See the full comparison in Scanner, pentest or bug bounty.

E-commerce and healthtech: where the risk concentrates

E-commerce. Customer records, order history, addresses, payment data (usually tokenized by the gateway), coupons and loyalty programs. Typical flaws:

BOLA/IDOR in order, invoice and tracking APIs (one customer reads another’s order).
Poorly implemented password recovery and social login leading to account takeover.
Exposed admin panels or default credentials.
Outdated plugins and themes on store platforms.
Report exports and marketplace integrations without access control.

Healthtech. Medical records, exam results, prescriptions, appointments, insurance data. These are sensitive personal data (article 5, II), which raises the duty of care and, as we will see, the risk classification of any incident. Typical flaws:

Role-based authorization badly implemented (patient, doctor, front desk, insurer).
Exam and teleconsultation links that never expire or are predictable.
Integration APIs with labs and health plans without proper authentication.
Clinical files stored in public buckets.

In both cases the breach usually starts with an application flaw, not a sophisticated infrastructure intrusion. That is why the scope of an LGPD-driven pentest should prioritize web applications, APIs and mobile apps. To understand test types, see what penetration testing is and how it works and our API penetration testing guide.

Timeline of an incident under the LGPD

Article 48 requires the controller to notify ANPD and the data subject of any security incident that may cause relevant risk or damage to data subjects. ANPD Resolution CD/ANPD no. 15/2024 details the procedure. In stages:

Detection and containment. Someone notices the problem (monitoring, a third-party alert, a researcher). The priority is to contain: revoke credentials, isolate systems, preserve logs and evidence.
Assessment. Which data was affected? How many data subjects? Was it accessed, copied, altered or lost? Does it meet any of the relevant-risk criteria (see below)?
Notification to ANPD and data subjects. The regulation sets a deadline of 3 business days from the moment the controller becomes aware that the incident affected personal data. Affected data subjects must also be informed, in clear language. (Compare GDPR: 72 hours to the supervisory authority.)
Supplementary information. If information was missing from the first notification, the company can complete it within 20 business days of filing.
Record keeping. Every incident, notified or not, must be recorded, and the record kept for at least 5 years, according to the regulation.

The central point: to meet 3 business days the company must know quickly what was affected. That depends on a data inventory, trustworthy logs and a rehearsed response plan. A pentest report helps because it mapped assets, data flows and weak points before the incident.

What counts as "relevant risk or damage"

Under article 6 of the regulation, an incident may cause relevant risk or damage when, cumulatively: (i) it can significantly affect the interests and fundamental rights of data subjects, for example by preventing the exercise of rights or the use of a service, or by causing material or moral damage (discrimination, financial fraud, identity theft, harm to image); and (ii) it involves at least one of these elements: sensitive personal data, data of children, adolescents or elderly people, financial data, system authentication data, data protected by legal, judicial or professional secrecy, or large-scale data.

Note the fit with both sectors: a breach of medical records meets the sensitive-data criterion almost by definition; a leak of store logins and passwords meets the authentication-data criterion. If in doubt, assess with counsel before deciding not to notify, and record the decision.

Penalties (article 52) and why diligence weighs

Article 52 provides for warnings, a fine of up to 2% of the legal entity’s revenue in Brazil in its last fiscal year (excluding taxes), capped at BRL 50 million per infraction, daily fines, public disclosure of the infraction, blocking and deletion of data, among other sanctions.

In applying them, ANPD follows its sanctions methodology regulation (Resolution CD/ANPD no. 4/2023). It classifies the infraction (minor, medium or serious) and sets aggravating and mitigating circumstances. Mitigating factors include ceasing the infraction, adopting good practices and governance, measures able to reverse or mitigate the effects, and cooperation or good faith.

In practical terms: after an incident, a documented history of tests, fixes and retests works in your favor. It does not remove liability or guarantee a reduction, but it shows the company did not ignore the risk and acted in a structured way. A company that reaches an investigation with no evidence of testing starts from a weaker position.

How a pentest becomes evidence of "adequate technical measures"

For the report to serve your compliance file, it needs:

Declared scope and methodology (OWASP WSTG, OWASP API Security, PTES or NIST SP 800-115).
Proof of exploitation: evidence the flaw was real, with impact described in terms of personal data (which fields, how many data subjects).
A coherent risk rating and a remediation plan with deadlines and owners.
Retest: confirmation that critical and high findings were closed. See what a good report contains in the pentest report: what it should contain.
Date and cadence: at least annual testing, and after relevant changes (new release, new integration, cloud migration).
Safekeeping of the report alongside your record of processing activities and your incident response plan.

If you already go through ISO 27001 or SOC 2, the same test serves several fronts. See pentest for ISO 27001, SOC 2 and GDPR.

Cyber insurance and due diligence

Insurers, investors and large customers usually ask for proof of controls before signing a policy, a funding round or a contract. A recent pentest with retest is often among the requested documents because it answers objectively the question "do you test your own security?". Requirements vary by insurer and by contract; confirm what yours asks for before planning the scope.

A good dossier for this purpose gathers:

the pentest report and the retest letter or section;
the incident response plan, including the ANPD notification flow;
the personal data inventory and data flow map;
the vulnerability management policy and the remediation deadlines actually practiced;
evidence of training and access controls.

The reasoning is the same for enterprise customer security questionnaires. See how to answer "do you have a recent pentest?".

How much it costs and when to do it

The price depends on scope (web application, API, mobile, infrastructure), depth and the complexity of access rules. In How much does a penetration test cost in 2026 we detail the ranges and what moves them. As a calendar rule: test before a major launch, after a structural change (a new payment integration, a new medical records module) and at least once a year. To choose a vendor, use the 10-question checklist; to understand the remediation cycle, see pentest retesting.

Frequently asked questions

Is a pentest mandatory under the LGPD?

The LGPD does not mention pentesting. It requires security measures apt to protect data (article 46). A pentest is a recognized way to show those measures work, but not the only one. Regulated sectors may have their own requirements beyond the LGPD.

What is the deadline to notify ANPD of an incident?

Under Resolution CD/ANPD no. 15/2024, 3 business days from awareness that the incident affected personal data, with the possibility of supplementing the information within 20 business days.

Must every incident be notified?

No. Notification is mandatory when the incident may cause relevant risk or damage to data subjects, according to the regulation’s criteria. Even incidents that are not notified must be recorded, and the record kept for at least 5 years.

What is the maximum LGPD fine?

Up to 2% of the company’s revenue in Brazil in its last fiscal year, capped at BRL 50 million per infraction, plus other article 52 sanctions such as daily fines, public disclosure and blocking or deletion of data.

Does a pentest reduce the penalty after an incident?

ANPD’s methodology considers mitigating factors such as good practices and governance, mitigation of effects and cooperation. A documented history of tests and fixes contributes to that picture, but each case is assessed individually and no reduction is guaranteed.

Does health data require extra care?

Yes. Health data is sensitive personal data (article 5, II), and an incident involving it tends to meet the regulation’s relevant-risk criterion. Prioritize role-based access control and protection of clinical files in the test scope.

Is a vulnerability scanner enough for the LGPD?

It helps with hygiene, but it does not prove that authorization rules and data flows resist an attacker. To demonstrate apt measures, combine continuous scanning with manual pentesting, retesting and a documented report.

How often should I run a pentest?

At least once a year and after significant system changes. Applications handling sensitive or financial data justify shorter cycles.

Next step

Want to know what an attacker sees of your store or health platform, and receive a report that works as evidence for ANPD, insurers and customers? Request a pentest quote and tell us the type of data you handle. For a first view in 30 seconds, use the External Security X-Ray.