Desarrollo y adquisición seguros NIS 2 conforme al artículo 21(2)(e)
NIS 2 establece que debe asegurar los sistemas a lo largo de la adquisición, el desarrollo y el mantenimiento. El artículo 21(2)(e) es el marco general. El §6 del CIR (UE) 2024/2690 lo divide en diez subsecciones. Alemania lo incorpora a su Derecho nacional a través del §30(2)(5) BSIG.
La versión breve
El artículo 21(2)(e) es el deber general de seguridad a lo largo de todo el ciclo de vida de TI. No solo el código. No solo los parches. Todo el recorrido: comprar un sistema, construirlo, configurarlo, modificarlo, probarlo, parchearlo, operarlo, retirarlo de servicio. La misma regla se aplica en toda la UE.
El CIR (UE) 2024/2690 aporta el detalle. El §6 del Anexo tiene diez subsecciones (§6.1 a §6.10) que operativizan el deber. Esta página cubre la parte de desarrollo y cambios: adquisición (§6.1), el ciclo de vida de desarrollo seguro (§6.2), la gestión de la configuración (§6.3), la gestión de cambios (§6.4), las pruebas de seguridad (§6.5) y la gestión de parches (§6.6). La seguridad de red, la segmentación, el antimalware y la gestión de vulnerabilidades (§6.7 a §6.10) tienen sus propias páginas.
Alemania incorpora la misma regla a su Derecho nacional a través del §30(2)(5) BSIG. La redacción es casi palabra por palabra el texto de la UE. Esta página recorre la directiva, el reglamento de desarrollo de la UE y la transposición alemana en ese orden.
Artículo 21(2)(e) de la Directiva NIS 2 (2022/2555)
La seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de las vulnerabilidades.
Este es el punto (e) de la lista de diez medidas de ciberseguridad que toda entidad esencial e importante debe implantar. Es el único punto de la lista que se extiende explícitamente desde la orden de compra hasta el fin de vida.
CIR (UE) 2024/2690, Anexo §6
Medidas de seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información (artículo 21(2)(e) de la Directiva (UE) 2022/2555).
Como se trata de un reglamento (no de una directiva), es Derecho de la UE directamente vinculante. No se necesita transposición nacional. Se aplica a los proveedores de DNS, los registros de TLD, los proveedores de nube, los centros de datos, los proveedores de servicios gestionados y los demás sectores enumerados en su Anexo. El §6 tiene diez subsecciones numeradas, cada una de las cuales nombra un deber específico.
§30(2)(5) BSIG (Alemania)
La seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas de tecnología de la información, incluida la gestión y divulgación de las vulnerabilidades.
Alemania copia el texto de la UE casi palabra por palabra. 'Sistemas de tecnología de la información' en lugar de 'redes y sistemas de información' es cuestión de redacción, no de significado. El BSI señala los módulos de IT-Grundschutz CON.8 (desarrollo de software) y OPS.1.1.3 (gestión de parches y cambios) como la vía práctica.
Incorpore requisitos de seguridad a cada compra
Antes de comprar un producto o servicio de TI, anota lo que debe cumplir en materia de seguridad. Autenticación, registro de eventos, soporte de actualizaciones, divulgación de vulnerabilidades, región de alojamiento, dónde residen los datos. Después valida que el proveedor cumple realmente los requisitos. Esto recae en la entidad compradora, no en el proveedor. 'Usamos SaaS' no transfiere el deber.
Ejecute un ciclo de vida de desarrollo seguro
Los requisitos de seguridad se analizan durante la especificación y el diseño. Se aplican principios de codificación segura, incluidos la seguridad desde el diseño y las arquitecturas de confianza cero. Los propios entornos de desarrollo se aseguran. Las pruebas de seguridad se realizan antes del lanzamiento. Los datos de prueba se tratan con cuidado, no se copian de producción. Todo el ciclo de vida se documenta, no solo una o dos prácticas.
Parchee en un plazo adecuado, probando primero
Los parches de seguridad se aplican en un plazo adecuado (el texto del CIR), vinculado a la gravedad de la vulnerabilidad. Los parches se prueban antes de producción. Los parches de emergencia se documentan. 'Cuando el equipo tenga tiempo' no es un plazo. Elija una cadencia, anótela, demuestre que la cumple.
Seguridad desde la adquisición hasta la retirada de servicio
El §6 no trata del desarrollo en sentido estricto. Cubre todo el ciclo de vida: cómo elige lo que compra, cómo construye, cómo configura, cómo prueba, cómo parchea, cómo modifica, cómo retira. Un Mittelstand que compra el 95 por ciento de su software sigue siendo responsable del §6.1 (requisitos de adquisición) y del §6.6 (gestión de parches). No puede quedar fuera del ciclo de vida solo porque no escribe código.
Disciplina de cambios: ningún cambio en producción sin seguimiento
El §6.4 es tajante: los cambios en producción se gestionan, se documentan y se revisan. Los cambios de emergencia también se documentan, solo que a posteriori en lugar de antes. Un cambio sin ticket, sin aprobador y sin plan de reversión incumple el requisito, aunque funcione. Los auditores cotejan el registro de cambios con el sistema de tickets. Si no pueden reconstruir quién cambió qué y cuándo, el control no está implantado.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
El BSI asigna el §30(2)(5) BSIG a dos módulos de Grundschutz. CON.8 'Software-Entwicklung' cubre la parte del SDLC: requisitos, codificación segura, pruebas, lanzamiento. OPS.1.1.3 'Patch- und Änderungsmanagement' cubre la parte de cambios y parches. Si sigue CON.8 y OPS.1.1.3, está dentro de lo que exige el §30 BSIG.
Orientaciones técnicas de implementación de ENISA
ENISA, la agencia de ciberseguridad de la UE, publica unas Orientaciones técnicas de implementación (TIG) que toman el texto abstracto del §6 del CIR y le muestran qué hacer en la práctica. Asignan cada subsección a controles de ISO/IEC 27001:2022 (A.8.25 a A.8.32 sobre desarrollo seguro, A.5.20 a A.5.23 sobre relaciones con proveedores), de modo que las certificaciones existentes le dan ventaja.
Leyes nacionales de transposición
Cada Estado miembro tiene su propia ley de transposición (Países Bajos: Cyberbeveiligingswet, Austria: NISG, Bélgica: NIS2-Wet). Los deberes conforme al artículo 21(2)(e) son los mismos porque la directiva fija un único estándar para toda la UE. Lo que difiere: a qué marco nacional señala el regulador como vía práctica.
Usamos SaaS, así que el desarrollo seguro es cosa del proveedor.
Medio cierto. El proveedor es responsable del código. Usted sigue siendo responsable del §6.1: requisitos de seguridad documentados para cada producto o servicio de TI que compre, más la validación de que el proveedor los cumple. Autenticación, registro de eventos, soporte de actualizaciones, ubicación de los datos, notificación de vulneraciones. Si su expediente de adquisición está vacío, el deber no se cumple, por excelente que sea el proveedor.
Hacemos revisiones de código, así que la parte del SDLC está cubierta.
La revisión de código es una práctica. El §6.2 exige documentar todo el ciclo de vida: requisitos de seguridad durante la especificación, principios de codificación segura (incluidos la seguridad desde el diseño y la confianza cero), entornos de desarrollo asegurados, procedimientos de pruebas de seguridad antes del lanzamiento, tratamiento cuidadoso de los datos de prueba. Una única práctica sobre un proceso no documentado no cumple la sección.
Parcheamos cuando el equipo tiene tiempo.
El §6.6 exige un plazo adecuado vinculado a la gravedad, más pruebas antes de producción y documentación de los parches de emergencia. 'Cuando hay tiempo' no es un plazo. Elija una cadencia (por ejemplo, críticos en 72 horas, altos en 14 días), anótela, demuestre que la cumple en el registro de cambios. Un auditor reconstruirá su historial de parches a partir del sistema de tickets.
La mayoría de la TI del Mittelstand alemán tiene este aspecto: 90 por ciento de software de proveedores (ERP, nóminas, correo, recursos compartidos, CRM), algo de integración de unión y scripts internos ocasionales. El gran esfuerzo del §6 para ese perfil no es el SDLC. Es el §6.1 de adquisición y el §6.6 de gestión de parches.
Redacte la plantilla de requisitos de seguridad una vez. Autenticación, registro de eventos, divulgación de vulnerabilidades, soporte de actualizaciones, región de alojamiento, exportación de datos, notificación de vulneraciones. Aplíquela a cada nueva adquisición y a cada renovación. Combínela con una cadencia de parches escrita (crítico / alto / medio con un plazo cada uno) y un registro de cambios que todos usen. Eso cubre el grueso del §6 para un Mittelstand típico sin contratar a un especialista en seguridad de software.
Hemos incorporado los requisitos de adquisición del §6.1, la documentación del SDLC del §6.2, el registro de cambios del §6.4 y la cadencia de parches del §6.6 al módulo PRO de la plataforma. Rellena la plantilla de adquisición una vez y la reutiliza. Cada nuevo producto o servicio de TI pasa por la misma lista de comprobación de seguridad con una aprobación.
El registro de cambios y la cadencia de parches funcionan sobre la misma pista de auditoría que el resto de la plataforma: ticket, aprobador, plan de reversión, archivo de evidencia. Los cambios de emergencia obtienen el formulario a posteriori. No mantiene un registro de cumplimiento separado. Cuando un auditor pregunta cómo parcheó una CVE, la respuesta es una sola consulta, no tres hojas de cálculo.
- Directiva (UE) 2022/2555 (NIS 2), artículo 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), Anexo §6 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley del BSI (BSIG), §30(2)(5) en su versión modificada por la Ley de Implementación de NIS2 y de Refuerzo de la Ciberseguridad
- Módulos de IT-Grundschutz del BSI CON.8 'Software-Entwicklung' y OPS.1.1.3 'Patch- und Änderungsmanagement'
- Orientaciones técnicas de implementación de ENISA para el CIR (UE) 2024/2690 (a fecha de mayo de 2026)