Introducción
DORA Artículo 28 exige que las entidades financieras reguladas demuestren un control efectivo sobre los riesgos de terceros ICT.
Esta obligación va mucho más allá de cuestionarios a proveedores o declaraciones contractuales. Los auditores no evalúan intenciones — evalúan evidencias.
Este artículo proporciona un paquete de evidencias práctico para DORA Artículo 28, centrándose en lo que los auditores suelen solicitar, de dónde debe provenir la evidencia y cómo los sistemas CI/CD y de entrega en la nube deben respaldar la gestión de riesgos de terceros ICT.
Tiende un puente entre dos perspectivas complementarias:
- Los auditores piensan en términos de objetivos de control, evidencias y responsabilidad.
- Los ingenieros piensan en términos de sistemas, pipelines, configuraciones y automatización.
Ambas perspectivas son válidas — pero no son intercambiables. Este artículo muestra qué verifican realmente los auditores, cómo deben los ingenieros implementar controles para satisfacer esas expectativas y dónde suelen producirse malentendidos.
De qué tratan realmente las auditorías del Artículo 28
Desde una perspectiva de auditoría, el Artículo 28 responde a cuatro preguntas fundamentales:
- ¿Sabe en qué terceros ICT confía?
- ¿Son las obligaciones contractuales exigibles 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 operacional, trazable y verificable — no solo documental.
Cómo abordan los auditores una revisión del Artículo 28
Los auditores no comienzan con herramientas o diagramas de arquitectura. Comienzan con preguntas de riesgo:
- ¿Los proveedores ICT de terceros introducen riesgos operacionales no gestionados?
- ¿Son los controles exigibles 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 operacional, no como confirmación de política.
| Perspectiva | Enfoque |
|---|---|
| Visión del Auditor | ¿Puede esta organización demostrar un control efectivo del riesgo ICT de terceros? |
| Visión del Ingeniero | ¿Cómo aplicamos y generamos evidencias a través de CI/CD y sistemas en la nube? |
Descripción general del paquete de evidencias
Un paquete de evidencias DORA Artículo 28 abarca típicamente cinco dominios de evidencia:
- Inventario de proveedores y criticidad
- Controles contractuales y derechos de auditoría
- Aplicación de controles CI/CD y en la nube
- 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 provenir — desde la Visión del Auditor y la Visión del Ingeniero.
1. Inventario de Proveedores y Criticidad
Qué esperan los auditores
Los auditores quieren pruebas de que usted ha:
- identificado todos los proveedores ICT de terceros,
- los ha clasificado por criticidad,
- los ha vinculado a servicios empresariales y pipelines de entrega.
Esperan la inclusión de plataformas SaaS de CI/CD (no solo proveedores tradicionales), visibilidad sobre servicios en la nube, registros y alojamiento de código, y vinculación entre proveedores y los sistemas realmente en uso.
Evidencias a proporcionar
- Inventario centralizado de proveedores ICT
- Clasificación de criticidad (crítico / importante / no crítico)
- Mapeo entre proveedores, herramientas CI/CD y componentes de ejecución en la nube
Artefactos de evidencia típicos
- Registro de inventario de proveedores (exportable)
- Metodología de clasificación de riesgos
- Tabla de mapeo: Proveedor → Componente CI/CD / Nube
Visión del Auditor
Los auditores preguntan:
- ¿Tiene un inventario completo de proveedores ICT de terceros?
- ¿Están los proveedores clasificados por criticidad?
- ¿Está esta clasificación vinculada a servicios empresariales y sistemas de entrega?
Lo que verifican: integridad del inventario, coherencia con los sistemas realmente en uso y trazabilidad hasta las decisiones de gestión de riesgos.
Visión del Ingeniero
Los ingenieros deben garantizar que:
- las plataformas CI/CD, el alojamiento Git, los registros, los runners y los servicios en la nube estén registrados explícitamente como proveedores,
- los metadatos del proveedor (criticidad, propietario, uso) se mantengan sincronizados con el uso real,
- los pipelines hagan referencia solo a proveedores aprobados.
Implementación típica:
- CMDB o registro de proveedores vinculado a herramientas 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 exigibles que cubran:
- derechos de auditoría,
- plazos de notificación de incidentes,
- retención de evidencias,
- transparencia sobre subcontratistas,
- obligaciones de salida y transición.
Más importante aún, verifican que estas cláusulas sean operativamente exigibles.
«Tiene derechos de auditoría en el contrato — ¿cómo los ejerce en la práctica?»
Evidencias a proporcionar
- Extractos de contratos que muestren derechos de auditoría, acceso de monitorización y cláusulas de notificación de incidentes
- Prueba de que los contratos se aplican a los proveedores realmente en uso
Artefactos de evidencia típicos
- Extractos de cláusulas contractuales
- Registro de contratos con proveedores
- Notas de revisión legal que vinculan las cláusulas con los requisitos del Artículo 28
Visión del Auditor
Los auditores buscan:
- derechos de auditoría exigibles,
- obligaciones de notificación de incidentes,
- compromisos de retención de evidencias,
- visibilidad sobre subprocesadores,
- cláusulas de salida definidas.
No asumen que los contratos son efectivos solo porque existen.
Visión del Ingeniero
Los ingenieros deben:
- saber qué obligaciones contractuales afectan a los controles técnicos,
- garantizar que las plataformas puedan realmente producir la evidencia requerida,
- respaldar las auditorías sin recopilación de datos ad hoc.
Implementación típica:
- mapear cláusulas contractuales → controles técnicos,
- garantizar que los logs, SBOMs y aprobaciones se conserven el tiempo suficiente,
- hacer técnicamente posible el acceso de auditoría (solo lectura, con alcance definido).
3. Aplicación de Controles CI/CD y en la Nube
Qué esperan los auditores
Los auditores verifican que las herramientas de terceros están controladas en la práctica, no confiadas ciegamente. Esto incluye plataformas de alojamiento de código fuente, servicios de orquestación CI/CD, runners y entornos de ejecución, y registros de artefactos y ecosistemas de dependencias.
Evidencias a proporcionar
- Configuración de control de acceso (IAM, roles, SoD)
- Reglas de protección de ramas y aprobación
- Aislamiento de builds y gobernanza de runners
- Integridad de artefactos (SBOM, firma)
Artefactos de evidencia típicos
- Capturas de pantalla 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 plataformas Git / CI/CD
Visión del Auditor
Los auditores quieren pruebas de que:
- el acceso está controlado y segregado,
- las aprobaciones se aplican obligatoriamente,
- los artefactos están protegidos contra manipulaciones,
- las herramientas de terceros no eluden 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 puertas de política,
- generación de SBOM y firma de artefactos,
- aislamiento de runners y alcance de tokens.
Cambio de mentalidad clave:
«Seguro por defecto» no es suficiente — los controles deben ser demostrables.
4. Monitorización y Gestión de Incidentes
Qué esperan los auditores
DORA exige una monitorización continua, no comprobaciones periódicas. Los auditores verifican que los servicios de terceros se monitorizan, los incidentes se detectan y la evidencia se retiene y es trazable.
Buscan:
- datos de monitorización en tiempo real 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 la degradación de terceros sería detectada y los incidentes se escalarían dentro de los plazos definidos. Las evaluaciones de riesgo estáticas por sí solas son insuficientes.
Evidencias a proporcionar
- Paneles de monitorización (señales de disponibilidad e integridad)
- Logs de incidentes relacionados con servicios de terceros
- Evidencia de escalada y notificación de incidentes
Artefactos de evidencia típicos
- Logs y métricas de plataformas CI/CD y en la nube
- Tickets de incidentes que hacen referencia a proveedores de terceros
- Evidencia de integración 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,
- el manejo de incidentes está documentado y es trazable.
Rechazan las evaluaciones de riesgo anuales sin monitorización operacional.
Visión del Ingeniero
Los ingenieros garantizan que:
- las plataformas CI/CD, los registros y los entornos de ejecución en la nube emitan logs,
- la monitorización alimente el SIEM o el registro centralizado,
- los incidentes hagan referencia a los proveedores de terceros afectados.
Implementación típica:
- pipelines de observabilidad,
- tickets de incidentes vinculados a logs y métricas,
- alertas sobre degradación o fallo de proveedores.
SLAs de Notificación de Incidentes: Probados en la Realidad
Los auditores verifican que:
- los SLAs de notificación de incidentes existen contractualmente,
- los procesos internos pueden recibir y actuar sobre las notificaciones,
- los plazos son realistas y han sido probados.
A menudo solicitan ejemplos de incidentes pasados, marcas de tiempo que muestren los retrasos en las notificaciones, y evidencia de escalada y respuesta. Un SLA que nunca se ha ejercido se considera no probado.
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 han sido probados.
Evidencias a proporcionar
- Estrategias de salida documentadas por proveedor crítico
- Evidencia de pruebas de salida o fallback
- Resultados de pruebas DR / BCP que involucren dependencias de terceros
Artefactos de evidencia típicos
- Planes de salida y procedimientos de transición
- Informes de pruebas o resultados de ejercicios de simulación
- Documentación de sustitución de dependencias o fallback
Visión del Auditor
Los auditores preguntan:
- ¿Existen estrategias de salida para proveedores críticos?
- ¿Han sido probadas?
- ¿Podría salir realistamente 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 la dependencia rígida de un único proveedor,
- documentar rutas de sustitución o fallback,
- participar en pruebas de DR y salida.
Implementación típica:
- 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 según 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 coherente a lo largo del tiempo
- Integridad — protegida contra alteraciones
La evidencia que no cumple alguno de estos criterios debilita todo el paquete. Las hojas de cálculo manuales por sí solas raramente cumplen estos criterios.
Hallazgos Comunes en Auditorías del Artículo 28 (Señales de Alerta)
Los auditores elevan con frecuencia hallazgos cuando observan:
- inventarios de proveedores no vinculados a herramientas CI/CD,
- contratos sin aplicación operacional,
- monitorización limitada a revisiones anuales,
- ausencia de pruebas sobre la visibilidad de subcontratistas,
- planes de salida que nunca han sido probados.
| 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 conservan | ❌ No conforme |
| Plan de salida nunca probado | ❌ Hallazgo de alto riesgo |
Según la experiencia en auditorías, los paquetes de evidencias suelen fallar porque:
- las plataformas SaaS de CI/CD quedan excluidas del alcance de proveedores
- existe evidencia pero no puede vincularse a un control
- los logs están disponibles pero no se conservan el tiempo suficiente
- los SLAs de incidentes existen pero nunca han sido probados
- las estrategias de salida están documentadas pero no tienen respaldo técnico real
Estos problemas suelen surgir durante la auditoría, no durante la preparación. Diseñar la evidencia en 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 en la nube:
- los pipelines aplican el acceso y las aprobaciones,
- los SBOMs proporcionan transparencia en la cadena de suministro,
- los logs y las pistas de auditoría generan evidencia automáticamente,
- 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ñando para Ambas Perspectivas
Las organizaciones más maduras:
- diseñan controles una sola vez,
- satisfacen las necesidades de ambas partes: auditoría e ingeniería,
- generan evidencia continuamente a través de plataformas CI/CD y en la nube.
Esta es la base del cumplimiento continuo bajo DORA.
Conclusión Final
DORA Artículo 28 no es un ejercicio de documentación — es un problema de control operacional.
Los paquetes de evidencias más sólidos:
- integran CI/CD, la nube y la gobernanza de proveedores,
- generan evidencia continuamente,
- alinean arquitectura, contratos y monitorización.
Si los auditores pueden verificar los controles sin depender de explicaciones, su postura respecto 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
