El mandato de ENISA bajo el Cybersecurity Act: lo que de verdad cambia para tu programa de ciberseguridad

No hace falta convertir cada sello europeo de ciberseguridad en una epifanía regulatoria. Pero tampoco conviene despacharlo como simple marketing con estrellas azules. La certificación bajo el Cybersecurity Act sigue siendo voluntaria en su arquitectura formal. Lo que ocurre es bastante más interesante: se está convirtiendo en una pieza de lenguaje común entre fabricantes, compradores, supervisores y equipos de riesgo. Y eso, en compliance, suele importar más que un eslogan sobre “voluntariedad”.

El problema empieza cuando se exagera. Hay quien presenta los esquemas europeos de certificación como si ya fuesen una obligación transversal de mercado. No lo son. El Reglamento (UE) 2019/881, conocido como Cybersecurity Act, construye un sistema europeo de certificación de ciberseguridad para productos, servicios y procesos TIC, pero no impone una certificación general ex ante para operar en Europa. Lo que sí hace es crear una infraestructura regulatoria que puede ganar peso por tres vías distintas: porque un esquema concreto se use en contratación o en relaciones privadas, porque otra norma de la UE remita a él, o porque se convierta en señal de confianza en sectores donde la evaluación técnica independiente empieza a valer más que las promesas comerciales.

Aquí está el quid. La certificación europea no es todavía un mandato horizontal. Pero ignorarla por completo es una forma estupenda de llegar tarde cuando compras, vendes o evalúas riesgo tecnológico.

Qué dice realmente el Cybersecurity Act, sin adornos

Conviene bajar al texto. El Título III del Cybersecurity Act establece el marco europeo de certificación de ciberseguridad. No crea un único certificado mágico. Crea un sistema para desarrollar esquemas europeos de certificación aplicables a categorías de productos, servicios o procesos TIC.

La arquitectura básica está bastante delimitada:

• Artículo 46: define el objetivo general de los esquemas europeos de certificación de ciberseguridad.
• Artículo 47: regula los objetivos de seguridad de esos esquemas.
• Artículo 48: establece los niveles de aseguramiento: básico, sustancial y alto.
• Artículo 49: enumera los elementos que debe incluir un esquema europeo de certificación.

Ese reparto importa porque evita uno de los errores más repetidos en este debate: mezclar finalidad, objetivos de seguridad y niveles de aseguramiento como si fueran lo mismo. No lo son. El artículo 47 se centra en qué propiedades de seguridad pretende acreditar el esquema; el 48 clasifica la intensidad del aseguramiento; y el 49 baja al detalle operativo de lo que debe contener cada esquema, incluidos criterios de evaluación, periodo de validez o reglas sobre vigilancia y reevaluación.

Luego está la cuestión política que suele generar más ruido que luz: la voluntariedad. El artículo 56 dice que, salvo que el Derecho de la Unión o el de los Estados miembros disponga otra cosa, la certificación europea de ciberseguridad será voluntaria. No hay mucho misterio. La puerta a la obligatoriedad existe, pero no nace del aire ni de una moda de mercado; tendría que venir de otra disposición jurídica que así lo exija para un caso concreto.

Eso explica por qué la conversación seria no debería girar en torno a una falsa dicotomía entre “obligatorio” y “decorativo”. El sistema europeo sirve para estandarizar criterios de evaluación y para hacer comparables determinadas garantías de ciberseguridad. En un mercado donde cada proveedor asegura ser “secure by design” hasta que llega la auditoría, esa estandarización ya tiene valor propio.

La paradoja regulatoria: voluntario en el papel, relevante en la práctica

La palabra “voluntario” tranquiliza a quien no quiere mover un dedo. A veces con razón. Otras, no tanto.

En regulación tecnológica europea, lo voluntario suele tener varias vidas. La primera es la jurídica estricta: nadie te obliga de forma general a certificar. La segunda es la contractual: un cliente puede pedir evidencias concretas de seguridad en un pliego o en una negociación privada. La tercera es la de gobernanza interna: un comité de riesgos puede preferir soluciones cuya evaluación externa resulte más estructurada y comparable. Ninguna de esas tres capas convierte automáticamente la certificación en obligación legal universal. Pero sí puede convertirla en un factor material dentro de decisiones de compra, due diligence o diseño de controles.

