Seventy-two hours sounds like a lot of time. Three full days. When a CEO reads it on a compliance slide, they almost always nod and move on to the next one.
The first time I did that math with paper and a clock, during the seven years I spent at HSBC between fraud and risk, the result left me uneasy. And it has not improved that much since then.
What exactly does the CNBV require, and by when?
The 2026 update to the Disposiciones aplicables a las instituciones de tecnología financiera (rules for financial technology institutions) set a maximum deadline of 72 hours for a fintech with more than 50,000 users to report a cybersecurity incident. That is the number that circulated in the press and the one everyone repeats.
What is rarely mentioned is that this deadline does not replace anything, it adds to it. The obligation to notify the Commission as soon as an information security event or incident is detected already existed, by email to the CNBV's own cybersecurity office, and that notification has mandatory minimum content:
- The date and time the incident began.
- Whether it is ongoing or has already ended, and how long it lasted.
- A description of what happened.
- An initial assessment of impact and severity.
Then come two more deadlines that almost no one keeps in mind: the additional information is submitted within the following five business days, and the work plan to eliminate or mitigate the vulnerabilities that allowed the incident is sent no later than fifteen business days after the incident is deemed closed. That plan is, in practice, an exercise in vulnerability management with a due date.
If the institution also participates in SPEI, Banxico's Circular 8/2019 adds its own information security requirements and a periodic verification, every two years, that they are still being met. That is two different supervisors asking the same thing in different formats, and that is without counting what is already required by the general compliance framework in Mexico when personal data is involved in the incident.
The countdown almost no one does
The 72 hours are not 72 hours to investigate. They are the entire budget, and there are five things that eat into it before anyone writes the first line of the report.
The ranges in the table are mine, from what I have seen in companies that do not have continuous monitoring. They do not come from the rule; the rule only sets the limit.
| What has to be resolved | What it usually takes | Hours remaining |
|---|---|---|
| Confirm that the alert is real and not another false positive | 4 to 12 hours | 60 |
| Determine the scope: which systems, which data, how many users | 12 to 24 hours | 36 |
| Classify the incident and decide whether it is reportable | 4 to 8 hours | 28 |
| Gather the evidence and draft the notification | 6 to 12 hours | 16 |
| Legal review and signature by the person accountable for the institution | 8 to 16 hours | 0 |
The math comes out at exactly zero, and only if everything goes well: if the incident starts on a Tuesday morning and not on a Friday at eleven at night, if the person who knows how to read the affected system's logs is not on vacation, if the cloud provider answers the same day.
In practice you always have to go back. The scope is almost never what was thought at hour four.
And what if the clock starts months late?
Here is the part that really worries me, and it is not legal.
The regulatory deadline starts running when the institution detects the incident. The IBM report on the cost of a data breach published in July 2026 puts the global average at 247 days to identify and contain: 183 days to identify it and 64 more to contain it. These are the two metrics the industry calls MTTD and MTTR, and that number went up compared with the previous year, breaking five consecutive years of improvement.
Read them together: a company can meet the 72 hours flawlessly and have had the attacker inside for half a year. The regulatory record is clean. The company is not.
The same report puts a price on that difference. Incidents resolved in under 200 days cost 4.32 million dollars on average. Those that went past 200 days, 5.65 million. That is more than a million dollars that is not decided in the crisis room; it was decided months earlier, on the day no one was watching.
What has to be ready beforehand, because during the incident there is no time
The difficult decisions of those 72 hours cannot be made within the 72 hours. There are four that should be settled in writing well beforehand.
The first is the reportability criterion. What makes an incident reportable, who decides it, and what happens if that person does not answer the phone. At three in the morning no one improvises a classification that can be defended before a supervisor. That is part of what is solved by an incident response playbook that is rehearsed, not filed away.
The second is logs. If endpoint events rotate after seven days and firewall events after thirty, reconstructing the scope of something that started in March is an exercise in imagination. That is what a SIEM is for: it is where those logs are centralized and retained. The rule requires the start date and time. Without logs that go back that far, that field of the report is a guess.
The third is boring, and it is the one I have seen fail most often: synchronized clocks and evidence with chain of custody. When three systems disagree by forty minutes, the timeline you submit no longer holds up, and what follows is not a fine, it is a second round of questions.
The fourth is a signature. A first name, a last name and a designated alternate. The legal review hours in the table are almost always spent tracking down the person who has to sign.
The 72 hours are won before they begin
All of the above improves with procedure and rehearsal. But the variable that moves the outcome the most is not the procedure, it is when the alarm goes off.
An institution that detects in hours enters the countdown with the incident still small, with fresh logs and with room to make one mistake. One that detects in months enters with the damage done, the logs rotated and zero margin. The same deadline, two situations that look nothing alike.
I have written before about the days it takes a company to close a known vulnerability, and the pattern repeats. The regulator's deadline is met with continuous monitoring, not with a well-written procedure. We do it from the SOC 24/7, and once the incident has already occurred, with the team for response and recovery.
If your institution is subject to the deadline, the litmus test is simple: ask at your next meeting how long it would take today to fill in the four fields of that notification. The look on your team's face is worth more than any audit.
The deadline does not start when you are attacked. It starts when you find out.
