TEDAE y la Ciberseguridad: Estrategias para Amenazas Híbridas

La ciberseguridad se ha llenado de palabras grandilocuentes. “Híbrido” es una de ellas. El problema no es el término; el problema es usarlo como comodín para decir mucho y concretar poco. Cuando una organización se enfrenta a campañas que mezclan disrupción técnica, presión reputacional y dependencia de terceros, lo relevante no es recitar una definición solemne, sino entender qué exige eso a sus controles, a su gobierno y a su capacidad de respuesta.

Ahí es donde demasiados artículos se descarrilan. Saltan de una etiqueta geopolítica a una lista de normas europeas, meten dos o tres referencias legales cogidas con pinzas y concluyen que “hay que reforzar la resiliencia”. Gracias, Sherlock. La cuestión útil es otra: qué piezas regulatorias sí encajan de verdad cuando una empresa quiere traducir esa presión difusa en obligaciones concretas y decisiones operativas defendibles ante auditoría, supervisor o consejo.

La respuesta corta es incómoda: no existe un artículo mágico que resuelva el problema. Existe, más bien, un mosaico. En el sector financiero, DORA obliga a ordenar el caos con un marco de gestión del riesgo TIC, pruebas, gobernanza y control de terceros. En sectores esenciales y importantes, NIS2 empuja hacia medidas técnicas, operativas y organizativas, además de un régimen de notificación de incidentes. Y en cualquier tratamiento de datos personales, el GDPR sigue ahí recordando que la seguridad no es una promesa de marketing, sino una obligación jurídica vinculada al riesgo.

La palabra “resiliencia” sirve de poco si no bajas al artículo

Si quieres hablar en serio de resiliencia operativa en finanzas, conviene dejar de lanzar referencias al azar. DORA no se resume bien con una apelación genérica a un artículo suelto mal citado; se entiende mejor como un sistema. El reglamento fija requisitos de gobernanza y gestión del riesgo TIC en sus artículos 5 a 16, trata la notificación y gestión de incidentes en los artículos 17 a 23, regula las pruebas de resiliencia en los artículos 24 a 27 y dedica los artículos 28 a 30 a la gestión del riesgo derivado de terceros prestadores de servicios TIC.

Ese último bloque, DORA art. 28 en particular, importa mucho más de lo que muchas entidades admiten en público. No porque convierta mágicamente la continuidad de negocio o la protección de datos de clientes en una cláusula contractual resuelta, sino porque obliga a gestionar el riesgo de dependencia de proveedores TIC con bastante más disciplina de la que era habitual. Inventariar contratos, identificar funciones soportadas, evaluar concentración y salida, y revisar derechos de acceso, auditoría e inspección: ahí empieza la resiliencia de verdad. Lo demás son PowerPoints con flechas.

También conviene no atribuir a DORA obligaciones que el texto no formula en esos términos. Si una entidad quiere sostener que sus controles técnicos responden al reglamento, tiene más sentido anclarse en el marco de gestión del riesgo TIC y en la lógica de protección, detección, respuesta y recuperación que atraviesa el texto, en lugar de citar artículos equivocados y esperar que nadie lo compruebe. Mala estrategia. Los supervisores sí lo comprueban.

El error habitual con NIS2: convertir la notificación en toda la historia

Con NIS2 pasa algo parecido. Se cita mucho y se lee menos. La directiva no es solo un régimen de comunicación de incidentes, aunque esa parte sea la más visible porque tiene reloj. El núcleo está en el artículo 21, que obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que amenacen la seguridad de las redes y sistemas de información. El propio artículo enumera materias concretas: análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de la eficacia de las medidas y prácticas básicas de ciberhigiene, entre otras.

Eso importa porque permite hablar con precisión. Si una empresa energética, de transporte, salud o telecomunicaciones quiere justificar un programa de refuerzo, el anclaje correcto no es atribuir a NIS2 un mandato específico sobre sistemas de control industrial que no estás citando bien, ni presentar el artículo 23 como si toda la directiva cupiera en un plazo simplificado. El punto defensable es este: NIS2 obliga a gestionar riesgos de ciberseguridad con medidas proporcionadas, y entre esas medidas están la continuidad, la cadena de suministro y la gestión de incidentes. Ahí sí hay base.

