Cuando una organización descubre que perdió el control de sus datos, la primera pregunta del equipo técnico es “¿cómo lo contenemos?”. La primera pregunta del área de cumplimiento es otra: “¿a quién tenemos que avisar, y cuánto tiempo nos queda?”. Las dos preguntas conviven en la misma sala de crisis, y la segunda suele tener respuestas más rígidas de lo que la gente espera.
El problema es que no existe un único reloj. Una empresa con sede en España, operación financiera en Argentina y un proveedor de salud en Estados Unidos puede estar sujeta, para el mismo incidente, a tres plazos distintos que corren en paralelo. Confundirlos, o descubrirlos el día de la brecha, es una de las formas más caras de fallar un requisito de cumplimiento.
Este artículo ordena los marcos de notificación de brechas de seguridad más citados por plazo, destinatario y disparador, para que el reloj no te sorprenda.
¿Qué cuenta como brecha de seguridad y por qué no es lo mismo que una incidencia?
Conviene separar dos términos que en la operación diaria se mezclan. Una incidencia de seguridad es cualquier evento que afecta la disponibilidad, integridad o confidencialidad de la información: un servidor caído, un intento de acceso fallido, un correo sospechoso reportado a tiempo. Una brecha de seguridad es la incidencia que efectivamente compromete datos personales, ya sea por destrucción, pérdida, alteración, divulgación o acceso no autorizado.
La distinción no es semántica. La obligación de notificar se dispara con la brecha, no con la incidencia. Y ahí aparece el matiz que más discusiones genera en los comités. El reloj regulatorio no arranca cuando resuelves el incidente, sino cuando tomas conocimiento de que hubo una brecha. El GDPR usa exactamente esa expresión, “tras tener conocimiento de ella”, en su artículo 33.
Esto obliga a un cambio de mentalidad. La detección temprana deja de ser solo una buena práctica técnica y pasa a ser el punto donde empieza a correr un plazo legal.
¿Cuándo arranca el reloj de las 72 horas del GDPR?
El Reglamento General de Protección de Datos de la Unión Europea establece dos obligaciones distintas y con destinatarios distintos.
El artículo 33 obliga al responsable del tratamiento a notificar la violación de seguridad a la autoridad de control competente, como la Agencia Española de Protección de Datos, sin dilación indebida y, cuando sea posible, a más tardar 72 horas después de haber tenido conocimiento de ella. Si la notificación llega más tarde, hay que acompañarla de una justificación del retraso.
El artículo 34 cubre otro frente, la comunicación a las personas afectadas. Aquí no hay un plazo en horas, sino un criterio de riesgo. Solo se notifica a los titulares cuando la brecha entraña un alto riesgo para sus derechos y libertades, y en ese caso la comunicación debe ser sin dilación indebida.
Hay una excepción que se olvida seguido, y es que no toda brecha se notifica. Si es improbable que la violación suponga un riesgo para los derechos de las personas, el artículo 33 permite no notificar a la autoridad, aunque sí exige documentar la decisión. Esa documentación es la que un auditor pedirá ver después.
El mismo incidente, relojes distintos: cómo comparar los marcos
Un mismo grupo empresarial puede tener que responder a varios reguladores a la vez. La siguiente tabla ordena cuatro marcos de referencia por lo que realmente importa en una sala de crisis: a quién avisar, en cuánto tiempo y qué dispara la obligación.
| Marco | A quién se notifica | Plazo | Qué dispara la obligación | ¿A las personas afectadas? |
|---|---|---|---|---|
| GDPR (Unión Europea) | Autoridad de control (ej. AEPD) | 72 horas desde el conocimiento | Toda violación, salvo que sea improbable que suponga un riesgo | Sí, sin dilación indebida, solo si hay alto riesgo |
| BCRA, sector financiero argentino (Com. “A” 7724 y “A” 8280) | Banco Central (Gerencia de Auditoría Externa de Sistemas) | Notificación inicial dentro de la primera hora ante un ciberincidente crítico, más actualizaciones y reporte de cierre | Ciberincidente que afecta la prestación de servicios, la integridad o la confidencialidad | El eje de la norma es el supervisor; la comunicación al cliente se rige por las reglas de protección al usuario financiero |
| HIPAA (EE. UU., sector salud) | Individuos afectados y el Departamento de Salud (HHS); medios si son 500 o más | A más tardar 60 días desde el descubrimiento (para menos de 500 personas, reporte anual al HHS) | Acceso, uso o divulgación no permitido de información de salud protegida | Sí, a los individuos, a más tardar 60 días |
| Chile (Ley 21.719 y Ley Marco 21.663) | Agencia de Protección de Datos; CSIRT Nacional para entidades bajo el marco de ciberseguridad | Sin dilaciones indebidas en la ley de datos; 72 horas para las entidades alcanzadas por la Ley 21.663 | Vulneración que destruye, filtra, pierde o altera datos personales | Sí, a los titulares, si hay alto riesgo |
Tres lecturas saltan de la tabla. La primera es la dispersión de plazos, porque de la primera hora del regulador financiero argentino a los 60 días de HIPAA hay dos órdenes de magnitud de diferencia. La segunda es que el destinatario cambia según el marco, ya que unos priorizan al supervisor y otros a la persona afectada. La tercera es que los marcos más nuevos, como el chileno, se están alineando al modelo del GDPR, con lo cual el criterio de “72 horas y notificación por riesgo” se está volviendo un estándar regional de referencia.
Conviene un matiz para no leer mal la tabla. El marco del Banco Central argentino no es una ley general de protección de datos, sino una regulación sectorial de ciberseguridad para entidades financieras y proveedores de servicios de pago. Convive con el régimen general de datos personales, no lo reemplaza. Por eso una misma entidad financiera puede deberle un reporte al supervisor en la primera hora y, en paralelo, evaluar la notificación bajo el marco de protección de datos que le aplique.
¿Quién reporta y con qué evidencia?
La notificación no la redacta el firewall. La arma una persona, casi siempre bajo presión y con información incompleta. En la mayoría de los marcos el responsable formal es el responsable del tratamiento o su delegado de protección de datos, pero en la práctica la notificación depende de que varias áreas hayan hecho su parte antes: seguridad para caracterizar el incidente, legal para interpretar el marco aplicable, negocio para dimensionar el impacto.
El contenido mínimo que casi todos los reguladores esperan es parecido: la naturaleza de la brecha, las categorías y el número aproximado de personas afectadas, las consecuencias probables y las medidas adoptadas o propuestas. La Ley 21.719 chilena, por ejemplo, exige registrar exactamente esos elementos.
Ese registro es la parte que se subestima. Una organización que decide de manera fundada no notificar una brecha de bajo riesgo necesita poder mostrar el razonamiento que la llevó a esa decisión. La evidencia de la decisión pesa tanto como la decisión. Este es el mismo principio que aplica al resto del programa de cumplimiento. Lo que no se documenta, a los ojos de un auditor, no ocurrió. En SMARTFENSE lo vemos en el terreno más cotidiano de la demostración de cumplimiento en concienciación, donde el registro trazable de cada acción es lo que convierte una política en evidencia defendible.
Del marco a la operación, antes de que suene el reloj
Conocer los plazos no sirve de nada si la organización los descubre el día de la brecha. La diferencia entre cumplir un requisito y fallarlo se define semanas antes del incidente, en decisiones que rara vez parecen urgentes.
Vale la pena bajar el marco a cuatro preguntas operativas que un comité debería poder responder en frío:
- ¿Sabemos qué marcos nos aplican, por país y por sector? Un grupo con operación multinacional necesita un mapa de obligaciones, no una lista genérica. El reloj del sector financiero argentino no es el mismo que el de un proveedor de salud sujeto a reglas de protección de datos sanitarios.
- ¿Tenemos definido el momento de “conocimiento”? Alguien tiene que poder afirmar, con respaldo, cuándo la organización supo de la brecha. De ese momento depende el conteo del plazo.
- ¿Están claros los roles? Quién caracteriza el incidente, quién decide si hay que notificar, quién firma la comunicación al regulador. Sin esos roles asignados, las primeras horas se pierden en coordinación.
- ¿Nuestra gente sabe reportar rápido? El plazo empieza cuando la organización toma conocimiento, y ese conocimiento muchas veces nace de una persona que reporta un correo raro o un acceso extraño. Un equipo entrenado para reportar temprano le da a la organización horas que después no se recuperan.
Las tres primeras preguntas son de gobierno y se resuelven en el diseño del programa. Un buen sistema de gestión de normativas, políticas y procedimientos mantiene ese mapa vivo y trazable. La cuarta es cultural, y es la que más tarda en madurar, porque no se compra. Se construye con un programa de concienciación sostenido, del mismo modo en que la protección de datos exige capacitación como requisito, no como accesorio.
El plazo es el síntoma, la continuidad es el objetivo
Es tentador leer la notificación de brechas como un trámite de llegar a tiempo, redactar bien y evitar la sanción. Pero el plazo regulatorio es apenas el síntoma visible de algo más grande. Una organización que puede caracterizar una brecha, decidir a quién notificar y hacerlo dentro del plazo es, casi por definición, una organización que entiende sus propios datos, sus dependencias y sus riesgos.
Esa misma capacidad es la que sostiene la continuidad del negocio cuando el incidente escala. El reloj de las 72 horas no mide solo el cumplimiento; mide qué tan lista está la organización para seguir operando el día que algo sale mal. Prepararse para el plazo, al final, es prepararse para el peor día del año.
Deja una respuesta