DORA para un proveedor tecnológico de entidades financieras

El Reglamento de Resiliencia Operativa Digital se aplica en toda la UE desde el 17 de enero de 2025. Va dirigido a las entidades financieras —bancos, aseguradoras, empresas de inversión, entidades de pago, proveedores de servicios de criptoactivos y otra quincena de categorías—, pero buena parte de su texto habla de sus proveedores.

Si vendes software o infraestructura a una entidad financiera, DORA te llega de dos formas: cláusulas contractuales que tus clientes están ahora obligados a imponer y, para un puñado de proveedores, supervisión directa de las Autoridades Europeas de Supervisión.

Los cinco pilares, en breve

DORA organiza los requisitos en gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia operativa digital, gestión del riesgo de terceros y compartición de información. Para un proveedor, la presión aterriza en el segundo y el cuarto.

La notificación de incidentes sigue un calendario definido para los incidentes TIC graves: una notificación inicial, un informe intermedio y un informe final, con las normas técnicas de regulación fijando las ventanas concretas. La entidad financiera informa a su supervisor, pero no puede hacerlo sin ti, lo que significa que tu contrato especificará con qué rapidez debes avisarla. Cuenta con que te pidan notificación en horas, porque su propio reloj empieza cuando tienen conocimiento.

La gestión del riesgo de terceros exige a la entidad financiera mantener un registro de información de cada contrato TIC, evaluar el riesgo de concentración y asegurar que ciertas cláusulas están en todos los contratos. Esta es la parte que aparece en tus renovaciones.

Qué van a contener ahora tus contratos

El artículo 30 establece las disposiciones contractuales obligatorias. Cuenta con que tu próxima renovación con un cliente financiero exija:

• Una descripción completa de los servicios, incluido si se permite subcontratar funciones críticas y bajo qué condiciones.
• Las ubicaciones donde se prestan los servicios y se procesan y almacenan los datos, con preaviso antes de cambiarlas. Mover una carga de trabajo a otra región se convierte en un hecho contractual.
• Disposiciones de protección de datos, disponibilidad, integridad y confidencialidad, con niveles de servicio especificados e incluyendo objetivos cuantitativos.
• Asistencia sin coste adicional, o a un coste pactado previamente, cuando ocurre un incidente.
• Cooperación plena con las autoridades competentes del cliente, incluidos derechos de acceso, inspección y auditoría sobre ti.
• Estrategias de salida: un periodo de transición obligatorio durante el cual sigues prestando el servicio, y obligaciones de devolución de datos.
• Participación en las pruebas de penetración guiadas por amenazas (TLPT) del cliente cuando la entidad esté obligada a realizarlas.

Tres de estas dan problemas con regularidad a proveedores que no las han visto antes.

Derechos de auditoría. Las entidades financieras necesitan derechos contractuales para ellas y para sus supervisores de inspeccionarte. Puedes gestionarlo con auditorías mancomunadas y ofreciendo certificaciones e informes existentes —un certificado ISO 27001 y un SOC 2 Tipo II cubren buena parte del aseguramiento rutinario—, pero no puedes excluir contractualmente el acceso del supervisor.

Salida y transición. Tienes que ser capaz de entregarle al cliente sus datos en un formato usable y mantener el servicio en marcha mientras se mueve. Escribe el plan de salida y prueba la exportación antes de que un cliente lo pida, porque "exportaríamos la base de datos" no es una respuesta cuando la pregunta va de un periodo de transición de dos años para una función crítica.

Transparencia de subcontratistas. Tu propio proveedor cloud y cualquier subencargado crítico deben declararse, con aviso de cambios. Mantén la lista al día; te la van a pedir muchas veces.

Proveedores terceros TIC críticos

Un número reducido de proveedores será designado como crítico por las Autoridades Europeas de Supervisión, en función de su importancia sistémica y su sustituibilidad. Los designados quedan bajo supervisión directa de la UE, con un Supervisor Principal, facultades de inspección y capacidad de emitir recomendaciones.

De forma realista, esa designación recae en los hiperescalares y en un puñado de grandes fabricantes de software del sector financiero. Si eres una empresa SaaS mediana no te van a designar, pero tus clientes financieros deben evaluar el riesgo de concentración entre sus proveedores, lo que significa que te pueden preguntar por tu propia dependencia de un único proveedor o región cloud.

Qué construir, y en qué orden

Si las entidades financieras son una parte relevante de tu base de clientes:

1. Un documento de descripción de servicio y ubicaciones, por servicio, mantenido al día. Alimenta su registro de información y te lo va a pedir cada cliente.
2. Un procedimiento de notificación de incidentes con plazos comprometidos, integrado en tu runbook de guardia con la vía de contacto del cliente dentro. El reloj de 24 horas de NIS2 y las expectativas de notificación al cliente de DORA se parecen lo bastante como para construirlo una sola vez.
3. Un plan de salida probado: exportación de datos en un formato documentado, un calendario de transición y evidencia de que has ejecutado la exportación.
4. Un registro de subcontratistas, con un proceso de notificación de cambios.
5. Evidencia de pruebas de resiliencia. DORA espera que las entidades prueben; los proveedores que pueden enseñar sus propias pruebas —incluidos ejercicios de conmutación con tiempos de recuperación registrados— acortan cualquier conversación de diligencia debida.

Nada de esto exige una certificación, y no existe un "certificado DORA" que obtener. Lo que sí existe es un conjunto de documentos y capacidades que tus clientes están ahora obligados a pedir. Tenerlos listos convierte una revisión de compras de seis semanas en una de una, que para un proveedor es todo el beneficio práctico.