Introducción
El Digital Operational Resilience Act (DORA) introduce un marco integral para fortalecer la resiliencia digital de las entidades financieras en toda la Unión Europea. Si bien el Artículo 21 recibe gran atención por su enfoque en la gestión interna del riesgo ICT, el Artículo 28 desplaza el foco hacia el exterior, abordando los riesgos introducidos por proveedores de servicios ICT de terceros.
En los entornos empresariales modernos, la entrega de software depende en gran medida de plataformas externas como proveedores de cloud, herramientas CI/CD SaaS, servicios de alojamiento de código fuente y soluciones de seguridad gestionadas. El Artículo 28 de DORA lleva formalmente estas dependencias al ámbito de aplicación, exigiendo a las organizaciones que identifiquen, evalúen, controlen y monitoreen continuamente los riesgos ICT de terceros.
Este artículo explica qué requiere realmente el Artículo 28 de DORA, por qué los pipelines CI/CD y las herramientas DevSecOps se ven directamente impactados, y cómo deben abordar el cumplimiento las organizaciones en entornos regulados.
Qué Cubre el Artículo 28 de DORA
El Artículo 28 de DORA establece un marco estructurado para la gestión del riesgo ICT de terceros. Su objetivo es garantizar que las entidades financieras mantengan la resiliencia operacional incluso cuando servicios críticos son prestados por proveedores externos.
A grandes rasgos, el Artículo 28 exige a las organizaciones:
- Identificar y mantener un inventario de proveedores de servicios ICT de terceros
- Clasificar a los proveedores según su criticidad y riesgo
- Realizar diligencia debida antes de la incorporación
- Definir cláusulas obligatorias de seguridad y auditoría en los contratos
- Monitorear continuamente los riesgos de terceros
- Gestionar el riesgo de concentración y las cadenas de dependencia
- Preparar y probar estrategias de salida
A diferencia de los enfoques tradicionales de gestión de proveedores, el Artículo 28 de DORA trata a los proveedores ICT como componentes integrales del panorama de riesgo operacional, no como preocupaciones periféricas de externalización.
Por Qué CI/CD y DevSecOps Están Explícitamente en el Alcance
Aunque DORA no menciona CI/CD o DevSecOps explícitamente, el Artículo 28 claramente les aplica en la práctica.
Los pipelines CI/CD modernos dependen de múltiples servicios ICT de terceros, entre ellos:
- Plataformas de alojamiento de código fuente (por ejemplo, Git hosting SaaS)
- Plataformas de orquestación CI/CD
- Build runners y entornos de ejecución gestionados
- Repositorios de artefactos y registros de contenedores
- Gestión de dependencias y ecosistemas de paquetes
- Infraestructura cloud y servicios de tiempo de ejecución gestionados
Cada uno de estos servicios puede afectar a:
- La integridad del código
- La seguridad de la cadena de suministro de software
- La disponibilidad de los pipelines de entrega
- Los plazos de respuesta a incidentes
- La evidencia y auditabilidad
Bajo el Artículo 28, estas plataformas deben tratarse como proveedores de servicios ICT de terceros, y sus riesgos deben gestionarse con el mismo rigor que los sistemas internos.
Clasificación y Criticidad de Terceros ICT
Un requisito clave del Artículo 28 es la clasificación de los proveedores ICT de terceros.
Las organizaciones deben evaluar:
- Si un proveedor soporta funciones críticas o importantes
- El impacto potencial de un fallo del proveedor
- El nivel de sustituibilidad
- La dependencia de subcontratistas y cuartas partes
En contextos CI/CD, las plataformas que influyen directamente en el código, las builds o los despliegues se clasifican frecuentemente como proveedores ICT de alto impacto o críticos, incluso si son servicios SaaS ampliamente utilizados.
Esta clasificación determina la profundidad de los controles requeridos, incluyendo cláusulas contractuales, derechos de auditoría y obligaciones de monitoreo.
Requisitos Contractuales y de Gobernanza
El Artículo 28 pone un fuerte énfasis en la gobernanza contractual.
Los contratos con proveedores ICT de terceros deben incluir disposiciones que cubran:
- Requisitos de seguridad de la información
- Control de acceso y segregación de funciones
- Plazos de notificación de incidentes
- Derechos de auditoría e inspección
- Restricciones sobre la ubicación y el procesamiento de datos
- Continuidad del negocio y recuperación ante desastres
- Condiciones de salida y terminación
Para las herramientas CI/CD y DevSecOps, esto significa que los contratos deben abordar explícitamente:
- Seguridad de los entornos de build y despliegue
- Protección contra inyección no autorizada de código
- Retención de evidencia para fines de auditoría
- Transparencia sobre subcontratistas e infraestructura compartida
Monitoreo Continuo y Recopilación de Evidencia
El Artículo 28 de DORA no permite una gestión del riesgo de proveedores del tipo «configurar y olvidar».
Se espera que las organizaciones:
- Monitoreen continuamente el rendimiento y la seguridad de los terceros ICT
- Rastreen los incidentes que involucren servicios de terceros
- Mantengan evidencia auditable de las actividades de supervisión
- Reevalúen los perfiles de riesgo con el tiempo
En entornos CI/CD, esto incluye típicamente:
- Logs de plataformas CI/CD de terceros
- Registros de acceso y actividad
- Evidencia de integridad de artefactos (firmas, SBOMs)
- Informes de incidentes que involucren servicios externos
- Registros de cambios y aprobaciones vinculados a herramientas proporcionadas por terceros
Este requisito se alinea estrechamente con las prácticas DevSecOps que enfatizan la automatización, la trazabilidad y la gobernanza basada en evidencia.
Estrategias de Salida y Riesgo de Concentración
El Artículo 28 exige explícitamente que las organizaciones preparen estrategias de salida para los servicios ICT de terceros.
Esto incluye:
- La capacidad de rescindir contratos sin interrupción inaceptable
- Planes de migración a proveedores alternativos
- Controles para evitar un riesgo de concentración excesivo
En la práctica, este es uno de los aspectos más desafiantes del cumplimiento del Artículo 28, especialmente para las plataformas CI/CD y cloud donde el bloqueo de proveedores es común.
Las organizaciones deben demostrar que:
- Los pipelines de entrega críticos no dependen de un único proveedor sin mitigación
- Los planes de salida están documentados, son realistas y se revisan periódicamente
- Las dependencias de subprocesadores se comprenden y gestionan
Relación con el Artículo 21 de DORA
El Artículo 28 de DORA no opera de forma aislada. Extiende y complementa el Artículo 21.
- El Artículo 21 se centra en la gestión interna del riesgo ICT y los controles
- El Artículo 28 aplica esos principios a los proveedores de servicios ICT externos
En entornos DevSecOps regulados, esto significa que:
- Los controles de seguridad aplicados internamente también deben aplicarse a través de plataformas de terceros
- La evidencia recopilada de los pipelines CI/CD debe incluir las herramientas de terceros
- La gobernanza y la responsabilidad deben abarcar los límites organizacionales
Juntos, los Artículos 21 y 28 forman un modelo de gestión de riesgos continuo en toda la cadena de entrega digital.
Errores Comunes del Artículo 28 en Entornos CI/CD
Las organizaciones suelen tener dificultades con el Artículo 28 debido a:
- Tratar las plataformas CI/CD SaaS como «utilidades de bajo riesgo»
- Falta de visibilidad sobre los subprocesadores utilizados por los proveedores
- Ausencia de derechos de auditoría en los contratos SaaS estándar
- Ausencia de estrategia de salida para herramientas CI/CD críticas
- Retención de evidencia insuficiente vinculada a servicios de terceros
Estas brechas suelen aparecer durante revisiones regulatorias o auditorías, incluso en organizaciones DevSecOps por lo demás maduras.
Qué Viene a Continuación
Este artículo proporciona los fundamentos conceptuales del Artículo 28 de DORA. En los próximos artículos de esta serie, exploraremos:
- Patrones de arquitectura del Artículo 28 de DORA para entornos CI/CD y cloud
- Un paquete de evidencia del Artículo 28: lo que realmente esperan los auditores
- Una lista de verificación práctica de auditoría para el riesgo ICT de terceros
- Escenarios y señales de alerta de riesgo de terceros específicos de CI/CD
En conjunto, estos recursos proporcionan una hoja de ruta práctica para implementar la gestión del riesgo de terceros alineada con DORA en entornos DevSecOps modernos.
