Reglamento de Ciberresiliencia: guía para empresas digitales
El Reglamento de Ciberresiliencia no es otra norma europea más para archivar en una carpeta de compliance. Es el paso con el que la Unión Europea empieza a exigir que muchos productos digitales lleguen al mercado con ciberseguridad de serie, actualizaciones previsibles y responsabilidades claras durante su ciclo de vida.
Para una empresa que desarrolla software, vende una app, lanza un dispositivo conectado, integra plugins o encarga tecnología bajo su propia marca, la pregunta ya no es solo si cumple RGPD. La pregunta empieza a ser si puede demostrar que su producto digital ha sido diseñado, documentado y mantenido con criterios reales de seguridad.
Qué es el Reglamento de Ciberresiliencia
El Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act o CRA, crea un marco horizontal de ciberseguridad para productos con elementos digitales. La Comisión Europea lo resume de forma bastante clara: hardware y software deberán diseñarse, actualizarse y mantenerse para proteger a usuarios y empresas frente a amenazas de ciberseguridad.
La idea de fondo es sencilla: si un producto digital se vende en el mercado europeo y puede conectarse directa o indirectamente a una red o dispositivo, no basta con que funcione. Tiene que ser razonablemente seguro, tener soporte, gestionar vulnerabilidades y ofrecer información clara a los usuarios.
Esto afecta especialmente a un tipo de empresa muy habitual en negocios digitales: compañías que no fabrican hardware, pero sí comercializan software, apps, plugins, componentes, plataformas conectadas o soluciones digitales bajo su propia marca.
Las fechas que importan
El CRA ya está en vigor, pero su aplicación es progresiva. Las fechas relevantes son estas:
- 11 de junio de 2026: empiezan a aplicarse las disposiciones sobre notificación de organismos de evaluación de la conformidad.
- 11 de septiembre de 2026: empiezan las obligaciones de informar sobre vulnerabilidades aprovechadas activamente e incidentes graves que afecten a la seguridad de productos con elementos digitales.
- 11 de diciembre de 2027: aplicación general del Reglamento de Ciberresiliencia.
La trampa está en pensar que 2027 queda lejos. Para productos digitales con roadmap, contratos de desarrollo, arquitectura de seguridad, documentación técnica y ciclos de soporte, dos años no es tanto. Si una empresa empieza a prepararlo cuando ya tenga el producto en mercado, probablemente llegará tarde.
Qué es un producto con elementos digitales
El Reglamento habla de productos consistentes en programas informáticos o equipos informáticos, incluidas sus soluciones de procesamiento de datos remoto. Traducido: no se limita a aparatos físicos. También puede alcanzar software, componentes, firmware, apps y determinadas funciones remotas sin las que el producto no cumpliría su finalidad.
Ejemplos claros:
- Dispositivos conectados, wearables, routers, sistemas domóticos o hardware con software integrado.
- Apps móviles que permiten usar, configurar o controlar un producto.
- Firmware y sistemas operativos.
- Componentes software comercializados por separado.
- Software que una empresa vende bajo su marca, aunque haya sido desarrollado por un tercero.
Más delicado es el caso de webs, SaaS y servicios cloud. Una web corporativa normal no debería convertirse automáticamente en un producto con elementos digitales. Un SaaS autónomo tampoco entra siempre por el mero hecho de estar en la nube. Pero si ese servicio remoto es necesario para que un producto con elementos digitales cumpla sus funciones, el análisis cambia.
Esta distinción es importante para negocios digitales: no conviene asumir que todo SaaS entra, pero tampoco conviene asumir que todo SaaS queda fuera. Hay que mirar el producto real, su comercialización, su marca, sus dependencias técnicas y su función.
El punto que muchas empresas no están viendo: quién es fabricante
El CRA define fabricante de forma amplia. No solo es quien programa o fabrica directamente. También puede ser la empresa para la que se diseña, desarrolla o fabrica un producto con elementos digitales y que lo comercializa con su nombre o marca, ya sea de forma remunerada, monetizada o gratuita.
Esto cambia bastante la conversación para fundadores y empresas digitales. Si encargas a una agencia o a un equipo externo el desarrollo de una aplicación, plugin, herramienta o producto digital y luego lo vendes bajo tu marca, puede que no puedas esconderte detrás del proveedor técnico.
En la práctica, esto obliga a revisar contratos de desarrollo, entregables técnicos, responsabilidades de mantenimiento, gestión de vulnerabilidades, documentación, dependencias de terceros y compromisos de soporte. No basta con que el proveedor entregue “la app funcionando”.
Obligaciones principales para fabricantes
El artículo 13 del Reglamento concentra buena parte del cambio. Los fabricantes deberán garantizar que el producto ha sido diseñado, desarrollado y producido conforme a requisitos esenciales de ciberseguridad. Además, tendrán que realizar una evaluación de riesgos y mantenerla integrada durante planificación, diseño, desarrollo, producción, entrega y mantenimiento.
En términos prácticos, esto exige empezar a trabajar con una lógica de producto más madura:
- Evaluación de riesgos de ciberseguridad antes de lanzar.
- Documentación técnica suficiente para demostrar cumplimiento.
- Gestión de vulnerabilidades durante el periodo de soporte.
- Control de componentes de terceros, incluidas librerías open source.
- Proceso de actualizaciones de seguridad.
- Información clara para usuarios sobre uso seguro y soporte.
- Declaración UE de conformidad y marcado CE cuando proceda.
Este es el tipo de obligación que no se arregla con una política genérica descargada de internet. Requiere coordinación entre legal, producto, desarrollo, soporte y dirección.
El calendario de vulnerabilidades empieza antes
Una de las partes más relevantes empieza antes de la aplicación general. Desde el 11 de septiembre de 2026, los fabricantes deberán notificar vulnerabilidades aprovechadas activamente e incidentes graves que repercutan en la seguridad del producto.
La Comisión Europea explica que habrá una plataforma única de notificación. El Reglamento exige alerta temprana en 24 horas, notificación completa en 72 horas y un informe final según el tipo de caso: 14 días después de que exista medida correctora para vulnerabilidades, o un mes para incidentes graves.
Esto implica algo muy concreto: si una empresa no tiene hoy un proceso interno para detectar, clasificar, escalar y documentar vulnerabilidades, no basta con esperar a 2027. El reporting empieza antes.
Qué deberían revisar ya las empresas digitales
Para una empresa digital seria, la pregunta útil no es “¿me afecta el CRA?” en abstracto. La pregunta útil es esta: si mañana tuviera que demostrar control razonable sobre la seguridad de mi producto digital, ¿qué tendría y qué me faltaría?
Checklist inicial:
- Mapa de productos: qué software, apps, plugins, componentes o servicios conectados comercializa la empresa.
- Rol jurídico: si actúa como fabricante, importador, distribuidor o simple comprador/integrador.
- Contratos con proveedores: quién responde por seguridad, documentación, vulnerabilidades, actualizaciones y soporte.
- Inventario técnico: componentes, librerías, dependencias, servicios cloud y software open source crítico.
- Evaluación de riesgos: amenazas razonables, activos protegidos, entorno de uso y consecuencias de incidente.
- Proceso de vulnerabilidades: canal de recepción, clasificación, tiempos de respuesta, corrección y comunicación.
- Soporte: periodo ofrecido, alcance de actualizaciones y fin de vida del producto.
- Documentación: evidencias técnicas y legales que permitan explicar cómo se ha diseñado y mantenido la seguridad.
Esta revisión no solo sirve para cumplir. También mejora la calidad del producto, reduce riesgo contractual y evita vender software con promesas de seguridad que nadie puede sostener.
Por qué esto importa para IA, plugins y SaaS
El CRA llega en un momento incómodo: muchas empresas están lanzando herramientas de IA, automatizaciones, agentes, plugins y productos digitales a una velocidad superior a su madurez legal y técnica.
Si una empresa vende una solución que conecta con datos, sistemas, cuentas, APIs, workflows o información sensible, el riesgo ya no es solo privacidad. También es seguridad del producto, ciclo de vida, dependencias, actualizaciones y capacidad de reacción ante vulnerabilidades.
Esto afecta especialmente a:
- Plugins y extensiones comercializadas para WordPress, ecommerce o CRMs.
- SaaS que dependen de APIs, conectores o tratamiento remoto imprescindible.
- Apps móviles conectadas a plataformas o dispositivos.
- Herramientas de IA integradas en procesos de clientes.
- Empresas que encargan software a terceros y lo venden bajo marca propia.
El error sería tratar el CRA como una obligación técnica que se delega al desarrollador. La dirección tiene que entender qué se está vendiendo, bajo qué marca, con qué soporte, con qué dependencias y con qué evidencias.
Mi lectura: compliance de producto, no papeleo
El Reglamento de Ciberresiliencia empuja a las empresas digitales hacia una idea incómoda pero necesaria: si vendes tecnología, tienes que gobernar el riesgo tecnológico. No basta con externalizar desarrollo y confiar en que “el proveedor sabrá”.
Para muchos negocios, el primer paso no será contratar una auditoría enorme. Será algo más básico y más útil: inventariar productos, entender roles, revisar contratos, documentar dependencias, definir soporte y crear un proceso de vulnerabilidades antes de que llegue el primer incidente.
Quien haga esto pronto tendrá una ventaja comercial. Podrá vender software, IA o producto digital con más confianza, responder mejor a clientes grandes y evitar improvisar cuando una vulnerabilidad deje de ser un problema técnico y pase a ser un problema legal, reputacional y comercial.
Fuentes y lectura recomendada
- Comisión Europea: Cyber Resilience Act
- Comisión Europea: implementación del CRA
- Comisión Europea: obligaciones de fabricantes
- Comisión Europea: reporting de vulnerabilidades e incidentes
- Reglamento (UE) 2024/2847 en EUR-Lex
Si estás desarrollando, comprando o lanzando un producto digital y no tienes claro si el Reglamento de Ciberresiliencia puede afectarte, merece la pena revisarlo antes de que el roadmap técnico esté cerrado. En una consultoría 1:1 podemos aterrizar tu caso, identificar riesgos y salir con un plan de acción claro para producto, contratos, proveedores y cumplimiento.
