Notificación de Incidentes: Guía Práctica para España y la UE

Por qué notificar importa (y no solo por la multa)

Cuando una organización sufre un ciberincidente, la tentación de gestionar el problema internamente y "no hacer ruido" es comprensible. Pero esta estrategia tiene tres problemas graves.

Primero, la ley lo exige. España y la UE han construido un marco regulatorio donde la notificación no es voluntaria. NIS2, RGPD, ENS y DORA establecen obligaciones concretas con plazos tasados y sanciones económicas significativas.

Segundo, la notificación temprana salva a otros. Cuando una organización comunica un incidente al CSIRT competente, esa información permite alertar a otras entidades que podrían estar afectadas por la misma campaña, el mismo actor o la misma vulnerabilidad. Los CERTs nacionales (CCN-CERT, INCIBE-CERT) operan como nodos de una red de alerta temprana que solo funciona si recibe datos.

Tercero, la transparencia protege a la propia organización. En litigios posteriores, la demostración de que se notificó en plazo, se colaboró con las autoridades y se tomaron medidas de contención es un atenuante relevante. La ocultación, en cambio, agrava las consecuencias.

Panorama de notificación en España: a quién notificar

España tiene un ecosistema de respuesta a incidentes con varios organismos competentes. La clave es entender que no se notifica a uno solo: dependiendo del tipo de organización y del incidente, puede ser necesario notificar a varios simultáneamente.

INCIBE-CERT (empresas privadas y ciudadanos)

El Instituto Nacional de Ciberseguridad opera el CERT de referencia para el sector privado en España. Si eres una empresa privada (no operador de servicios esenciales del sector público), INCIBE-CERT es tu primer punto de contacto.

Canal de notificación: formulario web en incibe.es o correo a [email protected]. Línea telefónica 017 para ciudadanos y empresas.

CCN-CERT (sector público y ENS)

El Centro Criptológico Nacional opera el CERT gubernamental. Es el organismo competente para administraciones públicas (AGE, CCAA, entidades locales) y para entidades del sector privado que prestan servicios a la administración y están sujetas al ENS.

Canal de notificación: plataforma LUCIA (Listado Unificado de Coordinación de Incidentes y Amenazas). Acceso mediante certificado digital.

AEPD (datos personales)

La Agencia Española de Protección de Datos es el organismo competente cuando un incidente afecta a datos personales. La notificación a la AEPD es adicional a la notificación al CERT competente: no la sustituye ni la reemplaza.

Canal de notificación: sede electrónica de la AEPD (sede.agpd.gob.es), formulario de notificación de brechas de datos personales. Requiere certificado digital o Cl@ve.

Fuerzas y Cuerpos de Seguridad del Estado

Si el incidente constituye un delito (ransomware con extorsión, acceso no autorizado, robo de datos, fraude), es recomendable (y en muchos casos necesario) interponer denuncia ante la Policía Nacional (Brigada Central de Investigación Tecnológica) o la Guardia Civil (Grupo de Delitos Telemáticos).

La denuncia no sustituye a las notificaciones regulatorias. Son actos independientes con finalidades distintas.

CNPIC (infraestructuras críticas)

El Centro Nacional de Protección de Infraestructuras y Ciberseguridad (integrado en la Oficina de Coordinación de Ciberseguridad, OCC) recibe notificaciones de operadores de infraestructuras críticas designados bajo la Ley 8/2011 PIC.

Si la organización está catalogada como operador crítico, la notificación al CNPIC/OCC es obligatoria y se canaliza a través de INCIBE-CERT.

Árbol de decisión: a quién notificar según tu caso

La decisión de a quién notificar depende de tres variables: tipo de entidad, tipo de incidente y datos afectados.

Administración pública (AGE, CCAA, local):

• Siempre: CCN-CERT (via LUCIA)
• Si hay datos personales: + AEPD
• Si es delito: + FCSE

Empresa privada (no operador esencial):

