ENISA ya no es un actor decorativo: así condiciona tu programa de certificación bajo el Cybersecurity Act

La pregunta útil no es si conoces a ENISA. La pregunta útil es si tu programa de seguridad ya asume que ENISA puede acabar influyendo en qué compras, qué desarrollas y cómo demuestras diligencia ante reguladores y clientes. Si la respuesta es no, vas con retraso.

Durante años, mucha organización trató la certificación europea de ciberseguridad como una promesa elegante de Bruselas: técnicamente interesante, comercialmente lejana y operativamente prescindible. En 2026 esa lectura ya se ha quedado vieja. El Reglamento (UE) 2019/881, el Cybersecurity Act, dio a ENISA un mandato formal y bastante menos ornamental de lo que parecía al principio. Los artículos 46 y siguientes crean el marco europeo de certificación de ciberseguridad; ENISA no emite certificados a productos concretos, pero sí está en el centro del diseño del sistema, de la preparación de esquemas candidatos, del mantenimiento técnico y del funcionamiento práctico de un mercado que la Unión quiere menos caótico.

Eso importa por tres motivos. Primero, porque NIS2 empuja a justificar medidas de gestión del riesgo con más trazabilidad de la que muchas empresas estaban acostumbradas a dar. Segundo, porque el Cyber Resilience Act convierte la seguridad de productos con elementos digitales en un asunto de diseño, documentación y conformidad, no solo de buenas intenciones. Y tercero, porque las compras corporativas y públicas empiezan a usar la certificación como atajo de confianza. A veces como prueba suficiente. Más a menudo como filtro de entrada. Y ahí es donde muchos CISOs descubren que el “ya veremos” sale caro.

Esta pieza no resume la web de ENISA. Intenta responder a algo más incómodo: qué cambia de verdad para un CISO, un responsable de cumplimiento o un equipo de procurement cuando el mandato de ENISA sobre certificación deja de ser un tema institucional y empieza a tocar el programa operativo.

El punto de partida: qué hace realmente ENISA bajo el Cybersecurity Act

El corazón jurídico está en el Título III del Cybersecurity Act, artículos 46 a 65. El artículo 46 establece el marco europeo para esquemas de certificación de ciberseguridad. El objetivo no es menor: crear esquemas de la UE para certificar que productos TIC, servicios TIC y procesos TIC cumplen requisitos específicos de ciberseguridad. Traducido al castellano llano: la Unión intenta evitar que cada Estado, cada sector y cada gran comprador jueguen a inventarse su propio sello.

ENISA entra de lleno en ese engranaje. El artículo 47 crea el European Cybersecurity Certification Group, compuesto por autoridades nacionales de certificación. El artículo 48 crea el Stakeholder Cybersecurity Certification Group, para canalizar la visión de industria, consumidores, organismos de evaluación y academia. ENISA actúa como secretaría y soporte técnico de ambos. Esto, por sí solo, no impresiona a un CISO curtido: todos hemos visto grupos de trabajo que producen más actas que impacto. Lo relevante está en el artículo 49, que atribuye a ENISA la preparación de esquemas candidatos de certificación europea cuando la Comisión se lo pida, además de evaluar y mantener la documentación relativa a esquemas existentes.

Es decir: ENISA no es “el regulador que certifica tu producto”, pero sí el actor que ayuda a definir el molde técnico que después condiciona qué se certifica, con qué nivel de aseguramiento, bajo qué metodología y con qué vocabulario común. En regulación europea, quien define el molde suele influir más de lo que aparenta.

La arquitectura del Reglamento tiene otra pieza clave: los niveles de aseguramiento “basic”, “substantial” y “high”, previstos en el artículo 52. No son adjetivos de marketing. Cada nivel expresa el grado de confianza en que el producto, servicio o proceso cumple los requisitos del esquema y resiste frente a actores y capacidades distintas. La diferencia entre vender algo “certificado” y vender algo “certificado a nivel high” no es semántica: puede afectar a la admisibilidad en ciertos entornos, al coste de evaluación, al ciclo de desarrollo y al tipo de evidencias que tendrás que conservar.

