El mandato de ENISA bajo el Cybersecurity Act: dónde empieza la certificación y dónde acaba la falsa tranquilidad

La pregunta útil no es si ENISA tiene más protagonismo. Lo tiene. La pregunta de verdad es otra: qué cambia en tu programa de seguridad y cumplimiento cuando la certificación europea deja de ser una conversación de policy y empieza a condicionar compras, arquitectura, evidencia y contratos.

Ahí está el giro. El Cybersecurity Act no convirtió a ENISA en un regulador con martillo propio, pero sí la colocó en el centro de una maquinaria que en 2026 ya importa bastante más de lo que muchos equipos de seguridad asumían hace dos años. Los esquemas europeos de certificación no son un adorno institucional. Son una pieza de mercado. Y cuando se cruzan con NIS2, con el Cyber Resilience Act y con la presión de procurement en sectores regulados, acaban influyendo en decisiones muy concretas: qué compras, cómo lo justificas, qué pides al proveedor, qué pruebas conservas y qué riesgo residual aceptas de forma explícita.

La ironía es que buena parte del mercado sigue tratando la certificación como un atajo psicológico. Si el producto lleva sello, parece que la discusión termina. No termina. En algunos casos, ni siquiera ha empezado.

El Cybersecurity Act, Reglamento (UE) 2019/881, establece en sus artículos 46 y siguientes el marco europeo de certificación de ciberseguridad. A partir de ahí, ENISA asume funciones técnicas y de coordinación: prepara candidatos a esquemas, mantiene la información asociada a los esquemas aprobados, apoya al European Cybersecurity Certification Group y contribuye a la coherencia del sistema. No es una nota al pie. Es la infraestructura institucional que intenta evitar 27 mini-mercados de confianza digital compitiendo entre sí con sellos incompatibles.

Para un CISO o un responsable de compliance, eso se traduce en una realidad menos glamurosa pero bastante más cara: la certificación europea empieza a convertirse en una variable de diseño del control interno, no solo en una casilla comercial.

Lo que ENISA hace realmente bajo el Cybersecurity Act

Conviene limpiar el ruido. ENISA no certifica productos uno por uno como si fuera una ventanilla única europea. El mecanismo es más sofisticado y, precisamente por eso, más fácil de malinterpretar.

El Cybersecurity Act crea un marco europeo para esquemas de certificación. Los certificados, declaraciones UE de conformidad y procedimientos de evaluación se articulan a través de esquemas aprobados por la Comisión Europea mediante actos de ejecución. ENISA juega un papel central en la cocina técnica de esos esquemas, no como autoridad política final. Esa arquitectura se ve en varias disposiciones clave:

Los artículos 46 a 49 definen el marco europeo, los objetivos de los esquemas y los requisitos generales. El artículo 50 introduce los niveles de aseguramiento basic, substantial y high, una clasificación que parece sencilla hasta que alguien intenta mapearla a su matriz interna de riesgos, a exigencias sectoriales y a adquisiciones complejas de software o servicios cloud. El artículo 51 entra en el contenido de los esquemas europeos. Los artículos 53 y siguientes desarrollan conformidad, certificados y supervisión. Y el artículo 58 aterriza el papel del European Cybersecurity Certification Group, donde las autoridades nacionales coordinan criterios y práctica.

ENISA, por su parte, aparece con funciones más amplias en el Reglamento, también fuera del capítulo de certificación: apoyo operativo, análisis, cooperación, mantenimiento de conocimiento y asistencia a instituciones y Estados miembros. Pero en certificación su peso es especialmente visible porque sin ENISA no hay continuidad técnica ni memoria institucional. Si mañana un fabricante, un hyperscaler o un proveedor de dispositivos IoT intenta vender “confianza europea” a escala, lo hace sobre una infraestructura normativa y técnica donde ENISA lleva la partitura.

