Una entidad financiera puede externalizar un servicio TIC, pero sigue siendo responsable de su propia resiliencia operativa. Esta es la regla de partida del artículo 28 de DORA: el contrato no traslada al proveedor las obligaciones regulatorias de la entidad. Para gestionar bien a un tercero hay que saber qué función sostiene, qué ocurriría si fallara, qué derechos de información y salida están pactados y quién presta realmente cada componente del servicio. El precio o el tamaño del proveedor no resuelven esas preguntas.
Esta guía está dirigida a equipos de riesgos, compras, tecnología y asesoría jurídica que revisan una relación concreta. Distingue los requisitos aplicables a todos los contratos de servicios TIC de los adicionales cuando el servicio sustenta una función esencial o importante. También explica qué debe preparar un proveedor que vende a una entidad financiera. Para situar el alcance general y las autoridades españolas, consulte la guía DORA para entidades financieras en España.
Primero: identificar a la entidad, el servicio y la función
DORA se aplica a las categorías de entidades financieras de su artículo 2. Un proveedor de software no adquiere por vender a un banco todas las obligaciones de una entidad financiera. En cambio, el banco debe gestionar el riesgo de ese servicio, y el proveedor tendrá que cumplir las obligaciones que asuma por contrato; si llega a ser designado tercero TIC crítico, tendrá además el régimen público de supervisión correspondiente. Esta separación evita atribuir automáticamente al vendedor deberes de registro o notificación que recaen en su cliente financiero.
Haga un mapa de la prestación antes de negociar cláusulas. Identifique al cliente financiero, la sociedad que firma, el servicio prestado, las funciones empresariales que dependen de él y sus posibles sustitutos. Una herramienta barata de autenticación puede sostener una función esencial; una gran licencia de ofimática puede tener usos menos críticos. El artículo 3 de DORA define la función esencial o importante por el efecto que una interrupción, defecto o fallo tendría en el rendimiento financiero, la solidez, la continuidad o el cumplimiento de la entidad. La clasificación debe basarse en la función real, no en una etiqueta comercial.
Pregunte también qué datos se procesan y quién decide su finalidad. Un proveedor TIC puede ser encargado del tratamiento para ciertos datos personales, responsable independiente para otros o no tratar datos personales en una parte del servicio. Si existe un encargo, el artículo 28 del RGPD requiere sus propias garantías. Una adenda DORA y un modelo de contrato de encargado tienen propósitos distintos; pueden convivir, pero ninguno sustituye automáticamente al otro.
Evaluar antes de contratar, no al renovar
El artículo 28.4 exige a la entidad, antes de un acuerdo TIC, valorar si sustenta una función esencial o importante, las condiciones de supervisión, los riesgos del acuerdo —incluida la concentración—, la diligencia debida del proveedor y los posibles conflictos de intereses. El apartado 5 exige estándares adecuados de seguridad de la información y una consideración adicional de su calidad actual cuando se sostienen funciones esenciales o importantes. La norma técnica 2024/1773 desarrolla la política de uso de terceros para esas funciones: evaluación previa, selección, seguimiento, auditoría y salida forman un ciclo, no un formulario de alta.
Una evaluación útil describe el servicio con suficiente precisión para decidir. ¿Qué negocio se interrumpe si la API deja de responder? ¿Cuál es la dependencia de una identidad común, una red, una región cloud o un subcontratista? ¿Qué información necesita el proveedor para diagnosticar un incidente y cuánto tardará en proporcionarla? ¿Puede el cliente recuperar datos legibles si el contrato termina o el proveedor entra en insolvencia? Documente las respuestas y la persona que acepta el riesgo residual. Un escenario de riesgo con amenaza, evento e impacto ayuda a conectar esta evaluación con decisiones de continuidad.
No convierta la diligencia en una lista de certificados. Un informe de auditoría o un estándar de seguridad puede ser evidencia útil, pero debe cubrir el servicio, periodo, región y cadena de suministro relevantes. Pida aclaraciones sobre excepciones, hallazgos pendientes y responsabilidades compartidas. Si el proveedor cambia de subcontratista o región, reevalúe el efecto; el informe que justificó la contratación inicial puede haber dejado de describir la prestación actual.
Artículo 30: cláusulas para todos los contratos TIC
El artículo 30.1 pide asignar claramente por escrito derechos y obligaciones, incluir los acuerdos de nivel de servicio y mantener el contrato completo en un soporte duradero y accesible. Su apartado 2 establece el mínimo para todos los acuerdos de uso de servicios TIC. Deben describirse funciones y servicios, las condiciones de subcontratación cuando ésta afecte a funciones esenciales o importantes, y los lugares donde se presta el servicio y se tratan o almacenan datos, con aviso previo de cambios previstos. No basta con decir «infraestructura en la nube» sin identificar regiones y reglas de cambio.
El mismo mínimo trata la disponibilidad, autenticidad, integridad y confidencialidad de los datos; la recuperación y devolución de datos personales y no personales ante insolvencia, interrupción o terminación; niveles de servicio y revisiones; asistencia del proveedor en incidentes relacionados con el servicio; cooperación con autoridades competentes y de resolución; derechos de terminación y avisos; y condiciones para participar en programas de formación pertinentes. La asistencia por incidente debe ser sin coste adicional o a un coste fijado previamente: el reglamento no exige que todo apoyo técnico sea siempre gratuito.
Convierta cada cláusula en una prueba de operación. Para ubicaciones, mantenga la lista de regiones y el canal que recibirá el aviso. Para devolución, defina formato, prueba de integridad, plazo, acceso durante la transición y borrado posterior cuando corresponda. Para niveles de servicio, acuerde qué se mide y de qué registro se extrae el dato. Para incidentes, pacte el contacto operativo, la información mínima y la velocidad interna de escalado. Un procedimiento de comunicación de vulnerabilidades con proveedores puede complementar el contrato sin confundir una vulnerabilidad con un incidente notificable. Si también se comprometen datos personales, la entidad debe evaluar por separado la notificación de una brecha a la AEPD según los artículos 33 y 34 RGPD; la alerta contractual del proveedor debe aportar información para esa evaluación.
La capa adicional para funciones esenciales o importantes
El artículo 30.3 añade obligaciones cuando el servicio sostiene una función esencial o importante. Los niveles de servicio han de incluir objetivos cualitativos y cuantitativos precisos que permitan seguir el rendimiento y corregir desviaciones. El proveedor debe comunicar hechos que puedan afectar considerablemente su capacidad de prestación. El acuerdo incorpora pruebas de contingencia y medidas de seguridad adecuadas, cooperación en las pruebas de penetración basadas en amenazas cuando correspondan, y derechos efectivos de supervisión continua, acceso, inspección y auditoría para la entidad y las autoridades pertinentes.
Los derechos de auditoría requieren negociación operativa, especialmente en plataformas compartidas. La norma contempla acordar niveles alternativos de garantía cuando se afecten derechos de otros clientes, pero eso no justifica vaciar el derecho de supervisión. Defina qué documentos se podrán consultar, cuándo se permite inspección in situ, cómo se protege la información de terceros y qué pasa si una evidencia revela una deficiencia. Una certificación genérica no sustituye la posibilidad de evaluar el servicio contratado.
También se necesitan estrategias de salida y un periodo transitorio suficiente durante el cual continúe el servicio mientras se migra a otro proveedor o se adopta una solución interna. La cláusula no debe limitarse a «el proveedor entregará los datos»: puede haber formatos propietarios, integraciones, licencias, claves, equipos y personal especializado. Describa la asistencia de transición, su coste y los disparadores de salida. Una prueba parcial de exportación muestra más que una promesa de portabilidad sin ensayo.
Subcontratación: mirar más allá del proveedor directo
Para una propuesta de cambio material en la cadena de un servicio que apoya una función crítica o importante, use una evaluación documentada del cambio de subcontratación: qué actividad cambia, qué riesgos añade y quién decide dentro del plazo previsto por el acuerdo. No se trata de aplicar el mismo procedimiento especial a cualquier proveedor.
La cadena de suministro puede cambiar el riesgo que la entidad creyó contratar. DORA exige expresar si se permite subcontratar servicios TIC que sostienen funciones esenciales o importantes y bajo qué condiciones. Al evaluar un acuerdo con esa posibilidad, el artículo 29 pide considerar beneficios y riesgos, incluido un subcontratista en tercer país y la dificultad de supervisar cadenas largas o complejas. La entidad debe saber qué parte del servicio cambia de manos y si podrá seguir auditando y recuperando datos.
El Reglamento Delegado 2025/532 concreta elementos de evaluación y condiciones contractuales para subcontratar servicios que sostienen funciones esenciales o importantes, o partes materiales de ellos. Exige una visión del ciclo de subcontratación: planificación, diligencia, seguimiento, cambios materiales y continuidad. No significa que todo subcontratista de cualquier herramienta trivial requiera el mismo expediente. Registre la cadena que importa para la función, los lugares pertinentes, la información que el proveedor directo debe comunicar y la facultad de reaccionar ante cambios que alteren el riesgo.
Un caso típico es una plataforma de pagos que usa una infraestructura cloud y, para autenticación, un servicio de identidad distinto. La entidad puede tener un contrato excelente con la plataforma, pero perder simultáneamente pago y acceso si ambos terceros dependen del mismo sistema de identidad. Pregunte por dependencias comunes, no solo por nombres en una lista. Si el cambio de un subcontratista afecta a ubicación, seguridad o posibilidad de inspección, la revisión debe llegar a riesgos y al dueño de la función antes de aceptarse como mero trámite administrativo.
Concentración y salida: dos decisiones relacionadas
El artículo 29 se centra en la evaluación a nivel de la entidad antes de contratar servicios que sostienen funciones esenciales o importantes. Pide valorar si el proveedor no es fácilmente sustituible o si varios contratos descansan en el mismo proveedor o en proveedores estrechamente relacionados. No impone automáticamente una arquitectura de múltiples nubes. La entidad debe ponderar beneficios y costes de alternativas frente a sus necesidades y estrategia de resiliencia. Distribuir servicios entre dos marcas que comparten una infraestructura crítica tampoco elimina la concentración.
Haga una prueba de sustituibilidad con preguntas concretas: ¿qué datos pueden extraerse, en qué plazo, con qué calidad y a qué coste? ¿Existe un proveedor alternativo con capacidad demostrable? ¿Depende el plan de personal que solo conoce la plataforma actual? ¿Qué servicios permanecerían mientras se ejecuta la migración? Una prueba de resiliencia DORA puede revelar dependencias técnicas, aunque TLPT tiene su propio ámbito y no es una obligación universal de todos los proveedores. Las estrategias de salida deben ser proporcionales al impacto de la función.
La localización puede afectar disponibilidad, aplicabilidad de leyes, insolvencia y recuperación. Si hay datos personales transferidos a un tercer país, añada el análisis separado de transferencias internacionales RGPD. Que DORA permita evaluar un proveedor fuera de la Unión no decide por sí mismo la licitud de una transferencia de datos. Y una región europea en la interfaz del proveedor no prueba que soporte, subcontratación y acceso remoto permanezcan allí.
Registro y supervisión de terceros críticos
El artículo 28.3 exige a las entidades financieras mantener un registro de información de todos sus acuerdos de uso de servicios TIC, distinguiendo los que sostienen funciones esenciales o importantes de los demás. Por eso el inventario no se limita a contratos «críticos». Registre entidad contratante, función, servicio, proveedor, lugares y cadena según las plantillas técnicas aplicables; reconcilie renovaciones y cambios con compras y arquitectura. La guía del registro de información DORA detalla su finalidad y contenido. El proveedor puede facilitar los datos, pero la obligación de mantener el registro pertenece a la entidad.
Otra figura es el proveedor tercero esencial de servicios TIC designado bajo el artículo 31: la designación a nivel europeo depende de criterios como impacto sistémico, dependencia de entidades y sustituibilidad. No se deduce simplemente de que un banco llame «crítico» a su contrato. Las Autoridades Europeas de Supervisión, a través del Comité Mixto, conducen la designación y asignan un supervisor principal conforme al marco legal. Este puede solicitar información, investigar, recomendar mejoras y, dentro de las condiciones legales, imponer multas coercitivas por incumplimiento de sus actuaciones de supervisión. No es un régimen general de multas DORA del 2 % a cualquier proveedor.
La supervisión pública no sustituye el trabajo de cada entidad. Un proveedor designado puede fallar en un servicio, región o subcontratación que importa a un cliente particular. La entidad continúa gestionando su contrato, sus concentraciones y su plan de salida. Un proveedor no designado puede sostener una función esencial de un banco concreto y merece la evaluación correspondiente. Mantenga separados el juicio contractual de la entidad y la designación sistémica europea.
Qué preparar si vende software a entidades financieras
Un proveedor puede facilitar la diligencia con un paquete verificable: descripción del servicio y sus límites, mapa de subcontratistas y ubicaciones relevantes, niveles de servicio, procedimiento de incidentes, medidas de seguridad, continuidad, exportación de datos y contacto para auditorías. Feche cada documento y explique qué clientes o versiones cubre. La entidad necesitará información para su propio registro, evaluación y contrato; un folleto genérico de «cumplimiento DORA» no ofrece suficiente detalle para decidir.
Si el servicio incorpora datos personales, prepare también el análisis de roles y, cuando proceda, el acuerdo RGPD. Si el proveedor está sometido por su actividad a otro régimen, no afirme automáticamente que DORA lo sustituye. La comparación entre DORA y NIS2 ayuda a separar destinatarios y obligaciones; la transposición de NIS2 en España requiere comprobar su estado en la fecha de la decisión. Contrato, regulación sectorial y protección de datos pueden coexistir sin convertirse en un único deber indiferenciado.
Al seleccionar un software de cumplimiento DORA, pruebe si permite relacionar función, contrato, proveedor, subcontratista, ubicación, evaluación, evidencia y salida. Una hoja de cálculo puede servir para un inventario pequeño si se controla su actualización. La herramienta no clasifica jurídicamente la función ni aprueba el riesgo por la entidad: debe hacer visibles los datos faltantes, los cambios pendientes y el responsable de cada decisión.
Revisión práctica de un contrato existente
Elija un servicio que sostenga una función importante y reúna contrato completo, anexos, niveles de servicio, mapa técnico, evaluación de riesgo y registro. Primero compruebe que todos describen la misma prestación y la misma entidad contratante. Después compare cláusula por cláusula con el artículo 30.2 y, si corresponde, con el 30.3; no presuponga que un anexo estándar contiene acceso, salida o asistencia suficiente. Liste lagunas, dueño de la acción y fecha de corrección.
A continuación, simule dos eventos: el proveedor pierde una región durante varios días y anuncia una subcontratación material en otro país. Pregunte quién recibe la alerta, cuándo se informa a la entidad, qué alternativa opera, cómo se recuperan datos y quién puede aprobar el cambio. Si las respuestas dependen de una persona no identificada o de un derecho que el contrato no reconoce, el control sigue incompleto. Documente el resultado y repita al cambiar servicio, proveedor o función. Ese ciclo convierte la gestión del tercero en una decisión revisable y no en una firma archivada.
Preguntas frecuentes
¿Hay que adaptar solo contratos de servicios esenciales?
No. El artículo 30.2 contiene elementos mínimos para los acuerdos de uso de servicios TIC en general. Su apartado 3 añade elementos para servicios que sostienen funciones esenciales o importantes. La prioridad de renegociación puede basarse en riesgo, pero la distinción legal debe mantenerse.
¿Debe ser gratuita toda asistencia por incidentes?
No necesariamente. El artículo 30.2.f permite asistencia sin coste adicional o a un coste determinado antes del incidente. Defina también contacto, alcance y entrega de información para que el precio pactado no oculte una respuesta insuficiente.
¿Un proveedor crítico designado libera al banco de supervisarlo?
No. La supervisión del proveedor por una autoridad europea tiene finalidad sistémica; la entidad conserva la responsabilidad de gestionar su acuerdo y dependencia concreta bajo el artículo 28.
¿Es obligatorio usar varios proveedores cloud?
DORA exige evaluar concentración y alternativas cuando corresponda, no imponer una solución multicloud universal. La salida escogida debe funcionar para la función, el riesgo y los recursos reales de la entidad.