Además, el artículo 53 prevé que los esquemas indiquen si la conformidad puede basarse en autoevaluación o requiere evaluación por un organismo de evaluación de la conformidad. Aquí está una de las grandes tensiones del sistema: Bruselas quiere escalar la confianza sin bloquear el mercado; la industria quiere proporcionalidad; los compradores quieren garantías; y seguridad, como de costumbre, no regala nada. Cuando una empresa oye “autoevaluación” y piensa “barra libre”, suele empezar mal.

El error más común: tratar la certificación como un sello comercial y no como una capa de gobernanza

Muchas compañías siguen mirando la certificación europea con una lógica heredada de ISO 27001 o de certificaciones de producto orientadas a ventas: conseguir el sello, responder RFPs y seguir con la vida. El problema es que el ecosistema que rodea al Cybersecurity Act no va por ahí. La certificación, bien leída, es una capa de gobernanza sobre cuatro decisiones que antes se tomaban con demasiada improvisación: qué riesgo aceptas, qué pruebas exiges a terceros, qué documentación mantienes y quién firma la responsabilidad cuando algo falla.

Un ejemplo práctico. Tu equipo de compras adquiere un servicio cloud o un dispositivo conectado para una función crítica. Antes, bastaba con un cuestionario de seguridad, alguna cláusula contractual y la promesa del proveedor de que “cumple estándares internacionales”. Ahora pregúntate algo más concreto: si mañana un supervisor, un auditor interno o un cliente institucional te pide explicar por qué consideraste ese proveedor apto, ¿puedes vincular la decisión a un esquema europeo reconocido, a un nivel de aseguramiento definido y a evidencias verificables? Si no puedes, tu due diligence depende demasiado de presentaciones de PowerPoint y demasiado poco de un marco defendible.

Por eso el papel de ENISA importa incluso a quienes no fabrican tecnología. ENISA ayuda a construir el lenguaje común que usarán fabricantes, evaluadores, autoridades nacionales, compradores públicos y sectores regulados. Ese lenguaje acaba filtrándose a contratos, procesos de homologación, matrices de riesgo y auditorías de terceros. Quien lo ignore acabará descifrando términos a contrarreloj cuando un cliente o una autoridad ya los dé por supuestos.

Qué cambia con NIS2: la certificación no sustituye la gestión del riesgo, pero empieza a pesar en cómo la demuestras

NIS2, la Directiva (UE) 2022/2555, no dice que toda entidad deba comprar solo tecnología certificada. Tampoco convierte la certificación europea en un salvoconducto automático. Quien lea eso está leyendo más deseo que Derecho. Pero sí introduce un marco en el que la certificación puede ganar un valor probatorio y operativo muy serio.

El artículo 21 de NIS2 obliga a las entidades esenciales e importantes a adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información y prevenir o minimizar el impacto de incidentes. La lista incluye análisis de riesgos, gestión de incidentes, continuidad, seguridad en la cadena de suministro, desarrollo y mantenimiento seguros, evaluación de la eficacia de medidas y prácticas básicas de ciberhigiene. A eso súmale el artículo 20 sobre responsabilidad de los órganos de dirección, que eleva el tema desde el SOC hasta el consejo de administración. Ya no es un asunto que puedas aparcar en un anexo técnico.

¿Dónde entra la certificación? En dos lugares. El primero es la cadena de suministro. El artículo 21.2.d de NIS2 menciona expresamente la seguridad de la cadena de suministro, incluidas las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. Si estás evaluando un proveedor crítico, una certificación europea aplicable puede convertirse en una señal fuerte de madurez o, al menos, en una base objetiva para modular pruebas adicionales. No te exime de revisar arquitectura, dependencias, soporte o exposición real. Pero cambia la calidad de la conversación.