La consecuencia práctica es incómoda para quien esperaba una solución binaria. Un certificado europeo no equivale a “seguro” en abstracto. Equivale a que un producto, servicio o proceso TIC ha sido evaluado conforme a un esquema concreto, con un alcance delimitado, un nivel de aseguramiento determinado y unas condiciones de validez específicas. Lo que queda fuera de alcance sigue siendo problema tuyo. Y créeme: siempre queda algo fuera de alcance.

La gran confusión: certificar un producto no es certificar tu riesgo

Esta distinción es el núcleo del asunto. Sigue habiendo consejos de administración y comités de compras que confunden cuatro cosas distintas: certificación de producto, cumplimiento regulatorio, seguridad operativa y transferibilidad del riesgo. Son primas hermanas, no gemelas.

El Cybersecurity Act organiza mecanismos de confianza sobre productos, servicios y procesos TIC. NIS2, en cambio, impone medidas de gestión de riesgos de ciberseguridad a entidades esenciales e importantes. Eso está en el artículo 21 de la Directiva (UE) 2022/2555: 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 medidas y prácticas básicas de ciberhigiene, entre otras. Ninguna de esas obligaciones desaparece porque un proveedor exhiba un certificado bonito en su web.

De hecho, NIS2 va justo en la dirección contraria: obliga a mirar la realidad operacional, no solo los papeles. El artículo 21.2.d habla de seguridad de la cadena de suministro, incluyendo aspectos relativos a las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios. El artículo 21.2.e se mete en seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades. Ahí el certificado puede ayudar. Sustituir el análisis, no.

Con el Cyber Resilience Act la presión se intensifica. El CRA, publicado como Reglamento (UE) 2024/2847, introduce requisitos horizontales para productos con elementos digitales a lo largo del ciclo de vida. Incluye obligaciones sobre diseño seguro, gestión de vulnerabilidades, documentación técnica, tratamiento de fallos explotados y notificación de incidentes activamente explotados y vulnerabilidades explotadas. En 2026, ya no estamos discutiendo si el CRA cambiará procurement. Lo está cambiando. Porque obliga al fabricante, sí, pero también empuja al comprador profesional a pedir pruebas más serias de seguridad desde la fase de selección y homologación.

El resultado de combinar estas piezas es claro: la certificación europea gana valor como evidencia, pero pierde cualquier pretensión razonable de ser un sustituto del gobierno del riesgo.

Por qué el papel reforzado de ENISA importa más ahora que en 2024 o 2025

En 2026 el contexto ya no es el de una promesa regulatoria. Es el de una convergencia lenta, burocrática a ratos, pero bastante tangible entre tres vectores.

Primero, la Unión Europea ha pasado de regular “la ciberseguridad” como concepto a regular responsabilidades distribuidas: operador, fabricante, proveedor cloud, entidad financiera, administración pública, organismo de certificación. Cada uno con su trozo de culpa. Eso crea demanda de lenguaje común. ENISA, a través de los esquemas y de su papel técnico, ayuda precisamente a eso.

Segundo, la presión sobre la cadena de suministro ya no se limita a TPRM clásico. NIS2 endurece expectativas sobre proveedores; DORA, para el sector financiero, entra de lleno en el riesgo de terceros TIC, especialmente en sus artículos 28 a 30; y el CRA afecta al propio diseño y mantenimiento de productos digitales puestos en el mercado. La certificación encaja aquí como una especie de capa intermedia: no elimina el riesgo de terceros, pero reduce asimetrías de información si el esquema está bien definido y si el alcance del certificado es relevante.

Tercero, el mercado está agotado de promesas autodeclarativas. Cualquiera puede publicar un white paper de seguridad de 40 páginas. Lo difícil es someter un producto o un servicio a un esquema europeo con criterios definidos, evaluación reconocida y vigilancia posterior cuando proceda. Ahí ENISA importa porque aporta continuidad metodológica en un terreno donde abundan más los folletos que la evidencia comparable.

