[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:la-evaluacion-de-riesgos-de-ciberseguridad-del-cra-lo-que-el-articulo-13-exige-realmente":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","la-evaluacion-de-riesgos-de-ciberseguridad-del-cra-lo-que-el-articulo-13-exige-realmente","La evaluación de riesgos de ciberseguridad del CRA: lo que el artículo 13 exige realmente, y el único resultado que debe producir","El artículo 13, apartados 2 a 4, del Reglamento de Ciberresiliencia convierte la evaluación de riesgos en el documento del que cuelga cualquier otra obligación del CRA. Debe analizar los riesgos a partir de la finalidad prevista, el uso previsible y las condiciones de uso durante el tiempo de uso esperado; decir si y cómo se aplica cada requisito del punto 2 de la parte I; decir cómo se aplican el punto 1 de la parte I y la parte II; estar documentada, mantenida al día durante el período de soporte e incluida en la documentación técnica, con una justificación clara de cada requisito excluido. Los cuatro apartados, y una estructura de una página que los satisface.","2026-09-11","\nPregunte qué tiene que hacer primero un fabricante según el Reglamento de Ciberresiliencia, Reglamento (UE) 2024\u002F2847, y la mayoría de las respuestas dirán «la documentación técnica». El Reglamento dice algo más estrecho: antes del expediente, antes de aplicar los [22 requisitos](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist), hay una **evaluación de riesgos de ciberseguridad**, y es el documento que decide qué requisitos se aplican a su producto y justifica cada uno que deja fuera. El artículo 13, apartados 2 a 4, la describe. Son cortos e inusualmente concretos sobre lo que debe contener la evaluación.\n\n## Para qué sirve: artículo 13, apartado 2\n\nEl fabricante «llevará a cabo una evaluación de los riesgos de ciberseguridad asociados a un producto con elementos digitales y tendrá en cuenta el resultado de dicha evaluación durante las fases de planificación, diseño, desarrollo, producción, entrega y mantenimiento», con el fin de minimizar los riesgos de ciberseguridad, prevenir incidentes y minimizar su impacto, «también en relación con la salud y la seguridad de los usuarios».\n\nDe ahí se siguen dos cosas. Es un documento del ciclo de vida, no del lanzamiento: el resultado se tiene en cuenta desde la planificación hasta el mantenimiento. Y la salud y la seguridad están en el ámbito: un producto cuya vulneración pudiera herir a alguien tiene que decirlo y tratar ese riesgo.\n\n## Qué debe contener: artículo 13, apartado 3\n\nEl apartado 3 es el que hay que leer despacio, porque enumera el contenido.\n\n**Documentada y actualizada.** «La evaluación de riesgos de ciberseguridad se documentará y actualizará según proceda durante un período de soporte.» Una evaluación hecha una vez en el lanzamiento y nunca revisada no es lo que describe el texto; se actualiza cuando cambian el producto, su entorno y la amenaza, mientras corra el [período de soporte](\u002Farticles\u002Fhow-long-is-the-cra-support-period).\n\n**Un análisis basado en el uso.** «Comprenderá al menos un análisis de los riesgos de ciberseguridad basado en la finalidad prevista y el uso razonablemente previsible, así como en las condiciones de uso, del producto con elementos digitales, como el entorno operativo o los activos que deban protegerse, teniendo en cuenta el tiempo durante el que se espera que el producto esté en uso.» Así que las entradas están nombradas: para qué es el producto, cómo se usará y se usará indebidamente de forma previsible, dónde funciona, qué protege y durante cuánto tiempo.\n\n**Una decisión sobre cada requisito del punto 2 de la parte I.** «Indicará si los requisitos de seguridad establecidos en el anexo I, parte I, punto 2, son aplicables al producto con elementos digitales de que se trate y, en su caso, de qué manera, y cómo se aplican dichos requisitos según lo determinado por la evaluación de riesgos de ciberseguridad.» Esta es la frase que convierte la evaluación en la columna vertebral del expediente: para cada una de las trece propiedades «cuando proceda», aplicable o no, y si lo es, cómo se implementa.\n\n**Una declaración sobre el punto 1 de la parte I y la parte II.** «Indicará también cómo va a aplicar el fabricante el anexo I, parte I, punto 1, y los requisitos de gestión de vulnerabilidades establecidos en el anexo I, parte II.» El punto 1 (un nivel de ciberseguridad adecuado) y los ocho requisitos de gestión de vulnerabilidades se aplican siempre; la evaluación dice cómo.\n\n## Dónde va, y la regla de justificación: artículo 13, apartado 4\n\nLa evaluación se incluye en la documentación técnica ([anexo VII, punto 3](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point)). Cuando un producto también está sujeto a otro Derecho de la Unión con su propia evaluación de riesgos, las dos pueden ser un solo documento. Y la frase que más importa: «Cuando determinados requisitos esenciales de ciberseguridad no sean aplicables al producto con elementos digitales, el fabricante incluirá una justificación clara al respecto en dicha documentación técnica.»\n\nUna exclusión sin motivo escrito es una laguna. Un motivo que no procede del análisis de riesgos («no tuvimos tiempo», «nuestros competidores no lo hacen») no es el tipo de justificación que pide el texto.\n\n## Una estructura de una página que satisface los cuatro apartados\n\nEl Reglamento no prescribe un método. Cualquier método estructurado sirve si su resultado cubre el contenido anterior. Uno que lo hace, en el orden que el texto sugiere:\n\n1. **Producto y finalidad prevista.** Qué es, para qué sirve, las versiones cubiertas y el tiempo de uso esperado (que también alimenta el período de soporte).\n2. **Uso previsible y uso indebido, y condiciones de uso.** Quién lo usa, dónde funciona, a qué se conecta, qué protege (los activos) y cómo es un uso indebido razonable.\n3. **Amenazas y riesgos.** Para cada activo e interfaz, qué podría salir mal, con qué probabilidad, con qué gravedad, incluidas la salud y la seguridad cuando proceda. Cualquier método reconocido (un modelo de amenazas, un árbol de ataque, un registro puntuado) vale; el texto pide un análisis, no una forma concreta.\n4. **La tabla del punto 2 de la parte I.** Trece filas, letras a) a m): aplicable sí o no; si sí, cómo se implementa; si no, el motivo extraído del paso 3. Esta tabla es el entregable que un organismo notificado o una autoridad lee primero.\n5. **Punto 1 de la parte I y parte II.** Cómo se alcanza en conjunto el nivel de ciberseguridad adecuado, y cómo se cumple en la práctica cada uno de los ocho requisitos de gestión de vulnerabilidades: la [SBOM](\u002Farticles\u002Fdoes-the-cra-require-an-sbom), la política de divulgación, el canal de actualizaciones, el punto de contacto.\n6. **Revisión.** Quién es responsable, cuándo se revisa la próxima vez y qué desencadena una revisión anticipada (una nueva versión, un nuevo entorno, una vulnerabilidad notificada). La evaluación se actualiza durante el período de soporte, y esta sección dice cómo.\n\nFéchela, versiónela y archívela con la documentación técnica. Cuando el producto cambie, cambie primero la evaluación y después el expediente, porque el expediente es la consecuencia de la evaluación, no al revés.\n\n## Lo que no necesita ser\n\nNo necesita ser larga: el texto pide «al menos» un análisis y las dos indicaciones, y un documento breve que resuelva cada decisión es mejor que uno largo que no resuelva ninguna. No necesita la metodología de un consultor, aunque una existente (ISO\u002FIEC 27005, una práctica de modelado de amenazas ya en uso) puede reutilizarse siempre que su resultado se corresponda con las trece filas y la declaración sobre la parte II. Y no necesita esperar a una norma armonizada: [no se ha publicado ninguna](\u002Farticles\u002Fthe-eu-s-own-cra-machinery-on-the-day-the-duty-started), y la evaluación es lo que un fabricante tiene en su lugar.\n\n## Qué añaden las FAQ de la Comisión\n\nLas FAQ de la Comisión sobre la aplicación, versión 1.4 de 4 de septiembre de 2026, sección 4.1, zanjan cinco cosas que el Reglamento deja al lector.\n\n**No se impone ninguna metodología.** Entrada 4.1.2: «El CRA no impone una metodología específica de evaluación de riesgos de ciberseguridad». Lo que pide es que el método «ayude a los fabricantes a documentar» que se ha tratado cada riesgo pertinente, para que una autoridad «pueda verificar cómo se han identificado, evaluado y mitigado los riesgos», y que el modelo de amenazas se ajuste al producto: los productos para infraestructuras críticas «pueden tener que tratar riesgos relacionados con actores estatales y amenazas persistentes avanzadas», mientras que los productos de consumo «suelen tener un perfil de riesgo más bajo y pueden usar un modelo de amenazas distinto».\n\n**La parte II siempre, la parte I según los riesgos.** Entrada 4.1.3: los requisitos de gestión de vulnerabilidades del anexo I, parte II, se aplican íntegramente «durante todo el periodo de soporte del producto», mientras que para las propiedades del producto de la parte I el fabricante «debe determinar, sobre la base de la evaluación de riesgos de ciberseguridad, cuáles de esos requisitos son pertinentes». Un requisito descartado necesita «una justificación clara en la evaluación de riesgos de ciberseguridad incluida en la documentación técnica». El ejemplo de las FAQ son los datos personales: un producto cuya finalidad prevista no incluye el tratamiento de datos personales puede no necesitar ninguna medida para su protección, y cuando una norma de interoperabilidad que el producto debe seguir (considerando 55) hace inaplicable un requisito pero deja un riesgo, el riesgo se trata «por otros medios, por ejemplo limitando la finalidad prevista del producto a entornos de confianza y\u002Fo informando a los usuarios».\n\n**Una evaluación puede servir a varios actos.** Entrada 4.1.1: un fabricante «puede realizar una única evaluación de riesgos que cubra las necesidades de distintas legislaciones», siempre que pueda «demostrar el cumplimiento de cada legislación individual». La evaluación cubre «todo el producto con elementos digitales, incluido el tratamiento remoto de datos cuando esté en el ámbito», y cada fase, de la planificación al mantenimiento, para todos los niveles.\n\n**La finalidad prevista es lo que usted publica.** Entrada 4.1.4 con el artículo 3(23): la finalidad prevista es el uso que el fabricante especifica «en las instrucciones de uso, en los materiales y declaraciones promocionales o de venta, así como en la documentación técnica», y cuando el producto permite al usuario alterar configuraciones o rebajar la seguridad por compatibilidad con sistemas antiguos, esos usos entran en la evaluación, reciben su propio tratamiento y se describen en las instrucciones.\n\n**El uso indebido previsible también está dentro.** Entrada 4.1.5 con el artículo 3(24): desplegar un producto «en una red insegura» cuando las instrucciones exigen una red segura «podría constituir un uso indebido razonablemente previsible», y los riesgos del uso indebido previsible «deben comunicarse también en la información e instrucciones al usuario» conforme al anexo II, punto 5. Hackear el propio dispositivo por diversión o investigación es uso indebido en este sentido, no uso previsto.\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, artículo 13, apartados 1 a 4 (citados), artículo 13, apartado 8, para el período de soporte, artículo 31 y anexo VII, punto 3, para el expediente, anexo I, partes I y II. Leído en el texto del Diario Oficial en EUR-Lex el 11 de septiembre de 2026.\n- Comisión Europea, FAQ sobre el Cyber Resilience Act, versión 1.4 de 4 de septiembre de 2026, entradas 4.1.1 a 4.1.5.\n\nEsto no es asesoramiento jurídico. El artículo 13, apartado 3, es un párrafo; léalo frente a su propia evaluación y compruebe que cada contenido nombrado está ahí.\n",1789383976466]