Saltar al contenido principal
100% Gratis · Sin registro

Generador de Protocolo de Brechas de Seguridad

Ley 21.719, Art. 14 sexies · 4 fases de respuesta · sin dilaciones indebidas + plantilla de comunicación

Paso 1 de 4Organización

Datos de tu organización

Aparecerán en el encabezado y en la plantilla de comunicación a afectados.

PrivacidadWeb.cl genera templates orientativos basados en la Ley N° 21.719. No constituye asesoría legal.

¿Qué es un protocolo de brechas y qué exige la Ley 21.719?

Un protocolo de brechas es el procedimiento interno que tu empresa activa cuando ocurre un incidente de seguridad que compromete datos personales. El Art. 14 sexies de la Ley N° 21.719 crea la obligación de notificar a la Agencia de Protección de Datos Personales (APDP) cuando existe una vulneración de seguridad significativa. La ley chilena usa el término "vulneración de seguridad", no "brecha" (que es terminología del GDPR europeo), aunque ambas expresiones se usen coloquialmente.

Tener el protocolo listo antes de un incidente evita errores que agravan la situación. Sin uno, la empresa puede fallar en notificar dentro del tiempo apropiado, destruir evidencia por desconocimiento, o comunicarse mal con los usuarios afectados. Todos esos errores pueden convertir un incidente manejable en una sanción grave. El Art. 14 sexies exige actuar "sin dilaciones indebidas" una vez confirmada la vulneración significativa, lo que requiere tener el proceso definido de antemano, no improvisarlo bajo presión.

¿Qué debe contener el protocolo de vulneraciones?

Un protocolo efectivo cubre desde la identificación del incidente hasta las mejoras posteriores. Estos son los elementos esenciales:

  • Definición de qué constituye una vulneración significativa — el umbral a partir del cual se activa el protocolo completo y la obligación de notificar
  • Equipo de respuesta y responsabilidades — quién hace qué: quién decide notificar, quién contacta a la APDP, quién comunica a los titulares
  • Pasos de contención inmediata — aislar los sistemas afectados, revocar accesos comprometidos, preservar la evidencia sin alterarla
  • Procedimiento de evaluación de impacto — determinar qué datos fueron comprometidos, cuántos titulares se vieron afectados y qué riesgo conlleva
  • Plantilla de notificación a la APDP (Art. 14 sexies) — con todos los campos requeridos: naturaleza del incidente, datos comprometidos, medidas adoptadas
  • Plantilla de comunicación a titulares afectados — en lenguaje claro, explicando qué ocurrió y qué pueden hacer para protegerse
  • Registro del incidente y acciones tomadas — documentación cronológica para demostrar diligencia ante la APDP
  • Análisis de causa raíz y mejoras post-incidente — para evitar que el mismo tipo de vulneración se repita
  • Criterio de notificación temporal — el estándar es actuar "sin dilaciones indebidas" (Art. 14 sexies) una vez confirmada la vulneración significativa

¿Qué empresas necesitan este protocolo?

Toda empresa que trate datos personales necesita un protocolo de vulneraciones, especialmente aquellas que manejan datos de alto riesgo. Las clínicas y centros médicos tienen una obligación reforzada porque los datos de salud son la categoría de mayor sensibilidad. Las tiendas online gestionan datos de pago que son objetivo frecuente de hackeos. Los estudios contables almacenan RUT y datos tributarios de sus clientes. Las startups y empresas tech son vulnerables a brechas por configuración incorrecta de servicios cloud. Finalmente, cualquier empresa con empleados tiene datos de RRHH que representan un vector de ataque frecuente.

Diferencia entre detectar, contener y notificar

El proceso de respuesta tiene tres fases distintas. Detección: identificar que existe un incidente de seguridad que puede haber comprometido datos personales. Contención: detener el daño, aislar sistemas afectados y preservar la evidencia para el análisis posterior. Notificación: comunicar a la APDP y, si corresponde, a los titulares afectados cuando la vulneración es significativa. Un punto clave: la Ley 21.719 exige notificar "sin dilaciones indebidas" — el plazo empieza cuando confirmas que hay una vulneración significativa, no cuando la detectas por primera vez. Eso te da tiempo para evaluar el alcance antes de notificar. El protocolo generado incluye árboles de decisión para cada fase.

Aprende de casos reales: 4 vulneraciones que cambiaron las reglas

Casos cerrados con sentencia firme bajo GDPR (Europa) y leyes federales de Estados Unidos. La Ley 21.719 toma referencias claras de estos marcos, así que sirven para anticipar cómo razonará la Agencia chilena al ponderar agravantes y atenuantes (Arts. 36 y 37).

