Setenta y dos horas suenan a mucho tiempo. Tres días enteros. Cuando lo lee un director general en una diapositiva de cumplimiento, casi siempre asiente y pasa a la siguiente.
La primera vez que hice esa cuenta con papel y reloj, en los siete años que pasé en HSBC entre fraude y riesgo, el resultado me dejó incómodo. Y no ha mejorado tanto desde entonces.
¿Qué pide exactamente la CNBV y en qué plazo?
La actualización de 2026 de las disposiciones aplicables a las instituciones de tecnología financiera fijó un plazo máximo de 72 horas para que una fintech con más de 50.000 usuarios reporte un incidente de ciberseguridad. Ese es el número que circuló en prensa y el que todo el mundo repite.
Lo que casi no se menciona es que ese plazo no sustituye nada, se suma. La obligación de notificar a la Comisión en cuanto se detecta un evento o un incidente de seguridad de la información ya existía, por correo a la dirección de ciberseguridad de la propia CNBV, y esa notificación tiene un contenido mínimo obligatorio:
- La fecha y la hora en que inició el incidente.
- Si continúa o ya concluyó, y cuánto duró.
- Una descripción de lo que ocurrió.
- Una evaluación inicial del impacto y la severidad.
Después vienen dos plazos más, que casi nadie tiene presentes: la información adicional se entrega dentro de los cinco días hábiles siguientes, y el plan de trabajo para eliminar o mitigar las vulnerabilidades que permitieron el incidente se manda como máximo quince días hábiles después de que el incidente se dé por cerrado. Ese plan es, en la práctica, un ejercicio de gestión de vulnerabilidades con fecha de entrega.
Si además la institución participa en el SPEI, la circular 8/2019 de Banxico agrega sus propios requisitos de seguridad informática y una verificación periódica, cada dos años, de que se siguen cumpliendo. Son dos supervisores distintos preguntando lo mismo con formatos distintos, y eso sin contar lo que ya pide el marco general de cumplimiento en México cuando en el incidente hay datos personales de por medio.
La cuenta hacia atrás que casi nadie hace
Las 72 horas no son 72 horas para investigar. Son el presupuesto completo, y hay cinco cosas que se lo comen antes de que alguien escriba la primera línea del reporte.
Los rangos de la tabla son míos, de lo que he visto en empresas que no tienen vigilancia continua. No salen de la norma, la norma solo pone el límite.
| Lo que hay que resolver | Lo que suele consumir | Horas que quedan |
|---|---|---|
| Confirmar que la alerta es real y no otro falso positivo | 4 a 12 horas | 60 |
| Determinar el alcance: qué sistemas, qué datos, cuántos usuarios | 12 a 24 horas | 36 |
| Clasificar el incidente y decidir si es reportable | 4 a 8 horas | 28 |
| Reunir la evidencia y redactar la notificación | 6 a 12 horas | 16 |
| Revisión legal y firma de quien responde por la institución | 8 a 16 horas | 0 |
La cuenta cierra justo en cero, y cierra solo si todo sale bien: si el incidente empieza un martes por la mañana y no un viernes a las once de la noche, si quien sabe leer los registros del sistema afectado no está de vacaciones, si el proveedor de la nube contesta el mismo día.
En la práctica siempre hay que volver atrás. El alcance casi nunca es el que se pensó en la hora cuatro.
¿Y si el reloj arranca con meses de retraso?
Aquí está la parte que de verdad me preocupa, y no es jurídica.
El plazo regulatorio empieza a correr cuando la institución detecta el incidente. El informe de IBM sobre el costo de una brecha de datos publicado en julio de 2026 pone la media global en 247 días para identificar y contener: 183 días hasta identificarla y 64 más hasta contenerla. Son las dos métricas que en la industria se llaman MTTD y MTTR, y ese número subió respecto al año anterior, rompiendo cinco años seguidos de mejora.
Léalo junto: una empresa puede cumplir las 72 horas de manera impecable y haber tenido al atacante dentro durante medio año. El expediente regulatorio queda limpio. La empresa, no.
El mismo informe pone precio a esa diferencia. Los incidentes que se resolvieron en menos de 200 días costaron 4,32 millones de dólares de media. Los que pasaron de 200 días, 5,65 millones. Es más de un millón de dólares que no se decide en la sala de crisis, se decidió meses antes, el día que nadie estaba mirando.
Lo que tiene que estar listo antes, porque durante no hay tiempo
Las decisiones difíciles de esas 72 horas no se pueden tomar dentro de las 72 horas. Hay cuatro que conviene dejar resueltas por escrito mucho antes.
La primera es el criterio de reportabilidad. Qué configura un incidente reportable, quién lo decide y qué pasa si esa persona no contesta el teléfono. A las tres de la madrugada nadie improvisa una clasificación defendible ante un supervisor. Eso es parte de lo que resuelve un playbook de respuesta a incidentes que se ensaya, no que se guarda.
La segunda son los registros. Si los eventos del endpoint rotan a los siete días y los del firewall a los treinta, reconstruir el alcance de algo que empezó en marzo es un ejercicio de imaginación. Para eso existe un SIEM, que es donde esos registros se centralizan y se conservan. La norma pide la fecha y la hora de inicio. Sin registros que lleguen hasta ahí, ese campo del reporte es una suposición.
La tercera es aburrida y es la que más veces he visto fallar: relojes sincronizados y evidencia con cadena de custodia. Cuando tres sistemas discrepan cuarenta minutos entre sí, la línea de tiempo que usted entrega deja de sostenerse, y lo que sigue no es una multa, es una segunda ronda de preguntas.
La cuarta es una firma. Un nombre, un apellido y un suplente designado. Esas horas de revisión legal de la tabla se van casi siempre en localizar a quien tiene que firmar.
Las 72 horas se ganan antes de que empiecen
Todo lo anterior mejora con procedimiento y con ensayo. Pero la variable que más mueve el resultado no es el procedimiento, es cuándo suena la alarma.
Una institución que detecta en horas entra a la cuenta regresiva con el incidente todavía pequeño, con registros frescos y con margen para equivocarse una vez. Una que detecta en meses entra con el daño hecho, los registros rotados y cero margen. El mismo plazo, dos situaciones que no se parecen en nada.
Ya escribí antes sobre los días que tarda una empresa en cerrar una vulnerabilidad conocida, y el patrón se repite. El plazo del regulador se cumple con vigilancia continua, no con un procedimiento bien redactado. Nosotros la hacemos desde el SOC 24/7, y cuando el incidente ya ocurrió, con el equipo de respuesta y recuperación.
Si su institución está sujeta al plazo, la prueba de fuego es sencilla: pregunte en su próxima reunión cuánto tardaría hoy en llenar los cuatro campos de esa notificación. La cara que ponga el equipo vale más que cualquier auditoría.
El plazo no empieza cuando lo atacan. Empieza cuando usted se entera.
