A quién obliga

Por producto conectado y papel en la cadena

Roles en la cadena
Asimilados a fabricante
Régimen propio
Roles que reparte

Notificación
de incidentes

A quién se notifica
Autoridad
CSIRT
Afectados
Público
Cadena

Régimen sancionador

Calendario ciber

Calendario ciber

29/10/2025

Publicación del Reglamento Delegado (UE) 2025/1535, que excluye de la aplicación del CRA los productos comprendidos en el ámbito del Reglamento (UE) n.o 168/2013 (vehículos de dos y tres ruedas y cuatriciclos), salvo los de la categoría L1e diseñados para funcionar a pedal, que siguen dentro. Entra en vigor a los veinte días de su publicación.

Art. 2.5 · Reglamento Delegado (UE) 2025/1535, art. 1 · fuente oficial ↗

Calendario ciber

01/12/2025

Publicación del Reglamento de Ejecución (UE) 2025/2392, que fija la descripción técnica de las categorías de productos importantes de las clases I y II del anexo III y de los productos críticos del anexo IV. De esa descripción depende qué procedimiento de evaluación de la conformidad corresponde a cada producto y si cabe la autoevaluación. Entra en vigor a los veinte días de su publicación.

Art. 7.4 · Reglamento de Ejecución (UE) 2025/2392 · fuente oficial ↗

Calendario ciber

20/04/2026

Publicación del Reglamento Delegado (UE) 2026/881, que especifica en qué condiciones el CSIRT que recibe inicialmente una notificación de los artículos 14 o 15 puede aplazar su difusión a los demás CSIRT coordinadores: entre ellas, que el fabricante haya informado de que espera disponer de una medida de reducción de riesgos en setenta y dos horas, o que lo notificado baste para construir una técnica de aprovechamiento de la vulnerabilidad. Entra en vigor a los veinte días de su publicación.

Art. 14.9 y art. 16.2 · Reglamento Delegado (UE) 2026/881 · fuente oficial ↗

Calendario ciber

11/09/2026

Aplicación del artículo 14: notificación de vulnerabilidades aprovechadas activamente e incidentes graves. Quince meses antes que el resto del Reglamento, y alcanza también a los productos ya comercializados.

Art. 71.2 · art. 69.3

Calendario ciber

26/03/2027

Es aplicable el artículo 104 del Reglamento (UE) 2025/327, del Espacio Europeo de Datos de Salud, que modifica el CRA: los fabricantes de productos con elementos digitales considerados sistemas de historia clínica electrónica demuestran la conformidad con los requisitos esenciales del anexo I por el procedimiento de evaluación del capítulo III de ese Reglamento, y no por el del CRA. La fecha es la de aplicación general del Reglamento (UE) 2025/327; su artículo 104 no figura entre las disposiciones de aplicación diferida.

Art. 32.5 bis · Reglamento (UE) 2025/327, arts. 104 y 105 · fuente oficial ↗

Calendario ciber

11/12/2027

Aplicación general del Reglamento: requisitos esenciales del anexo I, obligaciones de los operadores, evaluación de la conformidad y marcado CE.

Art. 71.2

Calendario ciber

11/12/2027

Surte efecto la derogación del Reglamento Delegado (UE) 2022/30, acordada por el Reglamento Delegado (UE) 2026/339, de 16 de febrero de 2026. Los requisitos esenciales del artículo 3, apartado 3, letras d), e) y f), de la Directiva 2014/53/UE dejan de aplicarse a los equipos radioeléctricos, cuya ciberseguridad pasa a regirse por el anexo I del CRA. Los equipos introducidos en el mercado entre el 1 de agosto de 2025 y el 10 de diciembre de 2027 siguen sujetos a esos requisitos y a su vigilancia del mercado.

Reglamento Delegado (UE) 2026/339, art. 1 y considerandos 3 a 5 · Directiva 2014/53/UE, art. 3.3, letras d), e) y f) · fuente oficial ↗

Calendario ciber

11/06/2028

Caducan los certificados de examen de tipo UE y las decisiones de aprobación expedidos sobre requisitos de ciberseguridad bajo otra legislación de armonización de la Unión.

Art. 69.1

Qué implantar

Notificación de vulnerabilidades e incidentes
Requisitos esenciales del anexo I
Deberes del fabricante
Resto de la cadena
Régimen del código abierto

Mapa NIST CSF

GOBERNAR NIST CSF 2.0 IDENTIFICAR Identificar · 4 medidas PROTEGER Proteger · 3 medidas DETECTAR Detectar · 0 medidas RESPONDER Responder · 2 medidas RECUPERAR Recuperar · 0 medidas
12 medidas sobre NIST CSF 2.0 Elige una función en la rueda o en la lista para ver sus categorías y medidas.

Gobernar GV

GV.OC Contexto organizativo
GV.RM Estrategia de gestión de riesgos
GV.PO Política
GV.SC Gestión de riesgos de la cadena de suministro de seguridad cibernética

Identificar ID

ID.AM Gestión de activos
ID.RA Evaluación de riesgos
ID.IM Mejora

Proteger PR

PR.PS Seguridad de la plataforma
PR.IR Resiliencia de la infraestructura tecnológica

Responder RS

RS.MA Gestión de incidentes
RS.AN Análisis de incidentes
RS.CO Notificación y comunicación de la respuesta al incidente
RS.MI Mitigación de incidentes
Sanción

Requisitos esenciales y deberes del fabricante · techo del Reglamento

Conducta
Incumplir los requisitos esenciales de ciberseguridad del anexo I o las obligaciones de los artículos 13 y 14: deberes del fabricante y notificación
Importe
Hasta 15 000 000 EUR o, si el infractor es una empresa, hasta el 2,5 % del volumen de negocio total anual mundial del ejercicio financiero anterior, la cuantía que sea superior

Art. 64.2

Sanción

Resto de la cadena y organismos notificados · techo del Reglamento

Conducta
Incumplir las obligaciones del resto de la cadena y de los organismos notificados: arts. 18 a 23, 28, 30, 31, 32, 33.5, 39, 41, 47, 49 y 53
Importe
Hasta 10 000 000 EUR o el 2 % del volumen de negocio total anual mundial del ejercicio financiero anterior, la cuantía que sea superior

Art. 64.3

Sanción

Información engañosa a las autoridades · techo del Reglamento

Conducta
Presentar información incorrecta, incompleta o engañosa a organismos notificados y a las autoridades de vigilancia del mercado en respuesta a una solicitud
Importe
Hasta 5 000 000 EUR o el 1 % del volumen de negocio total anual mundial del ejercicio financiero anterior, la cuantía que sea superior

Art. 64.4

Régimen sancionador · todo el detalle

Escalones

Requisitos esenciales y deberes del fabricante · techo del Reglamento

Incumplir los requisitos esenciales de ciberseguridad del anexo I o las obligaciones de los artículos 13 y 14: deberes del fabricante y notificación

Hasta 15 000 000 EUR o, si el infractor es una empresa, hasta el 2,5 % del volumen de negocio total anual mundial del ejercicio financiero anterior, la cuantía que sea superior

Art. 64.2
Resto de la cadena y organismos notificados · techo del Reglamento

Incumplir las obligaciones del resto de la cadena y de los organismos notificados: arts. 18 a 23, 28, 30, 31, 32, 33.5, 39, 41, 47, 49 y 53

Hasta 10 000 000 EUR o el 2 % del volumen de negocio total anual mundial del ejercicio financiero anterior, la cuantía que sea superior

