La revisión del Cybersecurity Act no va de sellos: va de quién manda en la cadena ICT europea

Bruselas quiere tocar una pieza delicada del puzle regulatorio europeo: la certificación de ciberseguridad. Y cuando la Comisión toca esa pieza, no está afinando una nota menor. Está metiendo mano a una arquitectura que afecta a fabricantes, prestadores de servicios, compradores públicos y privados, supervisores sectoriales y, de rebote, a cualquier empresa que ya se estaba acostumbrando a vivir entre DORA, NIS2, GDPR y una sopa de siglas que crece más rápido que la paciencia de los equipos de compliance.

La cuestión no es si Europa necesita revisar el Cybersecurity Act. La necesita. La cuestión es qué problema intenta resolver exactamente y qué efectos colaterales puede generar. Porque una cosa es simplificar un sistema de certificación que ha avanzado más lento de lo prometido, y otra muy distinta convertir la certificación en una palanca regulatoria que acabe desplazando cargas hacia empresas que ya operan con varias capas de obligaciones técnicas, contractuales y de gobernanza.

El debate importa por una razón muy concreta: el Cybersecurity Act no vive aislado. Dialoga —a veces mal, a veces a empujones— con NIS2, con DORA, con el futuro Cyber Resilience Act y con las reglas de contratación y supervisión sectorial. Si cambias las reglas de certificación, cambias también la forma en que el mercado demuestra confianza. Y eso, en ciberseguridad, nunca es un detalle administrativo.

El problema real: la certificación europea no ha despegado al ritmo que prometía

El Reglamento (UE) 2019/881, conocido como Cybersecurity Act, creó un marco europeo para esquemas de certificación de ciberseguridad de productos, servicios y procesos TIC. La promesa era razonable: reducir fragmentación, crear confianza común en el mercado interior y evitar que cada Estado miembro o cada sector jugara con reglas distintas. Sobre el papel, impecable. En la práctica, mucho más áspero.

El corazón jurídico del sistema está en el título III del reglamento, especialmente en los artículos 46 a 65. Ahí se define qué es un esquema europeo de certificación, qué niveles de aseguramiento puede incorporar —basic, substantial y high, según el artículo 52—, cómo se articula la evaluación de conformidad y qué papel desempeñan ENISA, la Comisión y las autoridades nacionales de certificación.

El diseño tiene lógica institucional, pero también fricciones evidentes. Elaborar un esquema europeo no es tan rápido como publicar una guía o emitir una recomendación. Requiere una combinación poco glamurosa, pero decisiva, de pericia técnica, negociación regulatoria, validación política y capacidad operativa de evaluación. Dicho de forma menos diplomática: cuando demasiados actores tienen que ponerse de acuerdo sobre requisitos técnicos complejos, el calendario se vuelve optimista por deporte.

Ahí está uno de los motivos de la revisión. La Comisión lleva tiempo viendo que el mecanismo necesita ajustes para ser más utilizable. No basta con tener un marco jurídico elegante si el mercado no puede traducirlo en certificaciones desplegadas con un nivel razonable de previsibilidad. Esa tensión —entre ambición normativa y ejecución práctica— recorre toda la reforma.

Qué sí hace el Cybersecurity Act y por qué conviene no atribuirle más de la cuenta

Antes de entrar en la revisión, conviene poner orden. El Cybersecurity Act sirve para dos grandes cosas. Primera: reforzar y estructurar el mandato permanente de ENISA. Segunda: crear el marco europeo de certificación de ciberseguridad. Lo que no hace, al menos no de forma automática, es imponer una obligación general y transversal de certificarse a todas las empresas o productos del mercado. El artículo 49 deja claro que los esquemas europeos de certificación son, como regla general, voluntarios, salvo que otra norma del Derecho de la Unión o del Derecho nacional disponga lo contrario.

