Esta lista de verificación está diseñada para revisiones formales de auditoría de la gestión de riesgos ICT de terceros bajo el Artículo 28 de DORA. Sirve a dos audiencias simultáneamente:
Los auditores la utilizan para verificar controles, evaluar evidencia e identificar brechas.
Los ingenieros la utilizan para entender qué debe implementarse y dónde ocurren las brechas comunes.
Cada sección cubre un dominio específico del Artículo 28 con: la lista de verificación formal de auditoría (Sí / No / Evidencia), las expectativas de implementación correspondientes para el ingeniero, y las brechas comunes que típicamente emergen durante las auditorías.
1. Inventario de Terceros ICT
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Existe un inventario completo de proveedores ICT de terceros
☐
☐
Registro de proveedores
Las plataformas CI/CD están incluidas como proveedores ICT
☐
☐
Extracto del inventario de proveedores
Los proveedores de servicios en la nube están incluidos
☐
☐
Inventario de proveedores
Los registros de artefactos y ecosistemas de paquetes están listados
☐
☐
Mapeo de proveedores
El inventario se revisa y actualiza periódicamente
☐
☐
Registros de revisión
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Inventario completo de proveedores ICT de terceros
CMDB o registro de proveedores incluyendo CI/CD, Git, nube, registros
Clasificación de proveedores por criticidad
Etiquetas de criticidad vinculadas a los sistemas de entrega
Alineación con los servicios de negocio
Mapeo pipelines → servicios → proveedores
Inventario mantenido actualizado
Actualizaciones automatizadas o por proceso vinculadas al uso de herramientas
Brecha común: Las herramientas CI/CD SaaS no están listadas como proveedores.
2. Clasificación de Criticidad
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Los proveedores ICT están clasificados por criticidad
☐
☐
Metodología de clasificación
Los criterios de clasificación están documentados
☐
☐
Marco de riesgo
Los proveedores críticos están explícitamente identificados
☐
☐
Lista de proveedores
Las herramientas CI/CD que soportan funciones críticas están clasificadas correspondientemente
☐
☐
Documento de mapeo
La clasificación impacta en los requisitos de gobernanza
☐
☐
Mapeo de controles
3. Diligencia Debida Pre-Contractual
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Se realiza diligencia debida de seguridad antes de la incorporación
☐
☐
Informes de diligencia debida
La evaluación de riesgos cubre riesgos ICT y operacionales
☐
☐
Evaluación de riesgos
El uso de subprocesadores se evalúa
☐
☐
Divulgaciones del proveedor
Los resultados de la diligencia debida están documentados
☐
☐
Registros de revisión
Se requiere aprobación antes de la incorporación
☐
☐
Flujo de trabajo de aprobación
4. Salvaguardas Contractuales
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Los contratos incluyen requisitos de seguridad de la información
☐
☐
Cláusulas del contrato
Los derechos de auditoría e inspección están definidos
☐
☐
Extractos del contrato
Las obligaciones de notificación de incidentes están definidas
☐
☐
Cláusulas de SLA
Los requisitos de retención de evidencia están incluidos
☐
☐
Términos del contrato
Las cláusulas de salida y terminación están definidas
☐
☐
Cláusulas del contrato
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Derechos de auditoría definidos en contratos
Plataformas capaces de acceso de auditoría de solo lectura
Obligaciones de notificación de incidentes
Pipelines de monitorización y alertas conectados a flujos de trabajo de incidentes
Compromisos de retención de evidencia
Retención de registros y artefactos configurada para cumplir la duración del contrato
Visibilidad de subprocesadores
Cadenas de dependencia SaaS documentadas
Brecha común: Los contratos existen pero las herramientas no pueden técnicamente soportar las auditorías.
5. Control de Acceso y Segregación de Funciones
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
El acceso a plataformas de terceros está basado en roles
☐
☐
Configuración IAM
La segregación de funciones está aplicada
☐
☐
Matriz de acceso
El acceso privilegiado está restringido y monitorizado
☐
☐
Registros de acceso
Las revisiones de acceso se realizan periódicamente
☐
☐
Registros de revisión
La revocación de acceso está documentada
☐
☐
Registros de baja
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Separación de roles aplicada
Roles IAM para dev, aprobador, operador
Sin control de extremo a extremo por una sola persona
Protección de ramas + flujos de trabajo de aprobación
Revisiones de acceso realizadas
Revisiones periódicas de acceso soportadas por registros
Mínimo privilegio aplicado
Alcances de tokens, permisos de runners, separación de entornos
Brecha común: Acceso de administración compartido entre roles CI/CD.
6. Controles de Aplicación CI/CD
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Los pipelines CI/CD aplican puertas de aprobación
☐
☐
Configuración del pipeline
Los controles de seguridad no pueden eludirse
☐
☐
Definiciones de política
Los runners CI/CD de terceros están gobernados
☐
☐
Configuración del runner
La integridad de los artefactos está protegida
☐
☐
SBOM / informes de firma
Los cambios del pipeline se registran
☐
☐
Registros de auditoría
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Controles aplicados automáticamente
Política como código en los pipelines
Sin evasión de aprobaciones
Puertas obligatorias para lanzamiento y despliegue
Integridad de artefactos garantizada
Generación de SBOM, firma, verificación
Herramientas de terceros gobernadas
Imágenes de runner aprobadas, plugins restringidos
Brecha común: Controles aplicados «por convención», no técnicamente.
7. Monitorización y Gestión de Incidentes
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Los servicios de terceros se monitorizan continuamente
☐
☐
Paneles de monitorización
Los incidentes de seguridad se detectan
☐
☐
Registros de alertas
Los incidentes que involucran proveedores ICT se rastrean
☐
☐
Tickets de incidentes
Los plazos de notificación de incidentes se respetan
☐
☐
Registros de incidentes
Los postmortems de incidentes están documentados
☐
☐
Informes RCA
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Monitorización continua de proveedores
Registros CI/CD, de registro y de nube recopilados
Capacidad de detección de incidentes
Alertas vinculadas a servicios de terceros
Trazabilidad de incidentes
Tickets vinculados a registros, pipelines, artefactos
Evidencia de incidentes pasados
Registros conservados, líneas de tiempo, documentación RCA
Brecha común: Los registros existen pero no están centralizados ni conservados.
8. Gobernanza de Subprocesadores
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Existe visibilidad sobre los subcontratistas
☐
☐
Divulgaciones del proveedor
Los subprocesadores están aprobados
☐
☐
Registros de aprobación
Los riesgos de los subprocesadores se evalúan
☐
☐
Evaluaciones de riesgo
Los cambios en los subprocesadores se monitorizan
☐
☐
Notificaciones de cambios
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Visibilidad de los subprocesadores
Documentación de dependencias SaaS
Conocimiento de los flujos de datos
Diagramas de arquitectura que muestran las rutas de terceros
Conciencia del riesgo
Evaluación de riesgos que referencia las dependencias reales
Brecha común: Subprocesadores «ocultos» dentro de las plataformas CI/CD.
9. Estrategia de Salida y Resiliencia
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
Existen estrategias de salida para proveedores críticos
☐
☐
Planes de salida
Las estrategias de salida están documentadas
☐
☐
Documentación
La viabilidad de la salida ha sido evaluada
☐
☐
Informes de evaluación
Se han realizado pruebas de salida o alternativas
☐
☐
Informes de prueba
Las estrategias de salida se revisan periódicamente
☐
☐
Registros de revisión
Implementación del Ingeniero
El auditor verifica
El ingeniero implementa
Estrategia de salida documentada
Herramientas alternativas identificadas
Viabilidad de la salida
Portabilidad de artefactos, reproducibilidad de IaC
Evidencia de pruebas de salida
Pruebas DR / de salida ejecutadas y registradas
Sin dependencia de un único proveedor
Acoplamiento reducido a características específicas de SaaS
Brecha común: El plan de salida existe solo como documento.
10. Gestión y Retención de Evidencia
Lista de Verificación de Auditoría
Control
Sí
No
Evidencia
La evidencia se almacena centralmente
☐
☐
Repositorio de evidencia
La evidencia tiene marca de tiempo y es inmutable
☐
☐
Configuración de logging
La retención de evidencia cumple las necesidades regulatorias
Brecha común: Evidencia recopilada manualmente «justo antes de la auditoría».
Conclusión del Auditor
Evaluación
Resultado
Cumplimiento general del Artículo 28
☐ Conforme ☐ Parcialmente Conforme ☐ No Conforme
Hallazgos principales identificados
☐ Sí ☐ No
Plan de remediación requerido
☐ Sí ☐ No
Principios Clave
Verificación de Realidad del Auditor
Los auditores no validan intenciones, explicaciones ni diapositivas de arquitectura por sí solos. Validan: controles en operación, evidencia producida por sistemas y consistencia a lo largo del tiempo.
Bajo el Artículo 28 de DORA, la ausencia de evidencia es evidencia de ausencia. Los controles deben ser operativos, repetibles y demostrables.
Verificación de Realidad del Ingeniero
Los ingenieros tienen éxito cuando: el cumplimiento está diseñado en CI/CD, los controles generan evidencia continuamente y las auditorías se convierten en verificación, no en reconstrucción.
