ENISA — Where do SMEs stand in preparing for the Cyber Resilience Act?
El valor de un modelo de madurez no está en la puntuación
ENISA publicó un modelo de evaluación de madurez de ciberresiliencia dirigido a microempresas, pequeñas y medianas empresas, en el contexto de su preparación ante el Cyber Resilience Act. El modelo puede servir para iniciar una conversación, pero no sustituye una decisión técnica, una auditoría ni una evaluación jurídica.
La pregunta útil no es solo «qué nivel tenemos», sino qué productos y servicios están dentro del alcance, qué riesgos afectan a usuarios y operaciones, qué controles existen realmente y qué evidencias permiten comprobar que funcionan.
1. Fijar el alcance antes de evaluar
Empieza por una lista concreta: software propio, aplicaciones web, integraciones, componentes de terceros, servicios cloud y procesos de actualización. No conviene evaluar «la empresa» como un bloque abstracto: el riesgo y la capacidad de respuesta pueden ser distintos entre un portal de clientes, una API y una herramienta interna.
- Responsable funcional y técnico.
- Datos y operaciones soportados.
- Dependencias y proveedores.
- Despliegue, actualización y exposición.
- Evidencias disponibles y huecos conocidos.
2. Convertir la evaluación en preguntas comprobables
Una autoevaluación mejora cuando cada respuesta se puede contrastar. Pregunta si existen criterios de seguridad antes de aceptar una funcionalidad, si se revisan dependencias antes de liberar, si hay separación entre desarrollo y producción, si se registran vulnerabilidades y si se prueban las copias de seguridad y la recuperación.
Clasifica cada respuesta como implementado, parcial, no implementado o no aplicable con justificación. «No aplica» debe explicar quién lo ha decidido y qué evidencia lo sustenta.
3. Separar control, evidencia y resultado
«Existe un procedimiento» describe un control documentado. «El procedimiento se aplicó en estas versiones» describe evidencia de ejecución. «La prueba mostró que el control funciona para este riesgo» describe un resultado de validación. Separar estas frases evita que la documentación aparente más madurez de la que puede demostrarse.
4. Priorizar por riesgo y capacidad de cambio
No todo hueco debe resolverse a la vez. Combina impacto posible, exposición, facilidad de abuso conocida, dependencia de terceros, capacidad de detección, esfuerzo de mitigación y capacidad real del equipo para mantener el control.
El resultado debe convertirse en un backlog con responsable, prioridad y condición de terminado observable. Por ejemplo: inventariar dependencias de una aplicación, registrar la severidad y fecha objetivo de cada vulnerabilidad abierta, o ejecutar una restauración de prueba y corregir el fallo encontrado.
Relación con los servicios de Blue Moon
Este enfoque puede conectarse con un diagnóstico de desarrollo seguro, AppSec, gestión de riesgos, preparación de evidencias o mejora del SGSI. El apoyo técnico debe aclarar alcance, decisiones, evidencias y siguientes pasos; no convierte el modelo en un certificado ni determina por sí mismo la aplicabilidad jurídica del Cyber Resilience Act.
¿Quieres convertir la evaluación en un plan verificable?
Podemos ayudarte a revisar el alcance, priorizar riesgos y definir evidencias mantenibles para tu producto, aplicación o proceso digital.
Solicitar diagnóstico