Preparación CRA para productos digitales

El Reglamento de Ciberresiliencia (CRA) no queda implementado al añadir un requisito a una hoja de cálculo. Un equipo de producto necesita saber a qué producto se aplica, quién responde del trabajo, cuándo vence, por qué se tomó una decisión y dónde encontrar las evidencias.

Las obligaciones de notificación CRA se aplican desde el 11 de septiembre de 2026. La parte principal del reglamento se aplicará desde el 11 de diciembre de 2027. Una parte del modelo operativo debe funcionar ya, mientras el resto debe construirse a tiempo para no reconstruir la documentación técnica al final.

Fechas clave del CRA

Fecha	Qué cambia
11 de septiembre de 2026	Se aplican las obligaciones de notificación del artículo 14
11 de diciembre de 2027	Se aplican las principales obligaciones CRA

Para eventos notificables, el plazo empieza cuando el fabricante toma conocimiento. La Comisión describe una alerta temprana en 24 horas y una notificación completa en 72 horas. El plazo del informe final difiere entre vulnerabilidad explotada activamente e incidente grave.

Consulta el flujo práctico de notificación CRA en 24/72 horas

El CRA trata de un producto, no de una puntuación abstracta de cumplimiento de toda la empresa

La primera pregunta útil es: ¿qué producto concreto con elementos digitales evaluamos?

El reglamento abarca productos de software y hardware y, bajo condiciones definidas, sus soluciones de tratamiento de datos a distancia. También importa el papel de la organización: fabricante, representante autorizado, importador, distribuidor o actor que realiza una modificación sustancial.

Empieza con un registro de un producto:

nombre e identificador único;
versión o familia de versiones;
fabricante y marca bajo la que se comercializa;
cómo se comercializa en el mercado de la UE;
finalidad prevista y funciones principales;
componentes y dependencias;
servicios remotos necesarios para sus funciones;
período de soporte;
personas responsables de seguridad del producto, vulnerabilidades y versiones.

Comprueba cómo evaluar el ámbito CRA de un producto

Siete áreas que deben conectarse

1. Ámbito

Determina si el producto y el papel de la organización están incluidos en CRA. Una etiqueta como «SaaS», «IoT» o «software» no es una evaluación del ámbito.

2. Riesgo del producto

Los requisitos CRA están ligados a una evaluación de riesgos de ciberseguridad del producto. Debe permanecer vinculada a su versión y revisarse al cambiar arquitectura, finalidad prevista o riesgo.

3. Seguridad desde el diseño y por defecto

Un requisito debe convertirse en trabajo de ingeniería: decisión de diseño, acción, responsable, prueba, revisión y evidencia.

Ir a seguridad desde el diseño en CRA

4. Vulnerabilidades y SBOM

El CRA exige identificar y documentar vulnerabilidades y componentes del producto, incluida la elaboración de una lista de materiales del software (SBOM) en formato habitual y legible por máquina que cubra al menos las dependencias de nivel superior.

Consulta por qué una SBOM es entrada del proceso, no resultado final

5. Notificación

La plataforma única de notificación CRA (SRP) está operativa desde el 11 de septiembre de 2026. En la práctica, el fabricante necesita más que acceso al portal: T0 claro, criterios de escalado, responsable de la decisión, cobertura de sustitución e información necesaria para presentar una notificación.

6. Documentación técnica

La documentación no debe ser un archivo de elementos desconectados. Debe hacer trazables producto, versión, arquitectura, evaluación del riesgo, gestión de vulnerabilidades, pruebas, decisiones y fundamento del período de soporte.

Consulta una estructura práctica de documentación técnica CRA

7. Período de soporte

El fabricante determina el período según uso previsto y criterios CRA. Como regla general es de al menos cinco años, salvo que se prevea usar el producto durante menos tiempo.

Consulta cómo documentar el período de soporte

Dónde encaja Pulsar GRC

