Son las 10:42 de la mañana de un martes. Tu equipo de TI detecta tráfico anómalo en uno de los servidores donde corre el sistema de atención a clientes. Diez minutos después confirman lo que nadie quería confirmar: ransomware. El servicio está caído. Y en la misma máquina vivía una base de datos con información personal de miles de usuarios.
En ese momento, dos relojes empiezan a correr al mismo tiempo. El primero es de la Agencia Nacional de Ciberseguridad (ANCI): tienes tres horas para enviar la alerta temprana bajo la Ley 21.663. El segundo es de la Agencia de Protección de Datos Personales: tienes que notificar sin dilaciones indebidas bajo la Ley 21.719, y eventualmente también a los titulares afectados.
El problema no es legal. El problema es operativo. Mientras el delegado de ciberseguridad redacta el formulario para ANCI, el DPO está pidiendo evidencia para evaluar el alcance bajo la 21.719. Legal pregunta si hay que avisar a los usuarios. Comms quiere un borrador. Y la conversación interna avanza más rápido que la coordinación entre las dos versiones del mismo incidente que están saliendo de tu organización.
Acá vamos a desarmar el problema. Cuándo se activan las dos leyes al mismo tiempo, cómo correr ambos flujos sin contradecirte, qué evidencia comparten y dónde divergen, y cómo coordinar al delegado de ciberseguridad y al DPO sin improvisar bajo presión. Si tratas a la 21.663 y a la 21.719 como flujos separados, vas a perder uno de los dos.
Cuándo un incidente activa las dos leyes al mismo tiempo
La 21.663 y la 21.719 no son la misma ley para el mismo problema. Cada una protege algo distinto y cada una se activa por motivos distintos.
La Ley 21.663 (Ley Marco de Ciberseguridad) se activa cuando hay un incidente que afecta un servicio esencial o que compromete la confidencialidad, integridad o disponibilidad de sistemas en organizaciones clasificadas como Operadores de Servicios Esenciales (OSE) u Operadores de Importancia Vital (OIV). Hablamos de hospitales, bancos, empresas de telecomunicaciones, energía, transporte, salud y otros sectores designados.
La Ley 21.719 (Ley de Protección de Datos) se activa cuando hay una vulneración de seguridad que afecta datos personales, sin importar si tu organización es OIV o no. Si tratas datos personales y hay brecha, hay obligación de notificar.
¿El punto donde se cruzan? Cuando un incidente activa los dos al mismo tiempo. Y en organizaciones reguladas, eso pasa más de lo que se cree. Un ransomware en un hospital es interrupción de servicio esencial (21.663) y exposición de datos clínicos (21.719). Una filtración por un servidor de telecom expone metadatos de llamadas (21.719) y puede comprometer la integridad de un servicio esencial (21.663). Hasta un acceso no autorizado al ERP de una empresa de energía puede activar las dos.
El primer paso, mucho antes de que ocurra un incidente, es saber qué te aplica. Si todavía no tienes claro si calificas como OIV o solo como responsable de tratamiento, esa es la primera tarea pendiente. La clasificación define qué notificaciones aplican y con qué plazos.
Quick win: Mapea hoy si tu organización es OIV, OSE o solo responsable de tratamiento de datos personales. Si hay duda, asume el escenario más exigente y prepara los formularios de ambas leyes desde el primer minuto.
Dos relojes distintos: plazos comparados de la 21.663 y la 21.719
Acá es donde la doble notificación se vuelve operativamente compleja. Los dos plazos no solo son distintos: son incompatibles si los manejas en secuencia.
Las tres horas de la 21.663 son intransables. Si esperas a tener la imagen completa del incidente antes de enviar la alerta temprana, perdiste el plazo. La alerta es preliminar por diseño: lo que se completa después, en el segundo reporte y en el informe final, es la profundización.
La 21.719 es más elástica pero también más amplia. No solo hay que notificar a la autoridad: si el riesgo para los titulares es alto, hay que notificarlos directamente. Y la decisión de notificar a titulares no se puede dejar para el día 14, porque genera implicancias reputacionales y operativas que requieren coordinación con comms y legal.
El delegado de ciberseguridad no puede esperar a que el DPO termine su evaluación. El DPO no puede esperar a que ANCI cierre el segundo reporte. Los dos flujos arrancan en paralelo desde la detección, y avanzan en pistas separadas hacia metas distintas.
Quick win: Configura una alerta interna que dispare ambos relojes simultáneamente cuando el equipo de respuesta confirme un incidente con potencial impacto en servicios o en datos personales. Pre-llena el formulario ANCI con los datos institucionales para ganar minutos en la primera hora.
Quién reporta a quién: ANCI, APDP y los roles internos
Los actores externos están claros: ANCI por la 21.663 y la Agencia de Protección de Datos Personales por la 21.719. El rol de la ANCI está bien definido (recibe los reportes vía portal.anci.gob.cl, supervisa el cumplimiento, aplica sanciones y coordina la respuesta nacional a través del CSIRT Nacional). La APDP, todavía en formación al momento de redactar esto, cumplirá un rol análogo para datos personales: recibir las notificaciones, evaluar el cumplimiento y eventualmente sancionar.
Internamente, el reparto de responsabilidades es donde aparece la mayoría de los problemas. Las dos figuras clave son el delegado de ciberseguridad (obligatorio para entidades reguladas por la 21.663) y el DPO o delegado de protección de datos personales (obligatorio para responsables de tratamiento bajo la 21.719). En la práctica, en muchas organizaciones chilenas estas dos figuras recaen en personas distintas, con reportes a áreas distintas, y con prioridades operativas distintas.
El delegado de ciberseguridad responde por la 21.663: presenta los reportes a ANCI, coordina con CSIRT, define las medidas de contención técnica. El DPO responde por la 21.719: evalúa el alcance de la afectación de datos personales, decide si hay que notificar a titulares, coordina con legal y comms el mensaje externo.
Cuando un incidente activa las dos leyes, ninguno de los dos puede operar en silos. Necesitan compartir la misma información de base, sincronizar versiones antes de que cualquier reporte salga de la organización, y mantener una sola fuente de verdad sobre lo que pasó.
Quick win: Documenta hoy en una sola página quién hace qué en las primeras 24 horas de un incidente: delegado, DPO, CISO, legal, comms, IT. Asigna sustitutos para cada rol. Si el delegado o el DPO están en una conferencia o de vacaciones cuando llegue el incidente, alguien más tiene que poder ejecutar.
El paquete de evidencia: qué pide cada agencia (y dónde se cruzan)
ANCI y la APDP no piden lo mismo, pero piden muchas cosas iguales. Entender qué se cruza y qué diverge es la diferencia entre un proceso interno eficiente y dos equipos paralelos generando información redundante (o peor, contradictoria).
Lo que se cruza entre los dos paquetes:
- Descripción factual del incidente (qué pasó, cuándo se detectó)
- Línea de tiempo del evento (hora de detección, hora de contención, hora de erradicación)
- Indicadores de compromiso técnicos
- Activos y sistemas afectados
- Medidas tomadas hasta el momento del reporte
- Datos de contacto del responsable interno
Lo que diverge:
- ANCI exige clasificación según la taxonomía oficial de la Resolución Exenta N.º 7 (uso indebido de recursos, confidencialidad, disponibilidad o integridad, con sus 11 categorías específicas). La APDP no usa esa taxonomía.
- La APDP exige caracterización de los datos personales afectados (categorías, volumen, sensibilidad) y una evaluación del riesgo para los titulares. ANCI no pide ese nivel de detalle sobre datos personales.
- La APDP eventualmente requerirá la justificación de la decisión sobre si se notifica a los titulares y cómo se les comunicó. ANCI no entra en ese terreno.
La inconsistencia de scope entre los dos reportes es la trampa más cara. Si la alerta temprana a ANCI dice "aproximadamente 12.000 registros comprometidos" porque a las dos horas del incidente esa era la estimación, y la notificación a la APDP al día siguiente dice "8.400 titulares afectados" porque la investigación más profunda corrigió la cifra, el delta puede ser interpretado como información tardía o errónea en uno de los dos reportes.
La solución no es esperar a tener la cifra exacta antes de reportar (no la vas a tener). La solución es documentar claramente que la primera cifra es preliminar, que se actualizará en reportes posteriores, y que el cálculo más fino se entregará en los plazos correspondientes a cada ley. Lo que ambas agencias castigan no es la imprecisión inicial: es la inconsistencia injustificada entre reportes y la falta de evidencia técnica que respalde cada cifra.
Acá es donde el control de dispositivos como evidencia se vuelve decisivo. Los logs de actividad de los endpoints, el historial de ubicación, los registros de lock/wipe, los reportes de cifrado: todo eso es la columna vertebral del paquete de evidencia que ambas agencias necesitan. Si esa evidencia vive solo en los equipos comprometidos, perdiste la mitad de la historia el día del incidente.
Quick win: Diseña un template interno de incidente que cubra los campos exigidos por las dos leyes en un solo formulario. Captura evidencia técnica desde el primer minuto y, si vas a hacer wipe remoto de un equipo, exporta primero los logs en una ubicación fuera del dispositivo.
Protocolo interno unificado para no contradecirte entre reportes
La doble notificación se gana o se pierde antes del incidente. El día que pasa el ataque ya es tarde para diseñar el protocolo.
El principio de fondo es simple: un solo war room, una sola línea de tiempo, una sola fuente de verdad. Las dos versiones del incidente que van a salir hacia ANCI y la APDP nacen del mismo cuerpo de información. Las divergencias entre los dos reportes vienen del enfoque de cada ley, no de los hechos.
En operación, un protocolo interno bien diseñado tiene cinco componentes:
- Bitácora compartida del incidente. Accesible en tiempo real para delegado, DPO, CISO y legal. Toda actualización queda registrada con timestamp. No hay versiones alternativas circulando por mail.
- Punto único de contacto interno. Una persona valida los dos reportes antes de que salgan. Esa persona no es necesariamente quien los redacta, pero sí quien revisa que sean coherentes entre sí.
- Ventana de revisión cruzada. Antes de enviar el segundo reporte a ANCI, el DPO lo lee. Antes de enviar la notificación a la APDP, el delegado de ciberseguridad la lee. Mínimo 15 minutos de revisión cruzada, idealmente más.
- Protocolo de comunicación a titulares predefinido. Si la 21.719 te obliga a notificar a usuarios afectados, ese mensaje tiene que existir como borrador antes del incidente. Hacerlo desde cero a las 36 horas, con presión mediática, es donde se cometen los errores más costosos.
- Simulacros periódicos. Al menos una vez al año, ejecuta un ejercicio donde se activen las dos notificaciones en paralelo. No es opcional. El protocolo solo funciona si el equipo lo ha ensayado.
Considera este escenario: una empresa de logística sufre el robo del notebook de un ejecutivo en un aeropuerto. El equipo contenía caché local del CRM con datos personales de aproximadamente 2.300 clientes. La empresa no es OIV ni OSE, así que la 21.663 no aplica. Pero la 21.719 sí, porque hubo pérdida de un dispositivo que contenía datos personales.
¿Qué hizo la empresa? Ubicó el dispositivo por última conexión registrada, ejecutó wipe remoto dentro de la primera hora, exportó el log de actividad para confirmar que no hubo login exitoso posterior al robo, y construyó la notificación a la APDP argumentando que la contención impidió el acceso efectivo a los datos. El alcance de la notificación se redujo significativamente, y la obligación de notificar a titulares individuales no se gatilló.
Quick win: Define la "ventana de revisión cruzada" para tu equipo: cuántos minutos mínimos antes de cada envío oficial el DPO y el delegado se sientan a leer la versión que va a salir. Si esa ventana no existe, los reportes salen sin verificación.
Errores frecuentes que convierten un incidente en dos infracciones
Cuando hablas con abogados especializados en estos casos, los errores que aparecen son siempre los mismos. No son sofisticados. Son operativos. Vale la pena agruparlos por la raíz del problema, no por su síntoma.
Esperar a tener todo claro antes de reportar
Es el error más frecuente y el más prevenible. El equipo se obsesiona con tener la imagen completa antes de enviar la alerta temprana a ANCI. Las 3 horas pasan. El reporte llega tarde o no llega. En paralelo, el DPO espera "confirmación oficial" del alcance antes de tomar decisiones sobre la 21.719, y termina notificando a la APDP a destiempo.
La alerta temprana está diseñada para ser preliminar. La 21.719 te permite explicar que la cifra inicial se va a refinar. Lo que no se perdona es el silencio durante las primeras horas mientras el equipo "termina de investigar".
Inconsistencia entre los dos reportes
Acá hay dos versiones del mismo problema, que conviene juntar. La primera es la inconsistencia de scope entre ANCI y APDP: cifras de afectados que no coinciden, fechas distintas para el mismo evento, descripciones de activos que se contradicen. La segunda es la inconsistencia temporal entre reportes parciales sucesivos: el segundo reporte ANCI dice una cosa, el informe final dice otra, y los reportes parciales (cada 15 días si el incidente sigue activo) simplemente dejan de enviarse porque nadie quedó asignado a esa continuidad.
La raíz es la misma: no hay una sola fuente de verdad sobre el incidente, ni un responsable claro de mantener esa fuente alineada con los reportes que están saliendo. Y sin nombre asignado, los reportes parciales mueren en el día 16.
Pérdida de evidencia durante la contención
El equipo de IT, en modo emergencia, formatea o reinicializa dispositivos comprometidos. Los logs se pierden con ellos. Cuando llega la solicitud de evidencia técnica del segundo reporte ANCI o de la APDP, no hay con qué respaldar.
Lo mismo aplica a la conservación de la cadena de custodia: si la evidencia se mueve entre técnicos sin trazabilidad, su valor probatorio frente al regulador se debilita. El plan de acción de los 7 días (solo OIV) suele ser donde este problema explota: el delegado de ciberseguridad descubre que la información que necesita para justificar la restauración operativa ya no existe.
Olvidar la dimensión humana de la 21.719
La 21.719 obliga a notificar a la autoridad y a los titulares cuando hay riesgo alto. Muchas organizaciones cumplen con la APDP y olvidan a los usuarios afectados, asumiendo que si la autoridad fue notificada el deber está cumplido.
No lo está. Cuando un titular se entera por la prensa de que sus datos fueron expuestos en un incidente que la empresa nunca le comunicó directamente, la sanción crece, la reputación se cae y la APDP suele endurecer su evaluación del caso. Si tienes duda de si es "riesgo alto" para titulares, notifica. La sanción por no notificar pesa más que la incomodidad operativa.
Quick win: Asigna por escrito quién es el responsable de los reportes parciales si el incidente sigue activo después de los 15 días. Sin nombre asignado, los reportes parciales mueren en el día 16.
Visibilidad endpoint y el factor "primeras 3 horas"
La doble notificación se juega en las primeras horas. Y las primeras horas se juegan en los endpoints.
Las 3 horas de la alerta temprana a ANCI son inviables si no tienes visibilidad real-time sobre tus dispositivos. La pregunta "qué equipos están comprometidos y qué datos viven en ellos" se responde rápido o no se responde a tiempo. Si tu único camino es llamar al equipo afectado, esperar que prendan el laptop, esperar que se conecten a la VPN para verificar logs en el servidor, las 3 horas se van antes de que tengas la primera cifra.
Lo mismo aplica al paquete de evidencia. Necesitas timeline preciso (cuándo se detectó la anomalía en el endpoint, cuándo se ejecutó el bloqueo, cuándo se completó el wipe). Necesitas inventario de dispositivos afectados (cuáles, dónde estaban, qué usuario los tenía asignados). Necesitas evidencia de medidas tomadas (lock remoto ejecutado a tal hora, wipe completado, último login conocido).
Y necesitas que esa evidencia sobreviva al incidente. Si los logs viven solo en el endpoint y el endpoint se borra durante la contención, la evidencia se pierde con él.
Entender qué plataforma resuelve cada pieza de este paquete operativo deja de ser opcional cuando el reloj de ANCI ya está corriendo.
Cómo las plataformas de visibilidad endpoint cierran este gap
Las plataformas de gestión y protección de endpoints como Prey resuelven varios de los puntos más críticos del paquete de evidencia que tanto ANCI como la APDP requieren.
El inventario centralizado responde a la primera pregunta operativa de cualquier incidente: ¿qué dispositivos están en juego y dónde están? El historial de ubicación y el registro de check-ins entregan el timeline preciso que ambos reportes necesitan. Los registros de lock remoto, wipe remoto y reset de fábrica documentan las medidas de contención ejecutadas, con timestamps que sostienen la versión oficial frente a las dos agencias.
El estado de cifrado documentado (por ejemplo, BitLocker activado y verificado por la plataforma) es particularmente importante para la 21.719. Si los datos personales en el dispositivo comprometido estaban cifrados y la clave no fue accedida, el alcance de la notificación puede argumentarse como reducido y la obligación de notificar a titulares puede no gatillarse.
Esto aplica transversalmente a fleets mixtos. Una organización chilena promedio en sectores regulados maneja Windows como base, macOS para ejecutivos, algo de Linux en servidores y Android e iOS en uso corporativo. La evidencia técnica que sostiene los reportes de ANCI y APDP debe cubrir las cinco plataformas, no solo Windows. Las plataformas que ofrecen cobertura multi-OS con un solo agente y una sola consola evitan que el delegado tenga que pedir logs a cinco equipos distintos a las dos de la mañana.
Considera el caso del hospital con ransomware del inicio de este artículo. Con visibilidad endpoint centralizada, el equipo identifica en minutos cuáles servidores y endpoints fueron afectados, ejecuta lock remoto sobre los dispositivos clínicos vinculados, exporta el inventario de dispositivos y el último check-in conocido como evidencia para ANCI, y entrega al DPO la cifra preliminar de equipos donde vivían datos clínicos. Las 3 horas se cumplen. Y la evidencia técnica para los reportes posteriores ya está exportada y respaldada.
Quick win: Audita hoy: si te llega un incidente esta tarde, ¿en cuántos minutos puedes decir cuáles dispositivos están comprometidos y qué datos vivían en ellos? Si la respuesta no se mide en minutos, ahí está el gap.
Conclusión
Un solo incidente activa dos relojes distintos. La 21.663 te exige velocidad y estructura escalonada para ANCI; la 21.719 te exige profundidad sobre datos personales para la APDP y eventualmente para los titulares. Si los tratas como dos flujos separados, alguno se te va a escapar.
La diferencia entre una organización que pasa por un incidente con orden y otra que sale con dos infracciones no es el tamaño del equipo ni el presupuesto. Es la preparación: un protocolo unificado, una sola fuente de verdad, evidencia técnica accesible desde el primer minuto, y un equipo que ha ensayado el ejercicio.
Visibilidad, control y evidencia. Esos son los tres pilares que sostienen la doble notificación. Visibilidad para saber rápido qué está pasando. Control para contener y demostrar que actuaste. Evidencia para que las dos versiones del incidente que envías a dos agencias distintas cuenten la misma historia, con datos que la respaldan.
Lo que puedes hacer este lunes en la mañana: agendar 90 minutos con el delegado de ciberseguridad y el DPO, abrir el plan de respuesta a incidentes que tienes hoy, y escribir en una sola página quién hace qué en las primeras tres horas si un incidente activa las dos leyes al mismo tiempo. Si esa página ya existe pero nadie la ha leído en seis meses, también es un buen momento para revisarla. La doble notificación no se gana cuando suena la alarma. Se gana antes.
FAQ
¿Un incidente siempre activa las dos leyes a la vez?
No. La Ley 21.663 se activa cuando hay impacto en un servicio esencial o en la confidencialidad, integridad o disponibilidad de sistemas en organizaciones OIV u OSE. La Ley 21.719 se activa cuando hay vulneración que afecta datos personales, en cualquier organización que los trate. Muchos incidentes en organizaciones reguladas activan las dos, pero hay casos donde solo aplica una: una filtración de datos sin impacto en servicio activa solo la 21.719; un ataque DDoS sin acceso a datos personales activa solo la 21.663.
¿Qué reporto primero, a ANCI o a la APDP?
ANCI primero, porque su plazo es más estricto: alerta temprana en 3 horas. La Ley 21.719 exige notificación sin dilaciones indebidas, lo que en la práctica se entiende como dentro de 72 horas. Pero los dos relojes corren en paralelo desde la detección, no en secuencia. La preparación de ambos reportes debe arrancar al mismo tiempo aunque el envío sea escalonado.
¿Puedo usar el mismo informe para ambas agencias?
No literalmente, porque los formularios y campos requeridos son distintos. ANCI exige clasificación según la taxonomía oficial de la Resolución Exenta N.º 7. La APDP exige caracterización detallada de los datos personales afectados y evaluación del riesgo para los titulares. Pero sí puedes y debes usar la misma base de hechos, el mismo timeline y la misma evidencia técnica. La inconsistencia entre reportes es uno de los errores más sancionados.
¿Quién es responsable: el delegado de ciberseguridad o el DPO?
Los dos, en sus respectivos ámbitos. El delegado de ciberseguridad responde por el reporte a ANCI bajo la Ley 21.663. El DPO responde por la notificación a la APDP y a los titulares afectados bajo la Ley 21.719. Pero ambos deben coordinarse para que las dos versiones del incidente sean coherentes en alcance, timeline y evidencia técnica.
¿Qué pasa si descubro el componente de datos personales después de enviar la alerta temprana a ANCI?
Tienes que actualizar el reporte a ANCI con esa información en el segundo reporte (72 horas, o 24 horas si eres OIV con servicio esencial afectado) y, en paralelo, activar la notificación a la APDP en cuanto confirmes la afectación de datos personales. No escondas información ni atrases la notificación a la APDP por estar enfocado solo en el flujo ANCI.
¿Las sanciones se acumulan si incumplo ambas?
Sí. Son leyes distintas, con agencias distintas y procedimientos sancionatorios separados. Una mala notificación bajo la 21.663 puede llegar a 40.000 UTM si eres OIV. La 21.719 tiene su propio régimen sancionatorio. El mismo incidente puede generar dos infracciones independientes que se acumulan.
.avif)