La paradoja, claro, es que cuanto más madura se vuelve la conversación sobre certificación, más evidente resulta su límite. Un producto certificado puede desplegarse mal. Un servicio bien evaluado puede integrarse de forma desastrosa. Un dispositivo puede salir de fábrica con un perfil aceptable y convertirse en una pesadilla seis meses después si el fabricante gestiona mal vulnerabilidades o si el cliente no parchea. Regulación europea, meet realidad operacional.

EUCC, EUCS y el problema de creer que todos los esquemas sirven para todo

Hablar de “certificación europea” en singular es cómodo, pero técnicamente pobre. Lo que importa son los esquemas concretos, su alcance y su madurez.

Uno de los desarrollos más relevantes del ecosistema ha sido EUCC, el esquema europeo basado en SOG-IS y Common Criteria para productos TIC. Su utilidad es clara en ciertos entornos de alto rigor técnico, especialmente donde la profundidad de evaluación y la tradición de Common Criteria ya eran conocidas. Pero conviene no sobredimensionarlo. EUCC no resuelve por sí solo la seguridad operativa de servicios complejos, ni el gobierno continuo de configuraciones en cloud, ni la higiene de la cadena de desarrollo.

Luego está EUCS, el esquema europeo para servicios cloud, objeto de mucha discusión política y no poca confusión comercial. Aquí el debate no es solo técnico. Es geopolítico, industrial y jurídico. Requisitos sobre soberanía, control, inmunidad frente a legislación extraterritorial o condiciones de operación local han sido el combustible de años de negociación. En la práctica, para CISOs y compliance officers, EUCS interesa por una razón menos ideológica: si acaba consolidándose como referencia de mercado, puede alterar de forma material la evaluación de proveedores cloud para cargas críticas o reguladas.

La lección operativa es sencilla: no metas en el mismo saco un esquema para productos, uno para cloud y futuros esquemas sectoriales o temáticos. Cada uno responde a riesgos, modelos de evaluación y usos regulatorios distintos. Si tu equipo de compras pregunta “¿está certificado por Europa?” sin concretar esquema, nivel, alcance, versión y fecha de validez, la conversación está mal planteada desde el minuto uno.

Los tres niveles de aseguramiento y el error habitual de procurement

El artículo 52 del Cybersecurity Act y la arquitectura de niveles de aseguramiento del marco europeo obligan a una disciplina que muchas organizaciones todavía no han interiorizado. Basic, substantial y high no son medallas decorativas. Son una declaración sobre el grado de confianza en que el producto, servicio o proceso TIC cumple determinados requisitos frente a riesgos y atacantes con capacidades diferentes.

El error más habitual en procurement es doble.

Uno: pedir “el nivel más alto posible” por reflejo político, sin mapear necesidad real, coste, disponibilidad y compatibilidad con el uso previsto. Eso puede retrasar adquisiciones, encarecer proyectos y, en algunos nichos, limitar drásticamente la oferta. No todo requiere high. A veces ni existe una opción realista con ese nivel para la categoría de tecnología que necesitas.

Dos: aceptar un certificado de nivel basic como si cerrara la discusión en entornos donde la exposición, criticidad o dependencia justifican exigencias adicionales. En infraestructuras críticas, servicios financieros esenciales o plataformas que procesan funciones operativas sensibles, ese salto de fe sale caro.

La forma seria de usar estos niveles es integrarlos en una taxonomía interna de criticidad. Si ya trabajas con clasificaciones de activos, impacto de negocio, requisitos de resiliencia o categorías de terceros, traduce esas capas a expectativas mínimas de aseguramiento. No hace falta inventar una religión nueva. Hace falta unir procurement, arquitectura, TPRM, legal y compliance en una matriz que diga, por ejemplo: para herramientas de colaboración internas, X; para EDR o PAM, Y; para componentes embebidos en OT o identidad, Z. Sin ese trabajo previo, la certificación se convierte en teatro administrativo.

NIS2 no te deja esconderte detrás del sello

