DORA · Proveedores TIC

DORA para proveedores TIC: qué te van a pedir tus clientes bancarios

Publicado 14 de octubre de 2026 · SystemFlare engineering

DORA no regula directamente a la mayoría de proveedores TIC, pero desde el 17 de enero de 2025 hace responsables de ti a tus clientes financieros. Tienen que inscribirte en un registro, incluir cláusulas concretas en tu contrato (artículos 28 a 30) y poder demostrar a su supervisor que las cumples. En la práctica, eso significa nuevas cláusulas, cuestionarios más largos y peticiones de evidencias: control de accesos, logs, copias de seguridad y pruebas de restauración, gestión de incidentes, gestión de cambios, un plan de salida y la lista de tus subcontratistas.

Este artículo explica cómo funcionan las normas en la práctica. No es asesoramiento jurídico. Para la redacción de contratos, consulta a un abogado.

Qué es DORA y por qué le importa a un proveedor

El Reglamento de Resiliencia Operativa Digital, el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025. Cubre a bancos, aseguradoras, empresas de inversión, entidades de pago y de dinero electrónico, proveedores de servicios de criptoactivos y otras entidades financieras de la UE.

La mayoría de proveedores TIC no están regulados por DORA. Un grupo pequeño de proveedores que las Autoridades Europeas de Supervisión designan como críticos tiene supervisión directa. Al resto le afecta de forma indirecta, a través de los contratos.

Con DORA, la entidad financiera sigue siendo plenamente responsable de los servicios que externaliza. Así que tiene que saber quién eres, qué haces para ella y si puede confiar en ti. Por eso un fabricante de software, una empresa de hosting o un contratista de DevOps que nunca ha oído hablar de DORA puede recibir de repente un cuestionario de 40 páginas y un anexo al contrato.

El registro de información

El artículo 28(3) obliga a cada entidad financiera a llevar un registro de información de todos sus acuerdos contractuales de servicios TIC con proveedores terceros. El formato lo fijan normas técnicas de ejecución (Reglamento de Ejecución (UE) 2024/2956 de la Comisión).

La entidad comunica el registro a su autoridad competente cada año y debe tenerlo disponible cuando se lo pidan. Para ti, como proveedor, eso significa que tu cliente necesita datos exactos sobre ti:

  • tu entidad jurídica y tus identificadores, por ejemplo un LEI;
  • qué servicios TIC prestas y qué funciones de negocio del cliente soportan;
  • dónde se prestan los servicios y dónde se almacenan y tratan los datos;
  • en servicios que soportan funciones críticas o importantes, la cadena de subcontratistas que realmente los sostiene.

Lo último importa. Si tu servicio corre en un proveedor cloud, usa un soporte externalizado o depende de la plataforma de otro proveedor, tu cliente puede necesitar ver esa cadena. Mantén al día la lista de subcontratistas que intervienen en cada servicio.

Las cláusulas que te llegan por contrato

Los artículos 28 a 30 fijan lo que debe contener el contrato entre la entidad financiera y su proveedor TIC. Tu cliente no puede saltarse estas cláusulas. Cuenta con verlas en los contratos nuevos y en anexos a los existentes.

Para todo servicio TIC (artículo 30(2))

  • Una descripción clara y completa de las funciones y servicios que prestas.
  • Las ubicaciones (regiones o países) donde prestas los servicios y donde se tratan y almacenan los datos, y la obligación de avisar al cliente antes de cambiarlas.
  • Disposiciones sobre disponibilidad, autenticidad, integridad y confidencialidad de los datos, incluidos los personales.
  • Garantizar el acceso, la recuperación y la devolución de los datos en un formato fácilmente accesible si entras en insolvencia, el servicio se interrumpe o el contrato se resuelve.
  • Descripciones de los niveles de servicio, incluida su actualización.
  • La obligación de asistir al cliente cuando ocurra un incidente TIC relacionado con tu servicio, sin coste adicional o con un coste fijado de antemano.
  • La obligación de cooperar plenamente con las autoridades competentes y de resolución, incluidas las personas que designen.
  • Derechos de resolución y plazos mínimos de preaviso. El artículo 28(7) enumera situaciones en las que el cliente debe poder terminar el contrato, por ejemplo un incumplimiento grave de la ley o del contrato, o debilidades en tu gestión del riesgo TIC.
  • Las condiciones de tu participación en los programas de concienciación sobre seguridad TIC y la formación en resiliencia operativa del cliente.

