Cuando ocurre un incidente de ciberseguridad, no solo importa contenerlo. Reportar rápido y bien puede ahorrarte multas, titulares negativos y pérdida de confianza; por su parte, hacerlo tarde o mal deja a tu organización expuesta por todos lados.
En Chile, por ejemplo, la Ley 21.663 (Ley Marco de ciberseguridad) exige notificar incidentes significativos que afecten servicios esenciales, y la Ley 21.719 (Ley de protección de datos) obliga a informar vulneraciones de datos personales a la autoridad e incluso a los afectados. A nivel global, marcos como ISO 27035, GDPR o NIS2 también fijan plazos y formatos, marcando el estándar de cómo y cuándo se debe actuar.
¿Ahora bien, qué, cómo y cuando debemos reportar?
¿Qué se considera un incidente que debe ser reportado?
Si bien esto puede variar dependiendo del marco legal y la industria, existen definiciones claras de qué es un incidente de ciberseguridad que debe ser reportado. En general, hablamos de situaciones significativas que afectan la disponibilidad, integridad o confidencialidad de la información y sistemas.
Bajo algunas industrias y regulaciones, como la de la ley 21.663, también son reportables las situaciones informáticas que puedan afectar la integridad física de las personas.
¿Evento de seguridad o incidente reportable?
No todo lo que suena a “problema” en ciberseguridad merece un reporte oficial. Un evento de seguridad es cualquier situación anómala que podría afectar la seguridad, mientras que un incidente reportable es aquel que realmente compromete datos, sistemas o servicios y que, por ley o contrato, debe notificarse. Algunos ejemplos claros de un incidente reportable, por ejemplo son:
- Interrupción de servicios esenciales: caída total o parcial de un servicio crítico para usuarios o clientes, como la caída de la banca en línea o la red de telefonía móvil.
- Acceso no autorizado a datos personales: cuando alguien obtiene información privada sin permiso, ya sea por hackeo o error interno.
- Filtraciones o pérdida de datos sensibles: exposición, robo o destrucción de datos que podrían causar daños significativos.
- Compromiso de infraestructura crítica: afectación de sistemas clave cuyo fallo impacta directamente en la operación y seguridad de una organización o incluso de un país.
La línea entre “evento” e “incidente reportable” no siempre es obvia. Este cuadro práctico te ayuda a separar qué se guarda en los logs internos y qué sí debe escalarse y notificarse:
¿Qué información debe incluir un reporte?
Un buen reporte de incidente no es solo “avisar que pasó algo”, sino documentar de forma clara y ordenada qué ocurrió, qué impacto tuvo y qué se está haciendo al respecto. Cuanto más preciso y completo sea, más fácil será coordinar la respuesta y cumplir con requisitos legales o contractuales. Aquí tienes un checklist práctico inspirado en ISO 27035:
- Descripción del incidente: Explica qué tipo de incidente ocurrió, cuándo empezó y a qué hora se detectó.
- Alcance y gravedad: Detalla qué servicios, sistemas o datos fueron afectados y la magnitud del impacto.
- Indicadores de compromiso (IoCs): Señala evidencias técnicas, como direcciones IP, dominios o archivos sospechosos, que ayuden a identificar la amenaza.
- Medidas tomadas y plan de acción: Resume qué se ha hecho hasta el momento y qué pasos están planificados para resolver y prevenir el incidente.
- Contacto del responsable designado para seguimiento: Proporciona los datos de la persona o equipo que lidera la gestión del caso para canalizar consultas y coordinar acciones.
Taxonomía de incidentes según la Ley 21.663
La Resolución Exenta N.º 7 (2025) define la taxonomía oficial de incidentes que deben reportar los Operadores de Servicios Esenciales (OSE) y los Operadores de Importancia Vital (OIV) bajo la Ley 21.663.
El objetivo es simplificar la clasificación: no importa si aún no sabes el origen exacto del ataque, lo clave es describir sus efectos observables, es decir, lo que realmente viste o sufriste en tus sistemas.
Para hacerlo más claro, la norma agrupa los incidentes en dos niveles:
- Áreas de impacto (4 grandes grupos): muestran qué dimensión de tu operación fue afectada: uso indebido de recursos, confidencialidad, disponibilidad o integridad.
- Categorías de incidentes (11 tipos): bajan al detalle de cómo se manifestó el problema en la práctica (por ejemplo: fuga de datos, ataque DDoS, defacement de un sitio web).
Plazos para reportar: referencias locales e internacionales
Reportar un incidente no solo es cuestión de buena práctica: en muchos casos, la ley marca un plazo claro y estricto. Estos tiempos varían según el marco legal o estándar aplicado, y conocerlos puede evitar multas y dolores de cabeza. Aquí tienes una comparativa rápida para ubicarte y cumplir sin contratiempos:
Reportes según la Ley 21.663 (Ley Marco de Ciberseguridad)
La Ley marco de ciberseguridad obliga a reportar incidentes a todos los Operadores de Servicios Esenciales (OSE) y Operadores de Importancia Vital (OIV), que incluyen desde empresas de energía y telecomunicaciones hasta hospitales y bancos. Su objetivo es asegurar que eventos con alto impacto sean informados de forma rápida y estructurada para permitir una respuesta coordinada y minimizar daños.
¿A quién le toca reportar?
Todos los Operadores de Servicios Esenciales (OSE): energía, agua, telecomunicaciones, transporte, salud, finanzas, entre otros.
Los Operadores de Importancia Vital (OIV): entidades privadas o públicas cuya interrupción tendría consecuencias graves para la sociedad o la seguridad nacional.
¿A dónde se reporta?
Los reportes deben enviarse al CSIRT Nacional, a través de la plataforma de la Agencia Nacional de Ciberseguridad (https://portal.anci.gob.cl), disponible 24/7, con su clave única. Puede haber más de una persona encargada de reportar a la ANCI.
¿Cómo se reporta?
Al ingresar al portal, se deberá llenar un formulario electrónico que guía paso a paso según el tipo de incidente.
El reporte debe incluir al menos: datos de la institución afectada, delegado de ciberseguridad, fecha/hora de detección, tipo de incidente, descripción del incidente, indicadores de compromiso (IoCs), activos y recursos comprometidos y otros antecedentes relevantes (repercusiones en otras instituciones, etc).
¿Cuándo y en qué formato se reporta?
La ley exige un flujo escalonado de reportes, cada uno con un plazo máximo:
Alerta temprana: dentro de las 3 horas desde que se detecta el incidente. La primera obligación tras detectar un incidente es la Alerta Temprana. Aunque es un reporte inicial, debe ser lo suficientemente claro para activar las medidas de respuesta. Se debe indicar: Datos de la institución, datos del delegado que reporta, descripción del incidente y activos afectados.
Segundo reporte: Máximo de 72 horas (o 24 horas si eres OIV y afecta un servicio esencial). Este documento amplía la información preliminar, actualizando los datos de la alerta temprana y sumando una primera evaluación sobre la gravedad, impacto e indicadores de compromiso detectados en la investigación inicial.
Plan de acción (Solo OIVs) → Dentro de los 7 días posteriores al descubrimiento del incidente. Se debe entregar un plan de acción que va más allá del diagnóstico; se debe plantear cómo la institución restaurará la continuidad operacional, distribuyendo responsabilidades y calculando los tiempos de recuperación esperados.
Informe final → en un máximo de 15 días desde la alerta temprana, se debe enviar un reporte que actualiza los datos entregados anteriormente e incorpora un análisis detallado de las causas, medidas aplicadas y, en su caso, repercusiones transfronterizas.
Informe parcial → si el incidente sigue activo tras 15 días, se debe reportar cada 15 días hasta resolverlo.
Cómo integrar ambas obligaciones en un solo procedimiento interno
Cumplir con la Ley 21.663 (marco de ciberseguridad) y la Ley 21.719 (datos personales) no debería significar correr con dos flujos distintos cada vez que ocurre un ataque. La clave está en unificar el manejo de incidentes bajo un solo flujo interno, lo que permite ahorrar tiempo, evitar confusiones y cumplir con todas las exigencias legales:
Designar un punto de contacto único: Designa a un responsable único (por ejemplo, el CISO, delegado de ciberseguridad o DPO) que reciba, valide y envíe todos los reportes. Eso asegura coherencia y evita versiones distintas circulando.
Uso de un formulario estandarizado: Contar con un único formato de reporte que incluya los campos exigidos por la Ley 21.663 y la Ley 21.719 facilita cumplir con ambas y reduce la probabilidad de omitir datos clave en la notificación.
Mapeo rápido: Tener una guía interna que relacione cada tipo de incidente con el marco legal aplicable:
- Si es incidente → reporta al CSIRT (21.663).
- Si involucra datos personales → también notifica a la Agencia de Protección de Datos (21.719) y, si corresponde, a los titulares.
Entrenamiento y simulacros: Capacitar al personal y realizar ejercicios periódicos asegura que, al enfrentar un incidente real, el equipo pueda ejecutar el procedimiento de forma automática, reduciendo errores y mejorando la velocidad de respuesta.
Conclusión y recomendaciones finales
En ciberseguridad, los minutos cuentan. Reportar un incidente no es un trámite burocrático: es una pieza crítica para contener daños, coordinar apoyo y proteger la reputación de tu organización. La Ley 21.663 y la Ley 21.719 marcan los plazos y formatos, pero el éxito depende de que tengas un protocolo listo antes de que suene la alarma.
Si tu organización aún no tiene un procedimiento sólido, este es el momento de crearlo. Implementar un Protocolo de Respuesta y Reporte de Incidentes adaptado a tu operación te permitirá reaccionar con seguridad y eficacia.
En ciberseguridad, improvisar cuesta caro. Empieza hoy, aunque sea con un checklist mínimo, y ve madurando tu protocolo. La diferencia entre multas, titulares negativos y pérdida de confianza… o una recuperación ágil y ordenada, dependerá de qué tan preparado estés antes del próximo incidente.
FAQ
¿Qué es un “incidente significativo” según la Ley 21.663?
Es todo aquel que afecta la confidencialidad, integridad, disponibilidad o uso legítimo de los sistemas y servicios esenciales. Se consideran significativos los que interrumpen la continuidad de un servicio crítico, exponen datos sensibles o comprometen la seguridad de terceros.
¿Cuáles son ejemplos de incidentes que debo reportar?
Ransomware, filtraciones de datos personales, interrupciones de servicios esenciales, ataques DDoS que afecten la operación o el compromiso de infraestructura crítica.
¿Qué plazos tengo para reportar un incidente en Chile?
Depende de la ley: la 21.663 exige alerta en 3 horas, informe preliminar en 72 h (24 h si es OIV con servicio afectado) e informe final en 15 días.
¿Qué pasa si el delegado de ciberseguridad no está disponible al momento del incidente?
La organización debe designar un sustituto o responsable alterno previamente definido. La obligación de reportar recae en la institución, no en una persona en particular: si el delegado no está, alguien más debe ejecutar el procedimiento.
¿Qué pasa si detecto el incidente después de las 3 horas?
El plazo corre desde el momento en que la institución toma conocimiento del incidente, no desde que ocurrió técnicamente. Si lo detectas con retraso, debes reportarlo de inmediato en cuanto lo descubras. Nunca omitas el reporte por haber pasado el plazo inicial.
¿Qué información mínima debo incluir en la Alerta Temprana?
La identificación de la institución, los datos del delegado de ciberseguridad, fecha/hora de detección, indicios del incidente y los activos comprometidos.
¿Qué pasa si envío información incompleta en el primer reporte?
No hay problema: la Alerta Temprana es preliminar. La información se complementa en el Segundo Reporte (72 h, o 24 h para OIV con servicios afectados) y en el Informe Final (15 días). Lo importante es no dejar pasar los plazos.
¿Qué sanciones hay por no reportar a tiempo?
La Ley establece multas administrativas ****que pueden llegar a niveles millonarios. Pero más allá de la sanción, el no reporte puede agravar el impacto operativo y reputacional, ya que impide activar la coordinación nacional de respuesta.