Aquí merece la pena ser tajante. NIS2 no está diseñada para premiar la pereza intelectual. La directiva exige medidas “apropiadas y proporcionadas” para gestionar riesgos de redes y sistemas de información, y obliga a la alta dirección a aprobar y supervisar esas medidas. Eso aparece en el artículo 20, que hace responsables a los órganos de dirección de aprobar las medidas de gestión del riesgo de ciberseguridad y supervisar su aplicación, además de exigir formación.

Traducido al idioma del comité de dirección: si compras tecnología certificada pero no puedes demostrar cómo esa compra encaja en tu análisis de riesgos, en tu arquitectura de seguridad, en tus medidas de continuidad y en tu control de proveedores, sigues expuesto. Y no solo técnicamente. También desde el punto de vista de gobernanza.

Hay una razón adicional por la que NIS2 y la certificación europea deben leerse juntas. El artículo 24 permite el uso de esquemas europeos de certificación y normas europeas como medios para demostrar conformidad con determinadas exigencias. Eso eleva el valor probatorio de la certificación. Pero “medio para demostrar” no significa “sustitución integral del deber de gestionar”. Si tu autoridad competente pregunta por segregación, monitoreo, respuesta o gestión contractual de terceros, un certificado servirá como pieza del expediente, no como comodín universal.

Los equipos maduros ya lo están entendiendo de otra manera: la certificación se usa como acelerador de diligencia debida, no como renuncia a la diligencia debida.

Con DORA, la discusión se vuelve más incómoda para banca, seguros y fintech

En el sector financiero europeo el impacto es aún más tangible porque DORA ya ha roto la ficción de que el riesgo TIC de terceros se gestiona solo con cuestionarios, anexos contractuales y un Excel con colores. El Reglamento (UE) 2022/2554 es bastante más exigente.

Los artículos 28 a 30 obligan a gestionar el riesgo derivado de terceros prestadores de servicios TIC con una aproximación estructurada: estrategia sobre riesgo de terceros, registro de información, evaluación previa a la contratación, requisitos contractuales, monitorización, planes de salida y, cuando aplica, atención reforzada a proveedores que apoyan funciones críticas o importantes. El artículo 28.2 subraya que las entidades financieras seguirán siendo plenamente responsables del cumplimiento de DORA aunque externalicen servicios TIC. Otra vez la misma música: puedes externalizar la operación, no la responsabilidad.

¿Dónde entra ENISA aquí? No porque DORA diga “compra solo productos certificados europeos”. No lo dice de forma general. Entra porque los esquemas europeos pueden convertirse en evidencia objetivable para soportar la evaluación de terceros, especialmente cuando el mercado financiero necesita comparar ofertas de infraestructura, servicios gestionados, autenticación, identidad, endpoints o componentes críticos con un lenguaje menos subjetivo que el marketing del proveedor.

Además, DORA aprieta donde la certificación suele ser más útil: en el detalle contractual y en la supervisión continuada. Si un proveedor afirma que un servicio o componente está cubierto por un esquema europeo, la entidad debería pedir cuatro precisiones mínimas: el esquema exacto, el alcance técnico evaluado, el nivel de aseguramiento y la fecha o condición de vigencia. Parece obvio. Sorprendentemente, no siempre se pide. Luego vienen las discusiones absurdas cuando se descubre que el certificado cubría un módulo, una versión o una región cloud concreta, pero no la configuración desplegada por la entidad.

Para bancos, aseguradoras y fintech españolas, la combinación DORA + NIS2 + certificación europea empieza a producir un efecto muy concreto: sube el listón de evidencia en compras críticas. No basta con que el proveedor “cumpla”. Hay que demostrar por qué la entidad consideró suficiente ese cumplimiento para el caso de uso y qué controles adicionales mantuvo bajo su propia responsabilidad.

El CRA cambia la conversación con fabricantes, no solo con auditores

Si el Cybersecurity Act ordena el ecosistema de certificación y NIS2 obliga a gestionar el riesgo operativo, el CRA aprieta a los fabricantes donde más les duele: producto, ciclo de vida y vulnerabilidades. Eso altera de forma directa la utilidad estratégica de los esquemas europeos.

