Qué es DORA y por qué alcanza al SaaS
El Digital Operational Resilience Act (Reglamento (UE) 2022/2554) es un único marco normativo para la resiliencia operativa digital del sector financiero de la UE. Se aplica directamente en todos los Estados miembros desde el 17 de enero de 2025. Abarca bancos, aseguradoras, empresas de inversión, entidades de pago y de dinero electrónico, y otras entidades financieras.
El reglamento descansa en cinco pilares: gestión del riesgo de ICT, gestión y notificación de incidentes de ICT, pruebas de resiliencia operativa digital, gestión del riesgo de terceros de ICT e intercambio de información. El SaaS se enmarca sobre todo en el pilar de riesgo de terceros.
Casi toda aplicación SaaS que usa una entidad financiera, como suites de colaboración, CRM, RR. HH., analítica o gestión documental, es un servicio de ICT prestado por un tercero. Así, el contrato cuenta como un acuerdo con un tercero de ICT, según el capítulo de DORA sobre riesgo de terceros.
Los proveedores designados como terceros proveedores críticos de servicios de ICT también son supervisados directamente por las Autoridades Europeas de Supervisión. Esa supervisión no traslada la responsabilidad: ante su propio supervisor, la entidad financiera sigue respondiendo por la resiliencia de las funciones que respalda el SaaS.
El registro de información y el deber de evaluación
DORA exige que cada entidad financiera mantenga un registro de información con todos sus acuerdos con terceros de ICT, y todo contrato SaaS debe figurar en él. El registro recoge la identidad del proveedor, la descripción de los servicios, si respaldan funciones críticas o importantes, la cadena de subcontratación, las ubicaciones de los datos y los derechos de resolución.
El registro llega a los supervisores nacionales, que informan a las Autoridades Europeas de Supervisión. Así, los registros SaaS incompletos afloran en la revisión supervisora y no quedan como una laguna interna. Un registro de activos de TI preciso es el punto de partida práctico.
La evaluación es un deber de todo el ciclo de vida, no un trámite de compra. Antes de depender de un servicio SaaS, la entidad debe evaluar la capacidad técnica del proveedor, sus prácticas de seguridad, la calidad del soporte y su solvencia financiera, y repetir la revisión cuando cambian las circunstancias.
La concentración recibe atención específica. Cuando muchas entidades dependen de las mismas pocas plataformas SaaS, el fallo de un proveedor se convierte en un evento de todo el sector, por eso el registro también documenta cuán sustituible es cada servicio.
Cláusulas contractuales que DORA espera
DORA fija el contenido mínimo de los contratos de servicios de ICT. En la práctica, un acuerdo SaaS debe contener al menos estas cláusulas:
| Cláusula | Qué exige |
|---|---|
| Derechos de auditoría y acceso | Inspección por la entidad, auditores y supervisores; promesas comerciales no bastan |
| Descripción y niveles de servicio | Descripción funcional clara, niveles medibles y seguridad proporcional a la criticidad |
| Ubicación, protección y devolución de datos | Ubicación de los datos, su protección y su devolución o eliminación verificables |
| Terminación y estrategia de salida | Derechos de terminación documentados y estrategia de salida probada para servicios críticos |
| Transparencia en la subcontratación | Subcontratistas relevantes divulgados, evaluados y comunicados si la cadena cambia |
Incidentes y pruebas donde aparecen las dependencias SaaS
DORA armoniza la clasificación y la notificación de incidentes graves relacionados con ICT. Un incidente que empieza en un proveedor SaaS sigue siendo incidente de la entidad. Esta debe detectar que una dependencia se ha degradado y evaluar el impacto en sus propias funciones.
No todo incidente grave es una brecha de datos. La caída de un proveedor que detiene un servicio crítico también puede ser notificable. Los informes inicial, intermedio y final deben entregarse en los plazos previstos, y para ello hay que saber de antemano qué funciones dependen de qué servicios.
Las pruebas de resiliencia deben incluir la dimensión de terceros. Los programas de prueba, incluidas las pruebas de penetración basadas en amenazas (TLPT) para las entidades designadas por la autoridad, deben considerar escenarios en los que un servicio SaaS no esté disponible, esté degradado o haya sido comprometido. Deben verificar que la recuperación y las estrategias de salida funcionen bajo presión, no solo que existan en la documentación.
Requisitos y su estado
No todo deber se aplica a todo servicio por igual. Estas obligaciones suelen gestionarse dentro de un proceso de gestión de cumplimiento, y el estado que aparece abajo depende del alcance.
| Requisito | Se aplica a | Estado |
|---|---|---|
| Registro de información | Cada acuerdo de ICT con terceros | Obligatorio |
| Notificación de incidentes graves | Todas las entidades financieras | Obligatorio |
| Estrategia de salida | Servicios que respaldan funciones críticas o importantes | Solo crítico |
| Pruebas de penetración basadas en amenazas (TLPT) | Entidades designadas por la autoridad | Solo designadas |
Donde los controles de SaaS se quedan cortos
Ningún control por sí solo cubre todo el panorama SaaS. La revisión de contratos verifica el papel, mientras que el inventario y los registros de actividad muestran lo que realmente se usa. Los servicios adoptados sin aprobación, el núcleo del Shadow IT, quedan en el hueco entre ambos.
| Control | Detecta SaaS no aprobado | Limita la subida de datos | Deja rastro de actividad |
|---|---|---|---|
| Revisión del contrato en la compra | |||
| Inventario de aplicaciones | |||
| Registro de actividad | |||
| Prevención de pérdida de datos en subidas |
Cómo es una buena seguridad SaaS según DORA
El reglamento fija los deberes, pero la práctica empieza por saber qué servicios SaaS usa realmente la organización. Los servicios que adoptan equipos concretos nunca entran en el registro ni se evalúan, y aun así mueven los mismos flujos de datos que los aprobados.
Ninguno de los controles siguientes aparece nombrado en el reglamento. Sin ellos, sin embargo, es difícil cumplir las obligaciones que sí nombra. Definir qué datos pueden llegar a cada servicio es la tarea de la prevención de pérdida de datos.
- 1
Empiece por el inventario
Registre cada aplicación SaaS en uso, incluidas las que los empleados adoptan por su cuenta.
- 2
Clasifique los datos
Defina qué datos pueden llegar a cada servicio.
- 3
Cubra los canales de entrada
Aplique prevención de pérdida de datos a las subidas desde el navegador, los clientes de sincronización y el correo, para que los datos regulados lleguen solo a servicios del registro.
- 4
Registre la actividad de los usuarios
Mantenga una pista de evidencias dentro y alrededor de las aplicaciones SaaS, para la clasificación de incidentes y las preguntas de los supervisores.
Por dónde empezar
Empiece por los datos cuya exposición causaría más daño y luego mapee los servicios que pueden recibirlos. Una política de clasificación de datos da a cada contrato y a cada control el mismo punto de referencia.
Lectura recomendada: El concepto de "Zero Trust".
Un contrato SaaS vale tanto como la lista de servicios que cubre.
Anexet Team