La mayoría de las organizaciones cree que evaluar proveedores en la nube consiste en revisar un informe SOC 2, echar un vistazo a un certificado ISO y dar el asunto por cerrado. Bajo DORA y NIS2, ese atajo se convierte en una responsabilidad regulatoria. El riesgo en la nube es ahora riesgo de negocio ; y los reguladores esperan que se demuestre que se comprende.
DORA y NIS2 han cambiado las reglas del juego. Los reguladores ya no se preguntan si el proveedor en la nube tiene «buena seguridad». Se preguntan si la organización puede seguir operando cuando el proveedor falla.
Esto implica:
- evaluaciones más profundas
- transparencia contractual
- análisis de riesgo de concentración
- seguimiento continuo
- estrategias de salida
- gobernanza real, no listas de verificación
La mayoría de las organizaciones no están preparadas para esto ; y los auditores lo saben.
A continuación se explica cómo evaluar correctamente a los proveedores en la nube bajo DORA y NIS2.
1. Comenzar por la criticidad: no todos los servicios en la nube son iguales
El error más frecuente es tratar todos los servicios SaaS o en la nube de la misma forma.
Bajo DORA y NIS2, los proveedores deben clasificarse según su impacto en el negocio:
- crítico
- importante
- no crítico
Los servicios críticos afectan directamente a:
- la continuidad del negocio
- las operaciones orientadas al cliente
- las transacciones financieras
- las obligaciones regulatorias
- la seguridad
- la infraestructura central
Caso real: Un cliente catalogó su CRM como «bajo riesgo» porque «lo usa el equipo de marketing». Resultó que el 60 % de su cartera de ingresos dependía de él. Bajo DORA, eso es crítico.
Los reguladores esperan priorización. Hay que empezar por ahí.
2. Exigir transparencia sobre arquitectura, dependencias y subencargados
Bajo NIS2 y DORA, se necesita claridad sobre:
- ubicación de los datos
- subencargados
- dependencias de infraestructura
- diseño de conmutación por error multirregión
- residencia de datos y exposición jurisdiccional
Los proveedores en la nube gustan de los diagramas vagos y el discurso de marketing. Los reguladores quieren datos concretos.
El riesgo propio es el proveedor del proveedor.
3. Evaluar la resiliencia operacional, no solo los controles de seguridad
ISO 27001 y SOC 2 informan sobre la higiene de seguridad. DORA y NIS2 quieren saber:¿Pueden las operaciones sobrevivir a un fallo del proveedor en la nube?
Solicitar:
- RTO/RPO de toda su pila tecnológica
- historial real de interrupciones
- resultados de pruebas de conmutación por error
- métricas de gestión de capacidad
- plazos de escalado de incidentes
- madurez del nivel de servicio
- fiabilidad de la página de estado (el historial importa)
Caso real: Un proveedor SaaS afirmaba tener una disponibilidad del 99,99 %. Su página de estado pública registraba ocho interrupciones en 6 meses. La evaluación debe reflejar la realidad ; no el marketing.
4. Verificar cómo gestionan los incidentes graves (DORA tiene expectativas claras)
DORA exige claridad contractual sobre:
- clasificación de incidentes
- plazos de notificación
- intercambio de información
- entrega del análisis de causa raíz
- vías de escalado
Si el proveedor en la nube no cuenta con un proceso maduro de respuesta a incidentes, la brecha recae sobre la propia organización.
Caso del campo: Un proveedor de servicios entregaba los RCA con 30 días de retraso ; siempre. Bajo DORA, eso se convierte en un problema regulatorio propio.
Si no pueden respetar los plazos regulatorios de notificación, no son válidos a efectos de cumplimiento.
5. Evaluar el riesgo de concentración y los puntos únicos de fallo
Es el aspecto que más organizaciones ignoran ; y donde los reguladores presionarán con más fuerza.
Preguntas que hay que plantear:
- ¿Varios servicios críticos dependen del mismo proveedor en la nube?
- ¿Estamos vinculados a un único proveedor sin alternativa viable?
- ¿Cuál es el coste de cambio?
- ¿Cuántos procesos críticos dependen de AWS/Azure/GCP?
- ¿Existe redundancia geográfica?
- ¿Son dos «proveedores» en realidad el mismo porque comparten infraestructura?
Caso real: Un banco creía tener «redundancia» porque usaba dos servicios SaaS. Ambos funcionaban sobre la misma región de AWS.
Se pueden externalizar servicios. No se puede externalizar la responsabilidad.
6. Exigir control contractual (DORA lo hace obligatorio)
DORA exige cláusulas contractuales obligatorias para los servicios TIC considerados críticos.
El contrato debe contemplar:
- derechos de auditoría e inspección
- informes de rendimiento
- obligaciones de seguridad
- planes de salida y transición
- requisitos de resiliencia
- notificación de incidentes
- transparencia sobre subcontratistas
- asistencia en la terminación
- responsabilidades de cifrado
Caso real: Un proveedor SaaS rechazó los derechos de auditoría. Bajo DORA, eso es un factor de exclusión. Sin más.
Si no permiten la supervisión, no se puede trabajar con ellos.
7. Evaluar el seguimiento continuo, no las evaluaciones puntuales
NIS2 y DORA hacen hincapié en la supervisión continua, no en listas de verificación anuales.
Se necesita:
- actualizaciones trimestrales del estado de seguridad
- informes SOC anuales
- monitorización de disponibilidad en tiempo real
- ciclos de actualización de cuestionarios a proveedores
- evaluaciones de impacto regulatorio ante cualquier cambio del proveedor
- reevaluación tras incidentes graves
Si el proveedor «no realiza revisiones continuas», hay que descartarlo.
Caso real: Un proveedor SaaS renovaba su informe SOC 2 cada 18-24 meses. Bajo NIS2 y DORA, eso es inaceptable para sistemas críticos.
8. Poner a prueba los planes de salida y portabilidad (el requisito más ignorado)
DORA exige explícitamente pruebas de la estrategia de salida. NIS2 espera continuidad operacional.
Los proveedores en la nube deben demostrar:
- que se pueden extraer los datos propios
- que se puede migrar sin interrumpir el servicio
- que los formatos son portables
- que los plazos son razonables
- que existe soporte disponible durante la salida
Caso real: Un proveedor indicó: «Ofrecemos exportación de datos». La exportación era un blob binario propietario. Portabilidad cero.
Si no es posible salir, no es posible usarlos.
9. Construir un modelo de puntuación de proveedores alineado con DORA y NIS2
La forma más sencilla de escalar las evaluaciones es utilizar un modelo de puntuación.
Categorías recomendadas:
- Seguridad (ISO/SOC)
- Resiliencia operacional
- Madurez en la gestión de incidentes
- Alineación regulatoria
- Transparencia y documentación
- Dependencia de proveedores (subencargados)
- Solidez contractual
- Riesgo de concentración
- Viabilidad de la salida
- Capacidad de monitorización
Cada categoría puntuada de 1 a 5. La puntuación ponderada determina la clasificación del riesgo.
10. Mapear las evidencias de los proveedores en la nube en todos los marcos normativos
ISO → acceso, registros, copias de seguridad GDPR → encargados, transferencias, protección de datos NIS2 → resiliencia, cadena de suministro, notificación de incidentes DORA → gobernanza TIC, pruebas, supervisión
En lugar de múltiples evaluaciones:Utilizar un único cuestionario mapeado a todos los marcos.
Una sola evaluación. Múltiples cumplimientos. Sin duplicidades.
Reflexión final
Las evaluaciones de proveedores en la nube ya no son una formalidad de compras. Bajo DORA y NIS2, son una parte central de la estrategia de resiliencia operacional.
Las organizaciones que tendrán éxito serán las que:
- clasifiquen a los proveedores por criticidad
- exijan transparencia
- evalúen la resiliencia, no solo la seguridad
- refuercen la solidez contractual
- monitoricen de forma continua
- minimicen el riesgo de dependencia
- construyan opciones de salida reales
El riesgo en la nube es riesgo regulatorio. Si los proveedores fallan, los reguladores preguntarán por qué la organización no los evaluó correctamente.
Este es el momento de pasar de las revisiones de proveedores por casillas a una gobernanza real.
Si se quiere construir un sistema de evaluación de proveedores unificado y preparado para los reguladores, alineado con DORA, NIS2, GDPR e ISO 27001, eso es exactamente lo que enseñamos en el curso DORA Lead Manager o NIS2 Lead Implementer de Cyber Academy Únase a la próxima sesión y proteja toda su cadena de suministro digital.