La encuesta CRA de ENISA a pymes de 2026 ilustra la distancia entre conocimiento y ejecución. En una muestra voluntaria de 194 respuestas, el 66% conocía CRA, el 54% declaró conocimientos limitados o nulos de evaluación de conformidad y el 42% de documentación necesaria. El 73% seleccionó apoyo de documentación técnica.

No debe tratarse como estimación representativa de todo el mercado de la UE: es una muestra pequeña y voluntaria. Sigue siendo útil como señal de que el problema no es simplemente «saber que existe CRA». Los equipos necesitan procesos operativos repetibles.

Pulsar GRC conecta trabajo que suele estar disperso entre documentos, hojas, solicitudes de trabajo y correos:

requisito → riesgo → control o acción → responsable → plazo → documento o evidencia → revisión → historial de decisiones.

Pulsar conecta auditorías, controles, riesgos, documentos, evidencias, informes, CAPA, proveedores y tareas. Es útil para ejecutar y demostrar un proceso sin atribuir al software la determinación jurídica por el cliente.

Pulsar no certifica cumplimiento CRA, no sustituye evaluación jurídica ni decide autónomamente si debe notificarse un evento. Las decisiones de ámbito, clasificación normativa y presentación corresponden a personas responsables.

Empieza con un producto

No empieces con un programa llamado «implantar CRA en toda la empresa». Elige un producto real. Define ámbito, responsables, riesgos actuales, flujo de vulnerabilidades, documentación y período de soporte. Ahí aparecen las brechas que pueden traducirse en acciones.

Consulta Pulsar GRC en un flujo operativo

Plan de trabajo propuesto: una primera revisión con un producto real

Elige un producto suficientemente conocido por el equipo y relevante para la actividad comercial. No selecciones un prototipo vacío solo porque resulte fácil completar sus campos. El piloto debe incluir una versión utilizada, responsables identificables y un cambio reciente que permita comprobar trazabilidad. Las actividades siguientes son una propuesta organizativa; no sustituyen los requisitos del reglamento ni una evaluación individual.

En la primera reunión, producto e ingeniería acuerdan qué se evalúa. Registran funciones, componentes entregados, soluciones remotas y modelo de comercialización. La persona responsable de cumplimiento revisa el papel de la empresa y las cuestiones abiertas. El resultado es una ficha con hechos comprobados y dudas específicas. «Estamos revisando CRA» no permite asignar trabajo; «falta confirmar quién desarrolla el componente remoto» sí.

Después, revisa el proceso actual de vulnerabilidades. Localiza el canal publicado, comprueba quién lo atiende y pregunta qué ocurre si llega un aviso durante una ausencia. Elabora una cronología de un supuesto hipotético y busca qué información permitiría decidir. No envíes una notificación ficticia a un canal oficial de producción. El ensayo prueba decisiones, contactos y registros internos mediante medios adecuados.

Prioriza por efecto y dependencia

Una lista extensa de brechas puede paralizar a una pyme. Clasifica cada carencia según el efecto que puede causar y el trabajo que bloquea. No disponer de responsables de recepción puede afectar un evento actual. No conocer la arquitectura impide completar evaluación de riesgos y documentación. Un índice con formato imperfecto puede tener menor urgencia si las evidencias pertinentes ya se localizan y revisan.

La priorización propuesta combina urgencia, impacto y dependencia. Deja el razonamiento visible y revisa cuando cambien los hechos. Una tarea no debe declararse crítica solo porque tiene un título regulatorio. Tampoco debe posponerse una obligación vigente por resultar incómoda. Dirección necesita conocer dónde falta capacidad y qué decisión material debe tomar.

Para cada acción, escribe una salida verificable. «Preparar documentación» se transforma en «identificar la versión de arquitectura pertinente, obtener revisión de ingeniería y vincularla a la ficha del producto». La segunda formulación permite comprobar cierre. Asigna a una persona responsable del resultado, aunque varias funciones aporten información. Los nombres de departamentos son insuficientes cuando aparece una urgencia.

