Qué hacer si se filtran datos personales de clientes en una empresa chilena

Una filtración de datos no siempre comienza con una base publicada en Internet ni con un mensaje de un atacante exigiendo dinero. Puede partir de algo mucho más pequeño: una cuenta que se conecta desde un lugar extraño, una exportación que nadie reconoce, un proveedor que informa un incidente, un archivo enviado al destinatario equivocado o un cliente que descubre que otra persona recibió información que le pertenecía.

En ese momento, la primera pregunta suele ser técnica: ¿cómo cerramos el acceso? Pero rápidamente aparecen otras mucho más difíciles. ¿Qué información estuvo comprometida? ¿Cuántas personas podrían estar afectadas? ¿Alguien descargó los datos o solo pudo visualizarlos? ¿Existen registros suficientes para reconstruir lo ocurrido? ¿Hay que informar a una autoridad? ¿Debemos contactar a los clientes?

Responder bien no depende solamente de tener un buen equipo de seguridad. Depende de cuánto sabía la empresa sobre sus propios datos antes del incidente.

Ese es uno de los motivos por los que en Datactil estamos abordando la protección de datos desde una perspectiva más amplia. En nuestro artículo sobre cómo proteger los datos de una empresa ante ataques potenciados por inteligencia artificial explicamos cómo están cambiando las amenazas. Luego revisamos un caso particularmente silencioso: el robo de credenciales que permite extraer información sin vulnerar directamente los servidores.

Este artículo comienza donde esos dos terminan: cuando existe una sospecha razonable de que la información ya pudo haber quedado expuesta.

El primer error es tratar la filtración como un problema exclusivo de informática

Cuando aparece un incidente, la reacción natural es intentar solucionarlo rápidamente. Cambiar contraseñas, bloquear una cuenta, cerrar un servicio o restaurar una configuración puede ser necesario, pero la urgencia también puede llevar a destruir información útil para entender lo ocurrido.

Una empresa necesita contener el problema y, al mismo tiempo, preservar evidencia.

Eso significa registrar cuándo se detectó el incidente, qué sistemas estaban involucrados, qué cuentas participaron y qué decisiones fueron adoptándose. Si existen logs de acceso, registros de exportaciones, historial de sesiones, alertas de seguridad o respaldos relacionados, deberían conservarse antes de realizar cambios que puedan sobrescribirlos.

La diferencia entre “creemos que alguien entró” y “sabemos qué cuenta accedió, desde qué dirección, durante cuánto tiempo y qué acciones realizó” es enorme cuando llega el momento de medir el impacto.

Por eso una filtración no debería quedar únicamente en manos del área tecnológica. Dependiendo de su magnitud, también puede involucrar gerencia, responsables de procesos, comunicaciones, legal, proveedores y quienes administran las bases afectadas.

La tecnología contiene el incidente. La organización necesita entenderlo.

Las primeras horas deberían concentrarse en contener sin perder la capacidad de investigar

Una vez identificado un posible acceso indebido, la prioridad es evitar que continúe.

Si el problema está asociado a una cuenta comprometida, puede ser necesario bloquearla, cerrar sesiones activas, cambiar credenciales y revisar mecanismos de autenticación. Si existe una aplicación vulnerable, puede ser necesario restringir temporalmente su exposición. Si el incidente proviene de un proveedor, la empresa necesita conocer qué sistemas propios se encuentran conectados con ese servicio.

Pero contener no significa borrar.

Eliminar inmediatamente archivos, formatear equipos, limpiar registros o modificar múltiples sistemas sin mantener una bitácora puede dificultar posteriormente la reconstrucción. Incluso acciones técnicamente correctas deberían quedar documentadas: qué se cambió, quién lo hizo y a qué hora.

Esto cobra especial relevancia cuando la empresa utiliza varios servicios conectados. Un incidente que inicialmente parece afectar solamente una plataforma podría haber alcanzado otras aplicaciones mediante credenciales reutilizadas, integraciones o permisos compartidos.

El artículo sobre dónde viven realmente los datos personales en una empresa muestra justamente por qué el recorrido de la información puede ser mucho más complejo de lo que parece. CRM, formularios, planillas, respaldos, herramientas de marketing, sistemas internos y proveedores pueden contener distintas copias del mismo dato.

Si no conocemos ese recorrido antes del incidente, tendremos que reconstruirlo bajo presión.

Saber que hubo un acceso no es lo mismo que saber qué datos fueron comprometidos

