Introducción
El Artículo 28 de DORA exige a las entidades financieras que gestionen los riesgos derivados de los proveedores de servicios ICT de terceros.
En la entrega de software moderna, estos proveedores no son periféricos — están integrados directamente en los pipelines CI/CD y los entornos de ejecución cloud.
Este artículo presenta una vista arquitectónica práctica del Artículo 28 de DORA, mostrando:
- dónde intervienen los proveedores de terceros a lo largo del ciclo de vida CI/CD,
- qué controles deben aplicarse para mantener el cumplimiento,
- y cómo debe producirse la evidencia para satisfacer a los auditores.
El objetivo no es describir herramientas, sino clarificar los límites de control, los puntos de aplicación y las expectativas de auditoría.
También establece un puente entre las perspectivas de los auditores y los ingenieros — dos audiencias que leen la misma arquitectura de forma muy diferente, y cuya alineación es esencial para el cumplimiento exitoso.
La Cadena de Suministro CI/CD Real bajo DORA
Un pipeline CI/CD empresarial típico depende de múltiples proveedores ICT externos, frecuentemente sin que se traten explícitamente como tales.
Bajo el Artículo 28 de DORA, los siguientes componentes deben considerarse servicios ICT de terceros:
- Alojamiento de código fuente (Git SaaS / Git gestionado)
- Orquestación CI/CD (plataforma CI SaaS o gestionada)
- Runners / ejecución de builds (runners autohospedados o gestionados)
- Registros de artefactos y contenedores
- Ecosistema de dependencias (paquetes, mirrors, generadores de SBOM)
- Runtime cloud / plataformas gestionadas
- Observabilidad (logs, trazas, SIEM)
- Herramientas ITSM / ticketing / aprobaciones (gestión de cambios)
El Artículo 28 aplica porque cada uno de estos proveedores puede afectar a:
- la confidencialidad e integridad del código fuente y los artefactos,
- la disponibilidad de los pipelines de entrega,
- la trazabilidad y auditabilidad de los cambios.
Cualquier componente de terceros involucrado en la construcción, prueba, despliegue o ejecución de software está dentro del alcance del Artículo 28.
Dos Perspectivas sobre la Misma Arquitectura
El Artículo 28 de DORA exige a las entidades financieras que gestionen el riesgo ICT de terceros de una manera verificable, aplicable y auditable. Sin embargo, los auditores y los ingenieros no leen las arquitecturas de la misma manera.
Perspectiva del Auditor (Gobernanza y Evidencia)
Un auditor que revisa el cumplimiento del Artículo 28 de DORA no evalúa herramientas o pipelines directamente. Verifica que el riesgo esté controlado, documentado y gestionado continuamente.
Desde la perspectiva del auditor, la arquitectura debe responder:
- ¿Tiene un inventario completo de proveedores ICT de terceros?
- ¿Los proveedores están clasificados por criticidad?
- ¿Los contratos son exigibles e incluyen derechos de auditoría, notificación de incidentes y cláusulas de salida?
- ¿Se produce evidencia de forma continua y se retiene?
- ¿Puede salir de proveedores críticos bajo presión?
Perspectiva del Ingeniero (Implementación y Aplicación)
Un ingeniero que mira la misma arquitectura ve un plano de control — un conjunto de mecanismos de aplicación que deben construirse, configurarse y mantenerse.
Su enfoque incluye:
- ¿Dónde están integrados los servicios de terceros en los pipelines?
- ¿Cómo se aplican técnicamente los controles de acceso, aprobaciones y aislamiento?
- ¿Cómo se generan los SBOMs, la firma y la procedencia?
- ¿Cómo se recopilan los logs, métricas y alertas de plataformas de terceros?
- ¿Qué sucede si un proveedor falla o debe ser reemplazado?
La Misma Arquitectura, Dos Lecturas
| Aspecto | Perspectiva del Auditor | Perspectiva del Ingeniero |
|---|---|---|
| Enfoque | Riesgo, gobernanza, cumplimiento | Automatización, aplicación, fiabilidad |
| Pregunta principal | «¿Puede probar el control?» | «¿Dónde aplico el control?» |
| Pipeline CI/CD | Superficie de riesgo | Plano de control |
| Proveedores de terceros | Proveedores a gobernar | Plataformas a integrar de forma segura |
| Evidencia | Requisito explícito | Salida automática |
| Estrategia de salida | Obligatoria | A menudo pasada por alto |
El Artículo 28 de DORA exige que ambas perspectivas se satisfagan simultáneamente.
Principios de Arquitectura para el Cumplimiento del Artículo 28
1. Tratar las Herramientas de Terceros como Activos de Grado Producción
Las plataformas CI/CD y los registros deben seguir las reglas de producción: hardening, control de acceso, logging, monitoreo y continuidad probada.
No son herramientas de desarrollo — son sistemas ICT regulados.
2. Hacer que los Contratos Apliquen los Controles
Las cláusulas contractuales deben habilitar (o al menos apoyar): derechos de auditoría, notificación de incidentes, retención de evidencia, transparencia del procesamiento de datos y estrategias de salida.
Los contratos por sí solos no son suficientes bajo el Artículo 28 de DORA. Las políticas definidas contractualmente deben ser aplicadas técnicamente:
- aprobaciones obligatorias,
- puertas de seguridad,
- rutas de ejecución restringidas,
- capacidades de auditoría e inspección.
Los pipelines CI/CD son la capa de aplicación natural para estas políticas.
3. La Evidencia Debe Diseñarse, No «Recopilarse Después»
La evidencia debe ser generada por la plataforma y retenida automáticamente: logs, aprobaciones, SBOM/procedencia, registros de acceso, cronologías de incidentes y pruebas de salida.
Si la evidencia requiere ensamblaje manual durante una auditoría, es improbable que cumpla las expectativas del auditor en cuanto a objetividad y continuidad.
Capas de Control a lo Largo del Ciclo de Vida CI/CD
Control de Acceso y Aislamiento
Bajo el Artículo 28 de DORA, las organizaciones deben demostrar que las plataformas de terceros no pueden ser utilizadas indebidamente o con privilegios excesivos.
Los principios clave incluyen:
- control de acceso basado en roles,
- segregación de funciones entre desarrollo, aprobación y despliegue,
- acceso de mínimos privilegios para pipelines y automatización.
El aislamiento de acceso aplica en:
- repositorios Git,
- pipelines CI/CD y runners,
- repositorios de artefactos,
- entornos de ejecución cloud.
La evidencia debe demostrar que ningún actor o sistema único puede eludir los controles de extremo a extremo.
Aplicación de Políticas Contractuales
Las políticas definidas contractualmente deben aplicarse técnicamente a través de los pipelines CI/CD:
- las aprobaciones se aplican antes de la liberación,
- policy-as-code previene cambios no autorizados,
- las plataformas de terceros operan bajo restricciones definidas y auditables.
Integridad de la Cadena de Suministro
El Artículo 28 de DORA exige visibilidad de la cadena de suministro de software, especialmente cuando se involucran componentes de terceros.
Esto incluye:
- seguimiento de dependencias y análisis de composición de software (SCA),
- generación de SBOM (Software Bill of Materials),
- firma de artefactos y verificación de procedencia,
- escaneo de imágenes de contenedores y verificaciones de integridad.
Los auditores esperan pruebas de que los artefactos producidos a través de sistemas CI/CD de terceros no han sido manipulados.
Monitoreo y Respuesta a Incidentes
Los servicios de terceros deben monitorearse continuamente:
- indicadores de disponibilidad y rendimiento,
- detección y escalada de incidentes,
- integración con logging centralizado o SIEM.
Los auditores verifican que el monitoreo aplica a los proveedores de terceros, no solo a los sistemas internos. Los flujos de trabajo de incidentes deben referenciar a los proveedores de terceros afectados y demostrar una escalada trazable.
Estrategia de Salida y Continuidad
La planificación de la salida es un requisito regulatorio bajo el Artículo 28, no un ejercicio opcional.
Los auditores cuestionarán:
- si existen planes de salida documentados para proveedores críticos,
- si estos planes han sido probados o ejercitados,
- si la organización podría realizar la transición de forma realista bajo presión.
Los ingenieros apoyan las estrategias de salida mediante:
- evitar el bloqueo estricto por proveedor,
- documentar rutas de reemplazo o alternativas,
- mantener la reproducibilidad de infraestructura como código,
- participar en pruebas de DR, BCP y salida.
Qué Solicitan Habitualmente los Auditores
Bajo el Artículo 28 de DORA, los auditores esperan evidencia en cinco dominios:
- Inventario de proveedores — lista completa de proveedores ICT de terceros, clasificados por criticidad, mapeados a componentes CI/CD y cloud
- Cláusulas contractuales — derechos de auditoría, SLAs de incidentes, retención de evidencia, visibilidad de subprocesadores, obligaciones de salida
- Evidencia de controles CI/CD — logs de acceso, registros de aprobaciones, SBOM/procedencia, definiciones de políticas de pipeline
- Evidencia de monitoreo — dashboards, tickets de incidentes referenciando proveedores de terceros, integración con SIEM
- Evidencia de estrategia de salida — planes de salida documentados, resultados de pruebas DR/BCP, documentación de reemplazo de dependencias
La evidencia debe ser:
- Trazable → vinculada a un proveedor o control específico
- Repetible → generada consistentemente por los sistemas
- Temporalmente acotada → muestra cuándo los controles estaban activos
- Resistente a manipulaciones → los logs y la evidencia están protegidos
Las hojas de cálculo manuales por sí solas raramente cumplen estos criterios.
Brechas Comunes y Patrones de Desalineación
Muchas organizaciones fallan las revisiones del Artículo 28 de DORA no porque falten controles, sino porque:
- los ingenieros implementaron controles sin respaldo contractual,
- la evidencia existe pero no es claramente atribuible,
- las estrategias de salida existen solo sobre el papel,
- las dependencias de terceros son implícitamente confiables,
- las plataformas CI/CD SaaS están excluidas del alcance de proveedores,
- los logs están disponibles pero no se retienen suficiente tiempo.
Separando explícitamente la Perspectiva del Auditor y la Perspectiva del Ingeniero, se garantiza que:
- cada control está respaldado por una base contractual,
- cada aplicación técnica se mapea a una pista de evidencia auditable,
- la preparación para la salida se valida, no se asume.
Conclusión
La arquitectura del Artículo 28 de DORA no consiste en listar herramientas — consiste en definir dónde reside el riesgo ICT de terceros, cómo se controla y cómo se prueba el cumplimiento.
La arquitectura debe apoyar tanto la necesidad del auditor de evidencia como la necesidad del ingeniero de controles aplicables y automatizados. Cuando ambas perspectivas están alineadas, el cumplimiento del Artículo 28 se convierte en una propiedad estructural del sistema de entrega, no en un ejercicio periódico.
Recursos Relacionados
- DORA Article 28 Evidence Pack (Auditor & Engineer Views)
- DORA Article 28 — Auditor Checklist
- Third-Party Risk in CI/CD Pipelines under DORA Article 28
- Continuous Compliance via CI/CD Pipelines