Hay que decirlo con precisión para no vender humo. El Cybersecurity Act, por sí solo, no prueba que todos los fabricantes, proveedores cloud, integradores o entidades sujetas a NIS2 estén ya condicionados de la misma manera por la certificación europea. Esa afirmación sería demasiado amplia. Lo que sí puede sostenerse con solidez es algo más sobrio y bastante más útil: el marco de certificación de la UE ofrece un mecanismo que puede ser utilizado por compradores, autoridades y operadores para evaluar o comparar determinadas garantías de ciberseguridad cuando exista un esquema aplicable.

La diferencia parece semántica, pero no lo es. Decir que “ya condiciona” a todo un ecosistema presupone una evidencia de mercado o una remisión normativa que no siempre existe. Decir que “puede ser utilizado como referencia estructurada” describe mejor la función real del sistema: un instrumento disponible, no una obligación transversal presumida.

Qué papel juega ENISA y por qué no es un detalle burocrático

Otra confusión habitual consiste en presentar a ENISA como una especie de oficina de estampación. Tampoco va por ahí. Bajo el Cybersecurity Act, ENISA tiene un papel técnico e institucional central en la preparación de esquemas candidatos y en el funcionamiento del ecosistema europeo de certificación, aunque la adopción formal de los esquemas corresponda a la Comisión mediante actos de ejecución y la evaluación la realicen organismos de evaluación de la conformidad o autoridades nacionales, según el caso.

Eso tiene dos consecuencias prácticas.

La primera: la certificación europea no equivale a una autoafirmación del proveedor. La lógica del sistema está diseñada para que el esquema defina criterios, métodos, niveles de aseguramiento y condiciones de validez con un grado de formalización que permita comparar resultados de forma más disciplinada que una simple matriz comercial de controles.

La segunda: cuando un esquema existe para una categoría concreta, el debate interno en las organizaciones cambia. Ya no discutes solo si el proveedor “parece maduro”. Discutes si existe una referencia europea diseñada precisamente para evaluar ese tipo de producto, servicio o proceso, qué cubre, con qué nivel de aseguramiento y con qué límites.

Eso no elimina la necesidad de evaluación propia. De hecho, el certificado no sustituye por arte de magia el análisis de riesgos, la revisión contractual ni la supervisión continuada. Pero sí puede ordenar la conversación. Y cualquiera que haya sobrevivido a un comité de compras tecnológicas sabe que ordenar la conversación ya es media victoria.

Lo que NIS2 sí permite afirmar, y lo que no

NIS2 ha añadido una capa de ansiedad a esta discusión, a veces con fundamento y a veces con bastante teatro. La Directiva (UE) 2022/2555 no convierte por sí misma la certificación del Cybersecurity Act en una obligación general para todas las entidades esenciales e importantes. Eso conviene dejarlo cristalino.

Ahora bien, NIS2 sí introduce puntos de conexión relevantes. El artículo 21 obliga a adoptar medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que afecten a la seguridad de las redes y sistemas de información. Ese mismo artículo menciona ámbitos muy concretos: gestión de incidentes, continuidad de negocio, seguridad en la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, políticas para evaluar la eficacia de las medidas, y prácticas básicas de ciberhigiene, entre otros.

¿Qué significa eso para la certificación europea? Algo preciso: cuando una organización tiene que demostrar que ha gestionado riesgos en adquisición tecnológica o cadena de suministro, un esquema europeo aplicable puede formar parte del conjunto de evidencias o criterios que revise. Puede ayudar, pero NIS2 no dice que la ausencia de certificación equivalga por sí sola a incumplimiento. Tampoco dice que elegir un proveedor no certificado obligue automáticamente a justificar “garantías equivalentes” en los términos grandilocuentes con los que a veces se vende esta idea.

La formulación prudente es otra. Si existe un esquema europeo relevante para una categoría TIC concreta, la organización debería valorar si ese esquema resulta útil dentro de su proceso de evaluación y selección, especialmente cuando esté documentando controles de seguridad, dependencia de terceros o criterios de adquisición segura al amparo del artículo 21 de NIS2. No es una orden automática. Es una pregunta de gobierno del riesgo que cada vez será más difícil fingir que no existe.