Ese matiz jurídico parece técnico, pero tiene consecuencias muy concretas. Si un regulador sectorial decide apoyarse en un esquema europeo como prueba de cumplimiento, o si un instrumento legislativo posterior convierte determinados requisitos en obligatorios para ciertas categorías, el efecto práctico cambia por completo. Por eso la revisión del Cybersecurity Act interesa tanto a sectores regulados: porque la voluntariedad formal no impide una obligatoriedad funcional por la vía de supervisión, contratación, mercado o responsabilidad.

También conviene no sobrecargar el texto con intenciones geopolíticas que no estén claramente ancladas en la propuesta o en el reglamento. El marco de certificación puede influir en cómo el mercado europeo evalúa confianza y seguridad en productos y servicios TIC, pero eso no equivale, sin más, a una potestad general para intervenir cadenas de suministro por la mera presencia de proveedores de terceros países. Si la preocupación es la gestión del riesgo derivado de dependencias externas, ese debate existe. Solo que su encaje jurídico exige mucha más precisión que un eslogan sobre “cybersecurity concerns”. Y, a estas alturas, conviene distinguir entre lo que la Comisión sugiere, lo que el reglamento habilita y lo que otras piezas normativas podrían llegar a exigir.

La revisión no va solo de técnica; va de gobernanza del mercado

La parte interesante de esta reforma no está únicamente en el detalle de laboratorio o en el lenguaje de conformidad. Está en la gobernanza. Quién define los requisitos. Quién certifica. Quién supervisa. Cómo se evita la fragmentación nacional. Y qué valor real tiene un certificado cuando una entidad financiera, un operador esencial o una gran empresa industrial tiene que decidir si compra, contrata o integra una solución en sistemas críticos.

El artículo 54 del Cybersecurity Act ya preveía que cada esquema europeo definiera, entre otras cosas, el ámbito de aplicación, las categorías de productos, servicios o procesos TIC cubiertos, los requisitos de ciberseguridad, el tipo de evaluación aplicable y las reglas sobre vigilancia, suspensión o retirada de certificados. Es decir: el reglamento no se queda en el titular político; baja al terreno donde de verdad se decide si una certificación sirve o si se convierte en una pegatina cara.

La revisión intenta precisamente hacer ese terreno más practicable. Menos ambigüedad procedimental, más claridad institucional y una conexión más usable entre lo que la UE certifica y lo que el mercado necesita comprar. Ese es el argumento fuerte a favor de la reforma. El débil, y bastante repetido, es el de “más Europa, más confianza” como si la simple existencia de un nuevo esquema resolviera por sí sola problemas de adopción, coste o interoperabilidad. No los resuelve.

El cruce con NIS2: aquí empieza el verdadero impacto operativo

Si quieres entender por qué esta revisión importa de verdad, mira NIS2. La Directiva (UE) 2022/2555 elevó la presión sobre entidades esenciales e importantes no porque inventara la ciberseguridad, sino porque convirtió la gestión del riesgo y la rendición de cuentas en obligaciones más concretas y supervisables. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información. No se queda en una declaración de buenas intenciones: menciona análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad en 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.

El artículo 23, por su parte, establece las obligaciones de notificación de incidentes significativos. Primero la alerta temprana, luego la notificación del incidente y después el informe final, con el calendario y el contenido que detalla la propia directiva. Esa arquitectura importa más que cualquier simplificación narrativa. Porque cuando una empresa tiene que demostrar que ha gestionado adecuadamente riesgos y proveedores, la certificación puede convertirse en prueba auxiliar, en criterio de compra o en expectativa supervisora, incluso si la norma de certificación sigue siendo formalmente voluntaria.

Eso cambia la conversación dentro de las empresas. Ya no se trata solo de preguntar “¿estamos obligados a certificarnos?”. La pregunta útil es otra: “¿podemos justificar ante el consejo, el regulador, el cliente y el auditor por qué no usamos esquemas de certificación disponibles para este activo o servicio concreto?”. No siempre habrá una obligación legal directa. A veces habrá algo casi más incómodo: una obligación de explicar por qué no seguiste una vía razonable de aseguramiento.

DORA no impone certificación general, pero sí endurece la conversación sobre terceros TIC

