Clasificación de severidad de incidentes para DORA, NIS2 y GDPR

La llamada de incidente de las 02:17 que se convierte en una decisión regulatoria

A las 02:17 de un jueves por la mañana, Sarah, CISO de FinScale, ve la primera alerta: tráfico anómalo de API, picos de autenticación fallida y latencia del panel de pagos por encima de 3000 ms. En cuestión de minutos, el soporte al cliente informa de errores en el estado de los pagos. El proveedor de servicios en la nube indica que no existe ningún incidente generalizado de plataforma. El SOC observa tokens de acceso sospechosos procedentes de dos regiones geográficas. Producto confirma que el panel vuelve a estar en línea tras 19 minutos, pero doce clientes ya han abierto tickets.

A las 03:05, Sarah está en el puente de crisis con el responsable del incidente, el asesor jurídico, el coordinador de privacidad, el responsable de operaciones en la nube y el patrocinador ejecutivo. La pregunta técnica es relativamente clara: ¿qué ha ocurrido con la pasarela de API? Las preguntas regulatorias son más difíciles:

1. ¿Es este un incidente grave relacionado con las TIC según DORA?
2. ¿Es un incidente significativo según NIS2?
3. ¿Existe una brecha de datos personales conforme a GDPR que exija notificación?
4. ¿Puede la organización demostrar cómo llegó a esas respuestas?

La respuesta incorrecta puede generar exposición regulatoria. La respuesta tardía puede hacer que se incumpla una ventana de notificación. La respuesta no documentada puede fracasar en una auditoría ISO/IEC 27001:2022 meses después.

Este es el reto de la respuesta a incidentes en 2026. Muchas organizaciones disponen de un plan de respuesta a incidentes, procedimientos forenses, playbooks de privacidad y plantillas de comunicación de crisis. Menos organizaciones cuentan con un modelo defendible de clasificación de severidad de incidentes que convierta un evento de seguridad ruidoso en una decisión documentada frente a las expectativas de evidencia de DORA, NIS2, GDPR e ISO/IEC 27001:2022.

La solución no consiste en tres procesos de triaje separados. Consiste en un único modelo de severidad gobernado, con capas regulatorias separadas, umbrales medibles, reglas de escalado, registros de decisión y requisitos de recopilación de evidencias. En términos prácticos, la severidad de un incidente no debe ser una etiqueta elegida bajo presión. Debe ser una decisión organizativa controlada que resista el escrutinio de reguladores, auditores, miembros del consejo de administración, clientes y el DPO.

Por qué la clasificación de severidad de incidentes es ahora un control a nivel del consejo de administración

La clasificación de incidentes solía ser principalmente técnica: severidad del malware, hosts afectados, vulnerabilidades explotadas y si se habían exfiltrado datos. En 2026 también es legal, financiera, social y contractual.

DORA convierte la resiliencia operativa digital en una obligación de gobierno para las entidades financieras. Se espera que el órgano de dirección defina, apruebe, supervise y siga siendo responsable del marco de gestión del riesgo de las TIC. Esto incluye la continuidad de negocio de TIC, los planes de respuesta y recuperación, los canales de notificación de incidentes graves, el riesgo de terceros de TIC y las lecciones aprendidas.

NIS2 eleva las exigencias de gobierno para las entidades esenciales e importantes. Article 20 exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implementación y reciban formación. También vincula los fallos en la gestión de riesgos y en la notificación de incidentes con consecuencias supervisoras graves. Para las entidades esenciales, los importes máximos de referencia de las multas administrativas pueden alcanzar al menos 10.000.000 EUR o el 2 por ciento del volumen de negocios anual mundial total, si esta cifra es superior. Para las entidades importantes, la referencia es de al menos 7.000.000 EUR o el 1,4 por ciento del volumen de negocios, si esta cifra es superior.

GDPR añade una perspectiva distinta. Una brecha de datos personales no se limita a una divulgación pública confirmada o a archivos robados. Incluye la destrucción, pérdida, alteración, divulgación no autorizada o acceso accidental o ilícito a datos personales. Los responsables del tratamiento deben evaluar el riesgo para las personas y demostrar responsabilidad proactiva respecto de la decisión de notificar o no notificar.