Un calendario que no mezcle todas las obligaciones

Mantén separadas las obligaciones ya aplicables y la preparación para requisitos principales posteriores. El registro indica fuente, fecha de aplicación y responsable. Cuando una tarea depende de una guía que cambia, registra su fecha de consulta y el motivo de revisar. No conviertas una estimación interna en una fecha legal ni una fecha legal en una recomendación opcional.

Un equipo puede trabajar con revisiones semanales breves durante la preparación y un ritmo diferente después. La frecuencia es una decisión operativa, no una exigencia universal del CRA. Lo importante es que los cambios de producto, vulnerabilidades y documentos lleguen a quienes deben decidir. Una revisión mensual fija puede ser demasiado lenta para un evento notificable y adecuada para otra actividad de mantenimiento.

Simulación: una versión nueva introduce una dependencia

Supón que un producto incorpora una biblioteca distinta para permitir una función solicitada por clientes. La entrega necesita revisar inventario, riesgos, pruebas, instrucciones y soporte. Si cada área modifica su archivo sin una referencia común de versión, la documentación puede terminar describiendo productos diferentes. El piloto debe comprobar que un cambio de ingeniería activa la revisión de los registros pertinentes.

Ingeniería aporta identificadores del componente y pruebas. Producto confirma finalidad y comunicación al usuario. Seguridad evalúa riesgos y vulnerabilidades conocidas. Cumplimiento identifica qué evidencias permiten explicar la decisión. El aprobador revisa las brechas restantes y registra el alcance de su conclusión. La IA puede resumir aportaciones, pero una persona debe comprobar que no ha mezclado versiones ni presentado una actividad pendiente como terminada.

Cuando la versión se publica, conserva un índice del expediente aplicable. No hace falta duplicar cada herramienta de trabajo en Pulsar. Puede utilizarse una referencia estable al resultado y adjuntar documentos pertinentes. Lo que no funciona es un vínculo que abre siempre «la última versión» sin permitir demostrar qué se revisó para la entrega anterior.

Mide capacidad operativa, no solo campos completos

Define pruebas sencillas de funcionamiento. ¿Puede otra persona localizar la decisión de ámbito? ¿Puede el sustituto reconstruir un aviso? ¿Puede ingeniería encontrar la SBOM de una versión suministrada? ¿Coincide la fecha de soporte anunciada con el expediente? Estos resultados describen capacidades que importan. Un porcentaje de campos completos puede ocultar respuestas incorrectas o fuentes obsoletas.

Registra las carencias detectadas por cada prueba, con responsable y criterio de cierre. Si el equipo tarda mucho en localizar evidencia, revisa identificadores o permisos. Si la evidencia no demuestra el control, solicita una verificación distinta. No intentes resolver ambos problemas añadiendo más documentos generales. La acción debe corresponder al mecanismo de fallo.

Qué puede evaluar el primer piloto

El piloto permite comprobar si la organización sabe conectar producto, requisito, decisión y evidencia. También revela trabajo técnico o jurídico que el software no ejecuta por ella. No demuestra por sí solo conformidad completa ni permite extender sus conclusiones a todas las ofertas. Antes de ampliar el alcance, identifica diferencias de arquitectura, operadores económicos y ciclo de vida.

Para probar Pulsar, utiliza un caso limitado y documentos autorizados. Si empleas estándares protegidos, verifica que tus derechos permiten el uso previsto y evita redistribuir su contenido normativo. Los borradores de IA necesitan revisión humana. Al finalizar, compara el recorrido con tu proceso actual mediante criterios observables: localizar una evidencia, asignar una acción y reconstruir una aprobación. La utilidad del piloto se decide por esos resultados, no por una promesa genérica de ahorro.

Fuentes

Fuentes comprobadas: 12 de septiembre de 2026.