Art. 64.3
Información engañosa a las autoridades · techo del Reglamento

Presentar información incorrecta, incompleta o engañosa a organismos notificados y a las autoridades de vigilancia del mercado en respuesta a una solicitud

Hasta 5 000 000 EUR o el 1 % del volumen de negocio total anual mundial del ejercicio financiero anterior, la cuantía que sea superior

Art. 64.4

Matices

  • El artículo 14 está en el escalón más caro, junto a los requisitos esenciales del producto. Llegar tarde a la alerta de 24 horas se expone al mismo techo que vender un producto inseguro.
  • Hay dos exenciones completas. Las microempresas y pequeñas empresas no pueden ser multadas por incumplir los plazos de alerta temprana (solo esos: no las 72 horas ni los informes finales), y los administradores de comunidad de código abierto quedan fuera de las multas por cualquier infracción del Reglamento (art. 64.10).
  • Esa primera exención llegó a estar rota. El texto publicado remitía a los «apartados 3 a 9», pero la multa por incumplir el art. 14 vive en el apartado 2, así que la exención no cubría la multa de la que pretendía eximir. La corrección de errores de 2 de julio de 2025 lo cambió a «apartados 2 a 9».
  • El porcentaje solo entra en juego si el infractor es una empresa; para quien no lo sea, el techo es el importe fijo. Y la multa es adicional, no alternativa, a las medidas correctoras o restrictivas por la misma infracción (art. 64.9).
  • Además de la multa hay vía de acción colectiva: la Directiva (UE) 2020/1828 se aplica a las infracciones del Reglamento que perjudiquen los intereses colectivos de los consumidores (art. 65).

En España

El Reglamento fija los techos, pero deja a cada Estado establecer el régimen concreto, designar la autoridad de vigilancia del mercado que sanciona y decidir si se puede multar a sus propias autoridades y organismos públicos. Mientras España no lo haga (y no se ha verificado que lo haya hecho), no se puede afirmar qué autoridad sancionaría ni con qué procedimiento.

Aviso

Los dos informes finales no comparten reloj ni disparador, y ahí es donde se falla. El de la vulnerabilidad son catorce días desde que existe una medida correctora o paliativa: puede vencer meses después, o no vencer nunca mientras no haya remedio. El del incidente es un mes desde que se presentó la notificación de las 72 horas, y vence haya parche o no. Un procedimiento interno que trate «el informe final» como un hito único llegará tarde a uno de los dos.

Notificación de incidentes

Alerta temprana de una vulnerabilidad aprovechada activamente

Plazo
24 horas
Desde cuándo corre
Desde que el fabricante tiene conocimiento de la vulnerabilidad aprovechada activamente

Art. 14.2.a)

Notificación de incidentes

Notificación de la vulnerabilidad

Plazo
72 horas
Desde cuándo corre
Desde el conocimiento de la vulnerabilidad, no desde la alerta temprana

Art. 14.2.b)

Notificación de incidentes

Informe final de la vulnerabilidad

Plazo
14 días
Desde cuándo corre
Desde que se dispone de una medida correctora o paliativa. No desde el conocimiento ni desde la notificación: si no hay remedio, no corre

Art. 14.2.c)

Notificación de incidentes

Alerta temprana de un incidente grave que repercute en la seguridad del producto

Plazo
24 horas
Desde cuándo corre
Desde que el fabricante tiene conocimiento del incidente. Debe indicar ya si se sospecha que se debe a actos ilegales o malintencionados

Art. 14.4.a)

Notificación de incidentes

Notificación del incidente

Plazo
72 horas
Desde cuándo corre
Desde el conocimiento del incidente

Art. 14.4.b)

Notificación de incidentes

Informe final del incidente

Plazo
1 mes
Desde cuándo corre
Desde que se presentó la notificación del incidente de las 72 horas, no desde el conocimiento ni desde el cierre

Art. 14.4.c)

Notificación de incidentes

Informe provisional con actualizaciones de la situación

Plazo
Sin plazo: lo pide el CSIRT designado como coordinador cuando lo necesita
Desde cuándo corre
Lo fija quien lo pide

Art. 14.6

A quién se notifica

El CSIRT designado como coordinador y la ENISA, simultáneamente

Cuándo
Todas las notificaciones del art. 14, por la plataforma única de notificación que gestiona la ENISA. No son dos envíos: es uno que llega a ambos por diseño
En España
Qué CSIRT ocupa este papel depende del art. 12.1 de la Directiva NIS2, que España no ha transpuesto, así que la designación formal a efectos del CRA está pendiente. Los CSIRT de referencia hoy son INCIBE-CERT para el sector privado, que es donde está el fabricante típico, y CCN-CERT para el sector público. La ENISA sí es destinataria directa y europea, sin ventanilla española.

Art. 14.1, 14.3 y 14.7 · art. 16

A quién se notifica

Los usuarios del producto

Cuándo
Una vez el fabricante tiene conocimiento de la vulnerabilidad o del incidente. A los afectados y, cuando proceda, a todos. Si no lo hace a tiempo, el CSIRT puede informarles en su lugar

Art. 14.8

A quién se notifica

El público

Cuándo
Cuando haga falta sensibilizar para prevenir o mitigar un incidente, o la divulgación sea de interés público. Decide el CSIRT coordinador, previa consulta al fabricante, y puede informar él o exigir al fabricante que lo haga

Art. 17.2

A quién se notifica

Las autoridades de vigilancia del mercado

Cuándo
Por vía distinta del art. 14: importadores y distribuidores que detectan un riesgo de ciberseguridad significativo avisan inmediatamente, y el fabricante que cesa su actividad avisa antes de que el cese surta efecto
En España
Pendiente. El art. 52.2 obliga a cada Estado a designar una o varias autoridades de vigilancia del mercado, y no se ha verificado contra fuente primaria española que España lo haya hecho. Sí está cerrado en el texto que, si el producto es además un sistema de IA de alto riesgo, quien vigila es la autoridad designada bajo el Reglamento de IA.

Art. 19.5 · art. 20.4 · art. 13.23

Notificación de incidentes · todo el detalle

Qué es notificable

Dos cosas distintas con relojes propios, notificadas por el mismo canal. Una, cualquier vulnerabilidad aprovechada activamente presente en el producto: no basta con que sea explotable, hace falta prueba fiable de que alguien la ha explotado de verdad. Y dos, cualquier incidente grave que repercuta en la seguridad del producto, entendiendo por grave el que afecta (o puede afectar) a la capacidad del producto de proteger disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, o el que ha llevado (o puede llevar) a que se ejecute código malicioso en el producto o en la red del usuario. Obliga al fabricante.

Literal de la norma «vulnerabilidad aprovechada activamente»: vulnerabilidad respecto de la cual existen pruebas fiables de que un agente malintencionado la ha aprovechado en un sistema sin autorización del propietario del sistema

Los dos informes finales no comparten reloj ni disparador, y ahí es donde se falla. El de la vulnerabilidad son catorce días desde que existe una medida correctora o paliativa: puede vencer meses después, o no vencer nunca mientras no haya remedio. El del incidente es un mes desde que se presentó la notificación de las 72 horas, y vence haya parche o no. Un procedimiento interno que trate «el informe final» como un hito único llegará tarde a uno de los dos.

Supuestos y plazos

Alerta temprana de una vulnerabilidad aprovechada activamente

24 horas

Desde que el fabricante tiene conocimiento de la vulnerabilidad aprovechada activamente