Equifax (2017, Estados Unidos)

147 millones de afectados · USD 575 millones (mínimo, hasta 700M)

Datos clave. 147 millones de personas afectadas (incluyendo 145,5 millones de números de seguridad social y 209.000 tarjetas de pago). Acuerdo regulatorio del 22 de julio de 2019 con la FTC, CFPB y 48 estados: USD 575 millones como mínimo, potencialmente hasta USD 700 millones. Causa técnica: vulnerabilidad de Apache Struts (alerta US-CERT del 9 de marzo de 2017) que la empresa no parchó dentro de las 48 horas recomendadas. Período del acceso no autorizado: mediados de mayo a julio de 2017. Detección por Equifax: 29 de julio de 2017. Notificación pública: 7 de septiembre de 2017 — alrededor de 40 días de demora.

Lección para Chile. Bajo el Art. 14 quinquies de la Ley 21.719 (deber de seguridad), conocer una vulnerabilidad y no parcharla constituye negligencia grave. Bajo el Art. 14 sexies (deber de notificación), los 40 días entre detección y comunicación pública configurarían "dilación indebida". Combinado con el volumen masivo y el tipo de datos económicos comprometidos, la conducta calificaría como infracción gravísima (Art. 34 quáter) en Chile.

Lo que habría atenuado. Protocolo de gestión de vulnerabilidades documentado, notificación oportuna a la autoridad, plan de comunicación a afectados pre-existente. Estas son las atenuantes del Art. 36 N° 1 (acciones de reparación) y N° 2 (colaboración con la autoridad).

British Airways (2018, Reino Unido)

~430.000 afectados · £20 millones (multa final; £183 millones la propuesta original)

Datos clave. Aproximadamente 430.000 clientes afectados según el Monetary Penalty Notice del ICO (16 de octubre de 2020). Multa propuesta originalmente en julio de 2019: £183,39 millones — caso emblemático por ser la primera multa multimillonaria bajo GDPR. Multa final tras representaciones de BA y ajuste por COVID-19: £20 millones (11% del NOI inicial). Causa técnica documentada por el ICO: credenciales privilegiadas guardadas en archivo de texto plano (hardcoding) que permitieron a un atacante acceder al sistema de remote access. Datos comprometidos: información de tarjeta de pago, credenciales y datos personales.

Lección para Chile. Bajo el Art. 14 quinquies de la Ley 21.719, hardcodear credenciales en archivos de texto plano violenta el deber de adoptar medidas técnicas razonables. Los datos financieros (tarjetas) son sensibles bajo el Art. 2° letra g) y exigen estándar reforzado. Tipificación esperable: infracción gravísima (Art. 34 quáter).

Lo que atenuó la sanción. El ICO redujo 20% por las acciones de mitigación de BA y otros £4 millones por el contexto COVID-19. La estructura de atenuantes del Art. 36 (acciones de reparación, colaboración, ausencia de sanciones previas) opera con la misma lógica.

Marriott / Starwood (2018, Reino Unido)

339 millones de huéspedes (cifra ICO) · £18,4 millones (multa final; £99 millones la propuesta original)

Datos clave. 339 millones de registros de huéspedes en todo el mundo según el Monetary Penalty Notice del ICO (30 de octubre de 2020). Marriott había estimado inicialmente hasta 500 millones (noviembre 2018) y posteriormente revisó a 383 millones (enero 2019). De los registros, 5,25 millones contenían números de pasaporte sin cifrar. Multa propuesta originalmente: £99,2 millones; multa final: £18,4 millones. Período de la vulneración: ataque iniciado en 2014 y no detectado hasta septiembre de 2018 — cuatro años sin detectar. La brecha estaba en sistemas de Starwood, adquiridos por Marriott en 2016.

Lección para Chile. Las vulneraciones heredadas en operaciones de M&A son responsabilidad del adquirente. Bajo la Ley 21.719, la due diligence de protección de datos antes de fusiones y adquisiciones forma parte del deber de seguridad del Art. 14 quinquies. Cuatro años sin detectar configuraría carácter continuado (agravante del Art. 36 letra b). Pasaportes sin cifrar = ausencia de medida técnica básica para datos de identificación oficial.

Lo que habría ayudado. Auditoría de seguridad pre-adquisición, monitoreo retroactivo de sistemas heredados, mapeo claro de qué empresa procesa qué datos. Cifrado AES-128 en lugar de SHA-1 (que Marriott reconoció en 2024 que se había usado en parte de los registros).

