Introducción
El Artículo 28 de DORA exige a las entidades financieras reguladas demostrar un control efectivo sobre los riesgos de terceros ICT.
Esta obligación va mucho más allá de los cuestionarios de proveedores o las declaraciones contractuales. Los auditores no evalúan la intención: evalúan la evidencia.
Este artículo ofrece un paquete de evidencia práctico para el Artículo 28 de DORA, centrado en lo que los auditores suelen pedir, de dónde debe proceder la evidencia y cómo los sistemas de entrega CI/CD y cloud deben respaldar la gestión del riesgo de terceros ICT.
Tiende un puente entre dos perspectivas complementarias:
- Los auditores piensan en términos de objetivos de control, evidencia y responsabilidad.
- Los ingenieros piensan en términos de sistemas, pipelines, configuraciones y automatización.
Ambas visiones son válidas, pero no son intercambiables. Este artículo muestra qué intentan verificar realmente los auditores, cómo deben los ingenieros implementar controles para satisfacer esas expectativas y dónde se producen habitualmente los malentendidos.
De qué tratan realmente las auditorías del Artículo 28
Desde la perspectiva de auditoría, el Artículo 28 responde a cuatro preguntas fundamentales:
- ¿Sabe de qué terceros ICT depende?
- ¿Son las obligaciones contractuales aplicables en la práctica?
- ¿Puede monitorizar continuamente los riesgos de terceros?
- ¿Puede salir de forma segura si un proveedor falla o deja de cumplir?
La evidencia debe ser operativa, trazable y verificable, no solo documental.
Cómo abordan los auditores una revisión del Artículo 28
Los auditores no empiezan por las herramientas ni por los diagramas de arquitectura. Empiezan por las preguntas de riesgo:
- ¿Introducen los proveedores terceros de ICT un riesgo operativo no gestionado?
- ¿Son los controles aplicables más allá de los sistemas internos?
- ¿Puede la organización demostrar una supervisión continua?
- ¿Es la evidencia objetiva y acotada en el tiempo?
La evidencia se evalúa como prueba de control operativo, no como confirmación de política.
| Perspectiva | Enfoque |
|---|---|
| Visión del auditor | ¿Puede esta organización demostrar un control efectivo del riesgo de terceros ICT? |
| Visión del ingeniero | ¿Cómo aplicamos y generamos evidencia mediante los sistemas CI/CD y cloud? |
Visión general del paquete de evidencia
Un paquete de evidencia del Artículo 28 de DORA suele abarcar cinco dominios de evidencia:
- Inventario de proveedores y criticidad
- Controles contractuales y derechos de auditoría
- Aplicación de controles en CI/CD y cloud
- Evidencia de monitorización e incidentes
- Evidencia de estrategia de salida y resiliencia
Cada dominio a continuación explica qué esperan los auditores, qué evidencia mostrar y de dónde debe proceder, tanto desde la visión del auditor como desde la visión del ingeniero.
1. Inventario de proveedores y criticidad
Qué esperan los auditores
Los auditores quieren pruebas de que ha:
- identificado todos los proveedores terceros de ICT,
- clasificado según su criticidad,
- vinculado a los servicios de negocio y pipelines de entrega.
Esperan la inclusión de las plataformas SaaS de CI/CD (no solo los proveedores tradicionales), visibilidad sobre los servicios cloud, los registros y el hosting de código, y la vinculación entre los proveedores y los sistemas realmente en uso.
Evidencia a aportar
- Inventario centralizado de proveedores ICT
- Clasificación de criticidad (crítico / importante / no crítico)
- Mapeo entre proveedores, tooling CI/CD y componentes de runtime cloud
Artefactos de evidencia habituales
- Registro de inventario de proveedores (exportable)
- Metodología de clasificación de riesgo
- Tabla de mapeo: Proveedor → componente CI/CD / cloud
Visión del auditor
Los auditores preguntan:
- ¿Dispone de un inventario completo de proveedores terceros de ICT?
- ¿Están los proveedores clasificados por criticidad?
- ¿Está esta clasificación vinculada a los servicios de negocio y sistemas de entrega?
Lo que verifican: la exhaustividad del inventario, la coherencia con los sistemas realmente en uso y la trazabilidad hasta las decisiones de gestión de riesgos.
Visión del ingeniero
Los ingenieros deben asegurar que:
- las plataformas CI/CD, el hosting Git, los registros, los runners y los servicios cloud estén registrados explícitamente como proveedores,
- los metadatos de proveedor (criticidad, responsable, uso) se mantengan sincronizados con el uso real,
- los pipelines referencien únicamente proveedores aprobados.
Implementación habitual:
- CMDB o registro de proveedores vinculado al tooling CI/CD,
- comprobaciones automatizadas que impidan servicios no aprobados,
- documentación generada a partir de configuraciones en vivo.
2. Controles contractuales y derechos de auditoría
Qué esperan los auditores
Los contratos deben habilitar el control, no solo describirlo. Los auditores buscan cláusulas aplicables que cubran:
- derechos de auditoría,
- plazos de notificación de incidentes,
- retención de evidencia,
- transparencia sobre los subcontratistas,
- obligaciones de salida y transición.
Más importante aún, verifican que estas cláusulas sean aplicables operativamente.
«Tiene derechos de auditoría en el contrato: ¿cómo los ejerce en la práctica?»
Evidencia a aportar
- Extractos de contrato que muestren cláusulas de derechos de auditoría, acceso de monitorización y notificación de incidentes
- Prueba de que los contratos se aplican a los proveedores realmente en uso
Artefactos de evidencia habituales
- Extractos de cláusulas contractuales
- Registro de contratos de proveedores
- Notas de revisión legal que vinculen las cláusulas con los requisitos del Artículo 28
Visión del auditor
Los auditores buscan:
- derechos de auditoría aplicables,
- obligaciones de notificación de incidentes,
- compromisos de retención de evidencia,
- visibilidad sobre los subencargados,
- cláusulas de salida definidas.
No dan por sentado que los contratos sean efectivos solo porque existen.
Visión del ingeniero
Los ingenieros deben:
- saber qué obligaciones contractuales afectan a los controles técnicos,
- asegurar que las plataformas puedan realmente producir la evidencia requerida,
- respaldar las auditorías sin recopilación de datos ad hoc.
Implementación habitual:
- mapeo de cláusulas contractuales → controles técnicos,
- garantizar que los logs, SBOM y aprobaciones se retengan el tiempo suficiente,
- hacer el acceso de auditoría técnicamente posible (solo lectura, con alcance acotado).
3. Aplicación de controles en CI/CD y cloud
Qué esperan los auditores
Los auditores verifican que el tooling de terceros esté controlado en la práctica, no confiado a ciegas. Esto incluye las plataformas de hosting de código fuente, los servicios de orquestación CI/CD, los runners y entornos de ejecución, y los registros de artefactos y ecosistemas de dependencias.
Evidencia a aportar
- Configuración de control de acceso (IAM, roles, SoD)
- Reglas de protección de ramas y aprobación
- Aislamiento de compilaciones y gobernanza de runners
- Integridad de artefactos (SBOM, firma)
Artefactos de evidencia habituales
- Capturas o exportaciones de la configuración de la plataforma CI/CD
- Definiciones de políticas de pipeline (Policy as Code)
- Informes de SBOM y firma de artefactos
- Logs de acceso de las plataformas Git / CI/CD
Visión del auditor
Los auditores quieren pruebas de que:
- el acceso está controlado y segregado,
- las aprobaciones se aplican,
- los artefactos están protegidos frente a manipulaciones,
- el tooling de terceros no elude los controles internos.
Comprueban si los controles son sistemáticos, no manuales.
Visión del ingeniero
Los ingenieros implementan:
- IAM, separación de roles, protecciones de ramas,
- aprobaciones de pipeline y gates de política,
- generación de SBOM y firma de artefactos,
- aislamiento de runners y acotación de tokens.
Cambio de mentalidad clave:
«Seguro por defecto» no basta: los controles deben ser demostrables.
4. Monitorización y gestión de incidentes
Qué esperan los auditores
DORA exige monitorización continua, no comprobaciones periódicas. Los auditores verifican que los servicios de terceros se monitorizan, que los incidentes se detectan y que la evidencia se retiene y es trazable.
Buscan:
- datos de monitorización en vivo o históricos,
- alertas vinculadas a servicios de terceros,
- visibilidad sobre la disponibilidad e integridad de la plataforma CI/CD.
La evidencia de monitorización debe demostrar que una degradación de un tercero se detectaría y que los incidentes se escalarían dentro de los plazos definidos. Las evaluaciones de riesgo estáticas por sí solas son insuficientes.
Evidencia a aportar
- Cuadros de mando de monitorización (señales de disponibilidad e integridad)
- Logs de incidentes que involucren servicios de terceros
- Evidencia de escalado y notificación de incidentes
Artefactos de evidencia habituales
- Logs y métricas de las plataformas CI/CD y cloud
- Tickets de incidentes que referencien a proveedores terceros
- Evidencia de integración con SIEM u observabilidad
Visión del auditor
Los auditores evalúan si:
- los servicios de terceros se monitorizan continuamente,
- los incidentes que involucran a proveedores son detectables,
- la gestión de incidentes está documentada y es trazable.
Rechazan las evaluaciones de riesgo anuales sin monitorización operativa.
Visión del ingeniero
Los ingenieros aseguran que:
- las plataformas CI/CD, los registros y los runtimes cloud emitan logs,
- la monitorización alimente el SIEM o el logging centralizado,
- los incidentes referencien a los proveedores terceros afectados.
Implementación habitual:
- pipelines de observabilidad,
- tickets de incidentes vinculados a logs y métricas,
- alertas sobre degradación o fallo de proveedores.
SLA de notificación de incidentes: probados en la realidad
Los auditores verifican que:
- existan SLA de notificación de incidentes a nivel contractual,
- los procesos internos puedan recibir y actuar sobre las notificaciones,
- los plazos sean realistas y estén probados.
A menudo solicitan ejemplos de incidentes pasados, marcas de tiempo que muestren retrasos en la notificación y evidencia de escalado y respuesta. Un SLA que nunca se ha ejercido se considera no demostrado.
5. Estrategia de salida y resiliencia
Qué esperan los auditores
Las estrategias de salida deben ser realistas y probadas. Los auditores cuestionarán si existen planes de salida, si se aplican a los proveedores críticos y si alguna vez se han probado.
Evidencia a aportar
- Estrategias de salida documentadas por cada proveedor crítico
- Evidencia de pruebas de salida o de contingencia
- Resultados de pruebas de DR / BCP que involucren dependencias de terceros
Artefactos de evidencia habituales
- Planes de salida y procedimientos de transición
- Informes de pruebas o resultados de ejercicios de simulación (tabletop)
- Documentación de sustitución de dependencias o de contingencia
Visión del auditor
Los auditores preguntan:
- ¿Existen estrategias de salida para los proveedores críticos?
- ¿Se han probado?
- ¿Podría salir de forma realista bajo presión?
Un plan de salida en PDF por sí solo es insuficiente.
Visión del ingeniero
Los ingenieros respaldan las estrategias de salida mediante:
- evitar un vendor lock-in rígido,
- documentar rutas de sustitución o de contingencia,
- participar en pruebas de DR y de salida.
Implementación habitual:
- portabilidad de artefactos,
- reproducibilidad mediante infraestructura como código,
- procedimientos de copia de seguridad y restauración probados.
Calidad de la evidencia: cómo juzgan los auditores la credibilidad
Los auditores evalúan la evidencia frente a cuatro criterios implícitos:
- Objetividad: generada por el sistema, no editada manualmente
- Trazabilidad: vinculada a un proveedor o control específico
- Continuidad: producida de forma consistente a lo largo del tiempo
- Integridad: protegida frente a alteraciones
La evidencia que incumpla cualquiera de estos criterios debilita todo el paquete. Las hojas de cálculo manuales por sí solas rara vez cumplen estos criterios.
Hallazgos habituales en auditorías del Artículo 28 (señales de alerta)
Los auditores plantean hallazgos con frecuencia cuando observan:
- inventarios de proveedores no vinculados al tooling CI/CD,
- contratos sin aplicación operativa,
- monitorización limitada a revisiones anuales,
- ausencia de prueba de visibilidad sobre los subcontratistas,
- planes de salida que nunca se probaron.
| Situación | Reacción del auditor |
|---|---|
| «Confiamos en este proveedor SaaS» | ❌ No aceptable |
| Evidencia recopilada manualmente antes de la auditoría | ⚠️ Control débil |
| Los logs existen pero no se retienen | ❌ No conforme |
| Plan de salida nunca probado | ❌ Hallazgo de alto riesgo |
Por experiencia de auditoría, los paquetes de evidencia suelen fallar porque:
- Las plataformas SaaS de CI/CD se excluyen del alcance de proveedores
- La evidencia existe pero no puede vincularse a un control
- Los logs están disponibles pero no se retienen el tiempo suficiente
- Los SLA de incidentes existen pero nunca se probaron
- Las estrategias de salida están documentadas pero no respaldadas por la realidad técnica
Estos problemas suelen aflorar durante la auditoría, no durante la preparación. Diseñar la evidencia dentro de los pipelines evita estas brechas.
Cómo la arquitectura CI/CD habilita el cumplimiento del Artículo 28
El cumplimiento moderno del Artículo 28 depende en gran medida de la arquitectura CI/CD y cloud:
- los pipelines aplican el acceso y las aprobaciones,
- los SBOM aportan transparencia sobre la cadena de suministro,
- los logs y registros de auditoría generan evidencia de forma automática,
- los sistemas de monitorización detectan fallos de terceros.
Sin evidencia a nivel de CI/CD, el cumplimiento del Artículo 28 sigue siendo frágil.
Diseñar para ambas visiones
Las organizaciones más maduras:
- diseñan los controles una sola vez,
- satisfacen las necesidades tanto de auditoría como de ingeniería,
- generan evidencia de forma continua mediante las plataformas CI/CD y cloud.
Esta es la base del cumplimiento continuo bajo DORA.
Conclusión final
El Artículo 28 de DORA no es un ejercicio de documentación: es un problema de control operativo.
Los paquetes de evidencia más sólidos:
- integran la gobernanza de CI/CD, cloud y proveedores,
- generan evidencia de forma continua,
- alinean arquitectura, contratos y monitorización.
Si los auditores pueden verificar los controles sin depender de explicaciones, su postura frente al Artículo 28 es sólida.
Lecturas relacionadas recomendadas
- DORA Article 28 Architecture — Explained
- Continuous Compliance via CI/CD Pipelines
- CI/CD Audit Red Flags
