When personal data leaks, Brazil's data protection law (LGPD) gives companies a short window to react. According to the national data protection authority, the leak must be reported — to the authority and to the people affected — within three business days of the moment the company becomes aware of the problem. The rule comes from Resolution nº 15, issued in April 2024 by the authority itself, which regulates article 48 of the LGPD.
Three business days is a tight window for any internal process — and that is the point. What almost no small or mid-sized company realizes before it needs to is something else: the clock only starts once someone actually knows the incident happened. Finding out what occurred, what was accessed, and who was affected does not count against those three days — it has to be sorted out before the clock even starts.
For whoever decides at the company, that changes the question worth asking. It is not "does our lawyer know what to do if data leaks?" — most do. It is "if it leaked today, how long would it take my team to know it leaked, what leaked, and who was affected?" Without an answer to that second question, the legal deadline is already lost before it begins.
The deadline nobody meets alone
The rule governing incident reporting is specific about what the message sent to the authority and to affected people must contain: the nature of the incident, the categories and volume of personal data involved, the risks at stake, the measures taken to reverse or reduce the effects, and the date the company became aware of the problem, among other items.
Every one of those points depends on a record that already needs to exist before the incident. There is no way to describe "the volume of data affected" without already knowing where customer and employee personal data is stored and who can access it. There is no way to state "the date the incident became known" with any precision if nobody is reviewing unusual access every day — the date becomes "we're not sure," and that gap is itself part of what gets reported.
The authority itself allows for some relief when full information is not yet available: a company can send a preliminary notice within the three business days and complete the details within twenty business days afterward. But even that preliminary notice requires knowing, at minimum, that something happened and having a first sense of its scope — which is already more than many companies can say the moment they discover a leak.
The authority also describes its own enforcement model as "responsive regulation," where the measures applied take into account how much the organization cooperated with the process. In practice, a company that shows up with some record — even an incomplete one — is in a very different position than a company that only learns of the problem when someone from outside points it out.
Why the usual approach doesn't hold
The usual way small and mid-sized companies handle personal data is, in practice, not handling it at all: customer and employee records sit scattered across spreadsheets, vendor systems, and the inbox of whoever has always taken care of it. Nobody formally decided who is responsible for protecting that data — the task landed on whoever was closest when the company grew.
That arrangement works until the day someone from outside says something happened — a customer, a supplier, or, worst case, the attacker announcing it. At that moment the company discovers three things at once: the incident, the lack of any record about it, and the lack of anyone with the authority to decide what happens next.
Buying another security tool after the scare does not solve this specific problem. Antivirus, firewall, and backup help prevent an attack from happening or spreading — but none of them, on its own, produces what an incident report requires: what was accessed, when, and by whom. That is a matter of operations, not a product on a shelf.
What has to be in place
Meeting the three-business-day deadline is not a legal problem — it is a matter of routine set up in advance. Six mechanisms make that difference.
A data protection lead named before the problem shows up. When the incident appears, someone already needs formal authority to decide on the report and to speak with the authority — this is not the moment to figure out whose job it is.
A map of where personal data actually lives. Customer records, payroll, medical files, contracts — each usually sits in a different system. Without that map, "how much data was affected" becomes a guess, and a guess is not what the report requires.
An access record detailed enough to reconstruct what happened. This is not a support ticket log — it is the trail of who entered which system holding personal data, and when. Without it, the date the incident became known is always "we're not entirely sure."
Someone with the explicit job of reviewing that access every day. A map and a log that nobody looks at only help after the damage has already surfaced somewhere else — their value is in catching the deviation before that.
A script for who tells whom in the first hours. Who discovers the problem, who decides it counts as an incident, who alerts the data protection lead, and who drafts the notice to affected people — defined by name, not by "we'll figure it out in the moment."
A ready draft of what the report needs to contain. Nature of the incident, categories of data, risks, measures taken — the content the rule requires can be prepared as a template before anything happens, and only needs filling in, not writing from scratch under a running clock.
This is how Skills IT approaches the issue: access records for systems holding personal data stay available for quick review, and the inventory of where that data is hosted is kept current — so reconstructing what happened doesn't depend on anyone's memory.
What the company gains by not improvising
The most direct gain is meeting the deadline — but the bigger one shows up earlier, while the company is still deciding what to say. A company with records walks into the conversation with the authority knowing the scope of the problem; a company without them walks in admitting it doesn't know, which counts against it under an enforcement model that weighs cooperation.
There is also a gain with the people affected. Notifying quickly with concrete information — what happened, what was exposed, what the company is doing about it — is very different from a generic notice weeks later, after the customer already heard about it elsewhere. The second scenario costs trust that a prompt, well-built notice preserves.
And there is a quieter internal gain: a company that knows where personal data is stored also knows where it no longer needs to be. An old customer record from years ago, a spreadsheet duplicated across three computers, a backup of a system nobody uses anymore — all of that is data that, if it leaks, counts against the incident without adding any value to the business.
A starting checklist
Before drafting a new policy, it is worth gathering leadership and answering these questions calmly — without a clock running.
Who, today, would have the authority to decide that a personal data incident occurred? If the answer has no name attached, that is the first thing to fix, before anything else.
Where is customer and employee data stored, and who has access to each place? List it by system, not by department — the same record usually sits in more than one place.
Is there any record of who accessed what, and how long is it kept? Without that trail, the date the incident became known — a required item in the report — will always be a guess.
If something happened today, who would tell whom, and in what order, in the first hours? Writing that order down in a single paragraph already removes most of the first day's confusion.
Is there a ready template for what the notice to the authority and to affected people needs to say? It doesn't need to be perfect — it needs to exist, so it isn't written from scratch while the clock runs.