Art. 14.2.a)
Notificación de la vulnerabilidad

72 horas

Desde el conocimiento de la vulnerabilidad, no desde la alerta temprana

Art. 14.2.b)
Informe final de la vulnerabilidad

14 días

Desde que se dispone de una medida correctora o paliativa. No desde el conocimiento ni desde la notificación: si no hay remedio, no corre

Art. 14.2.c)
Alerta temprana de un incidente grave que repercute en la seguridad del producto

24 horas

Desde que el fabricante tiene conocimiento del incidente. Debe indicar ya si se sospecha que se debe a actos ilegales o malintencionados

Art. 14.4.a)
Notificación del incidente

72 horas

Desde el conocimiento del incidente

Art. 14.4.b)
Informe final del incidente

1 mes

Desde que se presentó la notificación del incidente de las 72 horas, no desde el conocimiento ni desde el cierre

Art. 14.4.c)
Informe provisional con actualizaciones de la situación

Sin plazo: lo pide el CSIRT designado como coordinador cuando lo necesita

Lo fija quien lo pide

Art. 14.6

A quién se notifica

El CSIRT designado como coordinador y la ENISA, simultáneamente

Todas las notificaciones del art. 14, por la plataforma única de notificación que gestiona la ENISA. No son dos envíos: es uno que llega a ambos por diseño

Art. 14.1, 14.3 y 14.7 · art. 16
Los usuarios del producto

Una vez el fabricante tiene conocimiento de la vulnerabilidad o del incidente. A los afectados y, cuando proceda, a todos. Si no lo hace a tiempo, el CSIRT puede informarles en su lugar

Art. 14.8
El público

Cuando haga falta sensibilizar para prevenir o mitigar un incidente, o la divulgación sea de interés público. Decide el CSIRT coordinador, previa consulta al fabricante, y puede informar él o exigir al fabricante que lo haga

Art. 17.2
Las autoridades de vigilancia del mercado

Por vía distinta del art. 14: importadores y distribuidores que detectan un riesgo de ciberseguridad significativo avisan inmediatamente, y el fabricante que cesa su actividad avisa antes de que el cese surta efecto

Art. 19.5 · art. 20.4 · art. 13.23
A quién obliga

Fabricantes

Fabricante: quien desarrolla o fabrica el producto, o para quien se diseña, y lo comercializa con su nombre o marca, «ya sea de manera remunerada, monetizada o gratuita» (art. 3.13)

Ejemplo Quien desarrolla un router doméstico, una cámara de vigilancia o una aplicación de escritorio y la comercializa bajo su marca es fabricante, y lo sigue siendo si la distribuye gratis.
Roles que emanan
A quién obliga

Importadores y distribuidores

Importador y distribuidor: el primero introduce en el mercado un producto con nombre o marca de alguien establecido fuera de la Unión; el segundo lo comercializa «sin influir sobre sus propiedades» (arts. 3.16 y 3.17)

Ejemplo La empresa que trae al mercado europeo un termostato inteligente de un fabricante asiático es importador; la cadena de tiendas que lo revende sin tocarlo, distribuidor.
Roles que emanan
A quién obliga

Representantes autorizados

Representante autorizado: establecido en la Unión y con mandato escrito, pero con un núcleo indelegable: diseño, evaluación de riesgos, gestión de vulnerabilidades y conformidad de la producción se quedan con el fabricante (arts. 3.15 y 18.2)

Ejemplo El fabricante de fuera de la Unión que nombra por mandato escrito a alguien establecido aquí para guardar su documentación y responder a las autoridades usa un representante autorizado, que no puede asumir el diseño ni la gestión de vulnerabilidades.
Roles que emanan
A quién obliga

Quien modifica sustancialmente

Quien modifica sustancialmente un producto ya comercializado pasa a ser fabricante y asume los artículos 13 y 14, sea importador, distribuidor o un tercero cualquiera (arts. 21 y 22)

Ejemplo El integrador que toma un producto ya comercializado y le hace una modificación sustancial pasa a ser fabricante: de la parte afectada, o del producto entero si la modificación afecta a su ciberseguridad en conjunto.
Roles que emanan
A quién obliga

Administradores de código abierto

Administrador de comunidad de programas informáticos de código abierto: persona jurídica que da soporte sistemático y sostenido a productos destinados a actividades comerciales. Régimen propio y más ligero (arts. 3.14 y 24)

Ejemplo La fundación que sostiene de forma sistemática un componente de código abierto destinado a actividades comerciales tiene obligaciones propias, mucho más ligeras, y queda fuera de las multas.
Roles que emanan
A quién obliga

Exclusiones

Productos sanitarios y productos sanitarios para diagnóstico in vitro (Reglamentos 2017/745 y 2017/746), y vehículos de motor y sus remolques (Reglamento 2019/2144).

Art. 2.2

Productos certificados conforme al Reglamento (UE) 2018/1139, de aviación civil, y equipos marinos de la Directiva 2014/90/UE.

Art. 2.3 y 2.4

Piezas de recambio que sustituyen componentes idénticos y se fabrican con las mismas especificaciones que los componentes a los que sustituyen.

Art. 2.6

Productos desarrollados o modificados exclusivamente con fines de seguridad nacional o defensa, y los diseñados específicamente para el tratamiento de información clasificada.

Art. 2.7

Vehículos de dos y tres ruedas y cuatriciclos del Reglamento (UE) n.o 168/2013, excluidos por acto delegado. Las bicicletas eléctricas de pedaleo asistido (L1e) siguen dentro: la exclusión no les alcanza.

Art. 2.5 · Reglamento Delegado (UE) 2025/1535
A quién obliga · todo el detalle

No obliga por sector ni por tamaño de empresa: obliga por producto y por el papel que se juega en su cadena de suministro. Entra casi cualquier producto de programas o equipos informáticos cuyo uso previsible incluya conectarse a un dispositivo o a una red, aunque la conexión sea indirecta. Y alcanza al software que se regala: la definición de fabricante incluye el suministro gratuito.

Roles en la cadena

Fabricantes

Fabricante: quien desarrolla o fabrica el producto, o para quien se diseña, y lo comercializa con su nombre o marca, «ya sea de manera remunerada, monetizada o gratuita» (art. 3.13)

Importadores y distribuidores

Importador y distribuidor: el primero introduce en el mercado un producto con nombre o marca de alguien establecido fuera de la Unión; el segundo lo comercializa «sin influir sobre sus propiedades» (arts. 3.16 y 3.17)

Representantes autorizados

Representante autorizado: establecido en la Unión y con mandato escrito, pero con un núcleo indelegable: diseño, evaluación de riesgos, gestión de vulnerabilidades y conformidad de la producción se quedan con el fabricante (arts. 3.15 y 18.2)

Asimilados a fabricante

Quien modifica sustancialmente

Quien modifica sustancialmente un producto ya comercializado pasa a ser fabricante y asume los artículos 13 y 14, sea importador, distribuidor o un tercero cualquiera (arts. 21 y 22)

Régimen propio

Administradores de código abierto

Administrador de comunidad de programas informáticos de código abierto: persona jurídica que da soporte sistemático y sostenido a productos destinados a actividades comerciales. Régimen propio y más ligero (arts. 3.14 y 24)

Exclusiones

Productos sanitarios y productos sanitarios para diagnóstico in vitro (Reglamentos 2017/745 y 2017/746), y vehículos de motor y sus remolques (Reglamento 2019/2144).