Y hay un matiz adicional. NIS2 también contempla, en su artículo 24, el uso de esquemas europeos de certificación de ciberseguridad adoptados con arreglo al Cybersecurity Act. La directiva abre espacio para que los Estados miembros fomenten su utilización en relación con determinadas ofertas, servicios o procesos. Otra vez: fomentar no es lo mismo que imponer. Pero la conexión jurídica está ahí, escrita negro sobre blanco.

Certificación no es sustituto de due diligence. Es, como mucho, una capa útil

A algunos departamentos de compras les encantaría que un certificado europeo resolviese en una página lo que hoy exige cuestionarios interminables, revisión de anexos técnicos, discusiones sobre subcontratación y varias llamadas tensas con Legal. Malas noticias: no funciona así.

Un esquema de certificación delimita qué se evalúa y con qué nivel de aseguramiento. No te da una foto completa de todos los riesgos jurídicos, operativos o de resiliencia de un tercero. No responde por sí solo a cuestiones como localización de datos, reparto de responsabilidades en incidentes, tiempos de notificación, derecho de auditoría, dependencia de subprocesadores o capacidad real de recuperación. Para eso siguen estando los contratos, la gobernanza de terceros y la evaluación continua.

Precisamente por eso conviene evitar otra afirmación demasiado rotunda: decir que “la certificación actúa como evidencia de base” para third-party risk puede sonar razonable, pero depende del caso, del esquema y del alcance de la evaluación. Lo correcto es expresarlo sin vender más de lo que el certificado da. Una certificación europea aplicable puede aportar información estructurada sobre determinadas características de seguridad evaluadas bajo un esquema concreto, y esa información puede ser considerada dentro de un proceso más amplio de gestión del riesgo de terceros. Nada menos. Nada más.

Ese “puede” no es cobardía. Es exactitud. Y en compliance regulatorio, la exactitud suele ser más útil que la fanfarria.

Por qué el nivel de aseguramiento importa más que el logo

Una de las partes más malinterpretadas del Cybersecurity Act es la clasificación de aseguramiento del artículo 48: básico, sustancial y alto. Mucha gente se queda en la existencia del certificado y olvida la pregunta decisiva: ¿con qué nivel de confianza se ha evaluado?

El reglamento no usa esos niveles como simple estética. Los usa para reflejar la intensidad esperada de la evaluación y la capacidad del producto, servicio o proceso de resistir frente a determinados riesgos. Si una organización trata todos los certificados como equivalentes, está perdiendo justo la información que la certificación pretende ordenar.

En términos operativos, eso obliga a hacer tres preguntas mínimas antes de otorgar valor interno a un certificado:

• ¿Qué categoría de producto, servicio o proceso cubre exactamente el esquema?
• ¿Qué objetivos de seguridad contempla el esquema según el artículo 47 y el acto que lo desarrolla?
• ¿Qué nivel de aseguramiento se ha obtenido y si ese nivel encaja con el riesgo del caso de uso?

Si no puedes responder esas tres preguntas, el certificado se queda en fetiche corporativo. Muy presentable en PowerPoint. Mucho menos útil cuando el auditor pide sustancia.

Donde suelen equivocarse los equipos legales y de procurement

El error clásico del área legal es tratar la certificación como una cuestión binaria: existe o no existe. El error clásico de procurement es peor: usarla como criterio de corte sin haber definido antes para qué riesgo sirve.

La aproximación más seria exige conectar el esquema con la decisión concreta. No es lo mismo evaluar un componente crítico para autenticación que un servicio periférico con bajo impacto operacional. Tampoco es lo mismo una compra sujeta a exigencias sectoriales estrictas que una adquisición de apoyo con escasa exposición regulatoria. Si no se hace esa traducción al riesgo, la conversación sobre certificación se vuelve ritualista.

Para evitarlo, la secuencia útil suele ser esta:

• Primero, identificar si existe un esquema europeo aplicable a la categoría TIC relevante.
• Segundo, revisar qué cubre ese esquema y qué no cubre, con apoyo en sus objetivos de seguridad, alcance y nivel de aseguramiento.
• Tercero, decidir si ese resultado tendrá peso en la selección, en el scoring de riesgo, en las obligaciones contractuales o solo en la fase de monitorización.
• Cuarto, documentar por qué la certificación se usa —o no se usa— dentro del proceso.