Yahoo (2013-2014, divulgado 2016)

3.000 millones de cuentas · USD 35 millones (multa SEC) + USD 350 millones de ajuste en adquisición Verizon

Datos clave. Originalmente Yahoo divulgó "cientos de millones" en diciembre de 2016. En octubre de 2017, ya bajo Verizon/Oath, se confirmó que las 3.000 millones de cuentas existentes en 2013 fueron afectadas. La SEC sancionó a Altaba (sucesor de Yahoo) con USD 35 millones el 24 de abril de 2018, por la intrusión específica de diciembre de 2014, atribuida a oficiales del FSB ruso (acusación DOJ del 15 de marzo de 2017). Tiempo entre detección y notificación pública: aproximadamente 2 años. Verizon redujo el precio de adquisición en USD 350 millones tras conocer la vulneración.

Lección para Chile. Dos años de demora en notificar configuran "dilación indebida" claramente. Bajo el Art. 14 sexies de la Ley 21.719, omitir deliberadamente la comunicación de una vulneración es infracción gravísima (Art. 34 quáter letra f). En el caso de empresas listadas en bolsa, la falta de controles internos para evaluar materialidad cibernética genera doble exposición — ante la APDP y, en Chile, eventualmente ante la CMF.

Lo que habría ayudado. Cadena de mando clara para escalamiento de incidentes, procedimiento de notificación pre-establecido, cultura de transparencia frente al regulador. Estos elementos se materializan en un protocolo escrito y probado antes del incidente — exactamente el tipo de "diligencia debida" que el Art. 36 N° 5 reconoce como atenuante a través del Modelo de Prevención del Art. 49.

Estos casos comparten un patrón claro: la magnitud de la sanción depende menos de cómo ocurrió la vulneración y más de cómo se gestionó después. Tener un protocolo escrito antes del incidente es lo único que distingue una multa estimada de una catastrófica.

Genera tu Protocolo de Brechas →

Fuentes: FTC Press Release (Equifax), ICO Marriott MPN, SEC Yahoo Order, DOJ Indictment. Casos seleccionados por su precedente regulatorio bajo GDPR y leyes federales de EE.UU.

Preguntas frecuentes

¿Qué es una vulneración de seguridad de datos personales?

La Ley 21.719 (Art. 14 sexies) usa el término 'vulneración de seguridad' para referirse a cualquier incidente que afecte la confidencialidad, integridad o disponibilidad de datos personales: un hackeo, filtración por error humano, pérdida de un dispositivo con datos, acceso no autorizado a un sistema, o envío accidental de datos a destinatarios incorrectos. No toda vulneración es grave, pero todas deben evaluarse y documentarse.

¿A quién debo notificar en caso de una brecha de datos?

El Art. 14 sexies de la Ley 21.719 exige notificar a la Agencia de Protección de Datos Personales (APDP) cuando la vulneración es significativa y puede afectar derechos de los titulares. Si el incidente puede causar daño grave a los titulares (exposición de datos de salud, financieros, contraseñas), también debes notificarles directamente. El protocolo generado incluye el formulario de notificación a la APDP y la comunicación a titulares.

¿En cuánto tiempo debo notificar una brecha de datos?

La Ley 21.719 (Art. 14 sexies) exige notificar a la APDP 'sin dilaciones indebidas' una vez confirmada la vulneración significativa. La ley no establece un plazo específico en horas o días. Como referencia de buenas prácticas internacionales (GDPR) y como objetivo operacional recomendado: 72 horas para datos sensibles o de alto riesgo. Lo importante es no demorar la notificación una vez que tienes certeza del incidente.

¿Qué información debo incluir en la notificación de brecha a la APDP?

La notificación debe incluir: descripción de la naturaleza del incidente, categorías y número aproximado de titulares afectados, tipos de datos comprometidos, posibles consecuencias de la vulneración, medidas adoptadas o propuestas para mitigar el daño, y datos de contacto del responsable. El protocolo generado incluye plantillas de notificación a la APDP y comunicación a los titulares afectados con el contenido requerido.

¿Qué debo hacer inmediatamente después de detectar una brecha?

Los pasos inmediatos son: (1) Contener el incidente para evitar que se extienda. (2) Preservar la evidencia sin alterarla. (3) Evaluar el alcance: qué datos fueron afectados, cuántos titulares, qué riesgo conlleva. (4) Notificar a la APDP si es una vulneración significativa. (5) Notificar a los titulares si hay riesgo de daño grave. (6) Documentar todo el proceso para demostrar que actuaste diligentemente. El protocolo generado organiza estos pasos con plantillas de comunicación.