El CRA introduce requisitos esenciales de ciberseguridad y gestión de vulnerabilidades para productos con elementos digitales, con anexos técnicos que aterrizan expectativas de diseño, configuración segura por defecto, reducción de superficies de ataque, protección de confidencialidad, integridad, disponibilidad y tratamiento de vulnerabilidades. También impone obligaciones posventa y de soporte, algo que durante años el mercado trató casi como cortesía voluntaria.

La implicación para tu programa es clara. La certificación deja de ser solo una ayuda para validar afirmaciones presentes; también puede convertirse en una señal sobre la madurez futura del fabricante. Un proveedor que entiende el lenguaje de esquemas europeos, requisitos esenciales, SBOM, coordinación de vulnerabilidades y evidencias de conformidad suele estar mejor preparado para convivir con el CRA que otro que sigue vendiendo “security by innovation”, expresión que no significa absolutamente nada cuando un regulador pide documentación técnica.

Eso no garantiza seguridad. Pero sí ofrece una pista útil sobre la capacidad de un fabricante para sobrevivir en un mercado donde la conformidad ya no se improvisa con una política PDF de 18 páginas.

Qué debería cambiar en tu programa, de verdad

Si tu organización sigue tratando la certificación europea como asunto exclusivamente jurídico o institucional, vas tarde. En 2026 el enfoque correcto es transversal y bastante terrenal.

1. Reescribe tu inventario de terceros con una capa de “evidencia certificable”

No me refiero a coleccionar logos. Me refiero a identificar qué proveedores o componentes críticos podrían aportar valor probatorio si cuentan con un esquema europeo aplicable. La pregunta útil no es “quién tiene certificado”, sino “en qué partes de nuestro mapa de dependencia tecnológica un esquema europeo, si existe, reduciría incertidumbre material”.

Ejemplos: módulos criptográficos, identidad y acceso, hardware de red en funciones sensibles, servicios cloud para datos regulados, componentes integrados en entornos OT o productos IoT desplegados a gran escala. Si no haces esta clasificación, acabarás exigiendo certificados donde no aportan gran cosa y renunciando a pedirlos donde sí pueden ahorrarte semanas de evaluación y discusión interna.

2. Mete la certificación en procurement, pero con preguntas correctas

Una RFP madura debería preguntar al proveedor no solo si posee certificaciones, sino qué esquema europeo concreto aplica, qué objeto cubre, con qué nivel de aseguramiento, bajo qué condiciones y con qué exclusiones. También debería pedir cómo se gestiona el cambio: versiones nuevas, actualizaciones mayores, modificaciones de arquitectura, subprocesadores relevantes y mantenimiento de la validez.

Si el proveedor responde con una lista de siglas sin alcance definido, no está respondiendo. Está decorando.

3. Alinea arquitectura de control y alcance del certificado

Este punto evita bastantes disgustos. Si tu diseño operativo depende de funciones que quedan fuera del alcance certificado, necesitas controles compensatorios internos o contractuales. Pensemos en un servicio cloud: el certificado podría cubrir la plataforma base, pero no tu configuración, ni tus claves, ni tus flujos de integración, ni los permisos absurdamente amplios que alguien concedió por prisa.

La disciplina aquí es casi forense: qué cubre el esquema, qué no cubre, qué hacemos nosotros para cerrar ese hueco y quién lo supervisa.

4. Usa la certificación como palanca contractual, no como excusa contractual

En contratos relevantes, sobre todo bajo DORA o NIS2, la entidad debería exigir notificación de cambios que afecten al estado de certificación, a su alcance o a incidentes relacionados con componentes certificados. También conviene vincular compromisos de soporte, divulgación de vulnerabilidades y cooperación en auditorías o evaluaciones regulatorias.

Si el certificado existe pero el contrato no dice nada sobre su mantenimiento, pérdida, modificación o limitaciones, has desaprovechado media utilidad del esquema.