Respecto a la notificación, el matiz legal no es menor. El artículo 23 establece una secuencia escalonada para incidentes significativos, no una fórmula reducida de “todo en 24 horas”. La directiva prevé una alerta temprana sin dilación indebida y, cuando proceda, dentro de 24 horas desde que la entidad tenga conocimiento del incidente significativo; después exige una notificación de incidente y más tarde un informe final. Reducirlo a una única obligación lineal es cómodo, pero incorrecto. Y cuando los equipos legales empiezan a corregir al equipo de seguridad en mitad de una crisis, el tiempo se pierde en discusiones que ya deberían haber estado cerradas.

GDPR sigue siendo relevante, pero no como comodín sectorial

Otro reflejo muy extendido consiste en arrastrar el GDPR a cualquier conversación de ciberseguridad y usar el artículo 32 como sello de autoridad universal. El artículo 32, correctamente citado, exige aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, incluyendo, entre otras, seudonimización y cifrado cuando proceda, capacidad de asegurar confidencialidad, integridad, disponibilidad y resiliencia, y procesos para verificar y evaluar la eficacia de las medidas.

Eso es útil. Lo que no conviene hacer es convertirlo en un mandato sectorial específico para el financiero o cualquier otro sector cuando el argumento no lo necesita. El GDPR aplica al tratamiento de datos personales, no a la ciberseguridad corporativa en abstracto. Si un banco sufre una intrusión en un sistema que trata datos personales, el artículo 32 entra en juego. Si además hay una brecha de datos personales, aparecen los artículos 33 y 34 sobre notificación a la autoridad y, en su caso, comunicación a los interesados. Pero si estás analizando continuidad operativa, dependencia tecnológica o pruebas de resiliencia, DORA ofrece un encaje mucho más directo.

La mala costumbre de mezclar normas sin delimitar su objeto produce programas inflados y controles mal asignados. Un mismo incidente puede activar DORA, NIS2 y GDPR, sí. Lo decisivo es saber qué obligación nace de cada una. Si no haces esa cartografía desde el principio, acabas pidiendo a un delegado de protección de datos que resuelva un problema de concentración de proveedores o a un responsable de continuidad que interprete un régimen de brechas personales. No suele acabar fino.

El papel del consejo importa más que el organigrama ideal

En muchos textos de compliance aparece una figura recurrente: el CISO heroico que lidera todo, alinea la organización con marcos internacionales y baja del monte con una estrategia cerrada. Suena bien. Jurídicamente, se sostiene peor si lo presentas como obligación general sin base concreta. La realidad regulatoria europea reciente va en otra dirección: refuerza la responsabilidad del órgano de dirección y exige que la gobernanza del riesgo tecnológico no quede encapsulada en un silo técnico.

DORA es bastante claro en esto. El artículo 5 atribuye al órgano de dirección la responsabilidad última de definir, aprobar, supervisar y asumir la responsabilidad por la aplicación del marco de gestión del riesgo TIC. Traducido: el consejo no puede fingir que esto “lo lleva tecnología”. Puede delegar ejecución, no la rendición de cuentas. NIS2 también aprieta por esa vía. El artículo 20 impone a los órganos de dirección la aprobación de las medidas de gestión del riesgo de ciberseguridad y la supervisión de su aplicación, además de exigir formación. Esto no elimina el papel del CISO; lo coloca donde debe estar: como pieza crítica de ejecución y asesoramiento, no como parapeto perfecto para el resto de la organización.

La consecuencia práctica es menos glamourosa y más útil. Si tu programa de resiliencia depende de una persona concreta y no de una estructura de decisiones, presupuestos, escalado y priorización respaldada por la alta dirección, tienes un problema de gobernanza antes incluso de tener un problema técnico.

Terceros, concentración y esa dependencia que nadie quiere llamar dependencia

Una de las contradicciones más interesantes del momento regulatorio es que casi todas las empresas dicen tener más visibilidad sobre sus proveedores críticos, pero pocas pueden demostrarla de forma consistente cuando se les pide bajar al servicio, al subencargado, a la ubicación del dato o al plan de salida. Ahí DORA vuelve a ser incómodamente específico.

Los artículos 28 a 30 no convierten la gestión de terceros en un anexo aburrido del procurement. La llevan al corazón de la resiliencia operativa. Exigen una estrategia sobre riesgo de terceros TIC, mantenimiento de un registro de información relativo a los acuerdos contractuales, evaluación del uso de servicios que soportan funciones críticas o importantes y cláusulas contractuales concretas. El mensaje de fondo es bastante evidente: no puedes externalizar una función crítica y luego actuar sorprendido cuando descubres que el proveedor clave depende, a su vez, de otra capa de proveedores que nunca evaluaste con seriedad.