ISO/IEC 27001:2022 aporta a estas obligaciones una base probatoria. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, los requisitos de las partes interesadas, el alcance, las interfaces y las dependencias. Las cláusulas 5.1 a 5.3 exigen compromiso de liderazgo, política, roles, responsabilidades e información a la dirección. Las cláusulas 6.1.1 a 6.1.3 exigen planificación basada en riesgos, evaluación de riesgos, tratamiento de riesgos y una declaración de aplicabilidad. Las cláusulas 8.1 a 8.3 exigen control operacional, control de cambios, evidencias conservadas y reevaluación cuando cambien las condiciones de riesgo. ISO/IEC 27001:2022

Cuando se produce la llamada de incidente, la pregunta no debería ser: “¿Quién cree que esto es crítico?”. Debería ser: “¿Qué nos exigen hacer ahora nuestros criterios aprobados, los desencadenantes legales, las evidencias y las reglas de escalado?”.

Un evento, tres sistemas regulatorios de clasificación

DORA, NIS2 y GDPR no utilizan el mismo lenguaje para los incidentes. Esa es la razón principal por la que las organizaciones tienen dificultades durante la primera hora.

Article 17 de DORA exige que las entidades financieras establezcan un proceso de gestión de incidentes relacionados con las TIC que detecte, gestione y notifique incidentes de TIC; registre incidentes relacionados con las TIC y ciberamenazas significativas; aborde las causas raíz; utilice indicadores de alerta temprana; categorice y clasifique incidentes; asigne roles; gestione comunicaciones; escale incidentes graves a la alta dirección; y restaure operaciones seguras.

Article 18 de DORA exige la clasificación mediante criterios como clientes afectados, contrapartes afectadas, transacciones, duración, indisponibilidad, extensión geográfica, pérdida de datos que afecte a la disponibilidad, autenticidad, integridad o confidencialidad, criticidad de los servicios afectados e impacto económico. Article 19 de DORA exige la notificación de incidentes graves relacionados con las TIC y la comunicación a clientes cuando se vean afectados intereses financieros.

Article 23 de NIS2 define un incidente significativo como aquel que ha causado o puede causar una perturbación operativa grave o pérdidas financieras, o que ha afectado o puede afectar a otras personas causando daños materiales o inmateriales considerables. Exige una alerta temprana en las 24 horas siguientes a la toma de conocimiento del incidente significativo, una notificación del incidente en 72 horas, informes intermedios a petición y un informe final en el plazo de un mes desde la notificación del incidente. Cuando proceda, también debe informarse a los destinatarios de servicios afectados sobre las medidas o soluciones que pueden adoptar.

GDPR plantea una pregunta de riesgo de privacidad. ¿Una brecha de seguridad ha causado destrucción, pérdida, alteración, divulgación no autorizada o acceso a datos personales? En caso afirmativo, el responsable del tratamiento debe evaluar el riesgo para los derechos y libertades de las personas físicas. Si es probable que la brecha entrañe un riesgo, por lo general debe notificarse a la autoridad de control en un plazo de 72 horas desde la toma de conocimiento. Si es probable que entrañe un alto riesgo, puede ser necesario informar a las personas afectadas sin dilación indebida.

Por tanto, un único incidente necesita clasificación simultánea.

Para las entidades financieras, DORA es el acto jurídico sectorial específico de la Unión para las obligaciones de gestión del riesgo de las TIC y notificación de incidentes que se solapan con NIS2. Eso no hace que NIS2 sea irrelevante. Puede seguir importando para la cooperación, los flujos de información, servicios fuera del perímetro de DORA, entidades no financieras del grupo, servicios en la nube, servicios gestionados y obligaciones contractuales con clientes. El modelo de severidad debe registrar no solo el resultado, sino también la lógica de aplicabilidad.

El modelo de Clarysec: clasificar el evento, no la emoción

Clarysec parte del control 5.25 de ISO/IEC 27002:2022, evaluación y decisión sobre eventos de seguridad de la información, como anclaje de cumplimiento transversal. En Zenith Controls: The Cross-Compliance Guide Zenith Controls, este tema se mapea mediante la entrada “Evaluación y decisión sobre eventos de seguridad de la información” para el control 5.25, respaldada por “Planificación y preparación de la gestión de incidentes de SI” para el control 5.24 y “Recopilación de evidencias” para el control 5.28.

