When an organization discovers it has lost control of its data, the technical team’s first question is “how do we contain this?”. The compliance team’s first question is a different one: “who do we have to notify, and how much time do we have?”. Both questions share the same crisis room, and the second usually has answers far more rigid than people expect.
The catch is that there is no single clock. A company headquartered in Spain, with financial operations in Argentina and a healthcare provider in the United States, can face three parallel deadlines for the very same incident. Confusing them, or discovering them on the day of the breach, is one of the most expensive ways to fail a compliance requirement.
This article maps the most cited data breach notification frameworks by deadline, recipient and trigger, so the clock never catches you off guard.
What counts as a security breach, and why isn’t it the same as an incident?
It helps to separate two terms that daily operations tend to blur. A security incident is any event that affects the availability, integrity or confidentiality of information: a downed server, a failed access attempt, a suspicious email reported in time. A security breach is the incident that actually compromises personal data, whether through destruction, loss, alteration, disclosure or unauthorized access.
The distinction is not cosmetic. The duty to notify is triggered by the breach, not by the incident. And this is where the nuance that sparks the most boardroom debate appears. The regulatory clock does not start when you resolve the incident, but when you become aware that a breach has occurred. The GDPR uses exactly that phrasing, “having become aware of it”, in its Article 33.
This forces a shift in mindset. Early detection stops being merely a good technical practice and becomes the point where a legal deadline starts to run.
When does the GDPR’s 72-hour clock start?
The European Union’s General Data Protection Regulation sets two distinct obligations, each with a different recipient.
Article 33 requires the data controller to notify the personal data breach to the competent supervisory authority, such as the Spanish Data Protection Agency, without undue delay and, where feasible, no later than 72 hours after becoming aware of it. If the notification arrives later, it must be accompanied by reasons for the delay.
Article 34 covers another front, the communication to the affected individuals. Here there is no clock in hours but a risk criterion. Data subjects are only notified when the breach is likely to result in a high risk to their rights and freedoms, and in that case the communication must be without undue delay.
There is an exception that is often forgotten, and it is that not every breach must be notified. If the breach is unlikely to result in a risk to people’s rights, Article 33 allows the controller not to notify the authority, though it still requires documenting the decision. That documentation is exactly what an auditor will ask to see later.
The same incident, different clocks: how to compare the frameworks
A single corporate group may have to answer to several regulators at once. The table below sorts four reference frameworks by what really matters in a crisis room: who to notify, how fast and what triggers the obligation.
| Framework | Who is notified | Deadline | What triggers the obligation | The affected individuals? |
|---|---|---|---|---|
| GDPR (European Union) | Supervisory authority (e.g. AEPD in Spain) | 72 hours from awareness | Any breach, unless unlikely to result in a risk | Yes, without undue delay, only if there is high risk |
| BCRA, Argentine financial sector (Communications “A” 7724 and “A” 8280) | Central Bank (External Systems Audit Management) | Initial notification within the first hour of a critical cyber incident, plus updates and a closing report | A cyber incident affecting service delivery, integrity or confidentiality | The rule centers on the supervisor; communication to the customer follows financial consumer protection rules |
| HIPAA (US, healthcare sector) | Affected individuals and the Department of Health (HHS); media if 500 or more | No later than 60 days from discovery (for fewer than 500 people, an annual report to HHS) | Impermissible access, use or disclosure of protected health information | Yes, to individuals, no later than 60 days |
| Chile (Law 21.719 and Framework Law 21.663) | Data Protection Agency; National CSIRT for entities under the cybersecurity framework | Without undue delay under the data law; 72 hours for entities covered by Law 21.663 | A breach that destroys, leaks, loses or alters personal data | Yes, to data subjects, if there is high risk |
Three readings jump out of the table. The first is the spread of deadlines, because from the first hour of the Argentine financial regulator to HIPAA’s 60 days there are two orders of magnitude of difference. The second is that the recipient changes with the framework, since some prioritize the supervisor and others the affected person. The third is that newer frameworks, like Chile’s, are aligning with the GDPR model, so the “72 hours and risk-based notification” criterion is becoming a regional reference standard.
One nuance to avoid misreading the table. Argentina’s Central Bank framework is not a general data protection law but a sector-specific cybersecurity regulation for financial institutions and payment service providers. It coexists with the general personal data regime rather than replacing it. That is why the same financial institution may owe the supervisor a report within the first hour and, in parallel, assess notification under whatever data protection framework applies to it.
Who reports, and with what evidence?
The notification is not drafted by the firewall. It is put together by a person, almost always under pressure and with incomplete information. In most frameworks the formal responsibility lies with the data controller or its data protection officer, but in practice the notification depends on several areas having done their part beforehand: security to characterize the incident, legal to interpret the applicable framework, business to size the impact.
The minimum content that nearly every regulator expects is similar: the nature of the breach, the categories and approximate number of people affected, the likely consequences and the measures taken or proposed. Chile’s Law 21.719, for example, requires recording exactly those elements.
That record is the part that gets underestimated. An organization that makes a reasoned decision not to notify a low-risk breach needs to be able to show the reasoning that led to that decision. The evidence of the decision weighs as much as the decision itself. This is the same principle that applies to the rest of the compliance program. What is not documented, in an auditor’s eyes, did not happen. At SMARTFENSE we see it in the most everyday terrain of demonstrating compliance in awareness, where the traceable record of every action is what turns a policy into defensible evidence.
From framework to operations, before the clock rings
Knowing the deadlines is worthless if the organization discovers them on the day of the breach. The difference between meeting a requirement and failing it is settled weeks before the incident, in decisions that rarely feel urgent.
It is worth boiling the framework down to four operational questions a committee should be able to answer in calm:
- Do we know which frameworks apply to us, by country and by sector? A group with multinational operations needs a map of obligations, not a generic list. The Argentine financial sector’s clock is not the same as that of a healthcare provider subject to health data protection rules.
- Have we defined the moment of “awareness”? Someone has to be able to state, with backing, when the organization knew about the breach. The deadline count depends on that moment.
- Are the roles clear? Who characterizes the incident, who decides whether to notify, who signs the communication to the regulator. Without those roles assigned, the first hours are lost to coordination.
- Do our people know how to report quickly? The clock starts when the organization becomes aware, and that awareness often begins with a person who reports a strange email or an unusual access. A team trained to report early gives the organization hours it cannot recover later.
The first three questions are governance questions and are settled in the program’s design. A solid system for managing regulations, policies and procedures keeps that map alive and traceable. The fourth is cultural, and it is the one that takes longest to mature, because it cannot be bought. It is built with a sustained security awareness program, in the same way that data protection demands training as a requirement, not an accessory.
The deadline is the symptom, continuity is the goal
It is tempting to read breach notification as a formality of arriving on time, drafting well and avoiding the penalty. But the regulatory deadline is only the visible symptom of something larger. An organization that can characterize a breach, decide who to notify and do so within the deadline is, almost by definition, an organization that understands its own data, its dependencies and its risks.
That same capability is what sustains business continuity when the incident escalates. The 72-hour clock does not measure compliance alone; it measures how ready the organization is to keep operating the day something goes wrong. Preparing for the deadline is, in the end, preparing for the worst day of the year.
Leave a Reply