"Without undue delay": the clause that can trip companies up under the updated data protection law
Law 21.719 does not set a deadline in hours for reporting a breach. Before you carry one into a data processing agreement, tie your operations to specific deadlines, or align them with cybersecurity timelines, it helps to understand what each one measures.
The companies furthest along in adapting to Law 21.719 have already reached the contract stage: they are reviewing, or drafting, their data processing agreements (the contract between the party that commissions the processing and the party that carries it out, what the market calls a “DPA”) and pushing their vendors to sign them. And when they do, one clause keeps coming up that deserves a second look: the data processor will notify any breach of security measures that creates, or could reasonably create, a risk to the rights and freedoms of data subjects “without undue delay” or, in other words, “within a reasonable time”.
That is where the real need appears: when it comes to obligations, legal certainty is key. If the clause says “without undue delay” but nobody really knows how long that is, the duty is left open for both parties. So before signing, it is worth being able to translate that formula into a number or, at least, into a defensible standard.
Where do we get it from?
The problem with undefined deadlines
The reporting duty in Law 21.719 (article 14 sexies, for those keeping count) requires the data controller to report to the agency by the fastest means available and without undue delays, when there is a reasonable risk to the rights and freedoms of data subjects.
When an obligation comes with no written deadline, one of two things happens: either someone with authority defines it, or the market makes one up. The Data Protection Agency will probably end up setting an interpretive criterion or issuing instructions on this, but there is no specific administrative standard yet. In the meantime, every contract that gets signed puts a number (or none at all) where the law left a blank. It is worth pausing on which one.
Where the confusion comes from: the three hours
The three hours are real, but they belong to a different regime. They come from Law 21.663, the cybersecurity framework law. Operators of Vital Importance (banks, telcos, hospitals, energy) have to send an "early warning" to the National CSIRT within three hours of becoming aware of an incident.
And because those operators have to meet that deadline, some of them push it downstream: if I have three hours to report, my vendor has to tell me in less. That is how the three-hour clause travels down the contract chain until it lands on a data processor that is often not subject to the same critical infrastructure regime, and whose main obligation under that contract is to process personal data.
Early warning vs. diagnosis
A cybersecurity early warning and a data breach report do not measure the same thing. The early warning is a signal: something is happening, react. It exists to contain — isolate the system, cut off access, mobilize the team.
The article 14 sexies regime is after something else. The rule requires reporting certain breaches and, on top of that, keeping a record of those communications describing the nature of the breach, its effects, the categories of data, the approximate number of data subjects affected and the measures taken. That is not an alarm signal: it is a diagnosis.
Was it sensitive data?
Was there data on children under fourteen?
Financial data?
How many people?
What real risk are their rights exposed to?
That can hardly be answered seriously in three hours, at least not in most real incidents.
What is interesting is that the cybersecurity law's own logic points in the same direction. After the three-hour early warning, the operator has follow-up reports to file, including an update within deadlines that can run to 72 hours, to provide more detail on how serious the incident was and its impact, and a final report only at 15 days. In other words: even in the world of critical infrastructure, the analysis is not demanded in three hours.
The three hours are for raising your hand. The 72 are for understanding what happened. The reporting duty in Law 21.719 is much closer to that second logic.
The 72-hour standard: a reasonable reference
The GDPR has worked with this logic for years: the data controller notifies the authority without undue delay and, where feasible, within 72 hours; the data processor, for its part, tells the controller "without undue delay". The number that comparative practice has used as a reference to give that phrase content, when it comes to personal data, is 72 hours. When Law 21.719 uses almost the same words, "without undue delays", the reasonable thing is to read them by that same yardstick, not by one that comes from a different regime with a different purpose.
Contract strategy: how to write this obligation
Does this mean the contract can settle for notice on day three? No. There are two different clocks, and it is best not to confuse them.
The legal deadline runs from the data controller to the Agency. What the contract governs, by contrast, is the data processor's notice to the controller, and that one has to be shorter, because the controller needs room to analyze and report within its own window. The sensible approach is to split this into two contractual obligations: first, an initial notice, immediate or within a short window from detection of the incident; second, a structured, progressive report with the information available, updated as the investigation advances, carrying what the controller needs to meet its own reporting duty within a margin that lets it do so on time.
What makes no sense is writing "full breach report within three hours" and signing. You are creating a contractual obligation that is hard to perform properly in a real incident: it will probably be breached precisely when it matters most, because doing it well is physically impossible.
Until the Agency sets a criterion, the reading that best fits what the rule asks for is this: for personal data, ‘without undue delay’ can be built into a contract using the logic of 72 hours as a reasonable reference, not as an automatic deadline and not as permission to wait until the last minute. Not because 72 is a magic number, but because it recognizes that the obligation calls for analysis, not an alarm, and because it speaks to the international standard we are going to align with sooner or later.
Beyond the stopwatch: why preparation matters
There is also a point the debate about the deadline tends to leave behind: the number does not solve the problem on its own. You can agree on 24, 48 or 72 hours, but no deadline will help if, when the breach arrives, the organization does not know what data it processes, how many people it belongs to, or which systems it lives in. Mapping that before the incident (not during) is what makes a good response possible, whatever deadline you agreed on.