El segundo lugar es la demostración de diligencia. NIS2 no premia el teatro documental; premia, en teoría, la capacidad de probar que el riesgo se ha tratado de forma proporcionada. Un esquema de certificación europeo bien alineado puede ayudarte a demostrar que una decisión de compra o de integración no se apoyó solo en declaraciones unilaterales del proveedor. Dicho de otra forma: no sustituye tu análisis, pero sí puede reforzarlo ante terceros.

La ironía regulatoria aquí es deliciosa. Durante años, media industria criticó la proliferación de cuestionarios de seguridad porque cada cliente preguntaba lo mismo con formato distinto. Bruselas responde creando un lenguaje más estructurado de certificación. Y ahora algunas empresas descubren que ese lenguaje les exige más disciplina interna de la que tenían. Resulta que estandarizar no siempre significa simplificar.

Qué cambia con el Cyber Resilience Act: del “producto seguro” como promesa al “producto conforme” como obligación

Si NIS2 empuja desde la gestión del riesgo empresarial, el Cyber Resilience Act empuja desde el producto. El CRA, Reglamento (UE) 2024/2847, ya forma parte del tablero que un CISO y un responsable de cumplimiento deben leer juntos. Su lógica no es idéntica a la del Cybersecurity Act, pero ambas convergen más de lo que parece.

El CRA impone requisitos horizontales de ciberseguridad para productos con elementos digitales a lo largo de su ciclo de vida, con obligaciones para fabricantes, importadores y distribuidores. La pieza crítica para entender el vínculo con ENISA y la certificación europea es que el mercado europeo se mueve hacia un modelo de seguridad demostrable, documentada y trazable. No basta con decir que el producto se diseñó “siguiendo buenas prácticas”; hay que poder probar requisitos esenciales, gestión de vulnerabilidades, actualizaciones, documentación técnica y procedimientos de evaluación de conformidad.

En la práctica, la certificación europea bajo el Cybersecurity Act puede operar de tres maneras frente al CRA. La primera, como complemento de confianza comercial. La segunda, como fuente de alineamiento técnico: un esquema de certificación puede anticipar expectativas que luego resultan muy útiles para estructurar documentación y controles bajo CRA. La tercera, potencialmente, como mecanismo que en determinados contextos sirva para apoyar presunciones de conformidad o facilitar evaluaciones, dependiendo de cómo evolucionen los esquemas y actos de ejecución aplicables. Aquí conviene ser precisos: no toda certificación europea implica automáticamente conformidad con el CRA, ni el CRA convierte todo esquema de certificación en una llave maestra. Pero ignorar la convergencia sería torpe.

Para fabricantes y proveedores SaaS europeos, la consecuencia operativa es nítida: el equipo de producto, el equipo de seguridad y el equipo legal ya no pueden trabajar como departamentos vecinos que se saludan en Navidad. Si tu programa de secure development lifecycle no está mapeado contra requisitos de conformidad y evidencias de certificación potencialmente exigibles, llegarás tarde a ambos frentes.

Los esquemas importan más que el marco general: aquí se gana o se pierde el partido

Decir “cumplimos el Cybersecurity Act” carece de utilidad práctica si no aterrizas en esquemas concretos. El Reglamento crea el marco. Los esquemas determinan la vida real. ENISA, precisamente, gana relevancia porque participa en la cocina técnica donde se define esa vida real.

El ejemplo más conocido sigue siendo EUCC, el esquema europeo de certificación de ciberseguridad basado en Common Criteria. Su lógica encaja especialmente con productos TIC donde la evaluación técnica de seguridad del producto tiene tradición, profundidad metodológica y costes significativos. Para algunos fabricantes, EUCC es una evolución natural. Para otros, es una lección cara sobre lo que pasa cuando desarrollo, documentación y pruebas no se diseñaron pensando en certificación.

También han estado en el radar esquemas orientados a cloud y a otros ámbitos específicos. No todos avanzan al mismo ritmo, y no todos tendrán la misma adopción sectorial. Pero el mensaje de fondo no cambia: la certificación europea no se va a mover como una sola ola uniforme. Se moverá por familias de producto y servicio, por casos de uso y por presión de mercado. El CISO que espere a que “todo esté claro” probablemente aterrizará cuando compras ya haya firmado exigencias que seguridad no ayudó a redactar.

