Seguridad e incidentes: qué exige realmente la Ley 21.719
Dos artículos concentran todo: el 14 quinquies, que fija el deber de seguridad, y el 14 sexies, que regula qué hacer cuando algo falla. Este segundo es el que más se cita mal en Chile.
Empecemos por el error más repetido
Se lee por ahí que hay que notificar una brecha de datos «dentro de 72 horas», con artículos, guías y hasta playbooks chilenos construidos alrededor de ese plazo.
Lo que dice la ley que la Ley 21.719 no contiene ningún plazo de 72 horas. El estándar del artículo 14 sexies es «por los medios más expeditos posibles y sin dilaciones indebidas». Las 72 horas son del artículo 33 del Reglamento General de Protección de Datos de la Unión Europea, una norma que no rige en Chile.
Es un error comprensible —la ley chilena se inspira en el modelo europeo— pero tiene consecuencias prácticas. Si construyes tu procedimiento interno alrededor de un plazo que la ley no fija, puedes terminar en dos lugares equivocados: creyendo que tienes 72 horas de margen cuando el caso exigía actuar de inmediato, o gastando esfuerzo en cumplir un plazo que nadie te va a exigir mientras descuidas el registro, que sí es obligatorio.
Si en algún momento un reglamento o una instrucción general de la Agencia fija plazos concretos, la fuente será esa, y habrá que citarla como tal. A la fecha de revisión de esta página, la obligación es la que dice la ley.
El deber de seguridad · artículo 14 quinquies
El responsable de datos debe adoptar las medidas necesarias para resguardar el cumplimiento del principio de seguridad […] considerando el estado actual de la técnica y los costos de aplicación, junto con la naturaleza, alcance, contexto y fines del tratamiento, así como la probabilidad de los riesgos y la gravedad de sus efectos en relación con el tipo de datos tratados. Las medidas aplicadas por el responsable deben asegurar la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas de tratamiento de datos. Asimismo, deberán evitar la alteración, destrucción, pérdida, tratamiento o acceso no autorizado.
No hay una lista de controles obligatorios. El estándar es relativo al riesgo, y esa es una decisión deliberada del legislador: lo razonable para una consulta dental con fichas clínicas no es lo mismo que para una startup con analítica de comportamiento.
Lo que sí es común a todos es que debes poder explicar por qué tus medidas son las adecuadas. El principio de responsabilidad no se satisface con buenas intenciones.
A esto se suma el art. 14 septies, que ordena a la Agencia fijar por instrucción general las condiciones mínimas diferenciadas según tipo de dato, tamaño de la entidad, actividad y volumen. Es decir: habrá un piso más concreto, y será distinto según el caso.
El reporte de vulneraciones · artículo 14 sexies
El responsable deberá reportar a la Agencia, por los medios más expeditos posibles y sin dilaciones indebidas, las vulneraciones a las medidas de seguridad que ocasionen la destrucción, filtración, pérdida o alteración accidental o ilícita de los datos personales que trate o la comunicación o acceso no autorizados a dichos datos, cuando exista un riesgo razonable para los derechos y libertades de los titulares.
Ese texto contiene tres decisiones que hay que tomar en cada incidente:
Destrucción, filtración, pérdida o alteración —accidental o ilícita— de datos personales, o comunicación o acceso no autorizados. Cubre desde un ataque hasta un correo enviado a la lista equivocada o un respaldo perdido.
Éste es el umbral que activa el deber de reportar a la Agencia. Requiere una evaluación fundada, no una corazonada. Conviene tener el criterio escrito antes del incidente.
Sí, si son datos sensibles, de niños y niñas menores de catorce años, o de obligaciones económicas, financieras, bancarias o comerciales.
El registro es obligatorio, siempre
Independiente de si el incidente llega o no al umbral de reporte, la ley obliga a registrar estas comunicaciones describiendo:
- La naturaleza de las vulneraciones sufridas.
- Sus efectos.
- Las categorías de datos y el número aproximado de titulares afectados.
- Las medidas adoptadas para gestionarlas y precaver incidentes futuros.
Omitir las comunicaciones o los registros en casos de vulneración es infracción grave art. 34 ter k). Omitir de forma deliberada la comunicación de vulneraciones que puedan afectar la confidencialidad, disponibilidad o integridad es gravísima art. 34 quáter f).
Qué controles concretos exige, en la práctica
La ley no publica una lista de controles obligatorios, y eso desconcierta a los equipos técnicos que esperan un estándar cerrado. Lo que sí hace es fijar cuatro propiedades que las medidas deben asegurar —confidencialidad, integridad, disponibilidad y resiliencia— y obligar a que sean proporcionales al riesgo. Traducido a controles habituales, esto es lo que razonablemente cabe esperar en cada propiedad.
| Propiedad | Qué protege | Controles habituales |
|---|---|---|
| Confidencialidad | Que sólo acceda quien debe. | Control de acceso por rol; principio de mínimo privilegio; autenticación robusta en accesos administrativos; cifrado en tránsito; cifrado en reposo para datos sensibles; segregación de ambientes. |
| Integridad | Que los datos no se alteren indebidamente. | Registro de auditoría de cambios; validación de entrada; control de versiones; restricción de modificaciones masivas; trazabilidad de quién modificó qué y cuándo. |
| Disponibilidad | Que los datos estén cuando se necesitan, incluido para responder solicitudes. | Respaldos con periodicidad definida; monitoreo; redundancia proporcional al riesgo; control de dependencia de un único proveedor. |
| Resiliencia | Que el sistema se recupere de un incidente. | Restauración probada —no basta respaldar, hay que verificar que se puede restaurar—; plan de continuidad; procedimiento de respuesta a incidentes ensayado. |
Esta tabla es una lectura razonable del artículo, no una lista legal cerrada. La Agencia fijará por instrucción general las condiciones mínimas, y serán distintas según el tamaño y la actividad de cada organización art. 14 septies.
Tres controles que se olvidan y aparecen en casi toda revisión
- Ambientes de prueba con datos reales. Copiar la base de producción a un entorno de desarrollo sin protección es un tratamiento de datos personales con un nivel de seguridad inferior al declarado. Es de los hallazgos más frecuentes y de los más fáciles de corregir.
- Respaldos que nadie ha restaurado nunca. La ley exige asegurar la resiliencia. Un respaldo que nunca se probó no acredita resiliencia: acredita intención.
- Retención sin fecha de término. Guardar «por si acaso» choca con el principio de proporcionalidad art. 3° c) y agranda el impacto de cualquier brecha futura. Los datos que ya no tienes no se pueden filtrar.
Qué evidencia deberías poder mostrar
El principio de responsabilidad convierte cada deber en algo que hay que poder acreditar. Para el frente de seguridad e incidentes, esto es lo mínimo que conviene tener por escrito y fechado.
| Evidencia | Para qué sirve | Base |
|---|---|---|
| Política de seguridad escrita y fechada | Acredita que las medidas fueron decididas, no improvisadas. Además debe estar resumida en la información pública. | 14 quinquies · 14 ter e) |
| Matriz de accesos por rol | Demuestra el criterio de mínimo privilegio y permite responder «quién pudo ver estos datos». | 14 quinquies |
| Registro de vulneraciones | Obligatorio. Naturaleza, efectos, categorías de datos, número aproximado de titulares y medidas adoptadas. | 14 sexies |
| Cronología del incidente | Es la única forma de acreditar que se actuó «sin dilaciones indebidas». | 14 sexies |
| Cláusulas de seguridad e incidentes con proveedores | Acredita que el encargo está documentado y que el proveedor debe reportarte. | 15 bis |
| Evaluación de impacto, cuando corresponda | Debe existir antes de iniciar el tratamiento de alto riesgo. | 15 ter |
| Registro de capacitación del personal | Sostiene el deber de secreto y reduce el error humano, causa habitual de incidentes. | 14 bis |
Cómo prepararse
Explicado en simple
Lo más útil que puedes hacer hoy es escribir, en una página, qué van a hacer si mañana pasa algo. Un incidente se gestiona mal cuando nadie sabe a quién llamar.
Tu página debería responder cuatro cosas:
- ¿Quién decide? Una persona con nombre, y un reemplazo.
- ¿A quién se avisa dentro de la empresa, y en qué orden.
- ¿Cómo se deja registro? Aunque sea un documento con fecha y hora.
- ¿Quién habla con los afectados, si corresponde avisarles.
Y una recomendación que no está en la ley pero evita muchos problemas: cuando ocurre un incidente, lo primero no es redactar el comunicado. Es anotar la hora en que se detectó y qué se sabía en ese momento. Esa línea de tiempo es lo que después permite demostrar que actuaste sin dilaciones indebidas.
Para equipos técnicos y legales
Componentes mínimos de un procedimiento que resiste el estándar del art. 14 sexies:
- Criterio de «riesgo razonable» predefinido. Matriz por categoría de dato (sensible / NNA <14 / obligaciones económicas / identificación / contacto) cruzada con tipo de exposición (interna, a un tercero determinado, pública, indexada) y con reversibilidad. Definirlo después del incidente contamina la evaluación.
- Cronología con sellado de tiempo. Detección, escalamiento, contención, evaluación y reporte. «Sin dilaciones indebidas» es un estándar de conducta que sólo se puede acreditar con una línea de tiempo verificable.
- Plantilla de registro con exactamente los campos del inciso segundo: naturaleza, efectos, categorías de datos, número aproximado de titulares y medidas adoptadas —incluidas las de prevención futura—.
- Cláusula de notificación en contratos con encargados. El art. 15 bis obliga al encargado a reportar al responsable, pero no fija plazo contractual: fíjalo tú, y hazlo compatible con tu propio deber de reportar sin dilaciones.
- Telemetría que permita responder «cuántos titulares». Si tus logs no permiten acotar el alcance, el número aproximado de afectados será una estimación indefendible. Esto es una decisión de arquitectura que se toma antes, no durante.
- Separación entre contención y comunicación. Quien contiene el incidente no debería ser quien redacta las comunicaciones; en la práctica retrasa ambas cosas.
Sobre el estándar temporal: «sin dilaciones indebidas» no es más laxo que un plazo fijo. En un incidente de alto impacto sobre datos sensibles, esperar 72 horas podría ser perfectamente una dilación indebida. Diseña para reportar apenas exista base suficiente, y complementa después.
Qué se puede revisar técnicamente en tu sitio
La seguridad de una organización no se audita desde afuera, pero la superficie pública sí deja señales: si el sitio se sirve íntegramente por HTTPS, si hay formularios que envían en claro, si hay contenido mixto, qué terceros reciben datos desde el navegador, si hay endpoints administrativos expuestos. Son indicios, no un diagnóstico completo, y así es como hay que tratarlos.
Eso es parte de lo que revisa PixaPrivacy, con la advertencia explícita de que el análisis es pasivo y observa lo que el sitio publica.
Preguntas frecuentes
¿La Ley 21.719 obliga a notificar una brecha en 72 horas?
No. El artículo 14 sexies exige reportar a la Agencia por los medios más expeditos posibles y sin dilaciones indebidas. No establece un plazo en horas. El plazo de 72 horas proviene del artículo 33 del Reglamento General de Protección de Datos de la Unión Europea, que no rige en Chile.
¿Hay que reportar todas las brechas de seguridad?
No todas. El deber de reportar a la Agencia se activa cuando la vulneración ocasiona destrucción, filtración, pérdida o alteración de datos personales, o comunicación o acceso no autorizados, y existe un riesgo razonable para los derechos y libertades de los titulares. Sí hay que registrar internamente las vulneraciones.
¿Cuándo hay que avisarle también a las personas afectadas?
Cuando la vulneración se refiere a datos personales sensibles, a datos de niños y niñas menores de catorce años, o a datos relativos a obligaciones de carácter económico, financiero, bancario o comercial.
¿Qué pasa si el que sufre la brecha es mi proveedor?
El artículo 15 bis establece que, tratándose de una vulneración a las medidas de seguridad, el tercero mandatario o encargado deberá reportar el hecho al responsable. El responsable sigue siendo quien responde ante la Agencia y ante los titulares.
Sigue leyendo
¿Y cómo está tu sitio hoy?
Leer la ley es el primer paso. El segundo es mirar tu sitio con los mismos ojos con que lo mirará cualquiera: qué formularios pides, qué scripts de terceros cargas, qué informas y qué no. PixaPrivacy revisa el estado técnico y público de un sitio web y te entrega un informe priorizado con hallazgos, evidencia y una hoja de ruta.
PixaPrivacy es una herramienta de diagnóstico técnico. No emite certificaciones legales ni sustituye la asesoría de un abogado.
Sobre esta página
El contenido de esta página se redactó contrastando cada afirmación con el texto oficial de la Ley N° 21.719 publicado por la Biblioteca del Congreso Nacional y con el estado de tramitación publicado por el Senado. Puedes verificarlo tú mismo en fuentes oficiales.
Información general, no asesoría legal. PixaWeb es una empresa de desarrollo web y software, no un estudio jurídico. Esta guía explica la norma de forma divulgativa y no considera las circunstancias de tu organización. Para decisiones concretas —especialmente sobre bases de licitud, datos sensibles o incidentes— consulta con un abogado o abogada especialista.