NIS2 Artículo 21(2)(e): desarrollo seguro y gestión de vulnerabilidades para MSP
Una biblioteca de registro que su cliente nunca eligió a conciencia, nunca instaló a propósito y no sabría nombrar de memoria publica una CVE crítica un viernes por la tarde. Está tres capas por debajo de un agente de monitorización que usted desplegó para él hace dieciocho meses. El reloj que importa no es el del aviso del proveedor: es el que un auditor pone en marcha cuando pregunta con qué rapidez lo supo, con qué rapidez actuó y dónde está la prueba.
Ese escenario es justo lo que el Artículo 21(2)(e) de NIS2 pretende evitar. Es la medida que la mayoría de los consultores se saltan porque suena a problema de desarrolladores. No lo es. Es un problema de cadena de suministro y mantenimiento, y para los MSP una de las medidas más difíciles de evidenciar.
El Artículo 21(2)(e) abarca todo lo que construye, compra y mantiene
Las diez medidas de gestión de riesgos del Artículo 21(2) son la columna vertebral del cumplimiento de NIS2. La mayor atención va a las visibles: MFA, copias de seguridad, notificación de incidentes. La medida (e) es más silenciosa y más amplia: «la seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluidas la gestión y la divulgación de vulnerabilidades».
Léala despacio. Tres verbos —adquisición, desarrollo, mantenimiento— más una obligación permanente de gestionar y divulgar vulnerabilidades. Se aplica tanto si escribe código, como si revende una plataforma o simplemente mantiene parcheado el software de otro. No hay excepción para «nosotros no desarrollamos nada». Si mantiene los sistemas de un cliente, la mitad de mantenimiento de esta medida es suya.
Artículo 21 — 10 Medidas de Ciberseguridad NIS2
Artículo 21
10 Medidas de Ciberseguridad
Gobernanza & Estrategia
1Análisis de riesgos & políticas de seguridad de la información6Evaluación de la eficacia de las medidas de seguridadIncidentes & Continuidad
2Gestión de incidentes & notificación3Continuidad del negocio & recuperación ante desastresCadena de Suministro & Sistemas
4Seguridad de la cadena de suministro5Seguridad en el desarrollo de sistemas de redes e informaciónControles Técnicos
8Criptografía & cifrado10Autenticación multifactor & comunicaciones segurasPersonas & Activos
7Ciberhigiene & formación9Seguridad de RRHH & control de acceso
Para el mapa completo de cómo (e) se conecta con las otras nueve medidas, vea nuestro desglose de las diez medidas del Artículo 21.
Qué significa en la práctica «adquisición, desarrollo y mantenimiento seguros»
Divida la medida en las tres cosas que realmente pide.
Adquisición significa elegir software y proveedores con la seguridad como criterio de selección, no como ocurrencia tardía. Eso implica una evaluación documentada del proveedor: ¿sigue prácticas de desarrollo seguro, publica avisos, se compromete a divulgar vulnerabilidades en su producto? Un «usamos proveedores de confianza» de una línea no sobrevive a una auditoría.
Desarrollo significa que todo lo que construye —un portal de cliente, un script de automatización, una integración a medida— pasa por un ciclo de vida seguro. Estándares de codificación segura, revisión de código, pruebas de seguridad antes del despliegue y un proceso para las vulnerabilidades encontradas tras la puesta en producción. No necesita un documento de SDLC de 40 páginas. Necesita un proceso repetible que pueda mostrar.
El mantenimiento es donde vive la mayoría de los MSP. Significa parchear, gestionar cambios y mantener un inventario exacto de qué está desplegado y dónde. No puede parchear lo que no ve, y no puede probar que parcheó sin registros.
¿Construye o solo mantiene? Los controles difieren
La medida se aplica a todos los que están en el ámbito, pero el peso cambia según lo que haga. Use la lógica de decisión de abajo para determinar qué controles conllevan más riesgo de auditoría para su operación.
¿Se aplica la NIS2 a su organización?
1¿Opera su organización en un sector esencial o importante (energía, transporte, salud, infraestructura digital, etc.)?
Sí▼No▼2¿Tiene su organización 50 o más empleados, o un volumen de negocio anual superior a 10 millones de euros?
✗La NIS2 no se aplica directamente a su organización.
Sí▼No▼✓La NIS2 se aplica a su organización como entidad esencial o importante.
3¿Es su organización un operador de infraestructura crítica o un prestador cualificado de servicios de confianza?
Sí▼!La NIS2 podría aplicarse a su organización — solicite asesoramiento jurídico para confirmar su estatus.
1¿Opera su organización en un sector esencial o importante (energía, transporte, salud, infraestructura digital, etc.)?
Sí ↓No →2¿Tiene su organización 50 o más empleados, o un volumen de negocio anual superior a 10 millones de euros?
Sí ↓No →3¿Es su organización un operador de infraestructura crítica o un prestador cualificado de servicios de confianza?
Sí ↓No →✗La NIS2 no se aplica directamente a su organización.
✓La NIS2 se aplica a su organización como entidad esencial o importante.
!La NIS2 podría aplicarse a su organización — solicite asesoramiento jurídico para confirmar su estatus.
Se aplicaPosiblemente aplicaNo se aplica
Si solo mantiene software de terceros, su exposición está en la exactitud del inventario, los SLA de parcheo y los registros de cambios. Si desarrolla algo orientado al cliente, añada a la lista la codificación segura, la revisión de código y las pruebas previas al lanzamiento. Si revende o empaqueta plataformas de otros proveedores, sus controles de adquisición —evaluación de proveedores y cláusulas de divulgación— pasan a ser lo primero que un auditor examina. Cartografíe sus servicios con honestidad antes de construir el conjunto de controles.
Gestión de vulnerabilidades: recepción, triaje y SLA de parcheo
La gestión de vulnerabilidades es un bucle, no un proyecto. Tiene tres piezas móviles.
La recepción es cómo le llegan las vulnerabilidades: avisos de proveedores, su propio escaneo, pruebas de intrusión de terceros y un canal para que externos informen de un fallo en algo que usted opera. Si falta esa última bandeja de entrada, le falta un control que la directiva nombra explícitamente.
El triaje es cómo ordena lo que llega. Gravedad más exposición más explotabilidad, puntuado de la misma forma cada vez para que dos ingenieros lleguen a la misma respuesta.
La remediación es el parche, atado a un reloj de nivel de servicio. NIS2 no prescribe plazos de parcheo, así que el mercado ha adoptado un estándar de facto que los compradores ahora escriben en los contratos: crítico en 24–48 horas, alto en 7 días, medio en 30 días, bajo en 90 —con un proceso de excepción documentado para los casos en que realmente no puede parchear a tiempo. Ese proceso de excepción cuenta tanto como el SLA. Un auditor no busca un registro perfecto. Busca uno defendible.
La trampa para los MSP: debe poder producir estos registros por cliente, en el momento de la auditoría, a petición. Un escaneo que solo vive en un panel no es prueba. Un rastro fechado y exportable sí.
Divulgación coordinada de vulnerabilidades y la EUVD
Gestionar sus propias vulnerabilidades es la mitad de la medida. La otra mitad es la divulgación, y NIS2 construyó un canal formal para ello.
Según el Artículo 12, cada Estado miembro designa un CSIRT como coordinador de un programa nacional de divulgación coordinada de vulnerabilidades (CVD). Ese CSIRT actúa como intermediario de confianza entre quien informa de un fallo y el proveedor cuyo producto lo contiene. Contacta a las partes afectadas, apoya al informante y negocia los plazos de divulgación, incluidos los casos espinosos en que una vulnerabilidad afecta a productos de varios países a la vez.
Todo esto se alimenta de la European Vulnerability Database (EUVD), mantenida por ENISA, que opera un registro de vulnerabilidades como autoridad de numeración CVE (CNA) oficial desde enero de 2024. Para un MSP, la EUVD es una segunda fuente de verdad junto a los avisos de los proveedores, y saber trabajar con ella forma parte ya del oficio. Cubrimos la parte práctica en nuestra guía de la EUVD para MSP.
La lección práctica: necesita una vía publicada para que alguien informe de una vulnerabilidad en un producto o servicio que usted opera, y una decisión sobre cómo participa en el proceso CVD nacional. Ambas son auditables. Ninguna es opcional si está dentro del ámbito.
Cuando el fallo de un proveedor se convierte en la responsabilidad de su cliente
Aquí la medida (e) deja de ser abstracta. Una vulnerabilidad en el producto de un proveedor no permanece contenida. Se propaga en cascada —del proveedor a usted, a su cliente, a los clientes de este— y las obligaciones de cadena de suministro de NIS2 (medida (d)) hacen que la responsabilidad viaje con ella.
Escalada de sanciones NIS2 — Más allá de la multa
!Desencadenante
Incumplimiento detectado o incidente ocurrido
Una autoridad supervisora identifica una brecha de cumplimiento o una organización no cumple los requisitos NIS2
Las autoridades pueden imponer▼Sanciones no financieras1Órdenes de cumplimiento con plazos vinculantes
2Auditorías de seguridad obligatorias a tu cargo
3Divulgación pública de infracciones
4Instrucciones vinculantes sobre medidas de seguridad específicas
Escala hacia▼Consecuencias operativas y personales1Suspensión de certificaciones o licencias de operación
2Prohibición temporal de funciones directivas para individuos
3Identificación pública de personas físicas responsables
DesencadenanteNo financieroOperativo / personal
Si un componente que usted desplegó porta un fallo crítico sin parchear y un cliente es comprometido a través de él, «el proveedor debería habérnoslo dicho» no es una defensa. La directiva espera que haya evaluado a ese proveedor, contratado la divulgación y dispuesto de un proceso para actuar en cuanto llegara el aviso. Por eso adquisición y gestión de vulnerabilidades son una sola medida y no dos: la debilidad entra por lo que compró y se gestiona por lo que hace después. Nuestro desglose de la seguridad de la cadena de suministro recorre la parte contractual.
La prueba que un auditor pedirá de verdad
La medida (e) se juzga por rastros documentales, no por intenciones. Tenga estos listos, por cliente donde proceda:
Un inventario de software y proveedores actualizado, no una hoja de cálculo del año pasado. Evaluaciones de proveedores que muestren que la seguridad fue un criterio de selección. Una política de parches con SLA basados en la gravedad, más los registros que prueben que los cumplió —y los registros de excepción donde no—. Una gestión de cambios que ligue cada cambio a una aprobación. Un canal de recepción y divulgación de vulnerabilidades que exista y se supervise. Y, si desarrolla algo, notas de SDLC seguro: estándares de codificación, evidencia de revisión, resultados de pruebas previas al lanzamiento.
Nada de esto es exótico. Todo ello es la diferencia entre aprobar una auditoría y explicar, tras un incidente, por qué los registros no existen. La medida (f) —evaluar si sus controles funcionan de verdad— se apoya directamente sobre esta; vea nuestra guía del bucle de auditoría para ver cómo se conectan ambas.
Empiece por lo que puede ver
La mayoría de los MSP ya hacen el 60% de esta medida: parchean, siguen los cambios, eligen proveedores decentes. La brecha está casi siempre en la prueba y en el canal de divulgación, no en el trabajo subyacente. La forma más rápida de encontrar sus brechas concretas es mirar sus controles de mantenimiento y adquisición a través de la lente del Artículo 21(2)(e) y marcar qué podría entregar a un auditor hoy frente a qué tendría que reunir a las apuradas.
Si quiere que le cartografiemos esa brecha, ejecute un NIS2 quick scan gratuito: muestra, por medida, exactamente dónde se sitúa su postura de desarrollo seguro y gestión de vulnerabilidades frente a la directiva.
La medida (e) no es la parte más vistosa de NIS2. Es la que más probablemente quede fina cuando un auditor tira del hilo, precisamente porque parece el trabajo de otro. Para un MSP, es el suyo.