El momento de cumplimiento más importante a menudo no es la contención. Es la bifurcación en la que un evento de seguridad se convierte en un incidente regulatorio, o en la que queda registrado de forma defendible como un evento de menor severidad.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint describe este momento en la fase Controls in Action, Step 23:

“No toda anomalía es un desastre. No toda alerta indica compromiso. En el mundo real, los equipos de seguridad y las unidades de negocio están inundados de ruido: intentos de inicio de sesión, anomalías en registros, incumplimientos menores de políticas, actividad de shadow IT. El verdadero reto no está solo en la detección, sino en distinguir lo inocuo de lo dañino y saber qué exige escalado.”

Esa frase resume el problema operativo. Una alerta de SIEM no equivale automáticamente a un incidente grave DORA. Una indisponibilidad temporal no equivale automáticamente a un incidente significativo NIS2. Una consulta sospechosa a una base de datos no equivale automáticamente a una notificación obligatoria bajo GDPR. Cada una puede convertirse en notificable en función del impacto, el alcance, los datos, las partes afectadas y las evidencias.

Zenith Blueprint, en la fase Risk Management, Step 10, también recomienda adaptar las definiciones de impacto a la escala de la organización y a la exposición regulatoria:

“Al definir el impacto, conviene relacionar los niveles con la escala específica de su organización. Por ejemplo, ‘Impacto financiero mayor = pérdida > 100.000 $’ (ajústelo a su contexto). Considere también el impacto regulatorio: por ejemplo, una brecha de datos personales podría ser automáticamente ‘Mayor’ o ‘Severa’ debido a las sanciones y requisitos de notificación de GDPR, aunque la pérdida financiera directa no esté clara.”

Ese es el principio de diseño para la clasificación de severidad de incidentes en 2026: la severidad es el impacto en las operaciones de la organización más el impacto legal más la confianza en las evidencias.

Una taxonomía práctica de severidad de incidentes para DORA, NIS2 y GDPR

Una taxonomía defendible debe separar la severidad interna de la clasificación regulatoria. La severidad interna determina la urgencia de respuesta, la asignación de recursos y el escalado ejecutivo. La clasificación regulatoria determina la notificación, la revisión legal y la comunicación externa.

El nivel de severidad interna no es la respuesta regulatoria final. Es el modo operativo. Un evento SEV 3 puede convertirse en notificable bajo GDPR tras la revisión de registros. Una indisponibilidad SEV 2 puede no ser un incidente grave DORA si no se cumplen los umbrales de impacto. Un incidente de ransomware SEV 1 puede activar DORA, NIS2, GDPR, contratos con clientes y coordinación con las fuerzas y cuerpos de seguridad al mismo tiempo.

Una matriz de clasificación más detallada ayuda al equipo a pasar de la alerta a la acción.

El modelo debe estar integrado en la política, no quedar a merced de la voz más fuerte en el puente. La Incident Response Policy-sme para pymes Incident Response Policy-sme - SME, requisitos de gobernanza, cláusula 5.3.1, establece:

“El director general, con aportación del proveedor externo de TI, debe clasificar todos los incidentes por severidad en el plazo de una hora desde la notificación.”

La misma política para pymes, tratamiento de riesgos y excepciones, cláusula 7.4.1, añade:

“Cuando haya datos de clientes implicados, el director general debe evaluar las obligaciones legales de notificación en función de la aplicabilidad de GDPR, NIS2 o DORA.”

Para organizaciones de mayor tamaño, la Incident Response Policy corporativa Incident Response Policy, requisitos de gobernanza, cláusula 5.3, formaliza el mismo concepto:

“La clasificación de incidentes seguirá un modelo por niveles:”

El lenguaje de la política importa porque reguladores y auditores preguntarán si los criterios de clasificación existían antes del incidente. Una matriz creada a posteriori es una evidencia débil. Una matriz aprobada, objeto de formación, ejercitada y utilizada de forma consistente es defendible.

El registro de decisión: el artefacto de evidencia más importante

Cuando auditores, reguladores o miembros del consejo de administración revisan un incidente, rara vez preguntan solo: “¿Qué ocurrió?”. Preguntan: “¿Cuándo lo supieron, quién decidió, con base en qué evidencias y por qué no notificaron antes?”.

