Gestión de incidentes de seguridad bajo la Ley 21.719: protocolo, evidencia y las 72 horas que definen el resultado
- Por Amparo Silva | Amsoft
Introducción
FortiGuard Labs reportó que Chile sufrió 27.600 millones de intentos de ciberataques durante 2024, cifra que más que cuadruplicó los 6.000 millones del año anterior. El Panorama de Amenazas 2026 de Fortinet posicionó al país como el cuarto en volumen de amenazas en América Latina durante 2025. El costo promedio global de una filtración de datos alcanzó los 4,4 millones de dólares en 2025 según IBM. Estos números describen un entorno donde un incidente que comprometa datos personales ya no es una posibilidad teórica para la mayoría de las organizaciones chilenas. Es una variable que el plan de continuidad debe contemplar con la misma seriedad que una falla de infraestructura.
A partir de diciembre de 2026, la Ley 21.719 agrega consecuencias jurídicas concretas a ese escenario. Cuando una vulneración afecta datos personales y representa riesgo razonable para los titulares, la obligación de notificar se activa. La organización debe comunicarlo a la Agencia de Protección de Datos Personales en 72 horas desde que toma conocimiento. La omisión intencional es infracción gravísima, con sanciones que pueden alcanzar el 4% de los ingresos anuales en reincidencia. Cubrir esa distancia requiere un protocolo operativo con dueños definidos, evidencia datada y criterios claros para escalar decisiones bajo presión. Este artículo aborda ese ciclo completo.
1. El marco legal: lo que la Ley 21.719 exige ante un incidente
1.1 La obligación de notificar: plazos, criterios y umbrales
La Ley 21.719 establece una distinción operativa que las organizaciones deben internalizar: no todo incidente de seguridad es una vulneración reportable. Sí lo es toda vulneración que comprometa datos personales y genere riesgo razonable para los derechos de los titulares. En ese caso, debe notificarse a la Agencia de Protección de Datos Personales. El primer criterio que debe evaluarse es si el incidente efectivamente afectó la confidencialidad, integridad o disponibilidad de datos personales. El segundo, si ese compromiso representa un riesgo razonable para los derechos de quienes son titulares de esos datos.
Cuando ambos criterios se cumplen, el plazo de 72 horas comienza a correr desde el momento en que la organización “toma conocimiento” del incidente. La ley exige que la notificación se realice “por los medios más expeditos posibles y sin dilaciones indebidas”. En la práctica, esto exige tener resuelto de antemano el canal de comunicación con la Agencia y los contenidos mínimos de la notificación inicial. También es clave definir quién tiene la autoridad para enviarla. Cuando el riesgo es alto, la obligación se extiende a los propios titulares afectados. Un incidente que expone datos de salud, información biométrica o registros financieros detallados casi siempre activa este segundo umbral.
1.2 Obligaciones paralelas: Ley 21.663 y sector financiero
Las organizaciones de ciertos sectores ya operan bajo obligaciones de notificación más exigentes. La Ley Marco de Ciberseguridad (Ley 21.663), vigente desde marzo de 2025, exige notificación al CSIRT Nacional dentro de las 24 horas del incidente. Esta obligación aplica a los operadores de infraestructura crítica: banca, telecomunicaciones, salud, energía, transporte y organismos del Estado. Ese plazo se amplía a 72 horas para el reporte completo.
Cuando el incidente involucra datos personales, ambas obligaciones corren en paralelo: la notificación al CSIRT y la notificación a la Agencia de Protección de Datos. El sector financiero suma además las exigencias de la CMF, que establece sus propios canales y plazos de reporte. Diseñar el protocolo reconociendo estas obligaciones paralelas es más eficiente que gestionarlas como silos separados.
1.3 Las sanciones por omisión y el valor de la documentación
La omisión intencional de notificar una vulneración a la Agencia es clasificada como infracción gravísima bajo la Ley 21.719. Las sanciones para este nivel alcanzan hasta 20.000 UTM por hecho. En caso de reincidencia, la multa puede calcularse como porcentaje de los ingresos anuales en Chile, llegando hasta el 4% en los casos más severos. El incumplimiento del plazo de 72 horas puede calificarse como infracción grave, incluso si no fue intencional. En ese caso, las sanciones alcanzan hasta 10.000 UTM.
La diferencia entre una sanción leve y una grave depende, en gran medida, de si la organización puede demostrar que actuó con diligencia. Por ejemplo, que detectó el incidente a tiempo, que inició la evaluación de inmediato y que cualquier demora tuvo causa justificada. El mismo criterio distingue entre infracción grave y gravísima. Este punto tiene una consecuencia directa sobre el diseño del protocolo interno. La documentación del proceso no es solo buena práctica de gestión: es la evidencia que puede determinar el nivel de la sanción.
2. Detección temprana y contención
2.1 Capacidades técnicas mínimas para detectar antes de que sea tarde
La mayoría de los incidentes no se producen en un instante. Los actores maliciosos permanecen en los sistemas de sus víctimas durante un período previo a la extracción de datos o al cifrado de archivos. Sin logs centralizados, sin alertas de comportamiento anómalo y sin revisión periódica de accesos, pocas organizaciones detectan una intrusión antes de que cause daño. IBM estima que el tiempo promedio para identificar y contener una brecha de datos es considerablemente más largo en organizaciones sin capacidades de monitoreo activo.
Las capacidades técnicas mínimas para cumplir con el espíritu de la Ley 21.719 incluyen cuatro elementos. El primero es el registro centralizado de eventos de seguridad con retención suficiente para la investigación forense posterior. El segundo es la gestión de identidades y accesos con alertas configuradas para cuentas con acceso a datos personales. El tercero es un inventario actualizado de sistemas que procesan esos datos. El cuarto son mecanismos de backup verificados mediante pruebas de restauración documentadas. Estas capacidades no requieren inversión de nivel corporativo. Representan el piso mínimo que hace posible la detección y que vuelve viable la investigación una vez que ocurre un incidente.
2.2 Las primeras horas: la secuencia que define el resultado
Las primeras horas de un incidente determinan si la respuesta será ordenada o reactiva. Un protocolo bien diseñado define de antemano la secuencia básica. Primero, identificar el alcance preliminar del incidente. Segundo, activar el equipo de respuesta con roles preestablecidos. Tercero, aislar los sistemas afectados para detener la propagación y preservar evidencia antes de cualquier acción de limpieza o restauración. Este último punto es frecuentemente ignorado en la urgencia operativa. Si se restauran sistemas comprometidos antes de capturar los logs relevantes, la capacidad forense queda comprometida. Eso afecta tanto la comprensión de lo ocurrido como la documentación que la Agencia puede pedir.
La contención no equivale a la resolución del incidente. Contener significa detener el daño en curso; entender cómo ocurrió requiere un proceso distinto y posterior. Una organización que contiene con rapidez pero investiga superficialmente puede estar eliminando síntomas mientras deja la causa raíz activa. En el contexto de la Ley 21.719, la distinción entre contención e investigación debe ser explícita en el protocolo de respuesta. La ley exige documentar tanto el incidente como la gestión realizada.
3. Evaluación de impacto y documentación forense
3.1 Qué registrar y cómo: la evidencia que la Agencia puede requerir
La Ley 21.719 no establece un formato estándar para la documentación de incidentes. Sin embargo, la práctica de sistemas equivalentes en Europa permite anticipar qué información la Agencia puede requerir en una fiscalización. Esa información incluye la descripción del incidente (qué ocurrió y cómo se detectó), las categorías de datos comprometidos y el número aproximado de titulares involucrados. Además, la Agencia puede requerir las consecuencias probables para los titulares, las medidas de contención y la cronología desde la detección hasta la notificación.
Cada uno de esos elementos necesita evidencia datada que lo respalde. Un informe narrativo sin timestamps verificables tiene poco valor ante un proceso de fiscalización. Los logs deben estar disponibles y ser interpretables por alguien ajeno al equipo de respuesta original. Las decisiones tomadas durante la gestión del incidente deben quedar registradas, incluyendo quién las tomó y con qué información disponible en ese momento. Esta disciplina de registro no es burocracia: es la diferencia entre demostrar diligencia y no poder hacerlo.
3.2 Análisis de causa raíz: del síntoma al origen
Una vez estabilizada la situación y notificada la Agencia, comienza la fase más importante para el sistema de seguridad: identificar la causa raíz del incidente. Las causas superficiales son el punto de entrada al análisis, no su conclusión. Por ejemplo, el malware que cifró los archivos, las credenciales comprometidas que habilitaron el acceso o la vulnerabilidad de software que fue explotada.
El análisis de causa raíz efectivo busca responder preguntas estructurales. ¿Por qué esa vulnerabilidad no estaba parcheada? ¿A qué razón se debe que esas credenciales tenían acceso a esos datos personales? ¿Por qué el sistema de alertas no detectó el comportamiento anómalo antes del daño? ¿Qué proceso de revisión falló o directamente no existía? Las respuestas a estas preguntas son las que generan correcciones reales y duraderas. Un incidente documentado sin análisis de causa raíz es una oportunidad de mejora desperdiciada. También es un argumento débil ante la Agencia si el mismo tipo de incidente vuelve a ocurrir.
4. Comunicación con autoridades, afectados y stakeholders
4.1 Notificación a la Agencia: qué comunicar dentro de las 72 horas
Para que el plazo de 72 horas sea cumplible, la organización debe resolver de antemano tres preguntas prácticas. Primero, quién tiene la autoridad para tomar la decisión de notificar. Segundo, qué información mínima incluirá la notificación inicial. Tercero, a través de qué canal se realizará la comunicación con la Agencia. En sistemas regulatorios comparables, como el GDPR europeo, la primera notificación no requiere que la investigación esté completa. Puede incluir información provisional con el compromiso de actualizar a la Agencia a medida que se disponga de más datos. Este enfoque permite cumplir con el plazo sin esperar conclusiones que pueden tardar días.
En cambio, lo que sí es indispensable desde la primera notificación es una descripción general del incidente: qué ocurrió y cuándo se detectó. También deben incluirse la categoría de datos personales afectados, una estimación del número de titulares involucrados y las medidas de contención adoptadas hasta ese momento. El carácter provisional de esta información debe declararse explícitamente, junto con el compromiso de completarla cuando la investigación avance.
En cambio, lo que sí es indispensable desde la primera notificación es una descripción general del incidente: qué ocurrió y cuándo se detectó. También deben incluirse la categoría de datos personales afectados, una estimación del número de titulares involucrados y las medidas de contención adoptadas hasta ese momento. El carácter provisional de esta información debe declararse explícitamente, junto con el compromiso de completarla cuando la investigación avance.
En este proceso, el Encargado de Protección de Datos (EPD) cumple un rol central. El EPD coordina la evaluación del incidente, determina si se activa la obligación de notificar y gestiona la comunicación con la Agencia. Su figura es equivalente al Data Protection Officer del GDPR europeo, y registra formalmente todo el proceso. Su participación desde las primeras horas no es opcional: es el canal institucional que la Agencia espera encontrar al otro lado del reporte. Las organizaciones que aún no han designado su EPD tienen una brecha que resolver antes de diciembre de 2026.
4.2 Comunicación a los titulares y gestión de la crisis reputacional
Cuando el riesgo para los titulares es alto, la comunicación a los afectados agrega una capa adicional de complejidad. Esa comunicación debe ser suficientemente clara para que el titular pueda tomar medidas propias de protección. Por ejemplo, cambiar contraseñas, monitorear movimientos financieros o alertar a instituciones sobre el posible uso indebido de sus datos. Al mismo tiempo, no debe generar pánico desproporcionado ni confusión sobre el alcance real del incidente.
El manejo comunicacional de un incidente de datos personales tiene además una dimensión reputacional que excede la obligación legal. Las organizaciones que comunican de forma transparente y oportuna preservan mejor la confianza de sus clientes. En cambio, quienes gestionan el incidente en silencio hasta que la información circula por otros canales pierden esa ventaja. En el ecosistema de ciberseguridad chileno de 2026, los incidentes críticos generan cobertura mediática inmediata. Por ello, esa diferencia de gestión comunicacional tiene consecuencias concretas sobre la relación con clientes, proveedores y el regulador.
5. Aprendizaje organizacional y mejora continua
5.1 El post-mortem que genera cambio real
Un incidente gestionado correctamente produce, además del cumplimiento regulatorio, una mejora del sistema de seguridad de la organización. El post-mortem es el proceso que convierte la experiencia de un incidente en mejoras concretas: controles reforzados, procesos actualizados, capacidades añadidas. Para que funcione, debe ser una instancia formal con participación de los responsables técnicos y de las áreas de negocio afectadas. Además, debe producir conclusiones documentadas y un plan de acción con responsables y plazos verificables.
El post-mortem efectivo busca condiciones, no culpables. Los errores individuales en la respuesta a un incidente casi siempre son consecuencia de ausencia de controles, falta de capacitación o sobrecarga operativa. Son condiciones modificables, no fallas personales. Cuando el análisis post-incidente concluye que “el operador cometió un error”, casi siempre se detuvo demasiado pronto. La organización que aprende de sus incidentes construye resiliencia; la que solo los resuelve acumula exposición.
5.2 De la reacción al protocolo institucional
La primera vez que una organización enfrenta un incidente bajo la Ley 21.719, lo hará con más improvisación de la deseable. El objetivo del aprendizaje organizacional es que la segunda vez sea fundamentalmente diferente. Para ello, el protocolo debe existir, haber sido ensayado y tener roles claros. Además, la evidencia debe capturarse de forma sistemática desde el primer minuto.
Los ejercicios de simulación de incidentes son la herramienta más efectiva para construir esa preparación sin necesidad de esperar un incidente real. Un ejercicio de simulación de 90 minutos pone en evidencia los vacíos del protocolo, las ambigüedades de roles y las dependencias no resueltas. En ese entorno participan el equipo de TI, el área legal y la dirección, recorriendo juntos un escenario de vulneración de datos. Los errores tienen consecuencias de aprendizaje, no operativas. Las organizaciones que practican antes de necesitar responden mejor cuando el incidente real ocurre. Además, la documentación del ejercicio sirve como evidencia ante la Agencia de que existe una gestión activa del riesgo.
Conclusión
La gestión de incidentes de seguridad bajo la Ley 21.719 no es una tarea que el área de TI puede resolver de forma aislada. En particular, requiere capacidades técnicas, decisiones de negocio y comunicación regulatoria, todo coordinado en las 72 horas que la ley no negocia. Las organizaciones que llegan a diciembre de 2026 sin protocolo documentado, sin capacidades de detección y sin roles definidos enfrentan dos riesgos. Por un lado, las sanciones regulatorias. Por otro, un escenario de respuesta reactiva que amplifica el daño del incidente original.
El contexto chileno de 2026 hace urgente esa preparación. Según Fortinet, Chile registró 27.600 millones de intentos de ciberataques en 2024 y estuvo entre los cuatro más atacados de América Latina en 2025. Los datos personales que las organizaciones chilenas tratan están bajo presión real y sostenida. El punto de partida no es construir un centro de operaciones de seguridad ni contratar un CISO. En cambio, es tener un protocolo básico de respuesta con roles definidos y un inventario de los sistemas que procesan datos personales. También es necesario un ejercicio de simulación que ponga ese protocolo a prueba antes de que lo haga un incidente real.
La Agencia de Protección de Datos Personales comenzará a ejercer sus facultades fiscalizadoras desde el 1 de diciembre de 2026. En ese proceso, evaluará cómo las organizaciones respondieron a sus incidentes, no solo si los reportaron dentro del plazo. Esa evaluación incluye la calidad de la documentación, la coherencia del protocolo y la evidencia de que el incidente generó mejoras concretas. Prepararse bien no es solo cumplir la ley: es estar en condiciones de demostrarlo.
¿Cómo puede Amsoft ayudarte en este camino?
Amsoft acompaña a organizaciones chilenas en el diseño e implementación de las capacidades que la Ley 21.719 exige en materia de gestión de incidentes. Nuestro equipo incluye personal certificado en ciberseguridad con experiencia en proyectos de cumplimiento en empresas medianas y grandes del mercado chileno. Trabajamos con el área TI del cliente para construir protocolos operables con los recursos disponibles, no solo documentos correctos que nadie sabe ejecutar bajo presión.
Amsoft acompaña el ciclo completo: diseño del protocolo, evaluación de capacidades de detección, facilitación de simulaciones y análisis post-incidente. El objetivo es que la organización quede en condiciones reales de responder. La diferencia entre estar preparado y tener solo una política escrita determina el impacto sobre el negocio y la relación con el regulador.
Contáctanos si tu organización está construyendo su protocolo para la Ley 21.719 o evaluando su preparación actual.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- Fortinet / FortiGuard Labs, reportado en Transmedia. (2025, mayo 13). Reporte Fortinet: fortalecimiento de las ciberdefensas contra las amenazas emergentes. https://www.transmedia.cl/blog/2025/05/13/reporte-fortinet-fortalecimiento-de-las-ciberdefensas-contra-las-amenazas-emergentes/
- IBM Security. (2025). Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach
- Emol. (2026, mayo 4). Advierten brechas en ciberseguridad ante filtración masiva: En 2025 hubo 8,8 billones de intentos de ataque en Chile. https://www.emol.com/noticias/Nacional/2026/05/04/1198990/filtracion-datos-expertos-ciberseguridad-claveunica.html
- Prey Project. (2026, febrero 26). Ley 21.719: guía 2026 para cumplir con la protección de datos en Chile. https://preyproject.com/es/blog/ley-de-proteccion-de-datos-en-chile
- Biblioteca del Congreso Nacional de Chile. Ley 21.719, Ley de Protección de Datos Personales. https://www.bcn.cl/leychile/navegar?idNorma=1209272
- Biblioteca del Congreso Nacional de Chile. Ley 21.663, Ley Marco de Ciberseguridad. https://www.bcn.cl/leychile/navegar?idNorma=1202434