Aquí aparece un matiz que a menudo se pasa por alto. Los esquemas no solo afectan al vendor que quiere vender. También afectan al comprador sofisticado, porque condicionan qué preguntas tiene sentido hacer y cuáles son simple ruido burocrático. Si un esquema ya exige cierto tipo de pruebas, documentación o garantías, tu cuestionario de terceros debería apoyarse ahí y no reinventar veinte preguntas de baja señal. Eso reduce fricción y aumenta calidad. O debería. Si procurement se empeña en pedir el certificado europeo, tres SOC 2, dos ISO, una lista de CVEs de cinco años y una carta del CEO jurando amor eterno a la seguridad, no estás gestionando riesgo: estás fabricando papel.

Artículo 46 y siguientes: lo que un responsable de cumplimiento debería leer de verdad

Si solo vas a leer una parte del Cybersecurity Act con atención, que sea el bloque del Título III. Hay cuatro piezas especialmente útiles.

El artículo 46 define el objeto del marco. Parece básico, pero delimita algo crucial: productos TIC, servicios TIC y procesos TIC. Esa amplitud importa porque evita la tentación de pensar la certificación solo en clave de hardware o software empaquetado. Hay procesos y servicios cuyo encaje será cada vez más relevante, sobre todo en cadenas de suministro complejas.

El artículo 49, sobre tareas de ENISA en el ámbito de la certificación, merece lectura línea a línea. Ahí se ve que ENISA no está para colgar logos, sino para preparar esquemas candidatos, mantener información pública relativa a esquemas europeos, preparar candidatos a mantenimiento de esquemas y apoyar el funcionamiento consistente del sistema. Si trabajas en compliance, esto te dice algo muy simple: seguir a ENISA ya no es una actividad de “inteligencia institucional”, sino una forma de anticipar requisitos técnicos que pueden aterrizar luego en compromisos de negocio.

El artículo 51 enumera los elementos que deben incluir los esquemas europeos de certificación. Aquí está la munición operativa: alcance, finalidad, categorías de productos/servicios/procesos, requisitos de seguridad, tipo de evaluación, niveles de aseguramiento, reglas de vigilancia, periodo de validez y condiciones de renovación. Si gestionas terceros o si desarrollas producto, este artículo te da la estructura mínima de preguntas que tu organización debería saber responder.

El artículo 52, ya mencionado, define los niveles de aseguramiento. No te quedes en la etiqueta. El nivel condiciona pruebas, costes, tiempos y expectativas del comprador. Para un consejo de administración, “tenemos un producto certificado” puede sonar bien. Para un auditor serio, la pregunta siguiente será “¿a qué nivel y para qué alcance exacto?”.

Y el artículo 54, sobre certificados europeos de ciberseguridad y declaraciones UE de conformidad, merece atención porque toca de lleno el terreno delicado de la autoevaluación. En ciertos casos, los esquemas pueden permitir una declaración UE de conformidad emitida por el fabricante o proveedor. Eso no convierte la seguridad en autopromoción. Convierte la responsabilidad documental y jurídica en algo aún más sensible. Si tu empresa recurre a una declaración de conformidad donde el esquema lo permita, el nivel de disciplina interna que necesitas en expediente técnico, trazabilidad de pruebas y control de cambios sube, no baja.

Para CISOs: tres decisiones que ya no deberías delegar solo en compras o en producto

La primera decisión es qué categorías de tecnología de tu entorno justifican una preferencia explícita por esquemas europeos de certificación, presentes o previsibles. No hace falta reescribir toda la política de adquisiciones para cada portátil o cada herramienta marginal. Sí conviene definir dónde la certificación puede inclinar la balanza: identidades, componentes de acceso remoto, módulos criptográficos, soluciones cloud para cargas sensibles, dispositivos OT conectados, software embebido en operaciones críticas o servicios administrados con acceso privilegiado.