Art. 2.2

Productos certificados conforme al Reglamento (UE) 2018/1139, de aviación civil, y equipos marinos de la Directiva 2014/90/UE.

Art. 2.3 y 2.4

Piezas de recambio que sustituyen componentes idénticos y se fabrican con las mismas especificaciones que los componentes a los que sustituyen.

Art. 2.6

Productos desarrollados o modificados exclusivamente con fines de seguridad nacional o defensa, y los diseñados específicamente para el tratamiento de información clasificada.

Art. 2.7

Vehículos de dos y tres ruedas y cuatriciclos del Reglamento (UE) n.o 168/2013, excluidos por acto delegado. Las bicicletas eléctricas de pedaleo asistido (L1e) siguen dentro: la exclusión no les alcanza.

Art. 2.5 · Reglamento Delegado (UE) 2025/1535
Unión Europea · Reglamento UE

Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024, relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales (Reglamento de Ciberresiliencia)

Identificador
CELEX 32024R2847
Fuente
EUR-Lex · Diario Oficial de la Unión Europea · Oficina de Publicaciones de la Unión Europea
Ficha técnica

Ciberseguridad

Ciberseguridad de producto de la primera a la última página: requisitos esenciales del anexo I, gestión de vulnerabilidades durante todo el ciclo de vida, notificación de vulnerabilidades explotadas y marcado CE de ciberresiliencia.

Valoración del curador · nivel 5 de 5

Qué implantar · Notificación de vulnerabilidades e incidentes

Notificar al CSIRT coordinador y a la ENISA Ciber

Notificar simultáneamente al CSIRT designado como coordinador y a la ENISA toda vulnerabilidad aprovechada activamente y todo incidente grave que repercuta en la seguridad del producto, por la plataforma única de la ENISA.

Recae sobre
Alimenta estas medidas

Art. 14.1 y 14.3

Qué implantar · Notificación de vulnerabilidades e incidentes

Cascada de plazos de notificación Ciber

Cumplir las dos cascadas de plazos: alerta temprana a las 24 horas, notificación a las 72, e informe final: a los 14 días de que haya remedio si es una vulnerabilidad, a un mes de la notificación si es un incidente.

Recae sobre
Alimenta estas medidas

Art. 14.2 y 14.4

Qué implantar · Notificación de vulnerabilidades e incidentes

Aviso a los usuarios del producto Ciber

Informar a los usuarios afectados de la vulnerabilidad o el incidente y de las medidas que pueden adoptar. Si el fabricante no lo hace a tiempo, puede hacerlo el CSIRT en su lugar.

Recae sobre
Alimenta estas medidas

Art. 14.8

Qué implantar · Notificación de vulnerabilidades e incidentes

Alcance retroactivo al parque ya vendido Ciber

El deber de notificar alcanza a todos los productos ya comercializados antes del 11 de diciembre de 2027, no solo a los nuevos. Es la única obligación del Reglamento que mira hacia atrás.

Recae sobre
Alimenta estas medidas

Art. 69.3

Qué implantar · Requisitos esenciales del anexo I

Puerta de comercialización Ciber

No comercializar un producto que no cumpla los requisitos esenciales del anexo I, parte I, y no tener procesos de gestión de vulnerabilidades conformes con la parte II. Son dos conformidades distintas: el producto y los procesos.

Recae sobre
Alimenta estas medidas

Art. 6 y anexo I

Qué implantar · Requisitos esenciales del anexo I

Comercializar sin vulnerabilidades aprovechables conocidas Ciber

Es una condición de puesta en el mercado, no una tarea de mantenimiento. Convierte el inventario de vulnerabilidades del producto en un requisito previo a vender.

Recae sobre
Alimenta estas medidas

Anexo I, parte I, punto 2, letra a)

Qué implantar · Requisitos esenciales del anexo I

Configuración segura por defecto y actualizaciones automáticas Ciber

Estado seguro de fábrica con posibilidad de restablecerlo, y actualizaciones de seguridad automáticas habilitadas por defecto, con mecanismo de exclusión voluntaria claro y opción de posponerlas.

Recae sobre
Alimenta estas medidas

Anexo I, parte I, punto 2, letras b) y c)

Qué implantar · Requisitos esenciales del anexo I

Control de acceso, confidencialidad e integridad Ciber

Protección frente al acceso no autorizado con aviso de los intentos, cifrado en reposo o en tránsito con mecanismos de última tecnología, y protección de datos, comandos, programas y configuración frente a manipulación, con aviso de corrupción de datos.

Recae sobre
Alimenta estas medidas

Anexo I, parte I, punto 2, letras d), e) y f)

Qué implantar · Requisitos esenciales del anexo I

Superficie de ataque, resiliencia y registros Ciber

Disponibilidad de las funciones esenciales incluso tras un incidente y frente a denegación de servicio, diseño que limite las interfaces externas, mitigación del aprovechamiento de vulnerabilidades, y registro de la actividad interna pertinente con exclusión voluntaria del usuario.

Recae sobre
Alimenta estas medidas

Anexo I, parte I, punto 2, letras h) a l)

Qué implantar · Requisitos esenciales del anexo I

Nomenclatura de materiales del software (SBOM) Ciber

Identificar y documentar vulnerabilidades y componentes en un formato comúnmente utilizado y legible por máquina, que incluya al menos las dependencias de máximo nivel del producto.

Recae sobre
Alimenta estas medidas

Anexo I, parte II, punto 1

Qué implantar · Requisitos esenciales del anexo I

Subsanar sin demora y separar las actualizaciones de seguridad Ciber

Abordar y corregir las vulnerabilidades sin demora y, cuando sea técnicamente viable, entregar las actualizaciones de seguridad separadas de las de funcionalidad. Más exámenes y pruebas de seguridad periódicos.

Recae sobre
Alimenta estas medidas

Anexo I, parte II, puntos 2 y 3

Qué implantar · Requisitos esenciales del anexo I

Divulgación coordinada de vulnerabilidades Ciber

Política de divulgación coordinada, publicación de información sobre las vulnerabilidades ya solucionadas, y una dirección de contacto para que cualquiera pueda reportar. La publicación puede retrasarse en casos justificados hasta que los usuarios puedan parchear.

Recae sobre
Alimenta estas medidas

Anexo I, parte II, puntos 4, 5 y 6

Qué implantar · Requisitos esenciales del anexo I

Actualizaciones gratuitas y distribuidas de forma segura Ciber

Mecanismos de distribución segura, y difusión sin demora y gratuita de las actualizaciones de seguridad. Solo cabe pactar otra cosa en productos a medida con usuario profesional: no se puede cobrar por un parche de seguridad de un producto de consumo.

Recae sobre
Alimenta estas medidas

Anexo I, parte II, puntos 7 y 8

Qué implantar · Deberes del fabricante

Evaluación de riesgos documentada Ciber

Hacer una evaluación de riesgos de ciberseguridad, documentarla, mantenerla actualizada durante el período de soporte e incorporarla a la documentación técnica, justificando por escrito cada requisito esencial que no aplique.

Recae sobre
Alimenta estas medidas

Art. 13.2 a 13.4

Qué implantar · Deberes del fabricante

Período de soporte mínimo de cinco años Ciber

Fijar un período de soporte de al menos cinco años, publicar su fecha final con mes y año en el momento de la compra, y mantener disponibles las actualizaciones de seguridad diez años tras su publicación. El mínimo de cinco años solo cede si se prevé que el producto se use menos tiempo: entonces el período de soporte es el tiempo de utilización previsto.