• Siempre: INCIBE-CERT
• Si hay datos personales: + AEPD
• Si es delito: + FCSE

Operador de servicios esenciales (NIS2, sector privado):

• Siempre: INCIBE-CERT (como CSIRT de referencia)
• Si hay datos personales: + AEPD
• Si es infraestructura crítica: + CNPIC/OCC
• Si es delito: + FCSE

Entidad financiera (DORA):

• Siempre: INCIBE-CERT + supervisor financiero (BdE, CNMV o DGSFP según tipo)
• Si hay datos personales: + AEPD
• Si es delito: + FCSE

Entidad del sector público que presta servicios digitales:

• CCN-CERT + INCIBE-CERT (coordinación)
• Si hay datos personales: + AEPD

Plazos de notificación NIS2

La Directiva NIS2 (2022/2555) establece el régimen de notificación más estructurado de todos los marcos aplicables. Define tres fases con plazos tasados:

Fase 1: alerta temprana (24 horas)

Desde que la entidad tiene conocimiento del incidente significativo, dispone de 24 horas para enviar una alerta temprana al CSIRT competente. Esta alerta debe indicar:

• Si el incidente tiene sospecha de causa ilícita o maliciosa
• Si puede tener impacto transfronterizo

No se exige un análisis detallado. El objetivo es activar la cadena de alerta lo antes posible.

Fase 2: notificación del incidente (72 horas)

En un plazo de 72 horas desde el conocimiento del incidente, la entidad debe enviar la notificación formal que actualice la alerta temprana e incluya:

• Evaluación inicial del incidente: naturaleza, gravedad e impacto
• Indicadores de compromiso (IOCs) disponibles
• Medidas de contención adoptadas o en curso

Fase 3: informe final (1 mes)

A más tardar un mes después de la notificación del incidente, la entidad debe presentar un informe final que contenga:

• Descripción detallada del incidente, incluyendo gravedad e impacto
• Tipo de amenaza o causa raíz que probablemente desencadenó el incidente
• Medidas de mitigación aplicadas y en curso
• Impacto transfronterizo del incidente, si procede

Si el incidente continúa activo al cumplirse el mes, se presenta un informe de situación en lugar del final, y el informe final se entrega un mes después de la resolución.

¿Qué es un "incidente significativo" bajo NIS2?

No todo incidente activa la obligación de notificar. NIS2 define como significativo aquel que:

• Ha causado o puede causar graves perturbaciones operativas del servicio o pérdidas financieras
• Ha afectado o puede afectar a otras personas físicas o jurídicas al causar perjuicios materiales o inmateriales considerables

Los Estados miembros pueden definir umbrales adicionales en su transposición nacional.

Notificación RGPD: brechas de datos personales

El Reglamento General de Protección de Datos (RGPD, Reglamento 2016/679) establece obligaciones específicas cuando un incidente afecta a datos personales.

Notificación a la autoridad de control (art. 33)

El responsable del tratamiento debe notificar la brecha de datos personales a la AEPD sin dilación indebida y, a más tardar, 72 horas después de tener conocimiento de ella. Si la notificación se realiza después de 72 horas, debe acompañarse de los motivos de la dilación.

No es necesario notificar si es improbable que la brecha suponga un riesgo para los derechos y libertades de las personas físicas.

Comunicación a los afectados (art. 34)

Cuando la brecha entrañe un alto riesgo para los derechos y libertades de las personas, el responsable debe comunicarlo a los afectados sin dilación indebida. No hay un plazo concreto en horas, pero la jurisprudencia y las guías del EDPB esperan que sea lo más rápido posible, típicamente en días.

No es necesaria la comunicación si se han aplicado medidas de protección técnicas apropiadas (cifrado), si se han tomado medidas que garanticen que ya no existe alto riesgo, o si supone un esfuerzo desproporcionado (en cuyo caso se hace comunicación pública).

