Reporting a Data Breach to ANPD Brazil: When and How

Reporting a Data Breach to ANPD Brazil: When and How

You must report a security incident to Brazil's data protection authority (ANPD) when it involves personal data and may cause relevant risk or damage to the people affected. ANPD's regulation sets a deadline of three business days, counted from the moment the controller learns that the incident affected personal data. When an AI agent is involved (for example, one that serves customers on WhatsApp), the rule is the same, but finding out what happened depends on records that many companies do not yet keep.

Key takeaways

• Not every incident has to be reported. The trigger is the possibility of relevant risk or damage to data subjects, and that assessment should be recorded in writing.
• The three business day clock starts when the company knows personal data was affected, not when the technical problem began.
• The notification usually goes to ANPD and also to the affected individuals, in clear language with practical guidance.
• AI agents add new ways for incidents to happen (a reply sent to the wrong person, a leak caused by a malicious instruction, a tool with too much access) and require logs to reconstruct the facts.
• Incidents that are not reported must still be documented internally, with the reasoning behind the decision.

What counts as a security incident involving personal data?

Brazil's data protection law (LGPD), in Article 48, addresses security incidents that may cause relevant risk or damage to data subjects. In practice, it is any confirmed adverse event that compromises the confidentiality, integrity or availability of personal data. That includes unauthorized access, leaks, loss, improper alteration and unavailability that affects the people concerned.

A stolen laptop holding an unprotected customer spreadsheet is an incident. So is an employee sending a contact list to the wrong email address. A failure in which a system deletes customer records with no backup falls in the same category. What matters is the effect on the data and the people, not the technical cause.

It helps to separate three things that are often confused:

• Event: something unusual was observed, but it is not yet known whether personal data was affected.
• Incident: it is confirmed that personal data was compromised in some way.
• Reportable incident: the incident may cause relevant risk or damage, so it requires notifying ANPD and the data subjects.

This article is general guidance. It does not replace the analysis of your data protection officer (the encarregado), your legal team or a lawyer, and the current regulation should be checked directly on the ANPD website.

When is the risk considered relevant?

ANPD's regulation on incident reporting treats the risk as relevant when the incident can significantly affect the fundamental interests and rights of data subjects and involves at least one of these elements:

• sensitive personal data, such as health, biometrics, racial or ethnic origin, religious belief or political opinion;
• data about children, adolescents or elderly people;
• financial data;
• authentication data for systems, such as passwords and access tokens;
• data protected by legal, judicial or professional secrecy;
• large-scale data.

The first filter is therefore twofold: was there a possibility of significantly affecting rights, and did the incident touch one of these categories? If both answers are yes, the default path is to report. If there is real doubt, the prudent approach is to treat it as reportable and decide with your data protection officer, rather than postponing the analysis until the deadline has passed.

A simple decision guide, in the form of questions:

• Was personal data exposed, altered, lost or made unavailable? If not, treat it as an ordinary security incident, with no report to ANPD.
• Was the data protected so that a third party cannot read it (adequate encryption, for example)? That reduces the risk, but it must be demonstrated and recorded.
• Is there a category of data that increases the risk (sensitive, financial, authentication, children, large scale)? If so, the chance that the incident is reportable goes up considerably.
• Could the individuals suffer fraud, discrimination, embarrassment or material loss? If so, damage is plausible.
• Was the final decision recorded, with date, person responsible and justification? That record matters both when you report and when you decide not to.

Who reports, and by when?

The obligation belongs to the controller, meaning the company that decides how the data is processed. If a supplier (the operator) suffers the incident, it must notify the controller, and the contract needs to state how quickly and through which channel. Without that clause, the company learns of the problem late and is already behind the deadline.

The three business day deadline applies to the controller from the moment it knows the incident affected personal data. Two practical consequences:

• Do not wait for the investigation to finish. The report can be filed with the information available and supplemented later. The regulation provides a separate period for supplementing it, which should be checked in the current rule.
• If you cannot deliver everything on time, you need to explain why, rather than simply staying silent.

Notifying the data subjects follows the same logic of urgency and should be direct and easy to understand. When individual notice is not feasible, the regulation allows alternatives, such as a notice on public channels, but that should be assessed case by case.

What must the report contain?

The ANPD form and the rule ask, in essence, for the items below. Prepare this material before you need it:

• identification of the controller and contact details of the data protection officer;
• a description of the nature of the incident and the categories of data affected;
• the number of affected individuals, highlighting children, adolescents or elderly people, if any;
• the date the incident occurred (when known) and the date the company became aware of it;
• the technical and security measures in place before the incident;
• the risks and possible consequences for the individuals;
• the measures taken or planned to reverse or mitigate the effects;
• the reasons for any delay, if the report was not made within the deadline;
• identification of any operators involved.

