El Artículo 21 del Reglamento de Resiliencia Operativa Digital (DORA) define los requisitos fundamentales de gestión del riesgo ICT que las entidades financieras deben implementar, monitorizar y evidenciar de forma continua. A diferencia de las obligaciones de gobernanza de alto nivel, el Artículo 21 se centra en controles técnicos y organizativos concretos, y para la mayoría de las instituciones, el pipeline CI/CD es donde se aplica en la práctica una gran parte de esos controles.
Esta es la referencia completa y consolidada del Artículo 21 en un contexto CI/CD. Reúne, en un único recurso listo para auditoría, cuatro elementos que los equipos de cumplimiento y aseguramiento normalmente tienen que ensamblar por separado: un análisis en profundidad de cada requisito del Artículo 21, un mapeo control a control desde la normativa hasta los controles CI/CD específicos y la evidencia que generan, una lista de comprobación del auditor para revisiones internas y supervisoras, y un paquete de evidencia que describe exactamente qué artefactos presentar y dónde encontrarlos.
El público al que va dirigido son auditores, responsables de cumplimiento y profesionales de GRC que se preparan para —o llevan a cabo— una evaluación de DORA. Lea el análisis en profundidad para comprender la intención, utilice el mapeo para conectar los requisitos con los controles, trabaje la lista de comprobación durante el trabajo de campo y ensamble el paquete de evidencia para demostrar que los controles se aplican de forma coherente y reproducible.
Comprender el alcance del Artículo 21 de DORA
El Artículo 21 exige a las entidades financieras establecer, implementar y mantener un marco integral de gestión del riesgo ICT. Este marco debe garantizar la confidencialidad, integridad, disponibilidad y autenticidad de los sistemas ICT que respaldan funciones críticas o importantes.
Los pipelines CI/CD entran en este alcance porque influyen directamente en:
- el comportamiento de los sistemas de producción
- la frecuencia y estabilidad de los despliegues
- la integridad de la cadena de suministro de software
- el acceso privilegiado a la infraestructura y las aplicaciones
En consecuencia, los pipelines CI/CD deben gobernarse y controlarse como sistemas ICT regulados.
Artículo 21(1): marco de gestión del riesgo ICT y CI/CD
El Artículo 21(1) exige un marco estructurado de gestión del riesgo ICT que cubra la identificación, protección, prevención, detección, respuesta y recuperación.
Los pipelines CI/CD respaldan este requisito mediante:
- la identificación del riesgo a través de pruebas de seguridad automatizadas
- la prevención del riesgo mediante la aplicación de políticas y gates de aprobación
- la detección de anomalías a través de la monitorización del pipeline
- el respaldo a la respuesta mediante mecanismos de rollback trazables
- la habilitación de la recuperación mediante procesos de despliegue controlados
Integrar estos mecanismos en los flujos de trabajo de CI/CD garantiza que la gestión del riesgo ICT sea operativa en lugar de teórica.
Artículo 21(2)(a): control de acceso y operaciones privilegiadas
El Artículo 21(2)(a) exige mecanismos adecuados de control de acceso para proteger los sistemas ICT del acceso no autorizado.
En contextos CI/CD, esto se traduce en:
- una separación estricta entre los usuarios humanos y las identidades del pipeline
- la aplicación del mínimo privilegio para las cuentas de servicio de CI/CD
- el control de acceso basado en roles para la configuración del pipeline
- MFA obligatorio para los administradores
No proteger las rutas de acceso al CI/CD expone a las organizaciones a un riesgo sistémico, ya que los pipelines suelen tener privilegios elevados en todos los entornos.
Artículo 21(2)(b): segregación de funciones y gobernanza
El Artículo 21 hace hincapié en la segregación de funciones para reducir el riesgo de cambios no autorizados o no revisados.
Los pipelines CI/CD aplican la segregación de funciones mediante:
- la exigencia de una revisión de código independiente antes de ejecutar el pipeline
- la separación de los permisos de compilación, validación y despliegue
- la aplicación de flujos de trabajo de aprobación para las releases sensibles
- el registro de todas las anulaciones y excepciones
La segregación automatizada dentro de los pipelines ofrece garantías más sólidas que los controles manuales.
Artículo 21(2)(c): registro, monitorización y detección
El Artículo 21 exige capacidades de monitorización y detección continuas para identificar los incidentes relacionados con las ICT.
Los pipelines CI/CD contribuyen mediante:
- el registro de todas las ejecuciones del pipeline y los cambios de configuración
- el registro de los resultados de los análisis de seguridad y las decisiones de aprobación
- la emisión de alertas ante comportamientos anómalos o controles fallidos
- la integración con sistemas centralizados de monitorización y SIEM
Estos logs constituyen una parte crítica de los procesos de detección e investigación conformes con DORA.
Artículo 21(2)(d): gestión de cambios e integridad del sistema
La gestión de cambios es un componente central del Artículo 21. Los pipelines CI/CD implementan directamente procesos de cambio controlados.
Los mecanismos de aplicación clave incluyen:
- la aprobación obligatoria de cambios mediante gates de pipeline
- la validación y firma de la integridad de los artefactos
- la trazabilidad entre el código fuente, la ejecución del pipeline y el artefacto desplegado
- la prevención de despliegues fuera de banda
Estos controles garantizan que solo los cambios autorizados y verificados lleguen a los sistemas de producción.
Artículo 21(2)(e): resiliencia, copias de seguridad y recuperación
La resiliencia operativa es un objetivo central de DORA. Los pipelines CI/CD no deben convertirse en puntos únicos de fallo.
Un diseño de pipeline resiliente incluye:
- entornos de compilación reforzados y aislados
- redundancia para los componentes CI/CD críticos
- mecanismos de rollback y redespliegue probados
- copia de seguridad segura de la configuración y los artefactos del pipeline
Los pipelines CI/CD que fallan de forma controlada y se recuperan con rapidez respaldan los objetivos más amplios de resiliencia ICT.
Generación continua de evidencia para el cumplimiento del Artículo 21
Una de las ventajas más significativas del cumplimiento basado en CI/CD es la generación continua de evidencia.
Los pipelines CI/CD producen de forma natural:
- logs de acceso y registros de aprobación
- resultados de pruebas de seguridad
- metadatos de procedencia de artefactos
- historiales de despliegue
Esta evidencia respalda directamente las expectativas de auditoría del Artículo 21 al demostrar que los controles se aplican de forma coherente y continua.
Brechas habituales observadas durante las evaluaciones de DORA
Las organizaciones a menudo subestiman la relevancia del CI/CD durante los esfuerzos de preparación para DORA. Las brechas habituales incluyen:
- tratar los pipelines como herramientas no reguladas
- privilegios excesivos concedidos a la automatización
- falta de procedencia de artefactos
- retención de logs insuficiente
- excepciones y anulaciones no documentadas
Abordar estas brechas de forma temprana reduce significativamente el riesgo regulatorio y operativo.
Artículo 21 ↔ mapeo de controles CI/CD
El análisis en profundidad anterior explica qué pide cada requisito del Artículo 21. El mapeo siguiente lo convierte en una visión operativa: para cada requisito, nombra el control CI/CD correspondiente y la evidencia específica que ese control produce. Los auditores pueden leer cada fila como una afirmación comprobable: el requisito de la izquierda debería satisfacerse mediante el control del centro, y demostrarse con la evidencia de la derecha.
Artículo 21(1) — marco de gestión del riesgo ICT
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Identificar y evaluar los riesgos ICT | Pruebas de seguridad automatizadas (SAST, SCA, DAST) | Informes de análisis, logs del pipeline |
| Prevenir y mitigar los riesgos ICT | Aplicación de políticas y gates de pipeline | Decisiones de gate, aprobaciones |
| Detectar actividades anómalas | Monitorización del pipeline y alertas | Logs de alertas, eventos de SIEM |
| Responder a incidentes ICT | Rollback y redespliegues controlados | Historial de despliegues |
| Recuperarse de las interrupciones | Compilaciones y releases reproducibles | Metadatos de compilación |
Artículo 21(2)(a) — control de acceso
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Impedir el acceso no autorizado | RBAC para la configuración del CI/CD | Logs de control de acceso |
| Proteger las operaciones privilegiadas | Cuentas de servicio con mínimo privilegio | Políticas de IAM |
| Asegurar el acceso administrativo | MFA para administradores de CI/CD | Logs de autenticación |
| Controlar las identidades de automatización | Identidades de pipeline separadas | Inventario de identidades |
Artículo 21(2)(b) — segregación de funciones
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Separar roles en conflicto | Requisitos de revisión de código | Historial de pull requests |
| Impedir la autoaprobación | Reglas de aprobación aplicadas por el pipeline | Registros de aprobación |
| Controlar la autoridad de release | Permisos de compilación y despliegue separados | Mapeo de roles del pipeline |
| Registrar anulaciones y excepciones | Registro de excepciones | Logs de auditoría de anulaciones |
Artículo 21(2)(c) — registro y monitorización
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Monitorizar la actividad del sistema ICT | Registro completo de la ejecución del pipeline | Logs de ejecución |
| Detectar eventos relevantes para la seguridad | Controles fallidos y alertas de anomalías | Alertas de seguridad |
| Retener los logs de forma segura | Almacenamiento centralizado de logs | Configuración de retención |
| Respaldar las investigaciones | Rastros de auditoría inmutables | Logs listos para análisis forense |
Artículo 21(2)(d) — gestión de cambios e integridad
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Controlar los cambios en los sistemas ICT | Pipelines CI/CD obligatorios | Historial de despliegues |
| Garantizar la integridad de los cambios | Firma y verificación de artefactos | Metadatos de firma |
| Trazar los cambios de extremo a extremo | Vinculación código → pipeline → artefacto | Registros de procedencia |
| Impedir los despliegues no autorizados | Gates de política y aprobaciones | Logs de aplicación de gates |
Artículo 21(2)(e) — resiliencia, copias de seguridad y recuperación
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Garantizar la resiliencia del sistema | Entornos de compilación reforzados y aislados | Configuración del entorno |
| Evitar los puntos únicos de fallo | Componentes CI/CD redundantes | Documentación de arquitectura |
| Habilitar los mecanismos de recuperación | Flujos de trabajo de rollback y redespliegue | Logs de recuperación |
| Proteger las configuraciones | Copia de seguridad segura de la configuración del pipeline | Registros de copias de seguridad |
Artículo 21(2)(f) — mejora continua
| Requisito de DORA | Control CI/CD | Evidencia generada |
|---|---|---|
| Revisar la postura de riesgo ICT | Revisiones periódicas de seguridad del pipeline | Informes de revisión |
| Actualizar los controles según sea necesario | Cambios en la configuración del pipeline | Logs de cambios |
| Mejorar la detección y la prevención | Actualizaciones de herramientas y ajuste de reglas | Historial de versiones |
| Alinearse con la evolución de las amenazas | Actualizaciones del pipeline basadas en amenazas | Evaluaciones de riesgo |
Cómo utilizan los auditores esta tabla
- Validar que los requisitos del Artículo 21 se aplican técnicamente
- Identificar dónde contribuye el CI/CD a la gestión del riesgo ICT
- Solicitar la evidencia específica generada por los pipelines
- Evaluar la coherencia y repetibilidad de los controles
Lista de comprobación del auditor para el Artículo 21
Una vez que el mapeo establece qué controles deberían existir, la lista de comprobación siguiente permite a un evaluador confirmar si realmente existen. Está organizada por las mismas subsecciones del Artículo 21 y es apta para auditorías internas, revisiones supervisoras y evaluaciones regulatorias. Cada línea es una comprobación de control de sí/no; un “no” marca una brecha que justifica un hallazgo o una acción de remediación.
Artículo 21(1) — marco de gestión del riesgo ICT
| Comprobación de control | Sí | No |
|---|---|---|
| Los pipelines CI/CD se incluyen en el alcance de la gestión del riesgo ICT | ⬜ | ⬜ |
| Los riesgos ICT relacionados con la entrega de software se identifican formalmente | ⬜ | ⬜ |
| Los controles preventivos se aplican mediante los pipelines CI/CD | ⬜ | ⬜ |
| Existen mecanismos de detección para los incidentes relacionados con el pipeline | ⬜ | ⬜ |
| El CI/CD respalda los procesos de respuesta y recuperación | ⬜ | ⬜ |
Artículo 21(2)(a) — control de acceso
| Comprobación de control | Sí | No |
|---|---|---|
| El acceso al CI/CD sigue los principios de mínimo privilegio | ⬜ | ⬜ |
| Las identidades del pipeline están separadas de los usuarios humanos | ⬜ | ⬜ |
| Se aplica RBAC para la configuración del pipeline | ⬜ | ⬜ |
| MFA es obligatorio para los administradores de CI/CD | ⬜ | ⬜ |
| Las acciones privilegiadas están restringidas y monitorizadas | ⬜ | ⬜ |
Artículo 21(2)(b) — segregación de funciones
| Comprobación de control | Sí | No |
|---|---|---|
| Los desarrolladores no pueden autoaprobar cambios en producción | ⬜ | ⬜ |
| La revisión de código es obligatoria antes de ejecutar el pipeline | ⬜ | ⬜ |
| Los permisos de compilación y despliegue están separados | ⬜ | ⬜ |
| Las anulaciones y excepciones se registran | ⬜ | ⬜ |
| La segregación de funciones se revisa periódicamente | ⬜ | ⬜ |
Artículo 21(2)(c) — registro y monitorización
| Comprobación de control | Sí | No |
|---|---|---|
| Todas las ejecuciones de CI/CD se registran | ⬜ | ⬜ |
| Los logs incluyen aprobaciones y controles de seguridad | ⬜ | ⬜ |
| Los logs se recopilan de forma centralizada | ⬜ | ⬜ |
| La retención de logs cumple los requisitos regulatorios | ⬜ | ⬜ |
| Existen alertas ante comportamientos anómalos del pipeline | ⬜ | ⬜ |
Artículo 21(2)(d) — gestión de cambios e integridad
| Comprobación de control | Sí | No |
|---|---|---|
| Todos los cambios en producción pasan por los pipelines CI/CD | ⬜ | ⬜ |
| La integridad de los artefactos se verifica antes del despliegue | ⬜ | ⬜ |
| La procedencia vincula el código fuente con los artefactos desplegados | ⬜ | ⬜ |
| Los despliegues fuera de banda se impiden o se registran | ⬜ | ⬜ |
| Las aprobaciones de cambios son auditables | ⬜ | ⬜ |
Artículo 21(2)(e) — resiliencia, copias de seguridad y recuperación
| Comprobación de control | Sí | No |
|---|---|---|
| Los pipelines CI/CD están diseñados para la resiliencia | ⬜ | ⬜ |
| Los entornos de compilación están aislados y reforzados | ⬜ | ⬜ |
| Las configuraciones del pipeline se respaldan de forma segura | ⬜ | ⬜ |
| Los procedimientos de rollback están probados | ⬜ | ⬜ |
| Los componentes CI/CD no representan puntos únicos de fallo | ⬜ | ⬜ |
Artículo 21(2)(f) — mejora continua
| Comprobación de control | Sí | No |
|---|---|---|
| Los controles de seguridad del CI/CD se revisan periódicamente | ⬜ | ⬜ |
| Los controles del pipeline evolucionan con el panorama de amenazas | ⬜ | ⬜ |
| Las lecciones aprendidas se reincorporan a los pipelines | ⬜ | ⬜ |
| Las brechas de cumplimiento activan acciones correctivas | ⬜ | ⬜ |
| La supervisión de la dirección incluye la postura de riesgo del CI/CD | ⬜ | ⬜ |
Orientación para el auditor
Al utilizar esta lista de comprobación:
- Solicite evidencia técnica, no solo políticas
- Verifique que los controles estén automatizados y aplicados
- Confirme que la evidencia sea actual y reproducible
- Evalúe la coherencia entre equipos y pipelines
- Preste especial atención a las excepciones y anulaciones
Paquete de evidencia para auditores
Una lista de comprobación confirma que un control está presente; el paquete de evidencia se lo demuestra a un auditor. Esta sección final enumera, subsección por subsección, los artefactos técnicos y operativos que las instituciones financieras deben presentar, qué esperan los auditores de cada uno y dónde reside habitualmente esa evidencia. El énfasis en todo momento recae en la evidencia generada por el sistema, con marca de tiempo y reproducible, más que en las declaraciones de política por sí solas.
Cómo utilizar este paquete de evidencia
- Utilícelo como lista de comprobación durante la preparación de la auditoría
- Compártalo con los equipos de ingeniería, seguridad y cumplimiento
- Adjunte referencias a sistemas, logs y repositorios reales
- Asegúrese de que la evidencia sea actual, trazable y reproducible
Artículo 21(1) — marco de gestión del riesgo ICT
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Registro de riesgos ICT | Los pipelines CI/CD figuran explícitamente como sistemas ICT dentro del alcance |
| Modelos de amenazas | Riesgos relacionados con el CI/CD (abuso de credenciales, cadena de suministro, integridad) |
| Planes de tratamiento del riesgo | Controles asignados a los pipelines CI/CD |
| Documentación de gobernanza | Titularidad de la seguridad y el riesgo del CI/CD |
Fuentes habituales
- Herramientas de gestión de riesgos
- Documentación de arquitectura
- Repositorios de gobernanza de seguridad
Artículo 21(2)(a) — control de acceso
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Políticas de IAM | Mínimo privilegio para las cuentas de servicio de CI/CD |
| Configuración de RBAC | Separación de roles para la administración del pipeline |
| Aplicación de MFA | Prueba de que MFA es obligatorio para los usuarios privilegiados |
| Inventario de identidades | Distinción entre identidades humanas y de automatización |
Fuentes habituales
- Plataforma de IAM
- Configuración del sistema CI/CD
- Informes de revisión de acceso
Artículo 21(2)(b) — segregación de funciones
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Reglas de revisión de código | Revisión por pares obligatoria aplicada |
| Flujos de trabajo de aprobación | Aprobación independiente para los cambios en producción |
| Mapeo de roles | Separación entre los roles de compilación, validación y despliegue |
| Logs de excepciones | Registros de anulaciones y aprobaciones |
Fuentes habituales
- Plataforma de control de versiones
- Definiciones del pipeline CI/CD
- Logs de auditoría
Artículo 21(2)(c) — registro y monitorización
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Logs de ejecución del pipeline | Historial completo de las ejecuciones y sus resultados |
| Logs de eventos de seguridad | Controles fallidos, releases bloqueadas |
| Cuadros de mando de monitorización | Visibilidad sobre la salud del pipeline |
| Políticas de retención de logs | Alineación con los requisitos regulatorios |
Fuentes habituales
- Plataformas CI/CD
- Sistemas de SIEM / registro
- Herramientas de monitorización
Artículo 21(2)(d) — gestión de cambios e integridad
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Registros de despliegue | Todos los cambios en producción trazables hasta los pipelines |
| Firma de artefactos | Prueba de integridad criptográfica |
| Metadatos de procedencia | Vinculación código → compilación → artefacto |
| Aprobaciones de release | Puntos de decisión auditables |
Fuentes habituales
- Repositorios de artefactos
- Almacenes de metadatos de CI/CD
- Sistemas de gestión de releases
Artículo 21(2)(e) — resiliencia, copias de seguridad y recuperación
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Diagramas de arquitectura del CI/CD | Redundancia y aislamiento |
| Procedimientos de copia de seguridad | Copias de seguridad seguras de las configuraciones del pipeline |
| Pruebas de recuperación | Evidencia de ejercicios de rollback y recuperación |
| Playbooks de incidentes | Procedimientos de respuesta específicos del CI/CD |
Fuentes habituales
- Documentación de arquitectura
- Sistemas de copia de seguridad
- Herramientas de gestión de incidentes
Artículo 21(2)(f) — mejora continua
Evidencia a aportar
| Tipo de evidencia | Lo que esperan los auditores |
|---|---|
| Informes de revisión | Revisiones periódicas de seguridad del CI/CD |
| Logs de cambios | Mejoras en los controles del pipeline |
| Métricas y KPI | Indicadores de seguridad y resiliencia |
| Supervisión de la dirección | Evidencia de revisión de gobernanza |
Fuentes habituales
- Registros de revisiones de seguridad
- Historial de cambios del CI/CD
- Notas de reuniones de gobernanza
Errores habituales de auditoría (qué NO mostrar en solitario)
Los auditores cuestionarán:
- Políticas de alto nivel sin aplicación técnica
- Capturas de pantalla sin trazabilidad
- Atestaciones manuales sin evidencia del sistema
- Ejemplos puntuales en lugar de controles repetibles
La evidencia debe ser generada por el sistema, con marca de tiempo y reproducible.
Consejos de empaquetado orientados al auditor
- Agrupe la evidencia por subsección del Artículo 21
- Proporcione acceso de solo lectura a logs y cuadros de mando
- Incluya evidencia de muestra + explicación
- Indique claramente los responsables de los controles
- Evite sobrecargar a los auditores con datos irrelevantes
Conclusión
El Artículo 21 de DORA establece una expectativa clara: la gestión del riesgo ICT debe estar integrada, ser continua y aplicarse técnicamente. Los pipelines CI/CD, como facilitadores centrales de la entrega de software, son fundamentales para cumplir esa expectativa y, dado que generan logs, aprobaciones y procedencia como subproducto de su funcionamiento normal, son también una de las fuentes de evidencia de auditoría más ricas de que dispone una entidad financiera.
Al alinear el diseño del pipeline con los controles del Artículo 21 descritos aquí, y al preparar el mapeo, la lista de comprobación y el paquete de evidencia con antelación, las instituciones pueden pasar de las carreras reactivas ante las auditorías a un estado de preparación continua para la auditoría, demostrando resiliencia operativa, reduciendo el riesgo sistémico y ofreciendo a los reguladores una prueba de cumplimiento concreta y reproducible.
Recursos relacionados
- Cumplimiento continuo a través de CI/CD bajo DORA
- Auditoría de seguridad CI/CD — mapeo ISO 27001 / SOC 2 / DORA
- Arquitectura de cumplimiento DORA
- Cumplimiento normativo
- Seguridad CI/CD