Contenido mínimo de la notificación RGPD

• Naturaleza de la brecha de datos personales
• Categorías y número aproximado de interesados afectados
• Categorías y número aproximado de registros afectados
• Nombre y datos de contacto del DPO o punto de contacto
• Consecuencias probables de la brecha
• Medidas adoptadas o propuestas para poner remedio

Notificación ENS

El Esquema Nacional de Seguridad (RD 311/2022) establece obligaciones de notificación para las entidades del sector público y los operadores del sector privado que les prestan servicios tecnológicos.

Clasificación y plazos

El CCN-CERT clasifica los incidentes en cinco niveles: crítico, muy alto, alto, medio, bajo. La obligación de notificación y los plazos dependen del nivel:

• Crítico y Muy Alto: notificación inmediata (tan pronto como se detecte). El CCN-CERT activa procedimientos de respuesta coordinada.
• Alto: notificación en las primeras horas. Se espera comunicación antes de 12 horas.
• Medio y Bajo: registro obligatorio, notificación recomendada pero no exigida con urgencia.

Plataforma LUCIA

La herramienta de gestión de incidentes del CCN-CERT es LUCIA (Listado Unificado de Coordinación de Incidentes y Amenazas). Las entidades sujetas al ENS deben registrar sus incidentes en LUCIA, que proporciona:

• Formulario estructurado de notificación
• Seguimiento del ciclo de vida del incidente
• Comunicación bidireccional con el CCN-CERT
• Métricas de respuesta y resolución

El acceso requiere registro previo de la organización y certificado digital del punto de contacto.

Notificación DORA (sector financiero)

El Reglamento de Resiliencia Operativa Digital (DORA, Reglamento 2022/2554) establece un régimen específico para entidades financieras con tres fases de notificación:

Notificación inicial (4 horas)

Tras clasificar un incidente como grave, la entidad financiera dispone de 4 horas para enviar la notificación inicial al supervisor competente. Este es el plazo más corto de todos los marcos regulatorios aplicables en la UE.

En España, los supervisores financieros son:

• Banco de España (BdE): entidades de crédito, establecimientos financieros de crédito
• CNMV: empresas de servicios de inversión, gestoras de fondos
• DGSFP: entidades aseguradoras, fondos de pensiones

Informe intermedio (72 horas)

A las 72 horas del incidente, la entidad debe presentar un informe intermedio con la evaluación actualizada de impacto, las medidas de contención y los indicadores de compromiso.

Informe final (1 mes)

El informe final se presenta en un plazo de un mes tras la resolución del incidente. Incluye análisis de causa raíz, lecciones aprendidas y medidas correctivas implementadas.

¿Qué es un incidente "grave" bajo DORA?

DORA define criterios específicos: impacto en servicios financieros críticos, número de clientes afectados, duración de la interrupción, extensión geográfica, pérdida de datos e impacto económico directo. Las autoridades europeas de supervisión (EBA, EIOPA, ESMA) han publicado criterios de materialidad detallados.

Contenido de la notificación: qué incluir

Independientemente del marco regulatorio, una notificación de incidente bien construida debe contener los siguientes elementos:

Información de la entidad:

• Denominación social y CIF
• Sector de actividad
• Persona de contacto (CISO, DPO, responsable de seguridad)
• Datos de contacto (teléfono directo, correo electrónico)

Descripción del incidente:

• Fecha y hora de detección
• Fecha y hora estimada de inicio (si difiere de la detección)
• Tipo de incidente (ransomware, fuga de datos, DDoS, acceso no autorizado, phishing, etc.)
• Sistemas y servicios afectados
• Estado actual (activo, contenido, resuelto)

Evaluación de impacto:

• Servicios interrumpidos o degradados
• Número de usuarios, clientes o ciudadanos afectados
• Datos comprometidos (tipos y volumen estimado)
• Impacto transfronterizo (si aplica)
• Impacto económico estimado