Para funciones críticas o importantes (artículo 30(3))

Si tu servicio soporta una función cuya interrupción perjudicaría de forma importante al negocio del cliente o a su cumplimiento normativo, el contrato debe incluir además:

  • descripciones completas de los niveles de servicio, con objetivos de rendimiento cuantitativos y cualitativos precisos;
  • plazos de preaviso y obligaciones de información, incluido avisar al cliente de cualquier hecho que pueda afectar de forma importante a tu capacidad de prestar el servicio;
  • la obligación de aplicar y probar planes de contingencia, y de tener medidas, herramientas y políticas de seguridad TIC adecuadas;
  • la obligación de participar y cooperar en las pruebas de penetración basadas en amenazas (TLPT) del cliente cuando estén en su alcance;
  • el derecho del cliente a supervisar tu rendimiento, con derechos ilimitados de acceso, inspección y auditoría para el cliente, un tercero designado y la autoridad competente;
  • estrategias de salida, incluido un periodo de transición obligatorio y adecuado.

El artículo 29 pide además al cliente que valore el riesgo de concentración y cuánto depende tu servicio de cadenas de subcontratación largas o complejas. Otras normas técnicas describen la política del cliente para estos contratos y las condiciones para subcontratar servicios críticos.

Lo que de verdad pregunta el cuestionario

Las cláusulas son promesas. Los cuestionarios y las auditorías te piden demostrar que puedes cumplirlas. Como parten de los mismos artículos, las preguntas suelen girar en torno a los mismos temas. Un proveedor que prepara de antemano un paquete de evidencias responde más rápido y con más coherencia.

  1. Control de accesos. Quién tiene acceso a producción y a los datos del cliente, cómo se da y se quita, si se exige MFA y cómo se gestionan las cuentas privilegiadas y de servicio. Evidencia: lista de accesos, procedimiento de altas y bajas, última revisión de accesos.
  2. Logs y monitorización. Qué se registra, dónde se guardan los logs, cuánto tiempo y quién atiende las alertas. Evidencia: una descripción breve del sistema de logs y un ejemplo de alerta gestionada.
  3. Copias de seguridad y recuperación ante desastres. Frecuencia, dónde se guardan, si están cifradas y, sobre todo, cuándo restauraste una por última vez. Evidencia: política de copias y una prueba de restauración con fecha y resultado.
  4. Gestión de incidentes. Cómo detectas, clasificas y escalas incidentes, y en cuánto tiempo avisarías al cliente. DORA impone a las entidades financieras plazos de notificación ajustados, así que necesitan tu información rápido. Evidencia: procedimiento de incidentes, puntos de contacto y un informe de un incidente o simulacro anterior.
  5. Gestión de cambios. Cómo llegan los cambios a producción, quién los revisa y si puedes deshacerlos. Evidencia: descripción del pipeline, reglas de revisión y un ejemplo de registro de cambio.
  6. Gestión de vulnerabilidades y parches. Cómo encuentras y corriges vulnerabilidades en tu código, dependencias y servidores. Evidencia: informes de escaneo y plazos de parcheo.
  7. Plan de salida. Cómo recupera el cliente sus datos y pasa a otro proveedor, cuánto se tarda y qué ayuda das durante la transición. Evidencia: un plan de salida escrito por servicio.
  8. Subcontratistas y ubicaciones. Quién más interviene en el servicio y dónde están los datos. Evidencia: una lista de subcontratistas con servicios, ubicaciones y los datos que maneja cada uno.

