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