Después de contener el incidente comienza probablemente la parte más difícil: determinar el alcance.

No todas las filtraciones tienen la misma gravedad. Una lista de correos corporativos presenta un riesgo distinto a una base que incluya RUT, teléfonos, direcciones, antecedentes financieros o información de salud. Tampoco es equivalente que una cuenta haya podido consultar diez registros a que haya realizado una exportación de cientos de miles.

La evaluación debería separar hechos de posibilidades.

Puede estar confirmado que una cuenta fue comprometida, pero todavía no estar demostrado que se descargaron datos. Puede existir una exportación, pero no saberse si salió efectivamente de la infraestructura. Puede conocerse qué base estuvo accesible, pero no qué registros fueron consultados.

Esa distinción evita dos errores frecuentes: minimizar una exposición importante o comunicar como hechos situaciones que todavía forman parte de la investigación.

Un inventario de datos personales facilita considerablemente este trabajo. Si la organización ya sabe qué categorías de información están almacenadas en cada sistema, quién las utiliza y dónde existen copias, puede dimensionar más rápidamente qué estaba potencialmente expuesto.

Lo mismo ocurre con el Registro de Actividades de Tratamiento o RAT. El inventario ayuda a saber qué datos existen. El RAT permite entender para qué se utilizan, qué proveedores intervienen y qué controles acompañan ese tratamiento.

Durante un incidente, esa información deja de ser documentación de cumplimiento y se convierte en una herramienta de respuesta.

También hay que determinar quiénes están afectados

Una filtración de datos empresariales no equivale necesariamente a una filtración de datos personales.

Puede haberse expuesto información puramente técnica, documentación interna o datos que no permitan identificar a personas naturales. Pero cuando aparecen nombres, correos personales, teléfonos, RUT, direcciones, perfiles, antecedentes económicos u otras informaciones vinculadas a individuos identificados o identificables, la conversación cambia.

La empresa necesita determinar cuántas personas podrían estar afectadas y qué tipo de información de cada una estuvo involucrada.

Este punto será especialmente importante bajo la Ley 21.719. La nueva regulación incorpora obligaciones específicas frente a vulneraciones de seguridad de datos personales y exige analizar el riesgo que el incidente representa para los derechos y libertades de los titulares.

Por eso no debería responderse únicamente “se filtró una base”.

Hay que entender qué contenía.

La diferencia entre una base con correos públicos de contacto y otra con información financiera, datos de niños o antecedentes sensibles puede modificar sustancialmente la respuesta que corresponde adoptar.

¿Todas las empresas deben reportar hoy una filtración a la ANCI?

No.

Este punto merece precisión porque ciberseguridad y protección de datos están comenzando a convivir bajo marcos regulatorios diferentes.

La Ley N.º 21.663, Marco de Ciberseguridad, ya establece obligaciones de reporte para las instituciones públicas y privadas que prestan servicios calificados como esenciales, además de los operadores de importancia vital cuando corresponda. Para estas organizaciones, los incidentes de ciberseguridad de efecto significativo deben ser reportados a la Agencia Nacional de Ciberseguridad.

La alerta temprana debe realizarse en un plazo máximo de tres horas desde que se toma conocimiento del incidente significativo.

Eso no significa que cualquier empresa chilena tenga hoy que informar cualquier incidente a ANCI en tres horas. La obligación depende de si la organización se encuentra dentro de los sujetos regulados por la Ley Marco de Ciberseguridad, además de las eventuales exigencias sectoriales que puedan afectarla.

Para empresas reguladas, este análisis debería formar parte del procedimiento de respuesta antes de que ocurra una emergencia.

La Ley 21.719 agregará una obligación específica sobre vulneraciones de datos personales

El escenario cambia con la nueva regulación de protección de datos.

La Ley 21.719 establece que el responsable deberá reportar a la Agencia de Protección de Datos Personales las vulneraciones a las medidas de seguridad que provoquen destrucción, filtración, pérdida, alteración, comunicación o acceso no autorizado a los datos cuando exista un riesgo razonable para los derechos y libertades de las personas.

La norma utiliza una expresión importante: sin dilaciones indebidas.

Eso hace todavía más necesario que las empresas tengan un procedimiento previo. Cuando ocurre una vulneración, no es el momento ideal para descubrir quién tiene los accesos, quién toma la decisión, dónde están los logs o qué proveedor administra una determinada base.