Nada de esto tiene que ser un archivador gordo. Una docena de documentos breves, exactos y con fecha valen más que un juego de políticas genérico. Lo que buscan supervisores y auditores es la prueba de que el control funciona: un registro de restauración, una revisión de accesos, un pull request fusionado con su revisión.

Errores habituales

  • Prometer lo que no haces. Firmar un anexo con derechos de auditoría o un aviso de incidentes en cuatro horas que no puedes cumplir crea un problema contractual después. Lee las cláusulas con tus ingenieros, no solo con ventas.
  • Olvidar a tus propios proveedores. Tu hosting, tu monitorización y tu soporte forman parte de la cadena. Tu cliente puede preguntar por ellos.
  • Una respuesta distinta para cada cliente. Diez bancos mandarán diez cuestionarios. Mantén un único paquete de evidencias y adáptalo, para que tus respuestas sean coherentes.
  • Ninguna prueba de restauración. “Tenemos copias” es la respuesta más común y la más débil. Una restauración con fecha y con éxito es lo que convence.

Por dónde empezar

Elige un servicio que prestes a un cliente financiero. Apunta su descripción, ubicaciones, subcontratistas y los datos que toca. Luego repasa cada punto de la lista de evidencias y marca lo que puedes demostrar hoy. Las carencias son tu plan.

Si quieres ayuda, nuestro servicio de preparación DORA para proveedores TIC hace exactamente esto y cierra contigo las carencias técnicas. Si antes necesitas una visión honesta de tus servidores y accesos, empieza por una auditoría de seguridad de infraestructura.

Preguntas frecuentes

Somos una empresa de software pequeña. ¿Nos aplica DORA?

Normalmente no de forma directa. DORA se aplica a las entidades financieras y a una lista corta de proveedores TIC críticos designados por las Autoridades Europeas de Supervisión. Pero si das servicio a un banco, una aseguradora, una entidad de pago o de dinero electrónico, un proveedor de servicios de criptoactivos o una empresa de inversión, tu cliente tiene que aplicar DORA a su contrato contigo, así que los requisitos te llegan a través de ese contrato.

¿Qué es el registro de información y tenemos que rellenarlo nosotros?

Es un registro que tu cliente financiero lleva de todos sus acuerdos contractuales de servicios TIC y que comunica cada año a su supervisor. No lo presentas tú, pero tu cliente te pedirá los datos que necesita: tu identificador de entidad jurídica, los servicios que prestas, dónde se prestan y dónde están los datos y, en servicios que soportan funciones críticas o importantes, los subcontratistas que los sostienen.

¿Qué cambia si nuestro servicio soporta una función crítica o importante?

El contrato tiene que decir más. El artículo 30(3) añade niveles de servicio precisos, plazos de preaviso y obligaciones de informar, planes de contingencia probados y medidas de seguridad, participación en las pruebas de penetración basadas en amenazas del cliente, derechos ilimitados de acceso, inspección y auditoría, y una estrategia de salida con periodo de transición.

¿Dais una certificación DORA?

No. Nadie certifica a un proveedor como 'conforme con DORA'. Te ayudamos a poner en marcha los controles y las evidencias y a preparar respuestas claras a los cuestionarios de tus clientes. La redacción del contrato es cosa de tus abogados y los suyos.

¿Cuánto se tarda en estar preparado?

Nuestro trabajo de preparación DORA para proveedores TIC suele durar de 3 a 6 semanas y parte de 6.000 €, IVA no incluido. Casi todo ese tiempo se va en cerrar carencias y generar evidencias, no en redactar políticas.

Prepárate antes del próximo cuestionario

Contrastamos tus controles con lo que piden los clientes sujetos a DORA, cerramos las carencias y te ayudamos a montar un paquete de evidencias reutilizable.

Ver preparación DORA para proveedores TIC