Introducción
Este artículo conecta las obligaciones del Artículo 28 de DORA con controles técnicos concretos y la evidencia que los auditores esperan verificar. Une dos perspectivas complementarias:
- Desde las herramientas hasta la evidencia: cómo las herramientas comunes de DevSecOps empresarial y CI/CD aplican controles y producen salidas listas para auditoría.
- Desde la regulación hasta la evidencia: cómo cada requisito del Artículo 28 se mapea a controles implementables y evidencia verificable.
El objetivo es eliminar la ambigüedad entre el texto regulatorio, las herramientas, la gobernanza y el cumplimiento — y proporcionar una referencia única para la preparación de auditorías y el cumplimiento continuo.
Mapeo por Obligación del Artículo 28
1. Identificación de Terceros ICT
Requisito del Artículo 28: Las entidades financieras deberán identificar y mantener un inventario de todos los proveedores de servicios ICT de terceros.
| Controles implementados | Evidencia producida |
|---|---|
| Inventario centralizado de proveedores ICT | Exportación del registro de proveedores |
| Registro obligatorio de herramientas CI/CD, nube y SaaS | Registros de inventario incluyendo herramientas CI/CD |
| Mapeo de propiedad y negocio | Mapeo proveedor → servicio de negocio |
| Revisión periódica del inventario | Actas / registros de reuniones de revisión |
2. Clasificación de Criticidad
Requisito del Artículo 28: Los proveedores ICT de terceros deberán clasificarse según la criticidad y el riesgo.
| Controles implementados | Evidencia producida |
|---|---|
| Marco de clasificación de proveedores basado en riesgo | Metodología de clasificación |
| Identificación de proveedores ICT críticos | Lista de proveedores críticos |
| Herramientas CI/CD clasificadas cuando soportan servicios críticos | Mapeo CI/CD → servicio |
| Escalada de gobernanza para proveedores críticos | Registros del comité de riesgo |
3. Diligencia Debida Pre-Contractual
Requisito del Artículo 28: Se deberán realizar evaluaciones de riesgo antes de entrar en acuerdos contractuales.
| Controles implementados | Evidencia producida |
|---|---|
| Proceso de diligencia debida en seguridad | Informes de diligencia debida |
| Evaluación de riesgo que cubre riesgo ICT y operacional | Documentos de evaluación de riesgo |
| Revisión de divulgación de subprocesadores | Divulgaciones del proveedor |
| Aprobación formal antes de la incorporación | Registros de aprobación |
4. Salvaguardas Contractuales
Requisito del Artículo 28: Los contratos deberán incluir disposiciones mínimas de seguridad, auditoría y salida.
| Controles implementados | Evidencia producida |
|---|---|
| Cláusulas contractuales estándar para proveedores ICT | Extractos de cláusulas del contrato |
| Derechos de auditoría e inspección | Contratos firmados |
| SLAs de notificación de incidentes | Documentación de SLA |
| Obligaciones de retención de evidencia | Términos del contrato |
| Cláusulas de salida y terminación | Disposiciones de salida |
5. Control de Acceso y Segregación de Funciones
Requisito del Artículo 28: El acceso a los servicios ICT deberá controlarse apropiadamente.
| Controles implementados | Evidencia producida |
|---|---|
| Control de acceso basado en roles (RBAC) | Exportaciones de configuración IAM |
| Segregación de funciones en CI/CD | Matriz de acceso |
| Monitorización de acceso privilegiado | Registros de acceso |
| Revisiones periódicas de acceso | Informes de revisión |
6. Controles de Aplicación CI/CD
Requisito del Artículo 28: Los controles deberán prevenir cambios no autorizados y garantizar la integridad.
| Controles implementados | Evidencia producida |
|---|---|
| Aprobaciones obligatorias y puertas de política | Configuraciones de pipeline |
| Aplicación de política como código | Definiciones de política |
| Runners CI/CD controlados | Configuración de runner |
| Protección de integridad de artefactos | SBOM, informes de firma |
| Trazabilidad de cambios | Registros de auditoría CI/CD |
7. Monitorización y Gestión de Incidentes
Requisito del Artículo 28: Los riesgos ICT de terceros deberán monitorizarse continuamente.
| Controles implementados | Evidencia producida |
|---|---|
| Monitorización continua de servicios ICT | Paneles de monitorización |
| Alertas sobre fallos de terceros | Registros de alertas |
| Seguimiento de incidentes | Tickets de incidentes |
| Procedimientos de escalada de incidentes | Flujos de trabajo de incidentes |
| Revisiones post-incidente | Informes RCA |
8. Gobernanza de Subprocesadores
Requisito del Artículo 28: Los riesgos derivados de las cadenas de subcontratación deberán gestionarse.
| Controles implementados | Evidencia producida |
|---|---|
| Visibilidad de los subprocesadores | Divulgaciones del proveedor |
| Proceso de aprobación de subprocesadores | Registros de aprobación |
| Evaluaciones de riesgo para subprocesadores | Informes de riesgo |
| Monitorización de cambios en subprocesadores | Notificaciones de cambios |
9. Estrategia de Salida y Resiliencia
Requisito del Artículo 28: Las estrategias de salida deberán garantizar la continuidad en caso de fallo del proveedor.
| Controles implementados | Evidencia producida |
|---|---|
| Estrategias de salida documentadas | Planes de salida |
| Evaluaciones de viabilidad | Informes de viabilidad |
| Pruebas de salida o alternativas | Informes de prueba |
| Revisión periódica de planes de salida | Registros de revisión |
10. Gestión y Retención de Evidencia
Requisito del Artículo 28: La evidencia deberá estar disponible, protegida y conservada.
| Controles implementados | Evidencia producida |
|---|---|
| Repositorio centralizado de evidencia | Almacenamiento de evidencia |
| Registros con marca de tiempo e inmutables | Configuración de logging |
| Políticas de retención aplicadas | Documentos de política de retención |
| Acceso controlado a la evidencia | Registros de acceso |
| Producción de evidencia bajo demanda | Extractos de auditoría |
Mapeo por Categoría de Herramientas
La siguiente sección mapea las herramientas comunes de DevSecOps empresarial a los controles que aplican y la evidencia que producen bajo el Artículo 28 de DORA.
1. Gestión de Código Fuente (Plataformas Git)
Herramientas típicas: GitHub Enterprise, GitLab, Bitbucket
| Controles aplicados | Evidencia producida |
|---|---|
| Control de acceso basado en roles | Registros de acceso al repositorio |
| Segregación de funciones (PR vs. fusión) | Reglas de rama protegida |
| Revisiones y aprobaciones obligatorias | Historial de pull requests |
| Trazabilidad de cambios | Historial de commits |
| Gobernanza de acceso de terceros | Registros de auditoría de usuarios y tokens |
Relevancia para el Artículo 28: Las plataformas Git son proveedores ICT de terceros que influyen en la integridad del código.
2. Plataformas de Orquestación CI/CD
Herramientas típicas: GitHub Actions, GitLab CI, Jenkins (gestionado), Azure DevOps Pipelines
| Controles aplicados | Evidencia producida |
|---|---|
| Puertas de aprobación del pipeline | Exportaciones de configuración de pipeline |
| Aplicación de política como código | Definiciones de política |
| Entornos de ejecución controlados | Configuración de runner |
| Tokens de pipeline con mínimo privilegio | Configuración de alcance de tokens |
| Registro de cambios del pipeline | Registros de auditoría CI/CD |
Relevancia para el Artículo 28: Las plataformas CI/CD SaaS deben gobernarse como proveedores ICT críticos.
3. Seguridad de Compilación y Dependencias (SCA / SBOM)
Herramientas típicas: Snyk, Dependency-Check, Mend, GitHub Dependabot, Syft / CycloneDX
| Controles aplicados | Evidencia producida |
|---|---|
| Análisis de riesgo de dependencias | Informes SCA |
| Generación de SBOM | Archivos SBOM |
| Seguimiento de procedencia | Metadatos de compilación |
| Monitorización de vulnerabilidades | Alertas e informes |
| Transparencia de la cadena de suministro | Inventarios de dependencias |
Relevancia para el Artículo 28: Proporciona visibilidad sobre los riesgos de software de terceros y los subprocesadores.
4. Repositorios y Registros de Artefactos
Herramientas típicas: Artifactory, Nexus, registros Docker, registros de contenedores en la nube
| Controles aplicados | Evidencia producida |
|---|---|
| Control de acceso a artefactos | Registros de acceso al repositorio |
| Inmutabilidad de artefactos | Configuración del repositorio |
| Firma de artefactos | Verificación de firmas |
| Verificación de procedencia | Registros de attestation |
| Políticas de retención | Configuración de retención |
Relevancia para el Artículo 28: Protege la integridad de los entregables proporcionados por sistemas de terceros.
5. Plataformas en Tiempo de Ejecución y Nube
Herramientas típicas: AWS / Azure / GCP, plataformas Kubernetes, servicios PaaS gestionados
| Controles aplicados | Evidencia producida |
|---|---|
| IAM y separación de roles | Exportaciones de política IAM |
| Aislamiento de red | Configuraciones de grupos de seguridad |
| Monitorización en tiempo de ejecución | Registros y métricas |
| Detección de incidentes | Alertas |
| Monitorización de disponibilidad | Informes de SLA |
Relevancia para el Artículo 28: Los proveedores de nube son proveedores de servicios ICT de terceros críticos.
6. Gestión de Secretos
Herramientas típicas: HashiCorp Vault, gestores de secretos nativos de la nube, almacenes de secretos CI/CD
| Controles aplicados | Evidencia producida |
|---|---|
| Almacenamiento centralizado de secretos | Inventario de secretos |
| Restricción de acceso | Registros de acceso |
| Rotación de secretos | Registros de rotación |
| Prevención de secretos codificados | Informes de análisis |
| Auditabilidad | Rastros de acceso a secretos |
Relevancia para el Artículo 28: Controla el acceso a datos sensibles gestionados por plataformas de terceros.
7. Monitorización, Logging y SIEM
Herramientas típicas: Splunk, Elastic, Datadog, logging nativo de la nube
| Controles aplicados | Evidencia producida |
|---|---|
| Recolección centralizada de registros | Registros de ingesta de logs |
| Monitorización de servicios de terceros | Paneles |
| Alertas sobre incidentes | Registros de alertas |
| Correlación de incidentes | Tickets de incidentes |
| Retención de evidencia | Políticas de retención |
Relevancia para el Artículo 28: Apoya las obligaciones de monitorización continua y evidencia de incidentes.
8. Gestión de Identidades y Accesos (IAM)
Herramientas típicas: IAM empresarial, IAM en la nube, plataformas SSO
| Controles aplicados | Evidencia producida |
|---|---|
| Gestión centralizada de identidades | Inventarios de usuarios |
| Aplicación de MFA | Registros de autenticación |
| Separación de roles | Definiciones de roles |
| Revisiones de acceso | Registros de revisión |
| Revocación de acceso | Registros de baja |
Relevancia para el Artículo 28: Garantiza el acceso controlado a las plataformas ICT de terceros.
9. Plataformas de Gobernanza y Gestión de Riesgos
Herramientas típicas: Plataformas GRC, CMDB, registros de riesgos
| Controles aplicados | Evidencia producida |
|---|---|
| Inventario de proveedores | Registros de proveedores |
| Evaluaciones de riesgo | Informes de riesgo |
| Clasificación de criticidad | Registros de clasificación |
| Propiedad de controles | Documentación RACI |
| Preparación de auditorías | Repositorios de evidencia |
Relevancia para el Artículo 28: Proporciona la columna vertebral de gobernanza para la gestión de riesgos ICT de terceros.
Visión de Extremo a Extremo
Bajo el Artículo 28 de DORA:
- Las herramientas no equivalen a cumplimiento.
- Los controles crean cumplimiento.
- La evidencia demuestra el cumplimiento.
Las herramientas son aceptables solo si aplican controles y generan evidencia verificable.
Cómo Utilizan los Auditores este Mapeo
Los auditores típicamente:
- Parten de los requisitos del Artículo 28 (mapeo de obligaciones).
- Identifican el proveedor ICT de terceros y su categoría de herramientas.
- Verifican que los controles existen y operan a través de las herramientas.
- Solicitan salidas de evidencia directas para cada control.
- Validan la consistencia a lo largo del tiempo.
Cualquier eslabón faltante entre obligación → control → evidencia, o entre herramienta → control → evidencia, es un hallazgo potencial. Si un control no puede producir evidencia, se considera ineficaz.
Conclusión Clave
El cumplimiento del Artículo 28 de DORA se logra cuando cada requisito regulatorio es trazable a controles, y cada control produce evidencia — independientemente de qué herramientas se utilicen.
Este doble mapeo (por obligación y por herramienta) proporciona la columna vertebral para:
- preparación de auditorías,
- cumplimiento continuo,
- gobernanza CI/CD en entornos regulados.
Un entorno CI/CD alineado con DORA es aquel donde cada herramienta de terceros está gobernada, cada control se aplica técnicamente y cada control produce evidencia automáticamente.
Contenido Relacionado Recomendado
- DORA Article 28 — Evidence Pack (Auditor & Engineer Views)
- DORA Article 28 — Auditor Checklist (Yes / No / Evidence)
- DORA Article 28 Architecture: Third-Party Risk Controls Across CI/CD Pipelines
- Continuous Compliance via CI/CD Pipelines