5. Ajusta tu narrativa ante auditoría y supervisor

Una organización madura no presenta el certificado como prueba total de seguridad. Presenta una cadena lógica: criticidad del activo o servicio, criterios de selección, esquema europeo aplicable, alcance evaluado, riesgos residuales identificados, controles complementarios y monitorización continua. Eso convence mucho más que enseñar un sello y esperar que nadie haga preguntas incómodas.

Los límites políticos y técnicos del modelo europeo

Sería ingenuo pintar esto como una maquinaria perfecta. No lo es. El marco europeo de certificación tiene al menos cuatro fricciones estructurales.

La primera es la velocidad. El mercado tecnológico se mueve a ritmo de despliegue continuo; la certificación, a ritmo institucional. A veces esa tensión es inevitable. Otras veces genera una distancia preocupante entre la tecnología realmente usada y la tecnología formalmente evaluada.

La segunda es el alcance. Los esquemas funcionan mejor cuando el objeto evaluado es razonablemente definible. Cuanto más composicional, distribuido y cambiante es el servicio, más difícil resulta encapsular una afirmación de confianza que no envejezca demasiado rápido.

La tercera es la interoperabilidad de expectativas regulatorias. Un mismo proveedor puede enfrentarse a requisitos derivados de NIS2, DORA, CRA, GDPR, eIDAS 2.0 o marcos sectoriales nacionales. La certificación europea ayuda a armonizar, sí, pero no elimina duplicidades ni discusiones sobre suficiencia. Todavía estamos lejos del nirvana de “un esquema, una vez, para todos”.

La cuarta es política. Cualquier esquema que toque cloud, soberanía o dependencia estratégica acaba discutiéndose no solo en clave de seguridad, sino de autonomía europea, competencia y relaciones transatlánticas. Fingir que eso no afecta a la ingeniería regulatoria sería infantil.

Ahora bien, que el modelo tenga fricciones no lo hace irrelevante. Lo hace más interesante. Porque obliga a las organizaciones a pensar con precisión qué esperan de la certificación: ¿comparabilidad? ¿evidencia? ¿facilidad de procurement? ¿soporte a supervisión? ¿señal de madurez del proveedor? Si no respondes eso primero, pedir más esquemas será solo más burocracia cara.

Una tabla útil: dónde encaja la certificación y dónde no

Qué preguntas debería hacer un CISO al ver “certificado por Europa”

Si mañana un proveedor pone esa frase en una presentación comercial, la reacción profesional no debería ser entusiasmo ni cinismo. Debería ser un interrogatorio civilizado.

Primero: ¿qué esquema exacto? No “alineado con ENISA”, no “según estándares europeos”. Esquema exacto.

Segundo: ¿qué objeto está certificado? Producto, servicio, componente, versión, región, tenant model, hardware, software, proceso concreto.

Tercero: ¿qué nivel de aseguramiento? Basic, substantial o high, y por qué ese nivel resulta suficiente o no para tu uso previsto.

Cuarto: ¿qué queda fuera? Integraciones, configuraciones del cliente, subprocesadores, funcionalidades premium, actualizaciones futuras, módulos opcionales. Aquí suele estar la letra pequeña que nadie lee hasta que ya es tarde.

Quinto: ¿cómo se mantiene la validez? Frecuencia de reevaluación, gestión de cambios, impacto de vulnerabilidades críticas, obligaciones de notificación.

Sexto: ¿cómo enlaza esto con nuestras obligaciones regulatorias concretas? NIS2 art. 21, DORA art. 28 y siguientes, CRA para productos con elementos digitales, GDPR art. 32 si hay tratamiento de datos personales en juego. Si no puedes trazar esa relación, el certificado será un adorno caro en el archivo de compliance.

La tentación de usar la certificación como argumento de marketing regulatorio

Este riesgo va a crecer. Cuanto más valor tenga la certificación europea, más la verás convertida en eslogan. “Trusted in Europe”. “EU-certified security”. “Built for sovereignty”. Algunas afirmaciones serán razonables. Otras rozarán la prestidigitación comercial.