La segunda es cómo integrar la certificación en el third-party risk management sin convertirla en un sustituto perezoso del análisis real. Una certificación relevante puede reducir la necesidad de ciertas preguntas de base, acelerar homologaciones o justificar menor profundidad en controles ya cubiertos por el esquema. Pero no debe ocultar cuestiones que ningún esquema resuelve por sí solo: concentración de proveedor, dependencia geográfica, subcontratación crítica, calidad del soporte, tiempos de parcheo efectivos, capacidad de respuesta a incidentes o encaje contractual con tus obligaciones regulatorias. Un sello no arregla una mala arquitectura ni una dependencia mal gobernada.

La tercera es cómo alinear producto y evidencia. Si tu organización fabrica o integra tecnología, conviene mapear desde ya qué artefactos de desarrollo seguro sirven tanto para certificación como para CRA, NIS2, auditoría interna y due diligence de cliente. Amenazas modeladas, resultados de SAST/DAST, SBOM cuando aplique, gestión de vulnerabilidades, pruebas de penetración, evidencias de firma y build integrity, hardening, documentación de funciones de seguridad y control de cambios. El objetivo no es producir más carpetas; es dejar de producir cuatro veces la misma evidencia con nombres distintos porque cada equipo trabaja de espaldas al otro.

Para cumplimiento: la certificación empieza a ser una cuestión de prueba, no solo de política

El responsable de cumplimiento suele entrar tarde en estas conversaciones, cuando el contrato ya está cerrado o cuando alguien quiere usar una certificación en marketing. Error clásico. Bajo NIS2 y el CRA, y también bajo marcos sectoriales como DORA en servicios financieros, el valor real de la certificación está en cómo soporta una narrativa de control creíble.

DORA es un buen ejemplo lateral. El Reglamento (UE) 2022/2554 no exige por sistema certificaciones europeas bajo el Cybersecurity Act para todos los terceros TIC, pero sí impone una gobernanza mucho más exigente sobre riesgo de terceros, contratos, supervisión y pruebas, especialmente en los artículos 28 a 30. Si una entidad financiera evalúa un proveedor TIC crítico o importante, disponer de una certificación europea relevante puede reforzar la fase de due diligence y ayudar a discutir cláusulas técnicas con más objetividad. No sustituye la obligación contractual ni la supervisión continuada. Pero desde luego pesa más que el habitual “nuestro equipo sigue mejores prácticas líderes del sector”, fórmula que suele significar poco y probar menos.

Para cumplimiento, la pregunta correcta es esta: ¿cómo documentamos el uso de certificaciones en nuestras decisiones de control? No basta con archivar un PDF. Conviene dejar trazado qué riesgo cubre, qué alcance exacto tiene, qué nivel de aseguramiento aporta, qué limitaciones conserva y qué controles adicionales seguimos exigiendo. Esa trazabilidad será oro si dentro de doce meses un supervisor pregunta por qué aceptaste un proveedor o por qué diste por satisfactorio un producto en un entorno crítico.

La trampa de la autoevaluación: legalmente posible no significa prudentemente suficiente

Uno de los debates más espinosos del sistema europeo de certificación es el papel de la autoevaluación. El artículo 53 y el artículo 54 permiten, en determinados casos y según el esquema, que la conformidad se base en una declaración UE de conformidad emitida por el propio fabricante o proveedor. Esto tiene lógica económica: no todo producto ni todo servicio requiere el coste y la profundidad de una evaluación de tercera parte. El problema llega cuando el mercado interpreta “permitido” como “equivalente”. No lo es.

Para un comprador regulado, una autoevaluación puede ser razonable en activos de menor criticidad, usos acotados o capas tecnológicas donde el riesgo residual esté bien entendido y compensado por otros controles. Para activos que tocan datos sensibles, autenticación, administración privilegiada, continuidad de negocio o funciones operativas críticas, confiar de forma acrítica en una declaración unilateral sería una imprudencia bastante difícil de defender después.

