Descripción general: NIS2 Artículo 21 y las medidas de gestión del riesgo de ciberseguridad
El Artículo 21 de la Directiva NIS2 establece las medidas de gestión del riesgo de ciberseguridad de referencia que las entidades esenciales e importantes deben implementar. Para las organizaciones que dependen de pipelines CI/CD para la entrega de software, estos requisitos se traducen directamente en controles de gobernanza de pipeline que los auditores y los responsables de cumplimiento deben evaluar.
El Artículo 21 exige un enfoque de todos los riesgos — lo que significa que los controles deben abordar los riesgos en todo el ciclo de vida de entrega de software, no solo en la infraestructura de producción. Esto incluye entornos de compilación, automatización de despliegue, gestión de artefactos y flujos de trabajo de aprobación de cambios.
La tabla a continuación mapea cada requisito del Artículo 21 a los controles CI/CD correspondientes y la evidencia que los auditores deben solicitar durante las evaluaciones.
Requisitos del Artículo 21 mapeados a controles CI/CD
| Requisito NIS2 Artículo 21 | Control CI/CD | Evidencia para auditores |
|---|---|---|
| Art. 21(2)(a) — Análisis de riesgos y políticas de seguridad de sistemas de información | Política de seguridad de pipeline documentada que abarca las etapas de compilación, prueba y despliegue; evaluaciones periódicas de riesgos de la infraestructura CI/CD | Documentos de política aprobados con historial de versiones; informes de evaluación de riesgos que hacen referencia a activos CI/CD; registros de aprobación por parte de la dirección |
| Art. 21(2)(b) — Gestión de incidentes | Procedimientos de respuesta a incidentes en pipelines; alertas automáticas en fallos de compilación/despliegue; mecanismos de reversión | Libros de jugadas de respuesta a incidentes específicos para fallos de pipeline; registros de configuración de alertas; registros de incidentes que muestran los plazos desde la detección hasta la resolución |
| Art. 21(2)(c) — Continuidad del negocio y gestión de crisis | Planes de redundancia de pipeline y recuperación ante desastres; copias de seguridad de configuraciones de pipeline y secretos; objetivos de tiempo de recuperación para la infraestructura de compilación | Planes de continuidad del negocio que cubren los sistemas CI/CD; procedimientos de recuperación documentados; resultados de pruebas de ejercicios de DR; registros de verificación de copias de seguridad |
| Art. 21(2)(d) — Seguridad de la cadena de suministro | Políticas de gobernanza de dependencias; registros aprobados y catálogos de imágenes base; evaluaciones de proveedores para los proveedores de herramientas CI/CD; generación de Software Bill of Materials (SBOM) | Listas de dependencias aprobadas; registros SBOM por versión; informes de evaluación de riesgos de proveedores; flujos de trabajo de aprobación de componentes de terceros |
| Art. 21(2)(e) — Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información | Estándares de configuración segura de pipelines; separación de entornos (dev/staging/producción); puertas de análisis de seguridad automatizadas | Líneas base de configuración de pipelines; documentación de arquitectura de entornos; políticas de puertas de análisis y registros de aprobación/rechazo |
| Art. 21(2)(f) — Políticas y procedimientos para evaluar la eficacia de las medidas de gestión del riesgo de ciberseguridad | Métricas e indicadores clave de rendimiento (KPI) de seguridad de pipelines; auditorías periódicas de pipelines; revisiones de eficacia de controles | Informes de panel sobre tasas de aprobación de puertas de seguridad; hallazgos de auditoría y seguimiento de remediación; actas de revisión por parte de la dirección |
| Art. 21(2)(g) — Prácticas básicas de ciberhigiene y formación en ciberseguridad | Formación de desarrolladores sobre el uso seguro de pipelines; procedimientos de incorporación documentados para el acceso a pipelines | Registros de finalización de formación; listas de verificación de incorporación; materiales del programa de concienciación sobre seguridad CI/CD |
| Art. 21(2)(h) — Políticas y procedimientos relativos al uso de criptografía y cifrado | Políticas de gestión de secretos; cifrado de artefactos en tránsito y en reposo; requisitos de firma de código | Atestaciones de configuración de herramientas de gestión de secretos; políticas de cifrado; registros de verificación de artefactos firmados; registros de gestión de certificados |
| Art. 21(2)(i) — Seguridad de los recursos humanos, políticas de control de acceso y gestión de activos | Control de acceso basado en roles (RBAC) para sistemas de pipeline; inventario de activos de pipeline; procesos de incorporación/traslado/baja para el acceso CI/CD | Matrices RBAC para herramientas de pipeline; registros de revisión de accesos; registros de activos que listan los componentes CI/CD; registros de aprovisionamiento y desaprovisionamiento de acceso |
| Art. 21(2)(j) — Uso de autenticación multifactor (MFA) y comunicaciones seguras | Aplicación de MFA en todas las interfaces de administración de pipelines; canales de comunicación cifrados entre componentes de pipeline | Atestaciones de configuración de aplicación de MFA; registros de autenticación que muestran el uso de MFA; evidencia de configuración TLS/mTLS para comunicación entre componentes |
Qué deben verificar los auditores
Capa de políticas y gobernanza
- Existencia y vigencia de políticas: Confirmar que existen políticas de seguridad de pipeline, que están aprobadas por la dirección correspondiente y que han sido revisadas en los últimos 12 meses.
- Adecuación del alcance: Verificar que las políticas cubren explícitamente la infraestructura CI/CD, no solo los sistemas de producción. Muchas organizaciones pasan por alto los entornos de compilación en sus marcos de seguridad.
- Cobertura de la evaluación de riesgos: Comprobar que el registro de riesgos de la organización incluye riesgos específicos de CI/CD, como la manipulación de pipelines, la filtración de secretos y el envenenamiento de dependencias.
Capa de implementación de controles
- Segregación de funciones: Verificar que la persona que escribe código no puede también aprobarlo y desplegarlo sin revisión independiente.
- Trazabilidad de cambios: Confirmar que cada despliegue en producción puede rastrearse hasta una solicitud de cambio aprobada, una revisión de código y un análisis de seguridad exitoso.
- Controles de acceso: Solicitar evidencia de revisiones periódicas de acceso a las herramientas de administración de pipelines. Buscar cuentas inactivas y privilegios excesivos.
- Gestión de secretos: Confirmar que los secretos no están codificados directamente en las configuraciones de pipeline. Solicitar atestación de las herramientas de gestión de secretos.
Capa de evidencia y monitorización
- Integridad de registros: Verificar que los registros de pipeline capturan quién activó un despliegue, qué se desplegó, cuándo se desplegó y si todas las puertas requeridas pasaron.
- Periodos de retención: Confirmar que la retención de registros cumple tanto con los requisitos de NIS2 como con la política propia de la organización (normalmente un mínimo de 12–24 meses).
- Protección contra manipulaciones: Comprobar si los registros de pipeline se almacenan en un almacenamiento de solo adición o inmutable para evitar manipulaciones posteriores a los incidentes.
Señales de alerta a vigilar
- Políticas de seguridad de pipeline que simplemente hacen referencia a políticas generales de TI sin controles específicos de CI/CD
- Sin evidencia de revisiones periódicas de acceso a las herramientas de pipeline
- Despliegues que omiten las puertas de aprobación requeridas (buscar registros de despliegue de emergencia o anulación sin justificación posterior)
- Secretos visibles en los registros de pipeline o archivos de configuración
- Sin gobernanza documentada de la cadena de suministro para dependencias de terceros
Cómo prueban los auditores estos controles en la práctica
Mapear los requisitos a los controles es solo la mitad del ejercicio. Durante el trabajo de campo, los auditores no leen las políticas de forma aislada — comprueban si los controles mapeados funcionan realmente como se describe. Comprender su método ayuda a los equipos de cumplimiento a preparar la evidencia adecuada.
Una evaluación típica combina tres técnicas:
- Indagación — entrevistar a los responsables de los pipelines y a los ingenieros para comprender cómo se supone que funciona un control, y luego comparar ese relato con la política documentada.
- Inspección — examinar la configuración, las matrices RBAC, las definiciones de puertas y muestras de registros para confirmar que el control existe tal como está configurado, no solo como está redactado.
- Reejecución y muestreo — seleccionar una muestra de versiones de producción del periodo de revisión y rastrear cada una desde el cambio de origen a través de la revisión, las puertas de seguridad, la aprobación y el despliegue.
Dado que el Artículo 21 exige un enfoque de todos los riesgos, una sola muestra fallida — una versión que llegó a producción sin superar una puerta de seguridad, o una aprobación concedida por el autor del cambio — suele bastar para generar un hallazgo frente al requisito correspondiente. Preparar de antemano un pequeño número de ejemplos de versiones completos y trazables es una de las formas más eficaces de acortar una evaluación.
Superposición con DORA, ISO 27001 y SOC 2
La mayoría de las entidades reguladas están sujetas a más de un marco a la vez. Los controles que satisfacen el Artículo 21 también abordan gran parte de DORA, ISO 27001 y SOC 2 — lo que significa que un único entorno de controles de CI/CD bien evidenciado puede cumplir varias obligaciones simultáneamente. El mapeo siguiente destaca las superposiciones más fuertes.
| Tema del Artículo 21 de NIS2 | DORA | ISO 27001 (Anexo A) | SOC 2 |
|---|---|---|---|
| Análisis de riesgos y políticas de seguridad (a) | Marco de gestión de riesgos ICT | A.5.1, A.5.9 | CC3.x |
| Gestión de incidentes (b) | Gestión y notificación de incidentes ICT | A.5.24–A.5.27 | CC7.x |
| Seguridad de la cadena de suministro (d) | Riesgo ICT de terceros | A.5.19–A.5.23 | CC9.2 |
| Desarrollo y adquisición seguros (e) | Gestión de cambios ICT | A.8.25–A.8.32 | CC8.1 |
| Control de acceso y MFA (i, j) | Protección y prevención ICT | A.5.15–A.5.18, A.8.5 | CC6.x |
Para los auditores, esta superposición es una oportunidad para reducir la duplicación: un único recorrido por el pipeline puede aportar evidencia frente a múltiples marcos. Para los responsables de cumplimiento, es un argumento a favor de mantener un único conjunto consolidado de controles en lugar de documentación paralela específica de cada marco.
Preparación de un paquete de evidencia del Artículo 21
En lugar de recopilar evidencia de forma reactiva, los equipos maduros mantienen un paquete de evidencia permanente alineado con los diez subrequisitos del Artículo 21. Como mínimo, debe contener:
- La política de seguridad de pipeline vigente, con sus fechas de aprobación y última revisión
- La evaluación de riesgos CI/CD más reciente y el inventario de activos
- Las matrices RBAC y la última revisión de accesos para las herramientas de pipeline
- Un SBOM de muestra, un registro de artefacto firmado y una aprobación de dependencia para una versión reciente
- Procedimientos de respuesta a incidentes y de continuidad del negocio que nombran el pipeline de forma explícita
- Dos o tres ejemplos de versiones totalmente trazables que abarquen el código, la revisión, las puertas, la aprobación y el despliegue
Mantener este paquete actualizado convierte cada evaluación de un simulacro de emergencia en un recorrido sencillo, y aborda directamente el requisito (f) — la obligación de evaluar la eficacia de las propias medidas.
Recursos relacionados
Para una comprensión más profunda de cómo los principios de arquitectura de seguridad de NIS2 se aplican a los entornos CI/CD, consulte Arquitectura de seguridad de NIS2 explicada.
Para la biblioteca completa de recursos de cumplimiento de NIS2, visite nuestro Centro de cumplimiento NIS2.
Relacionado para auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- DORA Artículo 21 en profundidad
- Comparación NIS2 vs DORA
- Lista de verificación de preparación para auditoría
¿Nuevo en la auditoría de CI/CD? Comience con nuestra Guía para auditores.