NIS2 llega al mismo problema por otra puerta. El artículo 21 incluye expresamente la seguridad de la cadena de suministro y las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios. No dice exactamente lo mismo que DORA, ni con el mismo nivel de detalle financiero, pero empuja en la misma dirección regulatoria: el perímetro real del riesgo ya no acaba en tu CPD ni en tu nube principal. Termina donde termina tu dependencia operativa, contractual y técnica. Y eso suele estar bastante más lejos de lo que el mapa oficial sugiere.

ISO y marcos voluntarios: utiles, pero no los cites como si fueran ley ni al azar

Otro tropiezo habitual consiste en invocar ISO/IEC 27001 o marcos como NIST CSF como si cualquier referencia numérica sonara automáticamente rigurosa. No funciona así. Si no vas a citar con precisión el control correcto, mejor no improvises. Atribuir a un apartado equivocado controles de acceso o gestión de activos no solo resta credibilidad; demuestra que probablemente nadie ha hecho el trabajo de mapeo serio entre controles internos, certificaciones y obligaciones regulatorias.

Eso no significa que esos marcos no sirvan. Sirven mucho. ISO/IEC 27001 puede proporcionar estructura documental, asignación de controles y disciplina de mejora continua. NIST CSF puede ayudar a ordenar capacidades en torno a funciones y resultados. Pero, en un análisis jurídico-operativo, hay que colocarlos donde toca: como herramientas de implementación o evidencia de madurez, no como sustitutos automáticos del mandato legal ni como referencias ornamentales para rellenar párrafos.

La pregunta útil para el lector no es si su organización “está alineada” con un marco famoso. La pregunta útil es si puede demostrar qué control concreto responde a qué obligación concreta, con qué evidencia, bajo qué responsable y con qué frecuencia de revisión. Si no puedes contestar eso, la alineación es estética.

Qué hacer con el ruido regulatorio cuando diriges un programa real

La tentación de responder al alud normativo con una gran matriz universal es comprensible. También es una trampa si la matriz sustituye a las decisiones. Un programa serio debería empezar por tres mapas que casi nunca están suficientemente afinados.

Primero, un mapa de obligaciones por régimen jurídico. DORA para riesgo TIC, incidentes, pruebas y terceros en entidades financieras. NIS2 para medidas de gestión del riesgo y notificación de incidentes en entidades esenciales e importantes. GDPR para seguridad del tratamiento y brechas de datos personales cuando haya datos personales afectados. Separar esto evita duplicidades y discusiones bizantinas en mitad de un incidente.

Segundo, un mapa de dependencias operativas. No basta con listar proveedores. Hay que identificar qué servicios soportan funciones críticas o importantes, qué concentración existe, qué alternativas reales de salida hay y qué evidencias contractuales sostienen tu capacidad de auditoría, acceso y terminación. DORA art. 28 no pide fe; pide control verificable.

Tercero, un mapa de gobierno. Quién aprueba, quién ejecuta, quién informa, quién decide cuándo un incidente escala, quién coordina la notificación regulatoria y quién mantiene la trazabilidad documental. DORA art. 5 y NIS2 art. 20 dejan poco margen a la ambigüedad confortable.

Si esos tres mapas están hechos, el resto mejora: pruebas más útiles, notificaciones menos caóticas, auditorías menos teatrales. Si no están hechos, cualquier debate sobre resiliencia, amenaza híbrida o madurez cibernética corre el riesgo de quedarse en jerga cara.

La lección de fondo: menos eslóganes, más trazabilidad

La regulación europea reciente no pide a las empresas que adopten una pose épica frente a un entorno incierto. Les pide algo mucho más terrenal: saber qué riesgos tienen, qué sistemas sostienen procesos críticos, de quién dependen, qué controles aplican, cómo prueban su eficacia y cómo reaccionan cuando algo falla. Ese es el terreno donde se gana o se pierde la discusión con el supervisor.

Por eso conviene desconfiar de las piezas que mezclan términos de moda con citas legales imprecisas. El lector profesional no necesita otra oda a la complejidad. Necesita una traducción exacta entre presión externa, obligación jurídica y respuesta operativa. Y esa traducción exige disciplina. Citar bien. Delimitar bien. Priorizar bien.

Lo demás queda estupendo en una keynote. Hasta que llega el incidente, aparece el regulador y alguien pregunta una cosa bastante simple: “¿En qué artículo te apoyaste para decidir esto?”. Si la respuesta es un silencio elegante, la resiliencia no era tan robusta como parecía.