Cuando se filtra un dato personal, la ley brasileña de protección de datos (LGPD) da un plazo corto para reaccionar. Según la autoridad nacional de protección de datos, el aviso del incidente —a la autoridad y a las personas afectadas— debe hacerse dentro de tres días hábiles desde el momento en que la empresa toma conocimiento del problema. La regla está en la Resolución nº 15, de abril de 2024, dictada por la propia autoridad, que reglamenta el artículo 48 de la LGPD.
Tres días hábiles es poco tiempo para cualquier proceso interno, y así fue pensado a propósito. El detalle que casi ninguna empresa pequeña o mediana nota antes de necesitarlo es otro: ese plazo empieza a correr solo cuando alguien sabe que el incidente ocurrió. Descubrir qué pasó, qué se accedió y a quién afectó no entra en la cuenta de esos tres días: tiene que estar resuelto antes de que el reloj arranque.
Para quien decide en la empresa, eso cambia la pregunta que vale la pena hacerse. No es "¿mi abogado sabe qué hacer si se filtra un dato?" —casi siempre lo sabe—. Es "si se filtra hoy, ¿en cuánto tiempo mi equipo sabrá que se filtró, qué se filtró y a quién afectó?" Sin respuesta a esa segunda pregunta, el plazo legal ya nace perdido.
El plazo que nadie cumple solo
La norma sobre el aviso de incidentes es específica respecto a lo que debe constar en el mensaje enviado a la autoridad y a las personas afectadas: la naturaleza del incidente, las categorías y la cantidad de datos personales involucrados, los riesgos, las medidas adoptadas para revertir o reducir los efectos, y la fecha en que la empresa tomó conocimiento del problema, entre otros puntos.
Cada uno de esos puntos depende de un registro que ya tiene que existir antes del incidente. No se puede describir "la cantidad de datos afectados" sin saber, de antemano, dónde están guardados los datos personales de clientes y empleados y quién tiene acceso a ellos. No se puede informar "la fecha del conocimiento del incidente" con precisión si nadie revisa a diario los accesos fuera de lo común: la fecha se vuelve "no lo sabemos con certeza", y esa falta ya forma parte de lo que se reporta.
La propia autoridad prevé un alivio para cuando la información completa aún no existe: es posible enviar un aviso preliminar dentro de los tres días hábiles y completar los datos hasta veinte días hábiles después. Pero incluso ese aviso preliminar exige saber, como mínimo, que algo pasó y tener una primera idea del alcance —lo que ya es más de lo que muchas empresas pueden decir en el momento en que descubren una filtración.
La autoridad describe su propio modelo de fiscalización como una "regulación responsiva", en la que las medidas aplicadas consideran la cooperación del agente de tratamiento con el proceso. En la práctica, la empresa que llega con algún registro —aunque incompleto— está en una posición muy distinta a la de la empresa que solo se entera del problema cuando alguien de afuera avisa.
Por qué la manera habitual no resuelve
La manera habitual de manejar el dato personal en una empresa pequeña o mediana es, en la práctica, no manejarlo: los registros de clientes y empleados quedan repartidos entre planillas, sistemas de proveedores y el correo de quien siempre se ocupó de eso. Nadie decidió formalmente quién responde por proteger esos datos: la tarea quedó en manos de quien estaba más cerca cuando la empresa creció.
Ese arreglo funciona hasta el día en que alguien de afuera avisa que algo pasó —un cliente, un proveedor, o, en el peor de los casos, el propio atacante anunciando el ataque—. En ese momento la empresa descubre tres cosas a la vez: el incidente, la falta de registro sobre él y la falta de alguien con autoridad para decidir el siguiente paso.
Comprar otra herramienta de seguridad después del susto no resuelve este problema específico. El antivirus, el firewall y el backup ayudan a evitar que el ataque ocurra o se propague, pero ninguno de ellos, por sí solo, produce el dato que exige el aviso de un incidente: qué se accedió, cuándo y por quién. Eso es cuestión de operación, no de producto.
Lo que tiene que existir en la práctica
Cumplir el plazo de tres días hábiles no es un problema jurídico: es un problema de rutina armada con anticipación. Seis mecanismos marcan esa diferencia.
Un responsable del tratamiento de datos nombrado antes de que aparezca el problema. Cuando el incidente aparece, alguien ya necesita autoridad formal para decidir el aviso y hablar con la autoridad; no es el momento de descubrir quién se encarga de eso.
Un mapa de dónde vive el dato personal. Registro de clientes, nómina, historia clínica, contratos: cada uno suele estar en un sistema distinto. Sin ese mapa, "cuántos datos fueron afectados" se vuelve una estimación, y una estimación no es lo que exige el aviso.
Un registro de acceso que permita reconstruir lo que pasó. No es el ticket de soporte técnico: es la huella de quién entró a qué sistema con dato personal y cuándo. Sin ella, la fecha del conocimiento del incidente siempre será "no estamos seguros".
Alguien con la tarea explícita de revisar ese acceso todos los días. Un mapa y un registro que nadie mira solo sirven después de que el daño ya apareció en otro lado; su valor está en detectar el desvío antes.
Un guion de quién avisa a quién en las primeras horas. Quién descubre el problema, quién decide si es un incidente, quién avisa al responsable del tratamiento de datos y quién prepara el aviso a los afectados: definido con nombre propio, no con "ya vemos en el momento".
Un borrador listo de lo que debe constar en el aviso. Naturaleza del incidente, categorías de dato, riesgos, medidas adoptadas: el contenido que exige la norma se puede preparar como plantilla antes de que pase cualquier cosa, y solo hace falta completarlo, no escribirlo desde cero con el reloj corriendo.
Así trabaja la Skills IT este tema: el registro de acceso a los sistemas con dato personal queda disponible para consulta rápida, y el inventario de dónde está alojado ese dato se mantiene actualizado, para que reconstruir lo que pasó no dependa de la memoria de nadie.
Lo que gana la empresa por no improvisar
La ganancia más directa es cumplir el plazo, pero la mayor aparece antes, en el momento en que la empresa todavía está decidiendo qué decir. Una empresa con registros llega a la conversación con la autoridad sabiendo el alcance del problema; una empresa sin registros llega admitiendo que no lo sabe, lo que pesa en su contra en un modelo de fiscalización que considera la cooperación.
También hay una ganancia con los afectados. Avisar rápido y con información concreta —qué pasó, qué quedó expuesto, qué está haciendo la empresa— es distinto de un aviso genérico semanas después, cuando el cliente ya se enteró por otro lado. La segunda situación cuesta una confianza que el primer aviso, bien hecho, conserva.
Y hay una ganancia interna, menos comentada: una empresa que sabe dónde está guardado el dato personal también sabe dónde ya no necesita estar. Un registro viejo de un cliente que no compra hace años, una planilla duplicada en tres computadoras, un backup de un sistema descontinuado: todo eso es dato que, si se filtra, entra en la cuenta del incidente sin aportar ningún valor a la operación.
Una guía para empezar
Antes de escribir una política nueva, vale reunir a la dirección y responder estas preguntas con calma, sin el reloj corriendo.
¿Quién, hoy, tendría autoridad para decidir que hubo un incidente con dato personal? Si la respuesta no tiene un nombre, ese es el primer problema para resolver, antes que cualquier otro.
¿Dónde están guardados los datos de clientes y empleados, y quién tiene acceso a cada lugar? Conviene listarlo por sistema, no por área: el mismo registro suele estar en más de un lugar.
¿Existe algún registro de quién accedió a qué, y por cuánto tiempo se guarda? Sin esa huella, la fecha del conocimiento del incidente —un dato obligatorio en el aviso— siempre será una estimación.
Si algo pasara hoy, ¿quién avisaría a quién, y en qué orden, en las primeras horas? Escribir ese orden en un párrafo ya reduce buena parte de la confusión del primer día.
¿Existe una plantilla lista de lo que debe decir el aviso a la autoridad y a los afectados? No hace falta que sea perfecta: hace falta que exista, para no escribirla desde cero con el reloj corriendo.