Recae sobre
Alimenta estas medidas

Art. 13.8, 13.9 y 13.19

Qué implantar · Deberes del fabricante

Diligencia debida sobre componentes de terceros Ciber

Ejercer diligencia debida sobre los componentes de terceros, incluidos los de código abierto, y avisar aguas arriba a quien mantiene el componente cuando se le detecta una vulnerabilidad, compartiendo la corrección.

Recae sobre
Alimenta estas medidas

Art. 13.5 y 13.6

Qué implantar · Deberes del fabricante

Punto de contacto único para los usuarios Ciber

Un canal identificable fácilmente que permita comunicarse directa y rápidamente con el fabricante y notificarle vulnerabilidades. No puede limitarse a herramientas automatizadas.

Recae sobre
Alimenta estas medidas

Art. 13.17

Qué implantar · Deberes del fabricante

Evaluación de la conformidad y marcado CE Ciber

Someter el producto al procedimiento de evaluación de la conformidad que le corresponda y colocar el marcado CE. La clase II del anexo III no admite autoevaluación, y los productos críticos del anexo IV van a certificación europea. En la clase I la autoevaluación solo sobrevive mientras existan y se apliquen normas armonizadas.

Recae sobre
Alimenta estas medidas

Art. 32 y art. 30

Qué implantar · Resto de la cadena

Comprobaciones del importador Ciber

Comprobar antes de introducir el producto que el fabricante evaluó la conformidad, redactó la documentación técnica y colocó el marcado CE; avisar al fabricante de las vulnerabilidades que se conozcan e, inmediatamente, a las autoridades si hay riesgo significativo.

Recae sobre
Alimenta estas medidas

Art. 19

Qué implantar · Resto de la cadena

Comprobaciones del distribuidor Ciber

Comprobar el marcado CE y que fabricante e importador cumplieron sus deberes de identificación e información, y no comercializar el producto si hay motivos para creer que no es conforme.

Recae sobre
Alimenta estas medidas

Art. 20

Qué implantar · Resto de la cadena

Convertirse en fabricante por marca o por modificación Ciber

Quien pone su nombre o marca a un producto, o le hace una modificación sustancial, se convierte en fabricante y asume los artículos 13 y 14: del producto entero si la modificación afecta a su ciberseguridad en conjunto.

Recae sobre
Alimenta estas medidas

Arts. 21 y 22

Qué implantar · Resto de la cadena

Identificación de la cadena durante diez años Ciber

Identificar a petición de la autoridad quién suministró el producto y a quién se suministró, y poder hacerlo durante diez años.

Recae sobre
Alimenta estas medidas

Art. 23

Qué implantar · Régimen del código abierto

Política de ciberseguridad del administrador de comunidad Ciber

Establecer y documentar de manera verificable una política de ciberseguridad, y cooperar con la autoridad de vigilancia. Del artículo 14 solo les alcanzan los apartados 1, 3 y 8, y en la medida en que participen en el desarrollo.

Recae sobre
Alimenta estas medidas

Art. 24

Medida

Adquisición y desarrollo seguros Compartida

La seguridad como requisito de compra y de construcción: exigencias al adquirir, prácticas de desarrollo seguro al construir y mantenimiento con la seguridad dentro durante todo el ciclo de vida.

Cómo se despliega La seguridad integrada en el flujo de construir y de comprar, con un criterio de aceptación explícito y un responsable de sostenerlo: su incumplimiento impide el paso a producción o la firma del contrato.
Qué exige esta norma
  • Seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas
Matiz de esta norma El ciclo de vida es el del producto que se vende, no el de los sistemas propios, y son dos conformidades que se demuestran por separado: la del producto (anexo I, parte I) y la de los procesos de gestión de vulnerabilidades (parte II). Se puede fallar la segunda con un producto impecable.
Categoría CSF 2.0 PR.PS · Seguridad de la plataforma
Emana de

Art. 6 y anexo I · categorización del curador, no de la norma

Medida

Gestión de riesgos de seguridad Compartida

Conocer a qué está expuesto el negocio y decidir qué se acepta y qué se trata: el proceso de gestión de riesgos determina las prioridades del resto de iniciativas.

Cómo se despliega Un proceso con dueño y calendario propio, apoyado en una metodología reconocida y al día (ISO/IEC 27005:2022, MAGERIT, EBIOS RM) y alimentado por el inventario de activos, con apetito de riesgo declarado; el resultado ordena el plan de seguridad del año.
Qué exige esta norma
  • Análisis de riesgos con metodología, criterios y resultados documentados
Matiz de esta norma El análisis se entrega, no se archiva: va dentro de la documentación técnica, se mantiene vivo durante todo el período de soporte y ha de justificar por escrito cada requisito esencial del anexo I que se declare no aplicable.
Categoría CSF 2.0 ID.RA · Evaluación de riesgosGV.RM · Estrategia de gestión de riesgos

El análisis y la evaluación son ID.RA; el apetito de riesgo declarado y la estrategia que fija la tolerancia y los objetivos medibles son GV.RM. Van juntos porque en el corpus los exige la misma obligación.

Emana de

Art. 13.2 a 13.4 · categorización del curador, no de la norma

Medida

Gestión de riesgos de terceros (TPRM) Compartida

Gobernar el riesgo que entra por los proveedores: el riesgo del proveedor es riesgo propio, la cadena no termina en quien firma el contrato, y la relación completa, desde la selección hasta la terminación, se gestiona con la seguridad integrada.

Cómo se despliega Un proceso con dueño, integrado en compras y en jurídico: la seguridad participa antes de firmar y durante la vida del contrato, con una intensidad proporcional a la criticidad del servicio prestado.
Qué exige esta norma
  • Criterios de seguridad para seleccionar proveedores
  • Comprobación documental de la conformidad de lo que se incorpora o se revende, antes de ponerlo en el mercado
  • Trazabilidad de quién suministró y a quién se suministró, conservada el plazo que fije la norma
Matiz de esta norma El tercero aquí es un componente, no un proveedor de servicios: la diligencia se hace antes de integrarlo, también cuando es código abierto y no hay contrato ni nadie a quien auditar. Aguas abajo la cadena no evalúa seguridad, comprueba papeles: marcado, documentación técnica e identificación antes de comercializar, y saber durante diez años quién te lo vendió y a quién se lo vendiste.
Categoría CSF 2.0 GV.SC · Gestión de riesgos de la cadena de suministro de seguridad cibernética

GV.SC entero, de la diligencia previa a la salida. Las dos exigencias documentales del CRA (comprobar papeles al incorporar o revender, y saber a quién se suministró) viven aquí porque son deberes de cadena, aunque quien las cumple mire al mercado y no a un contrato de servicio.

Emana de

Art. 13.5 y 13.6 · arts. 19, 20 y 23 · categorización del curador, no de la norma

Medida

Gestión de vulnerabilidades Compartida

Tratar las vulnerabilidades como un proceso continuo con responsable y plazos, no como reacciones aisladas: las vulnerabilidades conocidas se gestionan en lugar de acumularse.

Cómo se despliega Un proceso con dueño, apoyado en herramienta y en fuentes de aviso (boletines, el CERT de referencia), con métricas de lo que queda abierto y de cuánto tarda en cerrarse.
Qué exige esta norma
  • Identificación, priorización por riesgo y corrección de vulnerabilidades en plazo
  • Vía de divulgación coordinada para quien encuentre una vulnerabilidad
  • Divulgación hacia fuera de las vulnerabilidades relevantes ya corregidas, a quien tiene que actuar
  • Aviso al fabricante o mantenedor del componente de tercero al que se le detecta una vulnerabilidad, compartiendo la corrección
