Viernes 8:14pm. Tu CFO te escribe por WhatsApp: "Perdí la laptop en un Uber, tenía abierta la planilla de clientes con RUT y datos de pago, ¿qué hago?". Lleva una hora desaparecida. Le pides que cierre sesión de todo desde el celular y que el lunes lo coordinan en la oficina.
Lunes 9am. Lo que ahora hay que decidir ya no es si la laptop aparece. Es si esto cuenta como brecha de datos. Si la respuesta es sí, tienes 72 horas para notificar a la Agencia de Protección de Datos y semanas de informes internos por delante. Si la respuesta es no, mejor que puedas demostrarlo.
Una brecha de datos no se decide por el evento. Se decide por la evidencia que puedes mostrar. Si no sabes qué dispositivos accedieron al dato, si estaban cifrados, qué se exfiltró y cuándo, no estás respondiendo a una brecha: estás escribiendo una declaración de fe frente al regulador.
Este artículo cubre qué cuenta como brecha de datos en términos operativos, en qué se diferencia de un incidente o de una "brecha de seguridad" sin más, qué obligan las leyes 21.719 y 21.663 en Chile cuando ocurre, cómo se ve en tu flota de dispositivos, y qué evidencia necesitas para responder con plazos y multas en juego.
¿Qué es una brecha de datos? Definición operativa
Una brecha de datos es el acceso, divulgación, alteración o pérdida no autorizada de información sensible, sea por ataque malicioso o por accidente. No requiere intención: una laptop perdida, un correo enviado al destinatario equivocado o una credencial filtrada también cuentan.
En la práctica eso incluye situaciones que muchas empresas ni siquiera registran como problema: un USB olvidado en una sala de reuniones, una planilla compartida con permisos públicos sin querer, un acceso anómalo desde un dispositivo que no estaba en el inventario, o una credencial filtrada en un dump del proveedor que el equipo nunca cruzó con sus logs.
La Ley 21.719 (en su artículo 14 quinquies) habla de "vulneración de medidas de seguridad" cuando se produce destrucción, pérdida, alteración o comunicación no autorizada de datos personales. Esa es la definición que importa cuando llega el regulador, y es más amplia de lo que la mayoría asume.
Donde las empresas se confunden es en distinguir una brecha de un "evento" o un "incidente". Un evento es cualquier ocurrencia observable (un intento fallido de login, por ejemplo). Un incidente es un evento que afecta la seguridad o disponibilidad. Una brecha es el subset de incidentes donde se vulneró información sensible. Esa cadena importa, porque define qué dispara obligaciones legales.
Quick win: Documenta tu definición operativa interna de "brecha" alineada al artículo 14 quinquies de la Ley 21.719, y pega esa definición en el plan de respuesta a incidentes. Si tu equipo no tiene un criterio escrito para clasificar un evento como brecha, esa decisión va a depender del más nervioso del grupo el día que ocurra.
Brecha de datos vs. brecha de seguridad: la diferencia que importa al regulador
Esta es la parte que la mayoría de los artículos en español confunde, y donde se juega la decisión de notificar o no.
Una brecha de seguridad es cualquier compromiso de tus controles: alguien escaló privilegios en un servidor, un firewall fue bypaseado, una vulnerabilidad fue explotada. No siempre involucra datos personales. Si un atacante ejecutó código en un servidor de logs operacionales internos, eso es brecha de seguridad (y probablemente incidente bajo Ley 21.663 si tu organización es OIV), pero puede no disparar Ley 21.719.
Una brecha de datos personales es el subset que sí dispara Ley 21.719: ocurre cuando los datos comprometidos identifican o son asociables a una persona natural (RUT, correo, dirección, datos de salud, datos de pago, ubicación, etc.). Y aquí aparece el matiz: toda brecha de datos personales es también brecha de seguridad, pero no al revés.
Esa diferencia parece teórica hasta que estás escribiendo el informe a las 11pm de un domingo. Si tu IRP no tiene un flujo claro de clasificación ("¿hubo datos personales involucrados?" como pregunta de minuto uno), vas a perder horas críticas en la decisión equivocada.
Quick win: Mapea tus bases de datos en dos categorías: "contiene datos personales (sujeto a 21.719)" y "operacional/no personal". Esa segmentación va dentro del IRP como tabla de referencia rápida. Cuando ocurra el incidente, la pregunta "¿qué bases tocó?" debe poder responderse en minutos, no en días. Para entender qué cuenta como dato personal bajo el marco chileno, revisa la Ley de Protección de Datos en Chile.
Tipos de brechas: físicas, digitales e internas (con ejemplos reales)
Hay tres categorías útiles para pensar la superficie de exposición. No son exhaustivas, pero te dan un mapa de dónde mirar.
Brechas físicas. Cuando el vector es un objeto del mundo real: una laptop perdida en un Uber, un USB olvidado en la sala de reuniones, documentos impresos dejados en una impresora compartida, un disco duro removido de un equipo dado de baja sin sanitizar. Las brechas físicas son las más subestimadas porque parecen accidentes y no ataques. Pero para el regulador, accidente y dolo se tratan igual cuando hay datos personales expuestos.
Brechas digitales. El vector es técnico: ransomware que cifra y exfiltra antes de pedir rescate, phishing exitoso que entrega credenciales válidas, exfiltración silenciosa por una API mal expuesta, vulnerabilidades en SaaS que comprometen tenants completos, o exposición de S3 buckets sin auth. Son las que se llevan los titulares, pero no son la mayoría de los casos en pymes chilenas.
Brechas internas. El vector es humano y autorizado: un empleado descontento que copia la base de clientes antes de renunciar, un contractor con acceso excesivo que descarga lo que no debía, un error humano (correo enviado al destinatario equivocado, planilla compartida con permisos públicos), o uso indebido de credenciales por parte de personal autorizado. Son las más difíciles de detectar porque vienen desde dentro del perímetro y muchas veces involucran credenciales válidas. Distintos reportes de la industria coinciden en que el factor humano (sea por dolo o por error) está presente en una proporción significativa de los incidentes reportados.
Mini escenario: Una pyme de 80 personas en Providencia. Un ejecutivo de cuentas pierde la laptop en un taxi. Tiene la base de 1.200 clientes, con RUT, correo y monto contratado. ¿Es brecha? Depende de tres cosas: si BitLocker estaba activo, si había sesión activa abierta, y si IT puede ejecutar un wipe remoto antes de que alguien acceda al disco. Sin esos tres datos en log, no puedes responder al directorio el lunes ni al regulador después.
Quick win: Mapea hoy tu superficie física: porcentaje de la flota con cifrado verificado (no "configurado", verificado), dispositivos sin agente de gestión, política activa de USB y almacenamiento removible. Si menos del 90% de la flota tiene cifrado verificado, esa es tu mayor exposición no atendida. Si la pérdida de un dispositivo te obligaría a una notificación reportable, la siguiente pregunta es si tu plataforma puede ejecutar un borrado remoto de datos y dejar evidencia en log.
Las 3 fases de una brecha: examinación, entrada, exfiltración
Las brechas no ocurren en un instante. Hay una cadena que casi siempre se cumple, y entender las fases te da las ventanas para detectar antes de que el daño esté hecho.
Fase 1: Examinación. Es el reconocimiento. El atacante (o el oportunista) está mirando: escaneando puertos abiertos, recolectando OSINT en LinkedIn para identificar empleados con acceso, probando si hay credenciales corporativas en dumps públicos, mapeando la infraestructura. Para una brecha física, la fase 1 es el ladrón observando que el ejecutivo deja la laptop en el café del piso 1. Es la fase más larga y la más invisible.
Fase 2: Entrada. Es la explotación. El atacante usa lo que aprendió en fase 1 para conseguir acceso: una credencial filtrada que sigue activa, un phishing que el empleado abrió, un parche faltante en un servidor público, o el acceso físico al dispositivo perdido. En esta fase se cruza el umbral. Si tienes monitoreo de credenciales, alertas de geolocation anómala, o detección de inicios de sesión desde dispositivos no inventariados, fase 2 es donde se atrapan las brechas que sí se atrapan.
Fase 3: Exfiltración. Es la salida del dato. Puede ser silenciosa (transferencia gradual a un C2) o estruendosa (publicación en un foro de la dark web pidiendo rescate). En brechas físicas, fase 3 es el momento en que el contenido del disco perdido aparece en un dump. La diferencia entre detectar en fase 2 y detectar en fase 3 puede ser de millones de dólares y de la diferencia entre notificar "intento fallido" o "5.000 registros expuestos".
Quick win: Define qué señal monitoreas en cada fase, y por dónde llega. Fase 1: aparición de credenciales corporativas en dumps. Fase 2: intentos de login desde IPs/países anómalos, dispositivos no inventariados accediendo a SaaS críticos. Fase 3: transferencias salientes inusuales, picos de descargas desde el CRM. Sin al menos una señal por fase, tu detección depende del azar. Para profundizar en cómo se prepara el equipo para cada fase, revisa el setup de IRT, IRP y técnicas de detección.
Modelo de evidencia de cumplimiento ley 21.719
Conoce si tu organización puede demostrar cumplimiento con la Ley ante una fiscalización. Evalúa tu modelo por componente y detecta brechas críticas.
Descargar Checklist
Checklist de Cumplimiento – Ley de protección de datos (21.719)
¿Quieres empezar con una hoja de ruta clara? Prepara a tu organización para cumplir con las nuevas exigencias regulatorias.
Descargar Checklist
Qué obligan Ley 21.719 y Ley 21.663 cuando ocurre una brecha
Aquí es donde la teoría se vuelve calendario.
Chile maneja dos leyes que se cruzan cuando ocurre una brecha, y ambas tienen plazos cortos y exigencias de evidencia que la mayoría de las pymes no tienen lista.
Ley 21.719 (Protección de Datos Personales). Si la brecha involucra datos personales y representa riesgo para los derechos de los titulares, debes notificar a la Agencia de Protección de Datos y a los titulares afectados "sin demora indebida". El artículo 14 quinquies no fija un plazo numérico explícito; en la práctica, distintas guías chilenas están convergiendo hacia las 72 horas como referencia operativa, alineado con el estándar GDPR (Art. 33). Hasta que la Agencia emita criterio formal, la postura conservadora es notificar dentro de 72 horas y documentar la cadena de decisión. La notificación debe incluir: tipo y volumen de datos comprometidos, alcance (cuántos titulares), medidas adoptadas, contacto del DPO, y una evaluación de probable impacto.
Ley 21.663 (Marco de Ciberseguridad). Si tu organización está bajo el alcance OIV (sectores críticos: financiero, salud, energía, telecomunicaciones, transporte, agua, etc.), tienes obligación de reportar incidentes a la ANCI con plazos escalonados:
- 3 horas desde la toma de conocimiento para alerta temprana
- 72 horas para entregar información detallada
- 15 días para el reporte final con análisis y medidas correctivas
Si la brecha cruza ambos marcos (caso típico: una empresa OIV con datos personales), tienes que notificar en paralelo a ambos reguladores con criterios y plazos distintos. No hay un proceso unificado.
Lo que ambas leyes asumen, y aquí está la trampa, es que la empresa puede demostrar lo que pasó. Sin trail operativo de endpoints, sin logs exportables, sin timestamps de las acciones tomadas, la notificación se vuelve una declaración de fe frente al regulador. Y "creemos que pasó esto" no es una defensa válida cuando viene la sanción.
Quick win: Identifica si tu organización está bajo Ley 21.663 (revisa si tu sector está listado como OIV). Si lo está, ten una "carpeta de evidencia ANCI" preparada: logs de los últimos 30 a 90 días exportables, plantilla de notificación inicial, contactos del comité de crisis, y un flujo de decisión documentado de quién autoriza la notificación. Para el proceso operativo de notificación, revisa el detalle de reporte de incidentes a ANCI bajo Ley 21.663, y la hoja de ruta de cumplimiento de Ley 21.719.
Cómo se ve una brecha en tu flota: 3 escenarios operativos
Las brechas que llegan al regulador casi nunca son ataques de Estado. Son situaciones cotidianas mal gestionadas. Aquí van tres reales que se repiten, y qué define en cada caso si es brecha notificable.
Escenario 1: La laptop perdida del viernes
Un ejecutivo de cuentas pierde la laptop el viernes a las 7pm y te avisa por WhatsApp esa misma noche. El lunes 9am, tres días después, la laptop sigue sin aparecer y el caso entra al ticket formal de IT. El equipo tiene la base de clientes con RUT, dirección, correo y datos de pago de los últimos 12 meses.
¿Brecha notificable bajo 21.719? Depende de:
- ¿Estaba BitLocker activo y verificable en el log de la consola de gestión?
- ¿Había sesión autenticada activa al momento de la pérdida?
- ¿Los datos personales eran identificables (RUT + dirección + monto)?
- ¿IT pudo ejecutar wipe remoto antes de que el dispositivo se conectara a una red ajena?
Si BitLocker estaba activo, sin sesión abierta, y se ejecutó wipe con timestamp en log, tienes un caso defendible: el riesgo material para los titulares es bajo y la evidencia operativa lo respalda. Si no, la notificación es probable, y va a costar.
Escenario 2: Credenciales en dark web
Lunes 8am. Tu sistema de monitoreo de credenciales (o un correo de un cliente) avisa que 47 cuentas con dominio @empresa.cl aparecen en un dump publicado hace 3 meses. Origen: una brecha en un proveedor SaaS de la cual se enteraron tarde.
El reloj corre desde que tomas conocimiento, no desde el evento. Esa es la mecánica regulatoria. Lo que sigue es:
- Identificar a los 47 usuarios afectados
- Forzar reset de password y revocar sesiones activas
- Cruzar logs de los últimos 90 días: ¿alguna de esas credenciales fue usada para acceder a sistemas que contienen datos personales?
- Si la respuesta es sí, evaluar bajo Ley 21.719 y notificar a la Agencia y a los titulares cuyos datos hayan podido comprometerse
¿Los datos de tu empresa están circulando en la dark web?
Detecta credenciales y datos corporativos comprometidos antes de que los atacantes puedan explotarlos.
Detecta la exposición de tus datos.
La trampa de este escenario es la fase 3 silenciosa: si los atacantes ya usaron las credenciales sin que lo notaras, "no las usaron contra nosotros" es una hipótesis, no una conclusión.
Escenario 3: Acceso desde dispositivo no inventariado
Logs del CRM muestran un acceso válido (credenciales correctas, MFA pasado) desde una IP nueva geolocalizada en Lima, a las 3am hora de Santiago. El usuario titular dice que estaba durmiendo en San Miguel.
¿Brecha o anomalía? Depende de poder cruzar ese acceso con tu inventario de dispositivos. Si la sesión vino desde un dispositivo no enrolado en tu plataforma de gestión, tienes un problema doble: alguien tiene credenciales válidas y un dispositivo capaz de pasar MFA. Sin visibilidad de fleet, este caso queda en limbo durante días, y el regulador no acepta "no sabíamos" como defensa.
Quick win: Define en tu IRP un árbol de decisión de 5 minutos para clasificar incidentes (brecha sí/no, datos personales sí/no, OIV sí/no). Activa BitLocker como default en provisioning de toda laptop nueva. Configura alertas de geolocalización fuera de las zonas de trabajo declaradas y de inicios de sesión desde dispositivos no inventariados. Cuando estos tres mecanismos están vivos, los escenarios anteriores se detectan en horas, no en semanas. Para profundizar en credenciales filtradas en la dark web, ahí está el desglose completo.
Visibilidad y evidencia: el rol del endpoint en la respuesta
El endpoint es el primer y último eslabón de la respuesta a una brecha. Es donde empieza la cadena (laptop perdida, credencial usada en un dispositivo comprometido), y es donde tienes que poder demostrar lo que pasó cuando llegue el regulador.
Una plataforma de gestión y seguridad de endpoints habilita tres capacidades que no son negociables si manejas datos personales:
Visibilidad antes de la brecha. Inventario actualizado de toda la flota (Windows, macOS, Linux, Android, iOS, Chromebook), estado verificable de cifrado (BitLocker activo o no), última ubicación conocida, último check-in, software instalado. Lo que no está en tu inventario no puede protegerse y no puede mostrarse al regulador.
Detección durante. Monitoreo de credenciales corporativas en la dark web (Breach Monitoring), geofencing con alertas cuando un dispositivo sale de zonas de trabajo, anomalías de comportamiento. Permite atrapar fase 2 y fase 3 antes de que la exfiltración esté completa.
Contención y evidencia. Lock remoto y wipe remoto ejecutables en minutos, con audit log timestamped. Historial de ubicación. Reportes exportables para entregar a la Agencia o a ANCI como prueba de las medidas adoptadas.
Plataformas como Prey encajan en este rol cuando manejas flotas mixtas de OS, equipos de IT pequeños y la necesidad de tener evidencia exportable lista para auditoría sin proyectos de implementación de seis meses. Lo importante no es la herramienta específica, sino la capacidad de responder en minutos en vez de en días, con un trail que el regulador acepte. Si quieres ver cómo funciona el monitoreo de credenciales en la dark web en la práctica, esa guía cubre el flujo completo.
Quick win: Verifica que tu plataforma actual de endpoint tenga audit log exportable (no solo visible en consola). Activa monitoreo de credenciales corporativas en dark web. Define una vista predefinida de "evidencia últimos 90 días" lista para auditoría: estado de cifrado, acciones remotas ejecutadas, logs de ubicación. Si tu equipo no puede generar ese paquete en menos de 30 minutos, ese es el primer gap a cerrar.
Conclusión
Las brechas de datos no son eventos extraordinarios. Son situaciones cotidianas (laptops perdidas, credenciales filtradas, accesos anómalos) que se vuelven extraordinarias por la respuesta. Y la respuesta depende de la evidencia que puedes mostrar.
La diferencia entre una notificación defendible y una sanción de hasta 4% del revenue bajo Ley 21.719 no se juega en la política escrita. Se juega en si tu equipo, el lunes a las 9am, puede responder con datos: qué dispositivo, cuándo, qué accedió, qué se contuvo, en qué timestamp. Si esa respuesta tarda días en ensamblarse, ya perdiste.
Empieza esta semana con tres cosas: define tu criterio operativo de brecha alineado al artículo 14 quinquies, mapea tus bases de datos personales vs operacionales, y verifica que tu plataforma de endpoint pueda exportar evidencia de los últimos 90 días en menos de 30 minutos. Esos tres entregables son lo que separa a las empresas que respondieron a una brecha de las que están explicándole al regulador qué fue lo que creen que pasó.
Preguntas frecuentes
¿Una credencial filtrada en dark web es una brecha de datos?
Depende. Una credencial corporativa filtrada es una brecha de seguridad, pero solo dispara Ley 21.719 si esa credencial fue usada (o pudo haber sido usada) para acceder a datos personales. Si tienes monitoreo de credenciales y forzaste el reset antes del uso, el evento es contenible. Si los logs muestran que se usó para acceder al CRM en los últimos 90 días, es brecha de datos personales y se notifica.
¿Cuánto tiempo tengo para notificar una brecha en Chile?
Bajo Ley 21.719, "sin demora indebida". El texto del artículo 14 quinquies no fija un plazo numérico explícito, pero la práctica chilena se está alineando con el estándar GDPR de 72 horas desde la toma de conocimiento como referencia operativa. Bajo Ley 21.663 para OIV, son 3 horas para alerta temprana, 72 horas para información detallada, y 15 días para el reporte final. Si la brecha involucra datos UE, GDPR exige 72 horas a la autoridad supervisora.
¿Qué pasa si la laptop perdida estaba cifrada?
Si BitLocker (o equivalente) estaba activo y verificable en log, sin sesión abierta al momento de la pérdida, y puedes demostrarlo con evidencia exportable de tu plataforma de gestión, el riesgo material es bajo y la notificación puede ser evitable o minimizable. Si el cifrado estaba "configurado" pero no verificable en log, la situación es la misma que si no hubiera estado cifrada para efectos prácticos: no puedes probarlo.
¿Brecha de seguridad y brecha de datos personales son lo mismo?
No. Una brecha de seguridad es cualquier compromiso de tus controles, sistemas o infraestructura. Una brecha de datos personales es un subset específico donde los datos comprometidos identifican o son asociables a una persona natural. Toda brecha de datos personales es brecha de seguridad, pero no al revés. Esta distinción define qué ley aplica y a quién notificas.
¿A quién notifico una brecha en Chile: Agencia, ANCI o ambas?
A la Agencia de Protección de Datos si hay datos personales involucrados (Ley 21.719). A ANCI si tu organización está bajo el alcance de Ley 21.663 (sectores OIV). Si la brecha cruza ambas (caso típico: empresa OIV con datos personales), notificas a ambas en paralelo, con plazos y requisitos distintos. No hay proceso unificado.
¿Qué evidencia pide el regulador como prueba de las medidas adoptadas?
Logs timestamped de las acciones ejecutadas (wipe remoto, lock, reset de credenciales, revocación de sesiones), reportes exportables del estado de cifrado de la flota, historial de ubicación del dispositivo afectado, registros de comunicaciones internas de respuesta, y la cadena de decisión documentada (quién autorizó qué, cuándo). El criterio operativo es: si no está exportable y timestamped, para efectos del regulador no existe.
