Three business days: the LGPD violation that shows up most in ANPD cases is not the breach

Anyone following the enforcement cases brought by ANPD, Brazil's data protection authority, runs into a pattern that surprises people expecting headline-grabbing mega breaches. The conduct being punished is usually not the technical failure that allowed the incident. It is what the company failed to do in the days that followed: it did not notify the authority, it did not notify the affected individuals, or it notified late and half complete. The reason is less legal than evidentiary, and it is worth understanding before you approve another dollar of security budget.

What the rule actually requires

Article 48 of the LGPD creates the duty to notify the national authority and the data subject of any security incident that may create relevant risk or harm. For almost six years that duty lived alongside an open ended deadline, the famous "reasonable period", which in practice became room for interpretation. Resolution CD/ANPD No. 15, of April 24, 2024, closed that door. The Security Incident Notification Regulation requires the controller to notify both ANPD and the affected individuals within three business days.

Three business days counted from awareness of the incident, not from the end of the forensic work. The rule allows notification in stages when the information is not yet available: you can file a preliminary notice within the deadline and complete it later, within up to twenty business days, as long as the delay is justified. This is the part most people miss. The deadline does not exist for you to understand the incident. It exists for you to declare that it happened.

• A description of the nature and category of the personal data affected.
• The technical and security measures used to protect the data, with trade and industrial secrets preserved.
• The risks related to the incident and the possible impact on the individuals affected.
• The reasons for any delay, when the notification is not immediate.
• The measures that have been or will be adopted to reverse or mitigate the effects.
• The date the incident became known and the contact details of the data protection officer.

What getting it wrong costs, with the correct number

A lot of compliance marketing material repeats the idea of a flat fine of fifty thousand reais for each day of delay in notification. The rule does not say that, and working from the wrong number weakens your argument the moment you have to defend it internally. What does exist sits in the Sanctions Dosimetry Regulation, Resolution CD/ANPD No. 4, of February 24, 2023. Article 15, item II caps the simple fine at 2% of the revenue of the private legal entity, group or conglomerate in Brazil in its last fiscal year, excluding taxes, with a ceiling of R$ 50,000,000.00 per violation.

A daily fine also exists, but it serves a different purpose. Article 16 of the same regulation is explicit: ANPD applies it when necessary to ensure compliance, within a set period, with a non pecuniary sanction or with a determination issued by ANPD itself. It is a coercive instrument to enforce an order already issued, not an automatic per day charge for staying silent. Paragraph 1 adds that the amount accumulates over the time between when the fine starts to apply and when the obligation is fulfilled, up to a total limit of R$ 50,000,000.00 per violation. The daily amount is set case by case. It is not a constant written into the rule.

In practice, delayed notification enters the bill through two doors. First as a standalone violation, subject to the simple fine. Second as a circumstance that worsens the dosimetry of everything else, because the regulation weighs the offender's cooperation and the measures adopted to mitigate harm. Two companies hit by exactly the same breach, one that notified in three days and one that notified in three months, do not end up in the same place.

Why this is the easiest violation to prove

Arguing whether a company's security measures were adequate under Article 46 is a long technical debate, with room for expert opinion, rebuttal and comparison against the state of the art in the sector. Arguing whether the notification went out within three business days is not. There are two dates: awareness and filing. The distance between them either fits inside the deadline or it does not.

That is why failure to notify shows up so often in published decisions. It is not that it is more serious than the incident itself. It is that it is objective, documentary, and does not depend on convincing anyone about a maturity level. From the point of view of whoever builds the case, it is the cheapest violation to prove in the entire LGPD.

And this is where a problem that looks legal turns into an engineering problem. The date of awareness is not the date legal counsel was told. It is the date the organization became aware, and that date is almost always recorded somewhere: an authentication log, a service desk ticket, an EDR alert, an email from an outside researcher, a message in an internal channel. If the alert fired on a Tuesday and the notice went out three weeks later, the timestamp is already written inside your own infrastructure.

# Freeze the "date of awareness" the moment the first alert fires.
# Anything reconstructed three weeks later is a claim.
# A hashed, timestamped export is evidence.

INCIDENT="INC-2026-0042"
mkdir -p "evidence/$INCIDENT"

# 1. Export the triggering alert and the surrounding access logs.
journalctl -u sshd --since "2026-08-18" --until "2026-08-21" -o json > "evidence/$INCIDENT/authlog.json"

# 2. Hash every artifact and record the exact collection time in UTC.
find "evidence/$INCIDENT" -type f -exec sha256sum {} + > "evidence/$INCIDENT/MANIFEST.sha256"
date -u +"%Y-%m-%dT%H:%M:%SZ" > "evidence/$INCIDENT/collected_at.txt"

# 3. Verify later, in front of whoever asks.
sha256sum -c "evidence/$INCIDENT/MANIFEST.sha256"

Detecting early is a compliance control, not just a security one

Formally, the three business day clock only starts once the company becomes aware, and that is not good news. It means an organization that takes eighty days to notice a compromise reaches the legal deadline in a far worse position: the individuals were exposed the whole time, mitigation started late, and that is precisely what the dosimetry regulation weighs. Slow detection does not save the deadline. It makes everything after it worse.

-- Bulk-read detection over a table holding personal data.
-- The threshold matters far less than having one that fires in hours
-- instead of surfacing in a quarterly access review.

SELECT
    a.actor_id,
    date_trunc('hour', a.ts)     AS window_start,
    count(*)                     AS reads,
    count(DISTINCT a.subject_id) AS distinct_subjects,
    b.p95_subjects_per_hour      AS baseline
FROM data_access_audit a
JOIN actor_hourly_baseline b USING (actor_id)
WHERE a.ts >= now() - interval '24 hours'
GROUP BY a.actor_id, date_trunc('hour', a.ts), b.p95_subjects_per_hour
HAVING count(DISTINCT a.subject_id) > 10 * b.p95_subjects_per_hour
ORDER BY distinct_subjects DESC;

Worse still is the most common scenario in practice: the company does not find out on its own. It finds out through an extortion email, an outside researcher, a customer who found their own data for sale, or the press. At that point awareness is established and documented by a third party, the clock started running at a moment you did not choose, and the response has to be assembled under public pressure.

This is where recurring penetration testing and continuous monitoring connect to legal risk, not only to technical risk. They produce two distinct effects and it is worth separating them. Testing reduces the probability of the incident by closing the flaw before someone else finds it. Monitoring reduces the time between compromise and awareness, which shortens exposure for the affected individuals and puts you in a position to meet the deadline with real information in hand, instead of filing a preliminary notice blind.

Neither one eliminates the chance of an incident, and anyone promising that is selling something else. What they change is the distance between what happened and what you are able to state in writing, with a date, to a regulator.

What you can fix before the next incident

• Define in writing who has the authority to declare that something is a security incident and start the count. Without that owner, the clock runs and nobody is counting.
• Record the date and time of awareness at the moment it happens, with a preserved artifact, instead of reconstructing it weeks later from memory and an inbox.
• Keep the preliminary notice as a ready template, with the fields required by the regulation already mapped, so the decision under pressure is only what to fill in, not what to write.
• Test the flow in a tabletop exercise with legal counsel and the data protection officer in the room. Most response plans treat regulatory notification as a closing line, not as a deliverable with a three business day deadline.
• Measure time to detection as a business metric, with a target and follow up, not as a number that shows up in the quarterly security report and changes nothing.

The breach is the event the press covers. The deadline is what the regulator measures. Investing in shortening the distance between compromise and awareness buys both things at once: fewer incidents, and less exposure to a violation that, unlike the debate over adequate controls, leaves no room for interpretation.