Por eso Clarysec recomienda un registro de decisión de severidad para todo evento SEV 3 o superior y para cualquier evento que implique datos personales, servicios críticos, clientes financieros, servicios gestionados, infraestructura en la nube o impacto transfronterizo.

Esto se vincula directamente con ISO/IEC 27001:2022. La cláusula 8.1 exige que los procesos se planifiquen, implementen y controlen, con información documentada suficiente conservada para demostrar que operaron según lo previsto. Las cláusulas 8.2 y 8.3 exigen reevaluación cuando se produzcan cambios significativos y conservación de evidencias de tratamiento del riesgo. Los controles del Anexo A A.5.24 a A.5.28 proporcionan la columna vertebral de la gestión de incidentes: planificación y preparación, evaluación y decisión sobre eventos, respuesta, aprendizaje de incidentes y recopilación de evidencias.

La Data Protection and Privacy Policy-sme para pymes Data Protection and Privacy Policy-sme - SME, aplicación y cumplimiento, cláusula 8.3.2, respalda el lado GDPR del modelo:

“El coordinador de privacidad determinará la severidad, iniciará acciones de contención y documentará el caso”

La evaluación de privacidad no debe comenzar cuando el reloj regulatorio ya resulta incómodo. Debe formar parte del flujo de trabajo de triaje.

Ejemplo práctico: clasificación del incidente de API de Sarah

Volvamos a FinScale. Es una plataforma fintech B2B que utiliza infraestructura en la nube, un proveedor externo de analítica de fraude y un proveedor de seguridad gestionada. Es una entidad financiera cubierta por DORA para algunas actividades. También es un proveedor de servicios digitales con operaciones relevantes para NIS2 en un Estado miembro. Trata datos personales de clientes como responsable del tratamiento para servicios de cuenta y como encargado del tratamiento para algunos clientes empresariales.

A las 02:17 se detecta tráfico anómalo de API. A las 02:35 se abre el ticket de incidente. A las 03:00, Sarah completa el triaje inicial con el responsable del incidente.

Primero, se establece la severidad interna. El incidente afectó a la disponibilidad del panel de clientes durante 19 minutos, implicó tokens de acceso sospechosos y afectó a una función crítica orientada al cliente. Se clasifica como SEV 3 Moderado pendiente de confirmación, con escalado al responsable del incidente, al coordinador de privacidad, al asesor jurídico y al propietario del servicio.

Segundo, se completa el análisis DORA. El equipo comprueba clientes afectados, contrapartes, transacciones, duración, indisponibilidad, extensión geográfica, pérdida de datos, criticidad e impacto económico. No se confirman transacciones fallidas ni alteradas. La indisponibilidad es limitada. No se ha demostrado pérdida de datos. Sin embargo, dado que pueden verse afectados un componente crítico de servicio financiero y los intereses financieros de clientes, el incidente permanece bajo monitorización DORA y puede reclasificarse.

Tercero, se registra el análisis NIS2. El equipo señala que DORA es el régimen sectorial específico primario de notificación para las obligaciones de la entidad financiera cubierta. También comprueba si el incidente afecta a servicios o clientes fuera del perímetro DORA. En esta fase no se confirma una perturbación operativa grave ni daños considerables.

Cuarto, se inicia el análisis GDPR. Los tokens sospechosos pueden haber permitido acceso a datos del panel de clientes. El coordinador de privacidad documenta las categorías de datos, usuarios afectados, alcance de los tokens, registros revisados, si los datos fueron visualizados o exportados, y salvaguardas como la caducidad de tokens y los controles de acceso.

A las 04:20, el análisis de registros muestra que dos tokens se utilizaron para acceder a metadatos del panel de 41 clientes, incluidos nombres, identificadores de cuenta y estado de transacciones, pero no credenciales de pago ni documentos de identidad. El equipo actualiza el incidente a SEV 2 Mayor porque se vio afectada la confidencialidad de datos personales y puede requerirse comunicación a clientes. El DPO evalúa el riesgo GDPR para las personas. La decisión DORA se revisa en función del impacto en clientes, el impacto en transacciones y el impacto económico.

Este es el valor práctico del modelo. La clasificación inicial no es una conclusión legal final. Es una decisión basada en evidencias que puede actualizarse a medida que se desarrollan los hechos.

Registro, monitorización y evidencias forenses: la capa de prueba