Matiz de esta norma El ciclo mira al parque ya vendido: política de divulgación coordinada publicada, dirección de contacto para quien encuentre un fallo, corrección sin demora y publicación de las vulnerabilidades ya solucionadas, que solo se puede retrasar hasta que los usuarios puedan parchear. Y la divulgación va también aguas arriba: al mantenedor del componente ajeno se le avisa y se le comparte la corrección.
Categoría CSF 2.0 ID.RA · Evaluación de riesgos

La identificación y priorización es ID.RA; el parcheo operativo resultante cae en PR.PS.

Emana de

Anexo I, parte II, puntos 2 a 6 · art. 13.6 · categorización del curador, no de la norma

Medida

Evaluación de la eficacia y mejora Compartida

Evaluar si las medidas implantadas son eficaces, no solo si existen, y convertir los resultados de esa evaluación en mejoras aplicadas.

Cómo se despliega Un cuadro de indicadores de seguridad revisado por el responsable y un registro de acciones correctoras con dueño y fecha, integrado en el ciclo de mejora del sistema de gestión.
Qué exige esta norma
  • Políticas y procedimientos para evaluar la eficacia de las medidas
Matiz de esta norma Lo que se somete a examen periódico es el producto, no el sistema de gestión: exámenes y pruebas de seguridad con calendario mientras dure el período de soporte.
Categoría CSF 2.0 ID.IM · Mejora
Emana de

Anexo I, parte II, punto 3 · categorización del curador, no de la norma

Medida

Capacidad de respuesta a incidentes Compartida

La capacidad de gestionar un incidente de seguridad de principio a fin, desde la detección del primer indicio hasta la recuperación de la operación normal.

Cómo se despliega Un equipo designado (propio, CSIRT contratado o retainer de respuesta), guardias y escalado definidos, criterio escrito sobre qué se preserva antes de tocar nada, un canal de coordinación que siga operativo si caen los sistemas propios, y simulacros periódicos que prueben la capacidad antes de necesitarla.
Qué exige esta norma
  • Criterios de clasificación de incidentes
  • Canal para que empleados, proveedores y clientes reporten sospechas
Matiz de esta norma Sin proceso propio no se llega a las 24 horas: hace falta un criterio escrito que distinga la vulnerabilidad aprovechada activamente del incidente grave que repercute en la seguridad del producto, y un punto de contacto único e identificable, que no puede limitarse a herramientas automatizadas, por el que lleguen los avisos.
Categoría CSF 2.0 RS.MA · Gestión de incidentesRS.AN · Análisis de incidentesRS.MI · Mitigación de incidentes

La contención y la erradicación son RS.MI, y el registro y la valoración del incidente RS.AN: las dos viven dentro de este proceso. La ejecución de la recuperación no está aquí; es RC.RP, en continuidad de negocio.

Emana de

Art. 14.1 y 14.3 · art. 13.17 · categorización del curador, no de la norma

Medida

Proceso de notificación regulatoria Compartida

Saber a quién, qué y en cuánto tiempo hay que notificar un incidente, y poder hacerlo bajo presión y con los relojes en contra.

Cómo se despliega Un procedimiento con responsables designados y suplentes, el asesor jurídico y comunicación dentro del circuito, y ensayos que comprueben si el procedimiento funciona bajo presión. Cada reloj arranca en un hecho distinto (conocer el incidente, clasificarlo o que ocurra), así que alguien declara ese momento y queda anotado; y un mismo incidente suele exigir varias notificaciones simultáneas, que deben ser coherentes entre sí.
Qué exige esta norma
  • Notificación de incidentes a la autoridad o al CSIRT en los plazos de la norma
  • Aviso a los destinatarios o afectados cuando el incidente pueda tocarles
Matiz de esta norma Dos relojes por un solo canal, simultáneo a la ENISA y al CSIRT coordinador: alerta a las 24 horas, notificación a las 72 e informe final a los 14 días de que exista remedio si es una vulnerabilidad, o a un mes de la notificación si es un incidente. Exigible desde septiembre de 2026 y también para los productos ya vendidos.
Categoría CSF 2.0 RS.CO · Notificación y comunicación de la respuesta al incidente
Emana de

Art. 14 · art. 69.3 · categorización del curador, no de la norma

Medida

Cuerpo normativo de seguridad Compartida

El cuerpo normativo de seguridad: qué se protege, quién decide y contra qué criterios se mide todo lo demás, escrito, comunicado a quien tiene que cumplirlo y vivo.

Cómo se despliega Un cuerpo normativo por capas (política, normativas, procedimientos) gestionado como exige un sistema de gestión tipo ISO 27001 o ENS: versionado, con dueño, publicado donde la plantilla lo encuentre, y con revisión programada y tras los cambios relevantes.
Qué exige esta norma
  • Política de seguridad de los sistemas de información aprobada por la dirección
Matiz de esta norma Régimen aparte del administrador de comunidad de código abierto: no se le pide aprobación de la dirección sino documentación verificable, y la política mira al desarrollo seguro y a la gestión de vulnerabilidades del componente, no a la seguridad de su propia organización.
Categoría CSF 2.0 GV.PO · Política
Emana de

Art. 24 · categorización del curador, no de la norma

Medida

Seguridad del producto por diseño y por defecto Compartida

La seguridad dentro del producto que se comercializa, no solo alrededor de los sistemas que se operan: se decide en el diseño y se comprueba antes de la comercialización, cuando el coste de cambio es menor.

Cómo se despliega Requisitos de seguridad en el diseño, modelado de amenazas por versión y un banco de verificación que repita las comprobaciones en cada versión que sale.
Qué exige esta norma
  • Comercializar sin vulnerabilidades aprovechables conocidas
  • Configuración segura de fábrica, con posibilidad de restablecer el estado original
  • Control de acceso implantado en el producto, con aviso de los intentos no autorizados
  • Confidencialidad e integridad de datos, comandos, programas y configuración, con cifrado de última tecnología y aviso de corrupción
  • Diseño que limite las interfaces externas y mitigue el aprovechamiento de vulnerabilidades
  • Disponibilidad de las funciones esenciales ante incidentes y denegación de servicio
  • Registro y seguimiento de la actividad interna pertinente, con exclusión voluntaria del usuario
Matiz de esta norma Los requisitos del anexo I no son absolutos: se aplican «cuando proceda» y sobre la evaluación de riesgos del producto, y cada uno que se descarte hay que justificarlo por escrito en la documentación técnica. La letra a) es la que más duele: convierte el inventario de vulnerabilidades en condición previa a vender, no en tarea de mantenimiento.
Categoría CSF 2.0 PR.PS · Seguridad de la plataformaPR.IR · Resiliencia de la infraestructura tecnológica

PR.PS y PR.IR se usan aquí sobre el producto que se vende, no sobre la infraestructura de la organización: es la lectura menos forzada que ofrece CSF 2.0 para requisitos de producto, y se declara para que no parezca descuido.

Emana de

Anexo I, parte I, punto 2 · categorización del curador, no de la norma

Medida

Soporte y actualizaciones de seguridad del producto Compartida

Comprometer por cuánto tiempo se mantiene lo vendido y montar la infraestructura para sostenerlo. Es una decisión de producto y de precio, no una tarea de cumplimiento.