En el sector financiero, el cruce más delicado no es con NIS2, sino con DORA. El Reglamento (UE) 2022/2554 ha cambiado la discusión sobre proveedores TIC de manera mucho más radical de lo que algunos departamentos de compras quisieron admitir al principio. Los artículos 28 a 30 regulan la gestión del riesgo asociado a terceros prestadores de servicios TIC, incluyendo estrategia sobre riesgo de terceros, registro de información contractual y requisitos clave de los contratos.

La lógica de DORA es bastante menos inocente que la de muchas políticas previas de vendor management. Ya no basta con un cuestionario anual, dos anexos contractuales y la ilusión corporativa de que “el proveedor es sólido”. DORA obliga a integrar el riesgo de terceros en el marco de gestión del riesgo TIC de la entidad financiera, con trazabilidad, gobernanza y capacidad de supervisión real. Cuando eso ocurre, cualquier instrumento europeo de certificación con reconocimiento suficiente puede ganar peso como evidencia de control, aunque DORA no diga: “usted debe exigir este certificado concreto”.

El artículo 28 exige que las entidades gestionen el riesgo derivado de terceros prestadores de servicios TIC como parte integrante del riesgo TIC. El artículo 30 entra en el detalle contractual: descripción de funciones y servicios, lugares de prestación y tratamiento, disponibilidad, integridad, confidencialidad, acceso, recuperación, asistencia en incidentes, derechos de terminación, cooperación con autoridades competentes y condiciones de subcontratación, entre otros. Esa densidad operativa convierte la certificación en una posible herramienta de diligencia reforzada, no en un adorno de marketing.

Por eso la revisión del Cybersecurity Act interesa tanto al sector financiero aunque no sea una norma sectorial financiera. Si Bruselas consigue hacer los esquemas más claros, más predecibles y más alineados con necesidades reales de compra y supervisión, su influencia práctica sobre DORA puede ser notable. Si no lo consigue, veremos lo habitual: entidades financieras creando sus propias capas de requisitos, Estados miembros reinterpretando expectativas y proveedores acumulando auditorías paralelas que no hablan entre sí. Europa tiene bastante afición a llamar “armonización” a ese tipo de caos administrado.

El punto más sensible: certificación y servicios gestionados de seguridad

Uno de los giros más observados en la evolución del marco europeo ha sido la posibilidad de ampliar la lógica de certificación más allá de productos y hacia determinadas categorías de servicios. Ahí entra la discusión sobre servicios gestionados de seguridad. La dirección política es relevante porque el mercado no compra solo tecnología empaquetada; compra también capacidades operadas por terceros: monitorización, detección, soporte, respuesta y funciones de seguridad externalizadas.

Ahora bien, aquí conviene ser quirúrgico con las afirmaciones. Lo verificable es esto: la evolución normativa europea ha abierto espacio para pensar la certificación de ciertos servicios gestionados de seguridad dentro del ecosistema del Cybersecurity Act. Lo que no conviene hacer es atribuir a la fuente concreta una cronología exacta o un catálogo cerrado de servicios si esa fuente no los respalda de forma explícita. En otras palabras, la dirección del cambio puede analizarse; los detalles no deben inflarse.

¿Por qué importa entonces esta extensión potencial? Porque cambia la escala del mercado afectado. Certificar un producto es difícil, pero conceptualmente acotable. Certificar un servicio gestionado es bastante más incómodo: exige evaluar procesos, personas, herramientas, subcontratación, continuidad, gobernanza y consistencia operativa a lo largo del tiempo. En productos puedes capturar una fotografía relativamente estable. En servicios, lo que intentas atrapar es una película. Y las películas, ya se sabe, cambian de guion en plena producción.

Para sectores sujetos a DORA o NIS2, esa posible evolución tiene sentido. Gran parte de sus riesgos críticos no reside solo en el software que compran, sino en el servicio que los vigila, administra o mantiene. Si Europa quiere que la certificación tenga relevancia económica, no puede quedarse únicamente en el perímetro de producto. Pero si se adentra en servicios, tendrá que resolver preguntas mucho más espinosas sobre auditoría continua, alcance, evidencia y responsabilidad compartida.