Un modelo de severidad sin evidencias es una opinión de reunión. La expectativa en 2026 es que la clasificación esté respaldada por registros, monitorización, artefactos preservados y cadena de custodia.

La Logging and Monitoring Policy-sme para pymes Logging and Monitoring Policy-sme - SME, aplicación y cumplimiento, cláusula 8.3.4, establece:

“Las investigaciones de brechas deben estar respaldadas por registros adecuados para cumplir el principio de responsabilidad proactiva bajo GDPR y DORA”

El manejo forense es igualmente importante. La Evidence Collection and Forensics Policy-sme para pymes Evidence Collection and Forensics Policy-sme - SME, requisitos de gobernanza, cláusula 5.3.1, exige:

“Debe mantenerse un registro sencillo de cadena de custodia (por ejemplo, un archivo Excel o un documento de plantilla) para cada incidente.”

Para entornos corporativos, la Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, requisitos de gobernanza, cláusula 5.5, exige:

“Todas las evidencias recopiladas se identificarán de forma única, se etiquetarán y se almacenarán en un repositorio seguro con:”

Zenith Blueprint, en la fase Controls in Action, Step 23, explica por qué esto importa para el control 5.28 de ISO/IEC 27002:2022:

“Cuando se produce un incidente de seguridad de la información, uno de los elementos más críticos, aunque a menudo ignorado, de la respuesta es la evidencia. No registros, no capturas de pantalla, no narrativas sueltas, sino evidencias correctamente preservadas, respetuosas con la cadena de custodia y resistentes a manipulaciones.”

Un paquete práctico de evidencias para un incidente grave o potencialmente notificable debe incluir:

• Ticket de incidente y cronología
• Registro de decisión de severidad e historial de reclasificación
• Alertas de SIEM, alertas de detección y respuesta en endpoints, registros en la nube y registros de identidad
• Registros de acceso a datos y registros de exportación
• Entradas del inventario de activos y servicios afectados
• Evaluación de impacto en clientes, transacciones y geografía
• Hoja de análisis DORA, NIS2 y GDPR
• Evaluación del DPO o legal
• Aprobaciones de comunicaciones y mensajes enviados
• Registro de cadena de custodia
• Análisis de causa raíz
• Acciones correctivas y lecciones aprendidas

Este paquete de evidencias también respalda los controles del Anexo A de ISO/IEC 27001:2022 A.8.15 registro de eventos, A.8.16 actividades de monitorización, A.5.28 recopilación de evidencias, A.5.27 aprendizaje de incidentes de seguridad de la información, A.5.31 requisitos legales, estatutarios, regulatorios y contractuales, y A.5.34 privacidad y protección de la información de identificación personal.

Mapeo de cumplimiento transversal: construir una vez, responder a muchos auditores

Los modelos de severidad de incidentes más sólidos se construyen una vez y se mapean muchas veces. Zenith Controls está diseñado como una brújula de cumplimiento transversal para este trabajo. Para este tema, las entradas centrales de ISO/IEC 27002:2022 son 5.24 planificación y preparación de la gestión de incidentes de seguridad de la información, 5.25 evaluación y decisión sobre eventos de seguridad de la información, 5.26 respuesta a incidentes de seguridad de la información, 5.27 aprendizaje de incidentes de seguridad de la información y 5.28 recopilación de evidencias.

Estos controles se integran de forma natural en el sistema de gestión ISO/IEC 27001:2022. Las cláusulas 4, 5, 6 y 8 definen alcance, liderazgo, criterios de riesgo, tratamiento y evidencias operativas. ISO/IEC 27002:2022 proporciona el lenguaje de implementación de controles. El enfoque de continuidad de negocio al estilo ISO 22301 respalda los umbrales de perturbación, las prioridades de recuperación y la gestión de crisis. Las prácticas de gestión de incidentes al estilo ISO/IEC 27035 respaldan la detección, notificación, evaluación, respuesta y aprendizaje estructurados. El gobierno de la privacidad al estilo ISO/IEC 27701 respalda los roles de brecha de datos personales, las consideraciones de responsable y encargado del tratamiento, las evidencias de privacidad y la responsabilidad proactiva.