Cómo se despliega El soporte tratado como un servicio con dueño, calendario y coste repercutido en el precio del producto, con telemetría de adopción que diga qué parque sigue expuesto.
Qué exige esta norma
  • Período de soporte definido y publicado con mes y año en el momento de la compra
  • Actualizaciones publicadas disponibles durante el plazo que fije la norma
  • Actualizaciones de seguridad automáticas por defecto, con exclusión voluntaria y opción de posponerlas
  • Actualizaciones de seguridad entregadas separadas de las de funcionalidad
  • Mecanismos de distribución segura de las actualizaciones
  • Actualizaciones de seguridad difundidas sin demora y de forma gratuita
Matiz de esta norma El mínimo son cinco años y solo cede si se prevé que el producto se use menos tiempo. Cada actualización publicada sigue disponible diez años: es un compromiso de archivo, no solo de desarrollo. Y cobrar por un parche de seguridad solo cabe en producto a medida con usuario profesional.
Categoría CSF 2.0 PR.PS · Seguridad de la plataforma
Emana de

Art. 13.8, 13.9 y 13.19 · anexo I, parte II, puntos 7 y 8 · categorización del curador, no de la norma

Medida

Conformidad y certificación Compartida

Poder demostrar a un tercero lo que se ha hecho, en sus dos versiones: la conformidad de la organización, que se audita y se certifica, y la del producto, que se evalúa, se documenta y se marca antes de venderlo. Es el expediente que convierte el cumplimiento en algo oponible a un cliente, a un pliego o a un supervisor.

Cómo se despliega Un repositorio de evidencias al día, una relación estable con quien evalúa desde fuera y el calendario de la acreditación gestionado como un compromiso más del negocio. El dueño lo fija cada norma: el sistema de gestión de la organización, o quien responde del producto.
Qué exige esta norma
  • Vía de evaluación de la conformidad elegida y documentada según la clase de riesgo
  • Documentación técnica y declaración de conformidad conservadas y a disposición de la autoridad
  • Marcado o declaración pública de conformidad antes de comercializar
  • Criterio y punto de control para decidir cuándo un cambio es una modificación sustancial que reabre la conformidad
Matiz de esta norma La vía no la elige del todo el fabricante: la clase II del anexo III no admite autoevaluación y los productos críticos del anexo IV van a certificación europea, y en la clase I la autoevaluación solo sobrevive mientras existan normas armonizadas que aplicar. Quien pone su marca a un producto ajeno o lo modifica sustancialmente pasa a fabricante y reabre el expediente entero.
Categoría CSF 2.0 GV.OC · Contexto organizativo

GV.OC recoge los requisitos legales y reglamentarios comprendidos y gestionados; la acreditación externa es su prueba oponible. La mejora que sale de esa auditoría no se queda aquí: va a evaluación de la eficacia (ID.IM). Aquí se demuestra; allí se corrige.

Emana de

Art. 32 y art. 30 · arts. 21 y 22 · categorización del curador, no de la norma

Medida

Inventario y gestión de activos Compartida

Un inventario completo de los activos y de sus dependencias: sin él, el parcheo, la vigilancia y la recuperación operan sobre un parque desconocido.

Cómo se despliega Una fuente única mantenida como proceso (alta, cambio y baja con autorización), no como foto anual, y conectada a lo que la consume: el parcheo, la vigilancia y la recuperación.
Qué exige esta norma
  • Nomenclatura de materiales del software (SBOM) en formato legible por máquina, con las dependencias de máximo nivel
Matiz de esta norma El inventario es el del producto que se vende, no el de los sistemas propios, y se entrega en formato legible por máquina: alcanza como mínimo a las dependencias de máximo nivel, y es lo que permite saber en horas si un fallo de un componente ajeno te toca.
Categoría CSF 2.0 ID.AM · Gestión de activos

ID.AM cubre los dos objetos que conviven aquí: el parque que se opera y la lista de materiales del producto que se vende. Son inventarios distintos con el mismo fin: mantener conocida la composición de lo que se opera y de lo que se comercializa.

Emana de

Anexo I, parte II, punto 1 · categorización del curador, no de la norma

Mapa NIST CSF · todo el detalle

Las obligaciones ciber de la norma, traducidas a medidas y organizadas por las funciones y categorías de NIST CSF 2.0 (traducción oficial al español, NIST CSWP 29). La asignación de categoría es juicio del curador; cada medida cita las obligaciones de las que emana.

Gobernar · GV

Conformidad y certificación ◆

La vía no la elige del todo el fabricante: la clase II del anexo III no admite autoevaluación y los productos críticos del anexo IV van a certificación europea, y en la clase I la autoevaluación solo sobrevive mientras existan normas armonizadas que aplicar. Quien pone su marca a un producto ajeno o lo modifica sustancialmente pasa a fabricante y reabre el expediente entero.

GV.OC · Art. 32 y art. 30 · arts. 21 y 22
Gestión de riesgos de seguridad ◆

El análisis se entrega, no se archiva: va dentro de la documentación técnica, se mantiene vivo durante todo el período de soporte y ha de justificar por escrito cada requisito esencial del anexo I que se declare no aplicable.

GV.RM · Art. 13.2 a 13.4
Cuerpo normativo de seguridad ◆

Régimen aparte del administrador de comunidad de código abierto: no se le pide aprobación de la dirección sino documentación verificable, y la política mira al desarrollo seguro y a la gestión de vulnerabilidades del componente, no a la seguridad de su propia organización.

GV.PO · Art. 24
Gestión de riesgos de terceros (TPRM) ◆

El tercero aquí es un componente, no un proveedor de servicios: la diligencia se hace antes de integrarlo, también cuando es código abierto y no hay contrato ni nadie a quien auditar. Aguas abajo la cadena no evalúa seguridad, comprueba papeles: marcado, documentación técnica e identificación antes de comercializar, y saber durante diez años quién te lo vendió y a quién se lo vendiste.

GV.SC · Art. 13.5 y 13.6 · arts. 19, 20 y 23

Identificar · ID

Inventario y gestión de activos ◆

El inventario es el del producto que se vende, no el de los sistemas propios, y se entrega en formato legible por máquina: alcanza como mínimo a las dependencias de máximo nivel, y es lo que permite saber en horas si un fallo de un componente ajeno te toca.

ID.AM · Anexo I, parte II, punto 1
Gestión de riesgos de seguridad ◆

El análisis se entrega, no se archiva: va dentro de la documentación técnica, se mantiene vivo durante todo el período de soporte y ha de justificar por escrito cada requisito esencial del anexo I que se declare no aplicable.

ID.RA · Art. 13.2 a 13.4
Gestión de vulnerabilidades ◆

El ciclo mira al parque ya vendido: política de divulgación coordinada publicada, dirección de contacto para quien encuentre un fallo, corrección sin demora y publicación de las vulnerabilidades ya solucionadas, que solo se puede retrasar hasta que los usuarios puedan parchear. Y la divulgación va también aguas arriba: al mantenedor del componente ajeno se le avisa y se le comparte la corrección.

ID.RA · Anexo I, parte II, puntos 2 a 6 · art. 13.6
Evaluación de la eficacia y mejora ◆

Lo que se somete a examen periódico es el producto, no el sistema de gestión: exámenes y pruebas de seguridad con calendario mientras dure el período de soporte.

ID.IM · Anexo I, parte II, punto 3

Proteger · PR