Esa última parte suele olvidarse. Y es la que luego marca la diferencia frente al auditor, al supervisor o al comité de riesgos. No por tener un certificado, sino por poder explicar qué hiciste con él.

El riesgo de sobrerreaccionar: convertir una herramienta en dogma

El entusiasmo regulatorio tiene una tendencia entrañable a convertir cualquier instrumento útil en una religión menor. Con la certificación europea puede ocurrir lo mismo si las organizaciones no mantienen la cabeza fría.

Hay al menos cuatro riesgos de sobrerreacción.

El primero es asumir que toda ausencia de certificación equivale a una carencia de seguridad. Falso. Puede significar muchas otras cosas: que no existe aún un esquema aplicable, que el proveedor no lo ha buscado, o que el mercado de ese producto funciona todavía con otros marcos de evaluación.

El segundo es olvidar el alcance exacto de la certificación. Un esquema no bendice todo el stack tecnológico ni toda la operativa del proveedor. Bendice, si se me permite la ironía, aquello que el esquema cubre y en las condiciones que el esquema define. Lo demás sigue siendo trabajo tuyo.

El tercero es usar la certificación como coartada para reducir la due diligence. Mala idea. Ni NIS2, ni DORA, ni la lógica básica de gestión del riesgo de terceros apoyan ese atajo.

El cuarto es diseñar políticas internas grandilocuentes del tipo “solo se comprarán soluciones certificadas” sin mapear antes disponibilidad real, impacto operacional, categorías afectadas y alternativas. Ese tipo de política queda muy bien hasta que el negocio necesita una herramienta que no encaja en la frase solemne aprobada por el comité.

Y el riesgo contrario: subestimarla por puro cansancio normativo

También existe el error espejo. Algunas empresas, agotadas de tantas siglas europeas, meten la certificación en el cajón de “ya veremos”. Es una lectura cómoda, pero cada vez menos defendible en organizaciones reguladas o intensivas en terceros TIC.

La razón no es que exista ya una obligación horizontal secreta. No existe. La razón es más mundana: cuando el derecho de la UE crea un mecanismo estandarizado para evaluar ciberseguridad, ese mecanismo puede acabar siendo utilizado por múltiples capas de decisión, aunque la norma matriz no obligue a todo el mundo al mismo tiempo. Quien espere a que todo venga empaquetado como obligación explícita puede descubrir demasiado tarde que el mercado, los clientes o la gobernanza interna ya se han movido antes.

Eso se ve con frecuencia en entornos donde la carga de prueba práctica recae sobre quien selecciona tecnología. Si una organización tiene que explicar cómo evaluó seguridad, resiliencia o dependencia de terceros, disponer de referencias comparables puede facilitar la defensa de la decisión. No porque la ley imponga siempre un certificado, sino porque la disciplina probatoria se está endureciendo. Y cuando la disciplina probatoria sube, las herramientas estructuradas suelen ganar terreno.

Cómo leer esto desde DORA sin decir lo que DORA no dice

La tentación de mezclar DORA con certificación europea es fuerte, sobre todo en el sector financiero. Pero conviene no pasarse de frenada. El Reglamento (UE) 2022/2554, DORA, no establece una obligación general de contratar únicamente con proveedores certificados bajo el Cybersecurity Act. Si alguien te lo vende así, te está simplificando demasiado el paisaje.

Lo que sí hace DORA es endurecer de forma muy seria la gobernanza del riesgo TIC, la gestión de terceros y la documentación contractual. Ahí están, entre otros, el artículo 28 sobre gestión del riesgo de terceros TIC, el artículo 30 sobre elementos contractuales clave, y el artículo 31 sobre el registro de información relativo a acuerdos contractuales con terceros proveedores de servicios TIC.

Desde esa lógica, una certificación europea aplicable puede tener relevancia como una referencia adicional dentro de la evaluación del proveedor o del servicio. Pero DORA exige bastante más: estrategia, inventario, clasificación de funciones, análisis de concentración, pruebas, supervisión y capacidad de salida. Un certificado no resuelve ese paquete. Lo que puede hacer es encajar como una pieza dentro del mosaico probatorio o de control, siempre que la entidad sepa exactamente qué valor le atribuye.