La pregunta que debes hacer no es “¿tenéis certificación o autoevaluación?”. La pregunta es “¿qué parte del riesgo cubre, con qué alcance técnico, bajo qué esquema y con qué evidencias revisables?”. Si el proveedor responde con un folleto, mala señal. Si responde con documentación clara, límites explícitos y encaje con tu caso de uso, la conversación cambia.

El impacto menos visible: contratos, procurement y derecho a pedir menos tonterías

Hay una buena noticia en todo esto, aunque suene poco épica: la certificación europea bien usada puede mejorar mucho la calidad de los procesos de compra y reducir burocracia inútil. Sí, has leído bien. Regulación que quita trabajo absurdo. Ocurre de vez en cuando.

Si tu organización compra tecnología en múltiples países de la UE, el marco del Cybersecurity Act ofrece un punto de armonización que debería permitir estandarizar criterios técnicos y rebajar variabilidad local. El artículo 56 del Reglamento, además, busca precisamente evitar la fragmentación derivada de esquemas nacionales conflictivos cuando exista un esquema europeo aplicable para un mismo propósito. La idea política es clara: una certificación europea debe valer en toda la Unión, y los Estados miembros no deberían levantar peajes paralelos sobre el mismo terreno.

En procurement, eso permite diseñar pliegos y plantillas con más precisión. Por ejemplo, puedes distinguir entre requisitos mínimos de admisibilidad, elementos que otorgan ventaja competitiva y controles adicionales por criticidad del caso de uso. También puedes dejar de exigir combinaciones arbitrarias de sellos que nadie dentro de la empresa sabe interpretar. Cuando un pliego pide cuatro certificaciones parcialmente solapadas y ningún criterio sobre alcance, el mensaje real no es “somos exigentes”; es “no hemos hecho el trabajo”.

Desde el punto de vista contractual, la certificación puede influir en tres cláusulas críticas: representación de conformidad, obligación de mantenimiento o renovación durante la vigencia del servicio y notificación de cambios materiales que afecten al estado certificado. Si dependes del proveedor para una función sensible, no tiene demasiado sentido celebrar la obtención del certificado y olvidarte de lo que pasa si ese certificado caduca, cambia de alcance o pierde validez tras una modificación sustancial del producto.

Cómo encajar ENISA, NIS2 y CRA en un solo programa sin montar tres burocracias distintas

El mayor riesgo en 2026 no es incumplir una sola norma. Es responder a cada norma con una mini-oficina, una taxonomía distinta y una carpeta documental separada. Ahí es donde los programas se vuelven caros, lentos y sorprendentemente ciegos. La alternativa razonable consiste en construir un núcleo común de evidencia y decisión.

Ese núcleo debería tener, como mínimo, cinco bloques. Uno: inventario claro de productos, servicios y procesos TIC que compras, operas o fabricas, con criticidad de negocio y dependencias. Dos: modelo de clasificación para determinar dónde la certificación europea existente o prevista es relevante. Tres: librería de evidencias reutilizables de desarrollo seguro, hardening, pruebas, vulnerabilidades y control de cambios. Cuatro: criterios de due diligence de terceros que distingan entre lo cubierto por certificación y lo que requiere comprobación adicional. Cinco: gobierno de excepciones, porque siempre habrá casos sin esquema aplicable, con certificación parcial o con urgencia operativa.

Si eso te suena a mucho trabajo, lo es. Pero menos que sostener tres programas paralelos que piden versiones incompatibles del mismo hecho. Además, tiene una ventaja política interna nada despreciable: permite hablar con negocio en términos de velocidad de compra, acceso a mercado, reducción de fricción comercial y defendibilidad regulatoria, no solo en jerga de control.

Implicaciones para entidades financieras españolas

Para banca, seguros, fintech y pagos en España, la conversación tiene una capa extra. La combinación de DORA, NIS2 y esquemas europeos de certificación está creando un estándar de exigencia donde la pregunta ya no es solo si el proveedor es seguro, sino si esa seguridad puede demostrarse de forma comparable y supervisable. Banco de España, CNMV y DGSFP no gestionan este asunto exactamente igual, pero el clima supervisor se ha endurecido hacia la trazabilidad del riesgo TIC y la dependencia de terceros.