La ley también contempla situaciones en las que el responsable deberá comunicar el incidente a los propios titulares afectados, especialmente cuando se trate de datos personales sensibles, datos de niños y niñas menores de catorce años o información relacionada con obligaciones económicas, financieras, bancarias o comerciales.

La comunicación deberá explicar el tipo de información afectada, las posibles consecuencias y las medidas adoptadas.

Este punto conecta directamente con nuestro artículo sobre los derechos de las personas sobre sus datos personales en Chile. La protección de datos no consiste solamente en impedir accesos: también exige que las organizaciones puedan responder frente a las personas cuando el control sobre la información falla.

Al momento de publicar este artículo, la fecha legal vigente para la entrada en aplicación de la Ley 21.719 continúa siendo el 1 de diciembre de 2026. Existe un proyecto que propone trasladarla al 1 de diciembre de 2027, pero todavía no ha modificado la norma. Estamos manteniendo el seguimiento de ese proceso en nuestra actualización sobre la posible postergación de la Ley 21.719.

Comunicar demasiado pronto también puede generar problemas

Cuando una empresa descubre una filtración, puede sentir presión por informar inmediatamente a clientes, trabajadores o públicamente. La transparencia es fundamental, pero una comunicación improvisada puede generar confusión si todavía no existe claridad sobre lo ocurrido.

La respuesta debería avanzar suficientemente rápido para no ocultar el incidente, pero también con la precisión necesaria para diferenciar lo confirmado de lo que sigue investigándose.

Un buen mensaje no necesita explicar cada detalle técnico. Necesita responder preguntas que interesan a la persona afectada: qué ocurrió, qué información podría estar comprometida, qué consecuencias razonables existen, qué medidas tomó la empresa y qué debería hacer el titular si necesita protegerse.

También es importante evitar comunicaciones contradictorias. Si atención al cliente entrega una versión, comunicaciones publica otra y el equipo técnico maneja antecedentes diferentes, la pérdida de confianza puede aumentar incluso cuando el incidente ya está contenido.

La capacidad para demostrar cómo actuó la empresa también formará parte del nuevo estándar. En cómo demostrar cumplimiento de la Ley 21.719 sin quedarse solo en documentos explicamos que una organización necesita conectar lo que declara con registros y procesos que permitan acreditar lo que realmente ocurrió.

Una respuesta a incidentes debería seguir el mismo principio.

Un proveedor afectado también puede convertirse en un incidente propio

Otro escenario frecuente ocurre cuando la vulneración no sucede directamente dentro de la empresa.

Puede sufrirla el proveedor de CRM, una plataforma de mailing, el hosting, un servicio de soporte, una empresa de desarrollo o cualquier tercero que trate datos por cuenta de la organización.

Desde el punto de vista operativo, que el incidente ocurra “afuera” no significa que deje de afectar a los clientes.

La primera tarea será determinar qué información había sido entregada al proveedor, qué acceso tenía, qué sistemas estaban conectados y cuál es el alcance informado de la vulneración. Después habrá que revisar responsabilidades contractuales, obligaciones de comunicación y medidas adoptadas por ambas partes.

Este problema es otra razón para no construir un mapa de datos limitado únicamente a los servidores propios. Como explicamos en el inventario de datos personales, proveedores y servicios externos también deberían aparecer en la radiografía de información de la empresa.

La Ley 21.719 regula además el tratamiento realizado mediante terceros encargados y establece deberes relacionados con seguridad, instrucciones y contratos. La preparación, por tanto, también debería revisar qué dicen los acuerdos con proveedores sobre incidentes, tiempos de aviso y devolución o eliminación de información.

Resolver el incidente no significa que el trabajo terminó

Una vez bloqueado el acceso y estabilizada la operación, comienza una etapa que con frecuencia recibe menos atención: entender por qué pudo ocurrir.

No basta con cambiar la contraseña comprometida si el mismo mecanismo podría afectar mañana a otra cuenta. Tampoco sirve restaurar un servidor sin corregir la configuración que permitió el acceso.

La revisión posterior debería buscar la causa y también las condiciones que aumentaron el impacto.

Quizás el atacante pudo descargar demasiada información porque los permisos eran excesivos. Tal vez no existían alertas porque nadie monitoreaba exportaciones. Puede que el proveedor comprometido tuviera acceso a datos que ya no necesitaba o que una base antigua siguiera disponible por costumbre.