Para una entidad financiera, la pregunta útil no es “¿me obliga DORA a exigir certificación europea?”. La pregunta útil es otra: “si existe un esquema aplicable a un componente crítico o sensible, ¿voy a ignorarlo en mi metodología de evaluación de terceros y luego pretender que mi framework es maduro?”. Esa conversación ya suena bastante menos teórica.

Qué debería hacer una organización ahora, sin esperar a que todo sea obligatorio

La respuesta sensata no es redactar una política maximalista ni seguir como si nada. Está en medio, que es justo donde casi nadie quiere quedarse porque obliga a pensar.

Un enfoque útil hoy tendría al menos cinco movimientos concretos.

1. Mapear esquemas aplicables a tu universo TIC

No hablo de un inventario poético. Hablo de identificar, por categorías de producto, servicio o proceso, si existe un esquema europeo aplicable o si hay desarrollos que puedan afectar a tus decisiones de compra o evaluación. Si no sabes qué categorías de tu stack podrían entrar en juego, no estás gestionando esto; estás improvisando.

2. Traducir cada esquema a casos de uso internos

Un certificado solo adquiere valor corporativo cuando se vincula a un caso de uso: selección de proveedor, reevaluación periódica, requisitos de pliego, scoring de terceros, compensating controls o monitorización contractual. Si no haces esa traducción, la certificación se queda en noticia de LinkedIn.

3. Definir por escrito qué peso tendrá en la evaluación

No hace falta inventar una pseudociencia. Basta con dejar claro si la certificación funcionará como elemento favorable, como requisito en determinados supuestos, como factor de reducción de pruebas duplicadas o simplemente como información contextual. Lo que no conviene es decidirlo de forma ad hoc en cada compra importante, porque ahí es donde nacen las incoherencias.

4. No confundir certificado con cobertura total

La política interna debería exigir siempre la revisión del alcance del esquema, del nivel de aseguramiento y de las áreas no cubiertas. Si el equipo solo registra “certificado sí/no”, está perdiendo la parte más útil del mecanismo.

5. Preparar una narrativa audit-able

Tu organización debería poder explicar, de forma coherente y documentada, por qué tomó en consideración un esquema europeo o por qué decidió no hacerlo en un caso concreto. Esa explicación, bien hecha, vale más que un eslogan corporativo sobre excelencia digital.

La gran lección: en ciberregulación, el detalle técnico acaba siendo estrategia

Lo más interesante del Cybersecurity Act no es que haya creado otro acrónimo para coleccionar. Es que convierte cuestiones técnicas de evaluación en infraestructura regulatoria reutilizable. Y eso tiene un efecto de fondo: desplaza parte del debate desde la confianza declarada hacia la confianza evaluada.

Ese desplazamiento no ocurre de golpe ni de forma uniforme. Habrá sectores donde avance rápido y otros donde apenas se note. Habrá categorías TIC con esquemas más influyentes que otras. Habrá compradores que lo usen bien y compradores que lo conviertan en casilla decorativa. Pero la dirección es bastante clara: cuando existe un vocabulario europeo común para hablar de aseguramiento en ciberseguridad, ese vocabulario tiende a filtrarse en la práctica regulatoria y contractual, aunque la norma de origen siga diciendo “voluntario”.

Por eso conviene huir de los dos extremos. Ni estamos ante una obligación horizontal encubierta que ya somete por igual a todo el mercado, ni estamos ante una formalidad irrelevante reservada a tecnócratas con tiempo libre. Estamos ante una herramienta jurídica y técnica cuyo peso dependerá del esquema aplicable, del sector, del caso de uso y de cómo otras obligaciones —NIS2, DORA o requisitos contractuales— empujen a las organizaciones a justificar mejor sus decisiones tecnológicas.

La moraleja, menos épica pero más útil, es esta: no des por hecho que la certificación europea te obliga a todo, pero tampoco te permitas tratarla como ruido. Si compras, vendes, integras o supervisas tecnología en un entorno regulado, te conviene entender exactamente qué cubre, qué no cubre y cuándo puede servirte como referencia estructurada. Lo demás es postureo normativo. Y de eso, francamente, ya vamos sobrados.