La simplificación procedimental suena bien. La pregunta es si simplifica de verdad

La Comisión presenta la revisión como un intento de hacer el sistema más ágil y claro. Esa intención es sensata. El problema aparece cuando “simplificación” significa cosas distintas para actores distintos. Para el regulador, puede significar reducir cuellos de botella institucionales. Para la industria, puede significar menos tiempo hasta tener un esquema utilizable. Para los evaluadores de conformidad, puede significar criterios más claros y menos zonas grises. Para los compradores regulados, puede significar que el certificado sirva realmente para algo frente al supervisor, el auditor interno o el comité de riesgos.

Si una reforma mejora el proceso de diseño de esquemas pero no resuelve la utilidad práctica del resultado, la simplificación será burocráticamente interesante y comercialmente limitada. El test no está en el comunicado político. Está en preguntas mucho más terrenales: ¿cuánto tardará una empresa en entender si el esquema le aplica? ¿Podrá anticipar costes y carga de evidencia? ¿Aceptarán los compradores regulados ese certificado como prueba suficiente o seguirán exigiendo sus propios controles adicionales? ¿Los Estados miembros lo aplicarán con un criterio relativamente uniforme?

La gran debilidad histórica de buena parte de la regulación tecnológica europea no ha sido la falta de ambición. Ha sido la distancia entre el diseño jurídico y la experiencia operativa de quien tiene que implementarlo. Cada vez que Bruselas promete simplificación, el mercado hace bien en preguntar: “¿simplificación para quién, exactamente?”

Qué no sabemos con certeza y por qué eso también es una noticia

En debates regulatorios como este, la tentación de rellenar huecos con detalles aparentemente plausibles es enorme. Fechas exactas de adopción, calendarios por defecto, atribuciones institucionales redondas, listados cerrados de servicios. Todo eso queda muy bien en un PowerPoint. El problema es que, si la fuente no lo respalda con claridad, el dato se convierte en decoración arriesgada.

Por eso hay tres cautelas que conviene dejar por escrito.

La primera: no puede afirmarse sin más que la revisión establezca un plazo por defecto cerrado para desarrollar esquemas de certificación. La ambición de agilizar existe; un calendario rígido y verificable, tal y como a veces se presenta, no está sólidamente respaldado por la fuente utilizada para esa afirmación.

La segunda: tampoco conviene atribuir de manera categórica a ENISA la operación de un supuesto punto único de entrada para notificación de incidentes en los términos en que se ha formulado en algunos borradores o comentarios. ENISA tiene un papel central en el ecosistema europeo de ciberseguridad, sí. Pero una atribución institucional concreta exige apoyo textual claro en la propuesta correspondiente.

La tercera: cuando se habla de servicios gestionados de seguridad, la prudencia importa. La evolución regulatoria apunta a darles un encaje más explícito en certificación, pero sin inventar una lista cerrada de actividades ni una cronología exacta si la fuente declarada no las detalla. Mejor una formulación precisa y honesta que un catálogo exuberante que no sobreviva a una comprobación básica.

En periodismo regulatorio esto no es una manía de puristas. Es higiene profesional. Entre otras cosas porque el lector que toma decisiones —el CISO, el responsable de terceros, el abogado interno, el miembro del consejo— no necesita una narrativa emocionante. Necesita saber qué está realmente decidido, qué sigue abierto y dónde puede pisar una mina interpretativa.

La conexión con el Cyber Resilience Act: producto certificado no equivale a producto cumplidor universal

Otro error frecuente en este debate es asumir que una certificación europea resolverá, por sí sola, el encaje con otras obligaciones de ciberseguridad del producto. No funciona así. El Cyber Resilience Act, una vez aplicable en toda su extensión, impondrá requisitos horizontales de ciberseguridad para productos con elementos digitales a lo largo de su ciclo de vida. Ahí la lógica ya no es solo de confianza de mercado, sino de requisitos esenciales, gestión de vulnerabilidades y obligaciones de fabricantes e importadores.