The notice to the individual should say, in plain language, what happened, which data was affected, what risks exist, what the company has already done and what the person can do to protect themselves (change a password, be wary of suspicious contacts, monitor account activity). Avoid jargon and avoid downplaying. A vague message harms both the person and the company.

How does an AI agent change the picture?

AI agents change the rule less than they change how hard it is to answer the questions above. Four common ways an incident happens:

• A reply sent to the wrong person, because of a failure to identify the conversation or because context was mixed between conversations.
• Data exposed through a malicious instruction: someone writes a message that induces the agent to reveal information it can see. OWASP publishes material on preventing prompt injection and a list of the main risks in LLM applications.
• A tool with permissions that are too broad: the agent can query or export more than it needs.
• Data sent to a supplier or country without proper care, a topic covered in international data transfer when using AI providers.

Illustrative scenario: a services company uses a WhatsApp agent to report order progress. A customer notices that, by asking for the status of another person's order and mentioning that person's name, the agent replies with an address and phone number. The team sees the message, confirms that the reply contained a third party's personal data and finds that the system lookup did not require the requester to be verified. The clock starts when the company knows personal data was affected. The next step is to find out whether this happened once or many times. Without records of the conversations and of the queries the agent made, there is no way to tell ANPD how many individuals were affected. With logs, the answer takes hours.

For this reason, logging decisions and tool calls is part of incident readiness, not an observability luxury. The OpenTelemetry observability primer helps clarify what to record, always taking care not to turn the log itself into a new, uncontrolled store of personal data.

What does a step-by-step response plan look like?

A lean outline that a small company can follow:

• Step 1: contain. Cut access, revoke the credential, pause the affected agent or flow. Containment comes before investigation.
• Step 2: involve the data protection officer and the decision maker. Name a single person to lead the response and record the time the company became aware.
• Step 3: preserve evidence. Keep logs, messages, configurations and versions of the prompt and tools before any fix that would overwrite them.
• Step 4: define the scope. Which data, how many individuals, over what period, through what path. If something is uncertain, record the uncertainty.
• Step 5: assess the risk. Use the questions from the relevant risk section and record the conclusion with its justification.
• Step 6: report. If the incident is reportable, send the notification to ANPD within the deadline with what is already known, and notify the individuals.
• Step 7: fix the cause. Adjust the agent's permissions, validations and limits, and test the point of failure before turning it back on.
• Step 8: document and learn. Keep the record of the incident, decisions and measures, and review the process.

If the agent had to be paused, have a plan for customer support: a contingency message and a human channel. Companies running automated support at scale should also prepare for the effect a shutdown can have on the channel account, a topic covered in how to avoid a WhatsApp number ban when using an AI agent.

How can you reduce the chance and the size of an incident?

The working method we use in AI projects on this topic has four moves: map, limit, pilot and hand over.

• Map: before any agent goes into production, list which data it can see, where that data flows, who the operator is and which contract covers incident notice. This map is the foundation for answering ANPD quickly.
• Limit: give the agent the minimum of data and actions. Verify identity before querying personal information, restrict tools and require human approval for sensitive actions. OWASP's authorization principles apply directly, and input, output and action guardrails reduce the risk of an improper reply.
• Pilot: start with one real flow, with logs, an agreed metric and an incident simulation. A tabletop exercise ("what if the agent replies to the wrong person?") exposes gaps in records and responsibilities before a real case does.
• Hand over: give the company's team the response plan, the access and the documentation, so operations do not depend on an outside person at the moment of crisis.

The NIST AI Risk Management Framework is a useful reference for structuring this work on an ongoing basis, rather than treating it as a one-off project.

Frequently asked questions

Does every failure involving personal data have to be reported to ANPD? No. Reporting is required when the incident may cause relevant risk or damage to data subjects. The remaining cases should be recorded internally, with the risk analysis and the reason for not reporting, so the decision can be demonstrated later.

When does the three business day deadline start? It runs from the moment the controller knows the incident affected personal data. That is why it is important to record the date and time of awareness and not wait for the full investigation before acting. If information is missing, report what you already know and supplement it later, as the regulation allows.

If the incident was caused by an AI provider, who reports it? As a rule, the controller remains responsible for notifying ANPD and the data subjects, and the provider, as operator, must notify the controller. For that reason the contract should define the notice period and channel, and the company should keep the logs that allow it to reconstruct what the agent did.

Do I need to notify customers even if ANPD has not yet responded? Yes. If the incident is reportable, notifying the data subjects does not depend on a reply from ANPD. The notice should explain what happened, which data was affected, the risks and what the person can do. If you are unsure how to word the notice, consult your data protection officer or a lawyer.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP: prompt injection prevention
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework