Respuesta Breve (Fragmento Destacado)
La notificación de una brecha de seguridad de datos en Chile debe activarse sin dilaciones indebidas cuando exista un riesgo razonable para los derechos y libertades de las personas. La Ley 21.719 exige reportar la vulneración a la Agencia de Protección de Datos Personales, registrar sus efectos y comunicarla a los titulares cuando involucre datos sensibles, de menores de 14 años o información económica, financiera, bancaria o comercial. La ley no fija un plazo universal de 24 o 72 horas para este reporte: la empresa debe tener un protocolo que califique el riesgo y permita informar de inmediato con antecedentes verificables.
Qué es una brecha de seguridad de datos
Una brecha de seguridad es una vulneración que puede destruir, filtrar, perder o alterar datos personales, o permitir su comunicación y acceso no autorizados. Puede originarse en ransomware, robo de credenciales, un correo enviado al destinatario equivocado, una mala configuración de nube, un notebook perdido o un proveedor comprometido.
No es necesario esperar a confirmar el volumen total de información para activar la respuesta. El criterio de gestión es el riesgo razonable para los derechos y libertades de los titulares. La investigación continúa mientras la empresa contiene el incidente y prepara un reporte inicial responsable.
Incidente técnico no siempre significa brecha notificable
Una alerta de antivirus, un intento bloqueado o una caída de servidor pueden ser incidentes de seguridad sin acceso confirmado a datos personales. En cambio, una cuenta comprometida que permite descargar una base de clientes requiere una evaluación de brecha, aunque todavía no se conozca cuántos registros fueron copiados.
La diferencia exige visibilidad sobre identidades, permisos, logs, respaldos y flujos de datos. Sin inventario, la gerencia no puede medir exposición ni decidir si corresponde notificar; solo está especulando bajo presión.
Qué exige la Ley 21.719 sobre la notificación
La versión de la Ley 21.719 consultada en Ley Chile tiene vigencia diferida al 1 de diciembre de 2026. Existe un proyecto, Boletín 18.623-07, que propone postergar esa entrada en vigencia al 1 de diciembre de 2027 y que al momento de redactar se encuentra en tramitación. Por eso, el protocolo debe distinguir entre la obligación legal vigente, la fecha de entrada en vigor publicada y los cambios que eventualmente apruebe el Congreso.
El artículo 14 sexies establece que el responsable debe reportar a la Agencia, por los medios más expeditos posibles y sin dilaciones indebidas, las vulneraciones a las medidas de seguridad que generen un riesgo razonable. La obligación no se limita a ataques sofisticados: también cubre errores operativos y fallas de terceros si afectan datos personales bajo responsabilidad de la empresa.
La notificación no reemplaza la investigación
El reporte inicial debe ser útil, no perfecto. Debe informar lo que la empresa conoce, separar hechos de hipótesis y actualizar los antecedentes cuando avance el análisis. Esperar un informe forense definitivo puede transformar una investigación diligente en una demora difícil de justificar.
La empresa debe revisar el texto oficial de la Ley 21.719 en Ley Chile y mantener controlada su versión de vigencia antes de aprobar el procedimiento interno.
A quién y cuándo se debe informar
El protocolo debe separar dos destinatarios: la Agencia de Protección de Datos Personales y los titulares afectados. El reporte a la Agencia se activa cuando la vulneración cumple el umbral de riesgo razonable indicado por la ley. La comunicación a titulares tiene exigencias específicas adicionales.
Reporte a la Agencia
La norma ordena utilizar los medios más expeditos posibles y actuar sin dilaciones indebidas. No establece en el artículo 14 sexies un cronómetro general de 24 o 72 horas aplicable a todas las empresas. Por eso, una política corporativa no debe copiar plazos de otros regímenes regulatorios sin analizar si la entidad y el incidente están dentro de su ámbito.
Comunicación a los titulares
La comunicación también debe hacerse a los titulares —por medio de sus representantes cuando corresponda— si la vulneración involucra datos personales sensibles, datos de niños y niñas menores de 14 años o datos relativos a obligaciones económicas, financieras, bancarias o comerciales.
El mensaje debe ser claro y sencillo. Debe singularizar los datos afectados, explicar las posibles consecuencias y describir las medidas de solución o resguardo adoptadas. Si no es posible notificar a cada persona, la ley contempla la difusión o publicación de un aviso en un medio de comunicación social masivo y de alcance nacional.
Plazos: cómo evitar el error de las “24 o 72 horas”
En una crisis circulan referencias a plazos de 24, 72 o 96 horas. El problema es que esos números pueden pertenecer a contratos, estándares, pólizas o leyes sectoriales distintas. Presentarlos como un plazo único de la Ley 21.719 puede llevar a una falsa sensación de cumplimiento o a una decisión equivocada.
| Elemento | Qué debe hacer la empresa | Riesgo de gestionarlo mal |
|---|---|---|
| Activación | Registrar el evento, nombrar al líder del incidente y preservar evidencias desde la detección. | Perder logs, sobrescribir respaldos y no poder reconstruir la línea de tiempo. |
| Calificación | Identificar datos, titulares, alcance, causa probable y riesgo para las personas. | Notificar tarde o informar a la Agencia sin antecedentes mínimos. |
| Reporte a la Agencia | Informar por el medio más expedito posible, sin dilaciones indebidas, cuando exista riesgo razonable. | Confundir una investigación incompleta con autorización para esperar. |
| Comunicación a titulares | Notificar en lenguaje claro cuando se trate de las categorías de datos indicadas por la ley. | Ocultar consecuencias relevantes o entregar un mensaje incomprensible. |
| Actualización y cierre | Registrar decisiones, medidas de contención, recuperación y controles para evitar recurrencia. | Repetir la brecha y no demostrar diligencia ante una fiscalización o reclamo. |
La recomendación de ingeniería es trabajar con un plazo operativo interno más exigente que el mínimo legal: activar en minutos, calificar durante las primeras horas y escalar a gerencia, asesoría legal y TI en paralelo. El objetivo no es llenar un formulario; es reducir el tiempo de exposición y proteger la continuidad operativa.
Protocolo de respuesta en siete pasos
1. Detectar y declarar el incidente
Recibe la alerta desde el EDR, firewall, mesa de ayuda, usuario o proveedor. Asigna un identificador, registra fecha y hora, y declara formalmente el incidente. La trazabilidad comienza antes de saber si hubo exfiltración.
2. Contener sin destruir evidencia
Aísla equipos, revoca sesiones, bloquea credenciales y segmenta redes según el plan aprobado. No borres archivos, reformatees servidores ni reinicies sistemas críticos sin preservar logs e imágenes forenses. La recuperación rápida no justifica perder la evidencia que explica el alcance.
3. Identificar los datos comprometidos
Cruza inventario de activos con permisos, respaldos, bases de datos, correo, ERP y servicios cloud. Clasifica las categorías de datos, los titulares potencialmente afectados, el período de exposición y si existía cifrado o anonimización efectiva.
4. Evaluar el riesgo
Considera sensibilidad, volumen, facilidad de identificación, posibilidad de fraude, impacto financiero y consecuencias para las personas. Un archivo con datos bancarios, credenciales o información de salud no se gestiona igual que un listado interno sin datos sensibles.
5. Preparar y enviar el reporte
El expediente debe incluir la naturaleza de la vulneración, sus efectos, las categorías de datos, el número aproximado de titulares afectados, las medidas adoptadas y las acciones para prevenir incidentes futuros. Si un dato aún es estimado, decláralo como estimación y deja programada su actualización.
6. Comunicar a las personas afectadas
Redacta un mensaje que explique qué ocurrió, qué información pudo verse afectada, qué consecuencias son posibles y qué medidas debe tomar el titular. Evita tecnicismos, promesas absolutas y lenguaje que minimice el impacto.
7. Recuperar y corregir
Restaura desde respaldos confiables, elimina persistencia del atacante, cambia secretos, corrige configuraciones y valida el monitoreo. El cierre requiere una revisión ejecutiva con causa raíz, costo del downtime, controles pendientes y dueño de cada acción.
Qué debe conservar la empresa como evidencia
Una notificación sin respaldo documental no demuestra control. Conserva la línea de tiempo, alertas, tickets, logs de autenticación, reglas de firewall, hash de archivos relevantes, respaldos, comunicaciones internas, decisiones de contención y versiones de los reportes enviados.
También registra quién decidió no notificar y por qué. Si el análisis concluye que no existió riesgo razonable, esa conclusión debe apoyarse en hechos: datos afectados, controles existentes, alcance validado y revisión de las áreas responsables.
El costo financiero de improvisar
Cada hora sin calificar una brecha aumenta el costo de investigación, recuperación y comunicación. A eso se suman facturación detenida, horas improductivas, asesoría legal de urgencia, pérdida de confianza y posibles sanciones. Un protocolo mantenido como OpEx preventivo suele ser menor que reconstruir evidencia después de un incidente.
Para que el control funcione, TI debe conocer los activos y respaldos; Finanzas debe poder estimar el impacto; gerencia debe tener autoridad de escalamiento; y los contratos con proveedores deben definir cooperación, evidencias y aviso de incidentes.
Cómo preparar tu empresa antes de una brecha
Empieza por un inventario de tratamientos: clientes, trabajadores, proveedores, videovigilancia, marketing, correo, ERP y servicios cloud. Para cada flujo, registra finalidad, categorías de datos, responsables, encargados, accesos, retención y controles. La matriz de bases de licitud y tratamiento debe conectarse con este inventario, no quedar como documento aislado.
Checklist de preparación ejecutiva
Antes de la entrada en vigencia, verifica que exista un canal de reporte 24/7, lista de contactos, responsables suplentes, procedimiento de preservación de evidencia y plantillas para la Agencia y los titulares. Prueba el proceso con un simulacro de ransomware o filtración de credenciales.
Revisa además MFA, privilegio mínimo, segmentación, EDR, respaldos inmutables, parches, monitoreo y acuerdos de nivel de servicio. La ciberseguridad no es solo CapEx en infraestructura: es capacidad operacional para detectar, decidir, informar y recuperar sin detener la empresa.
Para entender el marco completo, consulta la guía sobre Ley de Protección de Datos Personales en Chile. Este artículo se enfoca exclusivamente en la respuesta ante brechas y debe complementarse con revisión legal según el tratamiento y sector de tu empresa.
Veredicto Editorial: una brecha de seguridad no se gestiona esperando tener todos los datos. Se activa, contiene, califica y reporta con evidencia; después se actualiza. La Ley 21.719 no autoriza a convertir la investigación en una excusa para demorar. Si tu empresa no puede identificar rápidamente qué datos trata, quién accede y cómo recuperar sus logs, todavía no tiene un protocolo de notificación: tiene una reacción improvisada.
Preguntas Frecuentes (Answer Engine Optimization)
1. ¿Qué es una brecha de seguridad de datos?
Es una vulneración que puede destruir, filtrar, perder o alterar datos personales, o permitir su comunicación o acceso no autorizados. Puede originarse en un ataque, un error humano, una mala configuración o un proveedor comprometido.
2. ¿Cuál es el plazo para notificar una brecha según la Ley 21.719?
El artículo 14 sexies exige reportar a la Agencia por los medios más expeditos posibles y sin dilaciones indebidas cuando exista un riesgo razonable. No fija un plazo universal de 24 o 72 horas para todas las empresas.
3. ¿Cuándo debo informar una brecha a los titulares?
Cuando la vulneración involucra datos sensibles, datos de niños y niñas menores de 14 años o datos relativos a obligaciones económicas, financieras, bancarias o comerciales. La comunicación debe ser clara y explicar datos afectados, consecuencias y medidas adoptadas.
4. ¿Qué información debe contener el reporte de una brecha?
Debe describir la naturaleza de la vulneración, sus efectos, las categorías de datos, el número aproximado de titulares afectados y las medidas adoptadas para gestionarla y prevenir incidentes futuros. Los datos estimados deben identificarse como tales y actualizarse.
5. ¿Cómo puede prepararse una pyme para notificar una brecha?
Debe mantener un inventario de datos y sistemas, contactos de escalamiento, procedimiento de preservación de evidencia, respaldos confiables, monitoreo y plantillas de comunicación. Un simulacro permite probar el protocolo antes de que el incidente detenga la operación.