La relación entre certificación bajo el Cybersecurity Act y cumplimiento bajo el Cyber Resilience Act puede ser complementaria, pero no automática. Una certificación puede ayudar como evidencia o alineación en determinados aspectos técnicos, según se articule en actos posteriores o en prácticas de evaluación. Lo que no debería venderse es la idea de equivalencia universal. En regulación tecnológica, los sellos simplifican la comunicación comercial mucho mejor de lo que simplifican la responsabilidad jurídica.

Para las empresas, la lección es clara: no mezcles mapas. Un certificado puede servirte para demostrar un nivel de aseguramiento concreto dentro del alcance definido por un esquema. Eso no elimina otras obligaciones aplicables de diseño seguro, gestión de vulnerabilidades, documentación técnica, vigilancia postcomercialización o notificación de incidentes que provengan de instrumentos distintos.

Privacidad, resiliencia y certificación: el triángulo incómodo

Hay otra intersección menos comentada y bastante más interesante: la que une ciberseguridad certificada, resiliencia operativa y protección de datos. GDPR nunca ha exigido certificación general de ciberseguridad como condición de cumplimiento, pero sí impone seguridad apropiada al riesgo en el artículo 32, notificación de brechas a la autoridad de control en el artículo 33 y, cuando procede, comunicación al interesado en el artículo 34. Si una empresa sufre un incidente en un servicio TIC crítico, rara vez tendrá el lujo de gestionar la crisis dentro de un único compartimento normativo.

Un mismo evento puede activar, según el caso, notificaciones bajo NIS2, obligaciones de gestión y reporte interno bajo DORA y evaluación de brecha de datos personales bajo GDPR. Si además el proveedor o la solución contaban con certificación europea, esa certificación puede entrar en la conversación de dos maneras. Primero, como evidencia de diligencia previa en selección o evaluación. Segundo, como objeto de escrutinio incómodo cuando el incidente demuestra que el alcance real del certificado no cubría las expectativas que alguien proyectó sobre él.

Aquí aparece una ironía bastante europea: cuanto más se multiplica la certificación como lenguaje de confianza, más importante resulta leer la letra pequeña del alcance. El problema no suele ser el certificado en sí. El problema es la sobrerinterpretación del certificado por parte de compradores, juristas, comerciales o comités de dirección que querían una respuesta binaria a una pregunta que nunca fue binaria.

Lo que deberían hacer ahora las empresas, sin esperar a la versión final perfecta de Bruselas

No tiene sentido esperar a que cada pieza normativa encaje con precisión suiza. Eso no va a pasar. Lo que sí tiene sentido es preparar una posición operativa que permita absorber la revisión del Cybersecurity Act sin improvisación. Hay cuatro movimientos que merecen prioridad.

• Mapear dependencias reguladas: identifica qué productos y servicios TIC soportan funciones sujetas a NIS2, DORA, GDPR o requisitos sectoriales equivalentes. No todos los activos pesan igual. La certificación tampoco.
• Revisar criterios de compra y homologación: si tu organización ya evalúa seguridad de proveedores, decide ahora cómo tratará futuros esquemas europeos de certificación: como requisito, como factor de puntuación o como evidencia complementaria. Si esperas a que llegue el supervisor, llegarás tarde.
• Separar producto de servicio: muchas matrices de terceros siguen evaluando ambos como si fueran la misma cosa. No lo son. La eventual evolución del marco hacia servicios gestionados hace esa distinción aún más necesaria.
• Definir una política de confianza razonable: un certificado no debe equivaler a exención de diligencia. Tampoco a irrelevancia. La clave está en documentar cuándo reduce carga de evaluación adicional y cuándo no.

Ese último punto es el más infravalorado. Las organizaciones maduras no tratan la certificación como fetiche ni como humo. La tratan como evidencia con alcance delimitado. Si ese enfoque no está escrito y aprobado internamente, la empresa queda expuesta a dos errores opuestos: confiar demasiado o ignorar demasiado.

La objeción habitual: “otro marco más que solapa lo existente”