En algunos casos, la solución será mejorar autenticación. En otros será restringir permisos, segmentar sistemas, actualizar software o revisar proveedores. También puede aparecer una conclusión más estructural: ciertos datos estaban innecesariamente disponibles en demasiados lugares.

Ahí vuelve a ser relevante la privacidad desde el diseño en sitios, aplicaciones y CRM. La mejor respuesta frente a una filtración futura puede ser reducir desde ahora la cantidad de información que cada sistema necesita almacenar.

La empresa debería preparar la respuesta antes del incidente

La peor situación posible es descubrir una filtración y comenzar en ese momento a buscar quién administra el servidor, quién tiene acceso al CRM, dónde están los respaldos o qué empresa desarrolló una determinada integración.

Una preparación básica no necesita convertirse inmediatamente en un enorme plan de continuidad. Puede comenzar definiendo quién recibe una alerta, quién coordina la respuesta, qué sistemas contienen información relevante, qué proveedores deben ser contactados y dónde se encuentran los registros necesarios para investigar.

El checklist de la Ley 21.719 para empresas puede utilizarse como punto de partida para revisar varias de estas dependencias. No reemplaza un procedimiento de respuesta a incidentes, pero ayuda a identificar qué partes de la operación todavía no están suficientemente ordenadas.

También debería probarse la recuperación.

Tener respaldos no garantiza que puedan restaurarse correctamente. Tener logs no garantiza que alguien sepa interpretarlos. Tener una política no garantiza que los responsables sepan qué hacer un viernes por la noche cuando aparece una alerta.

La diferencia entre una organización preparada y otra que improvisa suele hacerse visible precisamente cuando algo deja de funcionar como estaba previsto.

La pregunta más importante aparece antes de informar una filtración

Cuando una empresa descubre que alguien pudo acceder indebidamente a sus sistemas, necesita responder una pregunta antes que muchas otras:

¿qué información estuvo realmente al alcance?

Si esa respuesta puede obtenerse rápidamente a partir de inventarios, permisos, registros y una arquitectura conocida, la organización tiene una base sólida para contener, investigar y comunicar.

Si, en cambio, necesita preguntar a diferentes áreas, revisar planillas antiguas, consultar a varios proveedores y reconstruir manualmente cómo se conectan los sistemas, el incidente expone algo más profundo que una falla puntual: revela que la empresa no conocía suficientemente bien el recorrido de sus propios datos.

Por eso prepararse para una filtración no significa vivir esperando un ataque.

Significa reducir incertidumbre.

En Datactil revisamos sistemas, bases de datos, accesos, integraciones, proveedores, automatizaciones y mecanismos de trazabilidad para ayudar a construir una visión técnica de cómo circula la información dentro de una organización.

Cuando esa radiografía existe, resulta mucho más sencillo decidir qué controles fortalecer y cómo preparar una respuesta proporcional al riesgo.

Si tu empresa necesita conocer su nivel de exposición o revisar cómo están distribuidos sus datos, puedes evaluar un proyecto con Datactil.

Preguntas frecuentes

¿Qué es una filtración de datos personales?

Es una pérdida de control sobre información vinculada a personas identificadas o identificables. Puede involucrar acceso no autorizado, divulgación, pérdida, alteración o extracción de datos, dependiendo del incidente.

¿Toda filtración debe comunicarse a la ANCI?

No. La obligación general de reporte bajo la Ley Marco de Ciberseguridad se aplica a instituciones reguladas por ese marco, como prestadores de servicios esenciales y operadores de importancia vital cuando corresponda. Existen además obligaciones sectoriales que pueden aplicar a determinadas organizaciones.

¿Qué cambiará con la Ley 21.719?

La nueva ley incorpora un régimen específico para vulneraciones de seguridad de datos personales. Cuando exista un riesgo razonable para los derechos y libertades de las personas, el responsable deberá reportar el incidente a la Agencia de Protección de Datos Personales, además de comunicar a los titulares en determinados casos previstos por la ley.

¿Qué debería hacer primero una empresa al detectar una posible filtración?

Contener el acceso sin destruir evidencia, registrar las acciones realizadas y comenzar a determinar qué sistemas, personas y categorías de datos podrían estar afectadas. Las medidas específicas dependerán de la naturaleza del incidente.

¿Es suficiente cambiar las contraseñas?

No necesariamente. Si el incidente involucró una cuenta comprometida, también es necesario revisar sesiones, permisos, segundo factor, dispositivos, registros de actividad y los sistemas a los que esa identidad podía acceder.