El mismo modelo se mapea al NIST Cybersecurity Framework 2.0. La función GOVERN exige que las obligaciones legales, regulatorias, contractuales, de privacidad y de libertades civiles se comprendan y gestionen. También espera que se definan el apetito de riesgo, los roles, las autoridades, las políticas y la supervisión. Las funciones DETECT, RESPOND y RECOVER respaldan el triaje, análisis, escalado, contención, restauración, comunicaciones y mejora.

El beneficio es práctico. Cuando un supervisor DORA solicita la justificación de un incidente grave relacionado con las TIC, una autoridad NIS2 pregunta por la decisión de alerta temprana de 24 horas, una autoridad de protección de datos pregunta por qué se notificó o no se notificó bajo GDPR, y un auditor ISO pregunta si el SGSI operó según lo planificado, la organización puede responder desde el mismo conjunto de evidencias.

Cómo probarán su modelo auditores y reguladores

Un auditor ISO/IEC 27001:2022 normalmente comenzará por el alcance y los requisitos legales. Preguntará si DORA, NIS2, GDPR, los contratos con clientes y las obligaciones de terceros de TIC se identificaron como requisitos de partes interesadas. Después seguirá la pista hacia los criterios de riesgo, la declaración de aplicabilidad, los procedimientos de incidentes, los registros operativos y la conservación de evidencias. Quiere pruebas de que el proceso de clasificación no se inventó durante el incidente.

Un supervisor DORA o un equipo de auditoría interna buscará un ciclo de vida completo: proceso de gestión de incidentes, indicadores de alerta temprana, criterios de clasificación, escalado de incidentes graves, comunicación a clientes, causa raíz, cifras finales de impacto, pruebas de resiliencia y supervisión por el órgano de dirección. También preguntará si se consideraron las dependencias de terceros de TIC, especialmente cuando intervinieron proveedores de servicios en la nube, SaaS, seguridad gestionada o externalización.

Un auditor o autoridad centrado en NIS2 comprobará si la entidad puede identificar incidentes significativos, cumplir plazos escalonados, comunicarse con destinatarios de servicios afectados y aportar evidencias de evaluación de impacto transfronterizo. Conectará la gestión de incidentes con las medidas de gestión de riesgos de Article 21, incluidas continuidad de negocio, gestión de crisis, seguridad de la cadena de suministro, control de acceso, gestión de activos y formación.

Un DPO o una autoridad de control GDPR examinará si la organización identificó datos personales, roles, interesados, categorías, sistemas afectados, tipo de brecha y riesgo para las personas. Comprobará si el responsable del tratamiento puede demostrar responsabilidad proactiva y si las notificaciones de encargados del tratamiento a responsables fueron oportunas y completas.

Un auditor con enfoque ISACA o COBIT 2019 se centrará en las evidencias de gobierno. ¿Quién aprobó la taxonomía de severidad? ¿Quién es propietario del riesgo? ¿Qué métricas se reportan a la dirección? ¿Cómo se gestionan las excepciones? ¿Cómo se convierten las lecciones aprendidas en mejoras de control?

Patrones habituales de fallo en la clasificación de incidentes

El primer fallo es pensar en una sola etiqueta. Los equipos clasifican un evento como alto, medio o bajo, pero nunca evalúan por separado los desencadenantes de DORA, NIS2 y GDPR. El resultado es una etiqueta de severidad que no puede explicar una decisión de notificación.

El segundo fallo es el sesgo de brecha confirmada. Los equipos esperan una prueba absoluta de exfiltración antes de involucrar a privacidad o legal. La evaluación de brecha GDPR a menudo empieza con un posible acceso no autorizado, pérdida, alteración o divulgación, no solo con la publicación confirmada de datos.

El tercer fallo es la confusión del reloj. Los plazos de NIS2 y GDPR dependen de la toma de conocimiento y la evaluación. Si el ticket de incidente no captura la hora de toma de conocimiento, la hora de clasificación y la hora de escalado, la organización puede tener dificultades para demostrar la puntualidad.

El cuarto fallo es la investigación forense después de la limpieza. Los ingenieros rotan claves, reconstruyen hosts y eliminan evidencias temporales antes de activar la postura investigadora. Esto puede destruir pruebas necesarias para la revisión regulatoria, contractual o legal.

El quinto fallo es la ceguera frente a proveedores. DORA, NIS2 y NIST CSF 2.0 enfatizan el riesgo de terceros y de la cadena de suministro. Si un proveedor de servicios en la nube, un proveedor de servicios gestionados, un procesador de pagos, un proveedor de identidad o un proveedor SaaS forma parte de la cadena del incidente, el modelo de clasificación debe incluir el impacto del proveedor y las obligaciones contractuales de notificación.