Adquisición y desarrollo seguros ◆

El ciclo de vida es el del producto que se vende, no el de los sistemas propios, y son dos conformidades que se demuestran por separado: la del producto (anexo I, parte I) y la de los procesos de gestión de vulnerabilidades (parte II). Se puede fallar la segunda con un producto impecable.

PR.PS · Art. 6 y anexo I
Seguridad del producto por diseño y por defecto ◆

Los requisitos del anexo I no son absolutos: se aplican «cuando proceda» y sobre la evaluación de riesgos del producto, y cada uno que se descarte hay que justificarlo por escrito en la documentación técnica. La letra a) es la que más duele: convierte el inventario de vulnerabilidades en condición previa a vender, no en tarea de mantenimiento.

PR.PS · Anexo I, parte I, punto 2
Soporte y actualizaciones de seguridad del producto ◆

El mínimo son cinco años y solo cede si se prevé que el producto se use menos tiempo. Cada actualización publicada sigue disponible diez años: es un compromiso de archivo, no solo de desarrollo. Y cobrar por un parche de seguridad solo cabe en producto a medida con usuario profesional.

PR.PS · Art. 13.8, 13.9 y 13.19 · anexo I, parte II, puntos 7 y 8
Seguridad del producto por diseño y por defecto ◆

Los requisitos del anexo I no son absolutos: se aplican «cuando proceda» y sobre la evaluación de riesgos del producto, y cada uno que se descarte hay que justificarlo por escrito en la documentación técnica. La letra a) es la que más duele: convierte el inventario de vulnerabilidades en condición previa a vender, no en tarea de mantenimiento.

PR.IR · Anexo I, parte I, punto 2

Responder · RS

Capacidad de respuesta a incidentes ◆

Sin proceso propio no se llega a las 24 horas: hace falta un criterio escrito que distinga la vulnerabilidad aprovechada activamente del incidente grave que repercute en la seguridad del producto, y un punto de contacto único e identificable, que no puede limitarse a herramientas automatizadas, por el que lleguen los avisos.

RS.MA · Art. 14.1 y 14.3 · art. 13.17
Capacidad de respuesta a incidentes ◆

Sin proceso propio no se llega a las 24 horas: hace falta un criterio escrito que distinga la vulnerabilidad aprovechada activamente del incidente grave que repercute en la seguridad del producto, y un punto de contacto único e identificable, que no puede limitarse a herramientas automatizadas, por el que lleguen los avisos.

RS.AN · Art. 14.1 y 14.3 · art. 13.17
Proceso de notificación regulatoria ◆

Dos relojes por un solo canal, simultáneo a la ENISA y al CSIRT coordinador: alerta a las 24 horas, notificación a las 72 e informe final a los 14 días de que exista remedio si es una vulnerabilidad, o a un mes de la notificación si es un incidente. Exigible desde septiembre de 2026 y también para los productos ya vendidos.

RS.CO · Art. 14 · art. 69.3
Capacidad de respuesta a incidentes ◆

Sin proceso propio no se llega a las 24 horas: hace falta un criterio escrito que distinga la vulnerabilidad aprovechada activamente del incidente grave que repercute en la seguridad del producto, y un punto de contacto único e identificable, que no puede limitarse a herramientas automatizadas, por el que lleguen los avisos.

RS.MI · Art. 14.1 y 14.3 · art. 13.17
Roles que reparte
Rol

Fabricante

Quien desarrolla o fabrica el producto, o para quien se diseña, y lo comercializa con su nombre o marca. La definición cubre el suministro «ya sea de manera remunerada, monetizada o gratuita»: regalar el software no saca a nadie del Reglamento. También se llega aquí por asimilación, y esa es la puerta que más gente no ve venir: el importador, el distribuidor o cualquier tercero que ponga su nombre a un producto ya comercializado, o le haga una modificación sustancial, pasa a ser fabricante y asume los artículos 13 y 14.

Arts. 3.13, 21 y 22

Rol

Importador

Quien, estando establecido en la Unión, introduce en el mercado un producto que lleva el nombre o la marca de alguien establecido fuera de ella. Ni lo desarrolla ni influye sobre sus propiedades: lo que se le exige es comprobar antes de introducirlo que el fabricante hizo su trabajo.

Art. 3.16

Rol

Distribuidor

Quien forma parte de la cadena de suministro y comercializa el producto «sin influir sobre sus propiedades». En cuanto influye sobre ellas, poniéndole su nombre o modificándolo sustancialmente, deja de ser distribuidor y pasa a fabricante.

Art. 3.17

Rol

Representante autorizado

Quien, estando establecido en la Unión, ha recibido del fabricante un mandato escrito para tareas concretas. El mandato tiene un núcleo indelegable: el diseño, la evaluación de riesgos, la gestión de vulnerabilidades y la conformidad de la producción se quedan con el fabricante, haya representante o no.

Arts. 3.15 y 18.2

Rol

Administrador de código abierto

Persona jurídica, distinta del fabricante, que da soporte sistemático y sostenido a productos de código abierto destinados a actividades comerciales. Tiene régimen propio y mucho más ligero: su deber es documentar de manera verificable una política de ciberseguridad, del artículo 14 solo le alcanzan los apartados 1, 3 y 8, y queda fuera de las multas por cualquier infracción del Reglamento.

Arts. 3.14 y 24

Qué implantar

Obligaciones por rol

FabricanteImportadorDistribuidorRepresentante autorizadoAdministrador de código abierto
Art. 14.1 y 14.3 Ciber Notificar al CSIRT coordinador y a la ENISA
Art. 14.2 y 14.4 Ciber Cascada de plazos de notificación
Art. 14.8 Ciber Aviso a los usuarios del producto
Art. 69.3 Ciber Alcance retroactivo al parque ya vendido
Art. 6 y anexo I Ciber Puerta de comercialización
Anexo I, parte I, punto 2, letra a) Ciber Comercializar sin vulnerabilidades aprovechables conocidas
Anexo I, parte I, punto 2, letras b) y c) Ciber Configuración segura por defecto y actualizaciones automáticas
Anexo I, parte I, punto 2, letras d), e) y f) Ciber Control de acceso, confidencialidad e integridad
Anexo I, parte I, punto 2, letras h) a l) Ciber Superficie de ataque, resiliencia y registros
Anexo I, parte II, punto 1 Ciber Nomenclatura de materiales del software (SBOM)
Anexo I, parte II, puntos 2 y 3 Ciber Subsanar sin demora y separar las actualizaciones de seguridad
Anexo I, parte II, puntos 4, 5 y 6 Ciber Divulgación coordinada de vulnerabilidades
Anexo I, parte II, puntos 7 y 8 Ciber Actualizaciones gratuitas y distribuidas de forma segura
Art. 13.2 a 13.4 Ciber Evaluación de riesgos documentada
Art. 13.8, 13.9 y 13.19 Ciber Período de soporte mínimo de cinco años
Art. 13.5 y 13.6 Ciber Diligencia debida sobre componentes de terceros
Art. 13.17 Ciber Punto de contacto único para los usuarios
Art. 32 y art. 30 Ciber Evaluación de la conformidad y marcado CE
Art. 19 Ciber Comprobaciones del importador
Art. 20 Ciber Comprobaciones del distribuidor
Arts. 21 y 22 Ciber Convertirse en fabricante por marca o por modificación
Art. 23 Ciber Identificación de la cadena durante diez años
Art. 24 Ciber Política de ciberseguridad del administrador de comunidad