En una entidad financiera, el efecto práctico suele aparecer en tres puntos. Primero, en la homologación de proveedores TIC con acceso a datos, credenciales o procesos críticos. Segundo, en adquisiciones de tecnología para autenticación, cifrado, comunicaciones seguras y operación remota. Tercero, en productos propios de banca digital, open banking, seguros conectados o servicios embebidos que pueden quedar atrapados entre exigencias de resiliencia operativa y de seguridad de producto.

Una entidad española que integre bien la certificación europea en su gobierno de terceros puede ganar dos cosas. La primera es calidad probatoria frente a auditoría interna, supervisión y clientes institucionales. La segunda es capacidad de compra transfronteriza más coherente. Lo contrario también es cierto: si cada unidad de negocio sigue pidiendo pruebas distintas y desconectadas del marco europeo, acabarás con un ecosistema de terceros difícil de comparar y aún más difícil de defender.

Lo que haría mañana un CISO sensato

No empezaría por encargar una presentación estratégica de cincuenta diapositivas. Empezaría por algo bastante menos glamuroso y mucho más útil: revisar el inventario de categorías tecnológicas críticas y cruzarlo con tres preguntas.

Primera: ¿dónde dependemos de afirmaciones de seguridad del proveedor que hoy no podríamos validar con rapidez? Segunda: ¿qué compras recurrentes podrían beneficiarse de un criterio armonizado basado en certificación europea, aunque sea como preferencia y no como requisito absoluto? Tercera: ¿qué evidencias generamos ya en desarrollo y operación que podrían reutilizarse si un esquema europeo, el CRA o un gran cliente las exige de forma más formal?

Después hablaría con procurement y legal antes de que procurement y legal hablen solos. La política de compras debería distinguir entre certificación exigible, certificación deseable y certificación irrelevante para ciertos supuestos. Los contratos, por su parte, deberían dejar claro el tratamiento de expiración, cambios de alcance y deber de informar sobre eventos que afecten a la condición certificada.

Y sí, también pondría a alguien a seguir de cerca la producción técnica de ENISA y la evolución de esquemas aplicables al perfil de la empresa. No por fetichismo regulatorio, sino porque el coste de enterarte tarde suele pagarse en RFPs perdidas, remediaciones improvisadas o discusiones desagradables con el supervisor.

La conclusión incómoda: ENISA no manda sobre tu programa, pero cada vez influye más en su credibilidad

ENISA no se convierte mágicamente en tu regulador directo por el hecho de que el Cybersecurity Act la sitúe en el centro del sistema europeo de certificación. Tampoco toda organización necesitará perseguir cada esquema en cuanto aparezca. Sería una lectura histérica y cara. Pero minimizar su papel a “publicador de guías” ya no se sostiene.

El mandato de ENISA bajo los artículos 46 y siguientes del Cybersecurity Act está ayudando a definir cómo Europa quiere medir y expresar la confianza en productos, servicios y procesos TIC. NIS2 hace que esa confianza importe más en la gestión del riesgo y la rendición de cuentas. El CRA hace que importe más en el diseño y la conformidad del producto. DORA, para el sector financiero, añade presión sobre terceros, documentación y gobernanza. Todo apunta en la misma dirección: seguridad demostrable, menos folclore comercial y más evidencia reutilizable.

Aquí está el quid. Si tu programa sigue tratando la certificación europea como una rareza de laboratorio, te faltan años de calendario regulatorio. Si la conviertes en un sustituto acrítico del análisis de riesgo, también te equivocas. El punto inteligente está en medio: usar el trabajo de armonización que articula ENISA para comprar mejor, diseñar mejor y defender mejor tus decisiones. No es tan vistoso como prometer “resiliencia de clase mundial”. Pero cuando llegue la auditoría, el incidente o la revisión del supervisor, te servirá bastante más.