La crítica no es absurda. Europa acumula capas regulatorias con entusiasmo industrial. Desde fuera, el paisaje parece una competición para ver qué norma consigue citar más conceptos similares con taxonomía distinta. Riesgo TIC, riesgo cibernético, seguridad de redes y sistemas de información, resiliencia operativa, seguridad por diseño, aseguramiento, certificación, conformidad. Cambia la etiqueta, no siempre cambia el trabajo.

La objeción seria es que revisar el Cybersecurity Act podría añadir otra capa semántica sin resolver la duplicidad de fondo. Y hay parte de verdad en eso. Si el resultado es un sistema de certificación elegante pero desconectado de DORA, NIS2, contratación pública y exigencias sectoriales reales, el mercado lo tratará como otro artefacto europeo interesante y parcialmente ornamental.

La respuesta, sin embargo, no debería ser resignarse a la fragmentación. De hecho, un marco de certificación bien diseñado puede hacer algo que otros instrumentos no logran por sí solos: traducir requisitos técnicos complejos en una señal de mercado relativamente legible y replicable entre Estados miembros. Ese valor existe. Solo que depende de una condición nada menor: que los esquemas sean útiles, creíbles y reconocidos de forma suficientemente consistente.

Mi lectura: la revisión merece apoyo, pero con menos épica y más disciplina jurídica

La reforma va en la dirección correcta si su objetivo es hacer que la certificación europea sea menos abstracta y más operativa. Europa necesita instrumentos comunes de confianza en ciberseguridad que no obliguen a cada sector, comprador o Estado a reinventar su propio estándar práctico. Hasta ahí, bien.

Donde conviene pinchar el globo es en la retórica que atribuye a la revisión más precisión, más velocidad o más alcance del que hoy puede verificarse con seguridad. No hace falta exagerar para explicar por qué importa. Basta con mirar el engranaje normativo que ya existe: NIS2 art. 21 y 23, DORA art. 28 a 30, GDPR art. 32 a 34 y el propio título III del Cybersecurity Act. Con ese material, la conclusión ya es lo bastante contundente: una certificación europea mejor diseñada puede alterar decisiones de compra, modelos de aseguramiento, expectativas supervisoras y estrategias de terceros en media economía regulada.

Y también puede generar frustración si la Comisión promete agilidad sin resolver la pregunta incómoda de siempre: quién aceptará el certificado, para qué y con qué efectos concretos. Ese es el test de realidad. No el número de comunicados, ni la longitud de las exposiciones de motivos, ni la habitual coreografía de paneles en Bruselas donde todos coinciden en que la ciberseguridad es una prioridad estratégica. A estas alturas, gracias por el recordatorio.

La llamada práctica: deja de tratar la certificación como un asunto de laboratorio

Si diriges cumplimiento, compras tecnológicas, riesgo de terceros o seguridad, este expediente ya no es periférico. La revisión del Cybersecurity Act toca una cuestión muy material: cómo se prueba la confianza técnica en un mercado donde la responsabilidad regulatoria no deja de endurecerse.

Tu siguiente paso no es esperar a una nota final del regulador explicándotelo todo con pulcritud pedagógica. Tu siguiente paso es más prosaico. Reúne a seguridad, legal, compras y riesgo operacional. Identificad qué decisiones dependen hoy de cuestionarios propios, qué evidencia aceptáis de proveedores y qué huecos queréis cubrir con certificación cuando exista una opción fiable. Si no haces ese ejercicio ahora, la reforma te llegará como llegan casi todas las reformas europeas: no como una sorpresa jurídica, sino como un problema operativo que llevaba meses siendo visible para quien quisiera mirar.

La revisión del Cybersecurity Act no resolverá por sí sola la fatiga regulatoria ni la inseguridad técnica del mercado. Pero puede mejorar algo bastante menos vistoso y mucho más útil: la capacidad de distinguir entre confianza demostrada y confianza declamada. En ciberseguridad, esa diferencia sigue siendo la que separa el control real del teatro de cumplimiento. Y de teatro, francamente, ya vamos servidos.