Tu defensa aquí es documental. Pide certificados, informes resumidos si existen, declaraciones UE de conformidad cuando apliquen, alcance, organismo de evaluación y condiciones. Si el proveedor no puede sostener con papeles lo que proclama con branding, ya tienes una señal de gobierno bastante elocuente.

También conviene vigilar un fenómeno menos obvio: la confusión deliberada entre certificaciones privadas y esquemas europeos. ISO/IEC 27001, SOC 2, PCI DSS, Common Criteria tradicional o atestaciones nacionales pueden ser útiles, a veces mucho. Pero no son intercambiables con un esquema europeo aprobado bajo el Cybersecurity Act. Mezclarlos como si fueran equivalentes es una forma elegante de no responder a la pregunta original.

Qué deberían hacer ahora los equipos de cumplimiento y seguridad

Sin recurrir al típico fetiche temporal de consultoría, hay varias decisiones que sí merecen ponerse encima de la mesa este año.

La primera es revisar el modelo interno de evidencia. Si tu repositorio de cumplimiento no distingue entre certificaciones europeas, certificaciones privadas, atestaciones contractuales y controles propios, estás mezclando categorías que tienen valor probatorio distinto. Ordénalo.

La segunda es actualizar políticas de compras y gestión de terceros para introducir lenguaje específico sobre esquemas europeos aplicables, alcance, nivel de aseguramiento y notificación de cambios. No hace falta reescribir 80 procedimientos. Hace falta tocar los puntos donde una mala pregunta produce una mala contratación.

La tercera es formar a quienes toman decisiones presupuestarias y contractuales. El órgano de dirección bajo NIS2 art. 20 no necesita convertirse en experto en Common Criteria ni en cloud assurance. Sí necesita entender por qué un certificado sirve como evidencia útil y por qué no exonera de supervisión. Esa diferencia separa a una organización madura de otra que está coleccionando sellos por ansiedad reputacional.

La cuarta es mapear tu exposición regulatoria cruzada. Si eres entidad financiera, DORA manda en terceros TIC. Si eres operador o proveedor cubierto por NIS2, el foco está en medidas de gestión de riesgos y notificación. Si fabricas o integras productos con elementos digitales, el CRA entra en escena. ENISA no sustituye ninguno de esos marcos; ayuda a articular un lenguaje técnico común entre ellos.

La quinta, quizá la más útil, es asumir una verdad poco vistosa: la certificación europea tiene más valor cuanto más sobrio sea tu uso de ella. Úsala para reducir incertidumbre, no para fingir certeza absoluta.

La conclusión incómoda: ENISA importa más, pero no te va a ahorrar el trabajo duro

El mandato de ENISA bajo el Cybersecurity Act se ha vuelto más relevante porque Europa ha decidido regular la ciberseguridad con mayor densidad, más actores y menos tolerancia hacia las promesas vagas. Los esquemas europeos de certificación son parte de esa respuesta. Ordenan, comparan, elevan el nivel de evidencia y, si se usan bien, mejoran procurement, supervisión y diálogo regulatorio.

Lo que no hacen es milagros.

No convierten un mal despliegue en buen despliegue. No arreglan una arquitectura torpe. No sustituyen las obligaciones de NIS2 en su artículo 21, ni las de DORA sobre terceros TIC en sus artículos 28 a 30, ni las exigencias de producto y vulnerabilidades del CRA. Y desde luego no absuelven a la dirección de su deber de supervisar.

Si quieres una fórmula simple, aquí la tienes: ENISA pone orden en la gramática de la confianza europea; tu organización sigue siendo responsable de escribir la frase completa.

Ese es el punto que importa en 2026. Y también el que más cuesta aceptar, porque implica trabajo real: clasificar, preguntar mejor, contratar mejor, evidenciar mejor y gobernar mejor. Todo lo demás es merchandising regulatorio con acento europeo.