Indicadores de compromiso (IOCs):

• Direcciones IP, dominios, URLs maliciosos
• Hashes de ficheros maliciosos (SHA256)
• Correos electrónicos de phishing (remitente, asunto)
• Vulnerabilidades explotadas (CVE)

Medidas adoptadas:

• Acciones de contención realizadas
• Medidas de erradicación en curso
• Plan de recuperación
• Comunicaciones a terceros afectados

Errores comunes en la notificación

La experiencia de los CERTs nacionales y de la AEPD revela patrones recurrentes de errores:

1. Confundir "conocimiento" con "confirmación." El plazo de 72 horas (RGPD) o 24 horas (NIS2) empieza cuando la organización tiene conocimiento razonable del incidente, no cuando completa la investigación forense. Esperar a tener todos los datos antes de notificar es un error frecuente y sancionable.

2. Notificar a un solo organismo. Un incidente de ransomware en una administración pública que cifra datos personales de ciudadanos requiere notificación al CCN-CERT (ENS), a la AEPD (RGPD) y denuncia ante FCSE (delito). Notificar solo al CCN-CERT no cubre las obligaciones de protección de datos.

3. Notificaciones excesivamente vagas. "Hemos sufrido un incidente de seguridad" sin indicar tipo, alcance, sistemas afectados ni medidas adoptadas es insuficiente. Aunque la información inicial sea parcial, debe ser lo más específica posible.

4. No actualizar la notificación. La notificación inicial no es un acto único. A medida que avanza la investigación, la organización debe actualizar la información. NIS2 lo formaliza con sus tres fases, pero el principio aplica a todos los marcos.

5. No documentar internamente. Si no documentas cuándo detectaste el incidente, cuándo notificaste, qué incluiste y a quién, no podrás demostrar cumplimiento en una inspección posterior. El registro interno de la gestión del incidente es tan importante como la propia notificación.

6. Considerar que "no hay datos personales" sin verificar. Muchas organizaciones asumen que un incidente de ransomware o un ataque DDoS no implica datos personales. Sin embargo, los logs de acceso, las cuentas de usuario, las bases de datos de clientes y las copias de seguridad exfiltradas casi siempre contienen datos personales.

Escenario multi-regulación: cuando un incidente activa todo

En la práctica, un incidente grave rara vez activa una sola obligación. Veamos un escenario realista:

Escenario: Una entidad financiera española (banco) sufre un ataque de ransomware que cifra sistemas de banca online y exfiltra una base de datos con datos personales de 50.000 clientes.

Este incidente activa simultáneamente:

Marco	Organismo	Plazo	Contenido
DORA	BdE	4h (inicial)	Incidente TIC grave, servicios críticos afectados
NIS2	INCIBE-CERT	24h (alerta)	Alerta temprana, posible impacto transfronterizo
RGPD	AEPD	72h	Brecha de datos personales, 50K afectados
NIS2	INCIBE-CERT	72h (notificación)	Evaluación inicial, IOCs, medidas
RGPD	Afectados	Sin dilación	Comunicación directa por alto riesgo
Penal	FCSE	Lo antes posible	Denuncia por acceso ilícito, extorsión
DORA	BdE	72h (intermedio)	Actualización de impacto
NIS2	INCIBE-CERT	1 mes (final)	Informe completo, root cause
DORA	BdE	1 mes (final)	Análisis causa raíz, lecciones

El plazo más corto domina: las primeras 4 horas son críticas para la notificación DORA. En paralelo, antes de las 24 horas, debe enviarse la alerta temprana NIS2. El equipo de respuesta a incidentes debe tener preparados los canales, formularios y contactos para actuar con esta velocidad.

Plantilla de notificación rápida

Esta plantilla cubre los campos comunes a todas las regulaciones. Adaptarla según el formulario específico de cada organismo:

NOTIFICACIÓN DE INCIDENTE DE CIBERSEGURIDAD
Fecha y hora de envío: [YYYY-MM-DD HH:MM UTC]
Tipo de notificación: [Inicial / Actualización / Final]

1. ENTIDAD
   Denominación: [nombre legal]
   CIF/NIF: [identificador fiscal]
   Sector: [según clasificación NIS2/CNAE]
   Contacto principal: [nombre, cargo, teléfono, email]
   DPO (si aplica): [nombre, teléfono, email]

2. INCIDENTE
   Fecha detección: [YYYY-MM-DD HH:MM UTC]
   Fecha estimada inicio: [YYYY-MM-DD HH:MM UTC]
   Tipo: [ransomware / fuga datos / DDoS / acceso no autorizado / phishing / otro]
   Estado: [activo / contenido / erradicado / en recuperación / resuelto]
   Descripción: [resumen en 2-3 párrafos]

3. IMPACTO
   Servicios afectados: [lista]
   Usuarios/clientes afectados: [número estimado]
   Datos comprometidos: [tipos y volumen]
   Impacto económico estimado: [rango en EUR]
   Impacto transfronterizo: [sí/no, países]

4. INDICADORES DE COMPROMISO
   IPs: [lista]
   Dominios: [lista]
   Hashes (SHA256): [lista]
   CVEs explotados: [lista]
   Correos phishing: [remitente, asunto]

5. MEDIDAS ADOPTADAS
   Contención: [acciones realizadas]
   Erradicación: [acciones en curso]
   Recuperación: [plan y ETA]
   Comunicaciones: [a quién se ha comunicado]

6. REGULACIONES APLICABLES
   [ ] NIS2  [ ] RGPD  [ ] ENS  [ ] DORA  [ ] PIC
   Otros organismos notificados: [lista]

Checklist de respuesta a incidentes (primeras 24 horas)

• Activar el equipo de respuesta a incidentes
• Documentar fecha y hora exacta de detección
• Clasificar el incidente (tipo, severidad inicial)
• Aplicar medidas de contención inmediatas
• Identificar qué regulaciones aplican (NIS2, RGPD, ENS, DORA, PIC)
• Identificar a qué organismos notificar
• Preparar y enviar alerta temprana NIS2 (si aplica, 24h)
• Preparar y enviar notificación DORA (si aplica, 4h)
• Evaluar si hay datos personales afectados
• Recopilar IOCs disponibles
• Informar a la dirección
• Contactar con asesoría jurídica
• Contactar con aseguradora de ciberriesgos (si existe póliza)
• Evaluar necesidad de denuncia ante FCSE
• Documentar todas las acciones con timestamp

Recursos y referencias

Plataformas de notificación:

• LUCIA (CCN-CERT): ccn-cert.cni.es
• Sede electrónica AEPD: sede.agpd.gob.es
• INCIBE-CERT: incibe.es
• Línea 017: teléfono gratuito de ayuda en ciberseguridad

Normativa:

• Directiva NIS2 (2022/2555): arts. 23-24 (notificación de incidentes)
• RGPD (2016/679): arts. 33-34 (notificación de brechas)
• RD 311/2022 (ENS): arts. 33-36 (gestión de incidentes)
• Reglamento DORA (2022/2554): arts. 17-19 (notificación de incidentes TIC)
• Ley 8/2011 PIC: disposiciones sobre notificación a operadores críticos

Guías prácticas:

• CCN-STIC 817: Gestión de ciberincidentes (CCN-CERT)
• Guía de brechas de datos personales (AEPD)
• Directrices 9/2022 del EDPB sobre notificación de brechas
• RTS de DORA sobre clasificación y notificación de incidentes (EBA/EIOPA/ESMA)

Herramientas de soporte:

• MalwareIntel IOC Search: consulta indicadores de compromiso para incluir en notificaciones
• MalwareIntel Threat Actors: identifica actores asociados a los TTPs observados
• MITRE ATT&CK Navigator: mapea técnicas observadas