Una lista de verificación de implementación de Clarysec para 2026

Para operacionalizar un modelo defendible de clasificación de severidad de incidentes, Clarysec recomienda esta secuencia:

1. Confirmar la aplicabilidad regulatoria en DORA, NIS2, GDPR, contratos con clientes y normas sectoriales.
2. Actualizar el alcance del SGSI y los requisitos de partes interesadas conforme a ISO/IEC 27001:2022.
3. Definir niveles internos de severidad con umbrales medibles para indisponibilidad, datos, clientes, geografía, pérdidas financieras y criticidad.
4. Añadir preguntas de análisis separadas para DORA, NIS2 y GDPR al flujo de trabajo del ticket de incidente.
5. Definir desencadenantes de escalado para el responsable del incidente, el DPO, asesoría jurídica, la alta dirección y el consejo de administración.
6. Crear una plantilla de registro de decisión de severidad.
7. Vincular la clasificación con los procedimientos de recopilación de evidencias y cadena de custodia.
8. Validar la cobertura de registro para eventos de identidad, nube, aplicación, base de datos, red y proveedor.
9. Ejecutar ejercicios de mesa para escenarios de incidente grave DORA, incidente significativo NIS2 y brecha GDPR.
10. Incorporar las lecciones aprendidas al tratamiento de riesgos, la declaración de aplicabilidad, la formación y las pruebas de resiliencia.

Zenith Blueprint, en la fase Controls in Action, Step 16, refuerza el lado humano de este modelo: los informes deben registrarse, triarse, escalarse a través del plan de respuesta a incidentes, e incluso los eventos menores deben seguirse porque las tendencias revelan debilidades de control. Promueve una mentalidad de notificación con umbral bajo: “En caso de duda, notifíquelo”.

Este punto cultural es crítico. Un modelo de severidad falla si los empleados retrasan la notificación por miedo a una reacción excesiva. El objetivo es notificación rápida, triaje disciplinado y clasificación defendible.

Convertir la incertidumbre del incidente en evidencias preparadas para auditoría

En 2026, la clasificación de severidad de incidentes ya no es una decisión exclusiva del SOC. Es un proceso de gobierno regulado que debe conectar los criterios de incidente grave relacionado con las TIC de DORA, los umbrales de incidente significativo de NIS2, el riesgo de brecha de GDPR y las evidencias de ISO/IEC 27001:2022.

Las organizaciones que mejor actúan durante los incidentes no serán las que tengan la carpeta de respuesta más gruesa. Serán las que puedan responder rápidamente a cuatro preguntas y demostrar cada respuesta posteriormente:

• ¿Qué ocurrió?
• ¿Qué severidad tiene?
• ¿Qué obligaciones regulatorias pueden aplicar?
• ¿Qué evidencias respaldan la decisión?

Clarysec ayuda a las organizaciones a construir ese puente mediante plantillas de políticas, taxonomías de severidad, registros de decisión, escenarios de mesa y mapeos de cumplimiento transversal. Empiece por las políticas de incidentes, valide sus criterios de riesgo en Zenith Blueprint Zenith Blueprint y utilice Zenith Controls Zenith Controls para mapear los controles 5.24, 5.25, 5.26, 5.27 y 5.28 de ISO/IEC 27002:2022 con DORA, NIS2, GDPR, NIST CSF y expectativas de auditoría.

Si su equipo no puede responder “¿Es esto un incidente grave DORA, un incidente significativo NIS2 o notificable bajo GDPR?” dentro de la primera hora, el siguiente paso no es otro plan de respuesta a incidentes genérico. El siguiente paso es un modelo operativo defendible de clasificación de severidad de incidentes, probado antes de que llegue la próxima llamada de las 02:17.

¿Listo para sustituir el pánico por proceso? Descargue las plantillas de políticas de respuesta a incidentes y recopilación de evidencias de Clarysec, revise su taxonomía de severidad actual frente a Zenith Blueprint o solicite una evaluación de preparación de Clarysec para construir un modelo de clasificación de incidentes DORA, NIS2, GDPR e ISO/IEC 27001 preparado para auditoría.