DORA para entidades de pago y entidades de dinero electrónico en 2026
Qué exige el Reglamento de resiliencia operativa digital a las entidades de pago y de dinero electrónico en 2026: ámbito y marco simplificado para entidades pequeñas, riesgo TIC, notificación de incidentes, pruebas, registro de información, contratos TIC y qué preguntar a su proveedor de core banking.
DORA en un párrafo
El Reglamento de resiliencia operativa digital, Reglamento (UE) 2022/2554 (DORA), se aplica desde el 17 de enero de 2025. Al ser un reglamento, es directamente aplicable en todos los Estados miembros sin necesidad de transposición nacional. Para una entidad de pago o de dinero electrónico abarca cinco áreas: gestión del riesgo relacionado con las TIC, notificación de incidentes relacionados con las TIC, pruebas de resiliencia, gestión del riesgo de terceros proveedores de servicios TIC e intercambio de información sobre ciberamenazas.
Las reglas detalladas están en normas técnicas que adopta la Comisión a propuesta de las tres Autoridades Europeas de Supervisión (AES): EBA, ESMA y EIOPA. Las que una entidad de pago o EDE encuentra con más frecuencia son las RTS sobre el marco de gestión del riesgo relacionado con las TIC (Reglamento Delegado (UE) 2024/1774), las RTS sobre la política contractual de servicios TIC (2024/1773), las ITS sobre el registro de información (Reglamento de Ejecución (UE) 2024/2956) y las RTS sobre notificación de incidentes (Reglamento Delegado (UE) 2025/301).
DORA es derecho de la UE. Una empresa británica autorizada por la FCA queda fuera y sigue en su lugar las normas de resiliencia operativa de la propia FCA, aunque un grupo británico con una filial en la UE tiene que aplicar DORA en esa filial.
¿Vas a construir un negocio con esta licencia?
Descubre lo que cubre la plataforma: las preguntas del regulador sobre TI, los rieles de pago, los proveedores y la parte técnica de tu solicitud.
- Core banking para EMI en Lituania
- Banca digital para EDE en Luxemburgo
- Banca digital para EDE en Portugal
Quién está incluido y quién tiene el régimen más ligero
El artículo 2, apartado 1, incluye a las entidades de pago y a las entidades de dinero electrónico, incluidas las exentas en virtud de PSD2 y de la Directiva de dinero electrónico. Los proveedores de servicios de información sobre cuentas figuran por separado. Dicho de otro modo, ser pequeño no le saca de DORA. Lo que cambia con el tamaño es cuánto de DORA le aplica.
| Tipo de entidad | Marco de riesgo TIC | Pruebas | Riesgo de terceros |
|---|---|---|---|
| Entidad de pago o EDE autorizada | Marco completo de los artículos 5 a 15. | Un programa de pruebas, con pruebas anuales de los sistemas que soportan funciones esenciales o importantes. | Estrategia de riesgo de terceros, registro de información, contratos del artículo 30, planes de salida. |
| Entidad de pago exenta (pequeña) según el art. 32 de PSD2 o EDE pequeña según el art. 9 de la DDE | Marco simplificado del artículo 16, desarrollado en el título III de las RTS 2024/1774. | Pruebas periódicas de los planes de continuidad y de los controles según el artículo 16. | Sin estrategia formal de riesgo de terceros, pero el registro de información y las reglas sobre contratos siguen aplicándose. |
| Microempresa (menos de 10 empleados y volumen de negocios o balance de hasta EUR 2 millones) | Marco completo, aplicado de forma proporcionada, con varias reglas específicas más ligeras. | Plan de pruebas basado en el riesgo, sin exigencia de evaluador independiente. | Las mismas obligaciones básicas. Los derechos de auditoría pueden delegarse en un tercero designado por el proveedor. |
Hay un punto que se malinterpreta a menudo. El marco simplificado del artículo 16 es para entidades exentas, las entidades de pago y EDE pequeñas registradas al amparo de las exenciones nacionales. Una EDE plenamente autorizada con cinco empleados es una microempresa, no una entidad del artículo 16, y mantiene el marco completo con proporcionalidad.
Gestión del riesgo TIC: qué debe contener el marco
El órgano de dirección es responsable del riesgo relacionado con las TIC y aprueba el marco. En la práctica, el supervisor buscará estos documentos y pruebas de que se utilizan:
- Marco de gestión del riesgo relacionado con las TIC y estrategia de resiliencia operativa digital, revisados al menos una vez al año y después de incidentes graves.
- Inventario de activos. Sistemas, datos, recursos de red y las funciones de negocio que soportan, con las funciones esenciales o importantes identificadas.
- Políticas de seguridad. Control de accesos, cifrado y gestión de claves, gestión de cambios, parches, registros, seguridad de red.
- Detección y respuesta. Cómo se detectan las anomalías, a quién se avisa y cómo se clasifica un incidente.
- Planes de continuidad de negocio y de recuperación TIC, con copias de seguridad, restauración y objetivos de tiempo de recuperación, probados según un calendario.
- Formación. Concienciación en seguridad para la plantilla y formación en resiliencia digital para la dirección.
Si opera sobre la plataforma de un proveedor, buena parte de las pruebas sobre inventario de activos, controles de seguridad y recuperación vendrá de ese proveedor. La responsabilidad no se traslada con ellas: el artículo 28, apartado 1, mantiene a la entidad financiera plenamente responsable del cumplimiento en todo momento.
Notificación de incidentes graves: los plazos
Un incidente relacionado con las TIC debe notificarse cuando cumple los criterios de incidente grave de las RTS de clasificación: clientes afectados, duración, pérdidas de datos, servicios esenciales afectados, impacto económico y extensión geográfica. Para las entidades de pago esto sustituyó al régimen de notificación de incidentes graves de PSD2: la EBA derogó sus directrices de PSD2 sobre incidentes el 17 de enero de 2025.
| Informe | Plazo según el Reglamento Delegado (UE) 2025/301 |
|---|---|
| Notificación inicial | En las 4 horas siguientes a clasificar el incidente como grave y, como máximo, 24 horas después de tener conocimiento de él. |
| Informe intermedio | En las 72 horas siguientes a la notificación inicial, aunque nada haya cambiado, y de nuevo cada vez que la situación cambie de forma significativa. |
| Informe final | Como máximo un mes después del último informe intermedio, una vez terminado el análisis de la causa raíz. |
El artículo 19 recoge dos obligaciones más. Si un incidente grave afecta a los intereses financieros de los clientes, debe informarles sin demora indebida y explicarles qué está haciendo al respecto. Además, puede externalizar la notificación en un proveedor, pero sigue siendo plenamente responsable de ella. Para una entidad que opera sobre la plataforma de un proveedor, esto significa que el contrato debe obligar al proveedor a avisarle de los incidentes con la rapidez suficiente para cumplir los límites de 4 y 24 horas.
Pruebas de resiliencia
Toda entidad de pago o EDE que no sea microempresa necesita un programa de pruebas de resiliencia operativa digital (artículo 24). El artículo 25 enumera las herramientas: análisis de vulnerabilidades, evaluaciones de seguridad de la red, revisiones del código fuente cuando sea viable, pruebas basadas en escenarios, pruebas de rendimiento y de extremo a extremo, y pruebas de penetración. Los sistemas que soportan funciones esenciales o importantes deben probarse al menos una vez al año, por evaluadores independientes de quienes los desarrollaron.
Las pruebas de penetración basadas en amenazas (TLPT) del artículo 26 son otra cosa. Solo se exigen a las entidades que identifiquen las autoridades competentes, aproximadamente cada tres años, y quedan excluidas las entidades del artículo 16 y las microempresas. La mayoría de las entidades de pago y de dinero electrónico no serán seleccionadas. Si lo es la suya, la prueba debe cubrir sistemas reales en producción, incluidos los que gestionan sus proveedores TIC, y por eso los contratos del artículo 30 incluyen la obligación de participar.
El registro de información
El artículo 28, apartado 3, obliga a toda entidad financiera, también a las pequeñas, a mantener un registro de información sobre todos los acuerdos contractuales de servicios TIC, señalando los que soportan funciones esenciales o importantes. El formato lo fija el Reglamento de Ejecución (UE) 2024/2956: un conjunto de tablas vinculadas que cubren la entidad, cada contrato, cada proveedor y sus subcontratistas, las funciones soportadas y la evaluación de cada servicio.
Fecha de referencia
A partir de 2026 el registro refleja los contratos vigentes a 31 de diciembre del año anterior.
Su plazo
Lo fija su autoridad nacional y es anterior al plazo de las AES. La CSSF de Luxemburgo, por ejemplo, recogió los registros de 2026 entre el 11 de febrero y el 31 de marzo.
Plazo de las AES
Las autoridades nacionales remiten los registros a las AES antes del 31 de marzo de cada año.
El registro no es solo un archivo anual. Su autoridad puede pedirlo en cualquier momento, y debe informarle con antelación suficiente de cualquier contrato previsto de servicios TIC que soporte una función esencial o importante. Las AES también utilizaron los registros para elegir a los proveedores que ahora supervisan directamente. Fuentes: calendario del registro según las AES, plazo de presentación de la CSSF en 2026.
Contratos con proveedores TIC y estrategias de salida
El artículo 30, apartado 2, fija el contenido mínimo de todo contrato TIC: una descripción completa de los servicios y de si se permite la subcontratación, los lugares donde se prestan los servicios y se almacenan los datos, la protección de datos, el acceso a los datos y su devolución en caso de insolvencia o resolución, los niveles de servicio, la asistencia en incidentes TIC sin coste adicional o a un precio pactado de antemano, la cooperación con sus autoridades, los derechos de resolución y la participación en su formación en seguridad.
Para los servicios que soportan funciones esenciales o importantes, el artículo 30, apartado 3, añade niveles de servicio precisos con objetivos cuantitativos, obligaciones de aviso e información, los planes de continuidad y las medidas de seguridad del propio proveedor, la participación en TLPT, derechos ilimitados de acceso, inspección y auditoría para usted y para su supervisor, y una estrategia de salida con un periodo de transición obligatorio.
La estrategia de salida es un documento suyo, no del proveedor. El artículo 28, apartado 8, le exige poder dejar a un proveedor sin interrumpir la actividad, sin incumplir la normativa y sin perjudicar a los clientes, contar con un plan de salida documentado y probado, y saber cómo pasarían los datos y los servicios a otro proveedor o a gestión interna. Para una plataforma de core banking esto supone formatos de exportación pactados para fichas de clientes, saldos e historial de operaciones, y un periodo de transición lo bastante largo para ejecutar una migración.
Proveedores terceros esenciales de servicios TIC
El 18 de noviembre de 2025 las AES publicaron la primera lista de proveedores terceros esenciales de servicios TIC (CTPP) conforme al artículo 31. Según Morgan Lewis, incluía 19 proveedores, en su mayoría grandes empresas de nube, centros de datos, redes y software empresarial. Cada uno tiene ahora un supervisor principal entre las AES con facultades directas para inspeccionarlo.
Esta supervisión no sustituye a su propio trabajo. Si su plataforma funciona sobre un gran proveedor de nube designado como CTPP, usted sigue evaluando el riesgo, mantiene las cláusulas contractuales e incluye al proveedor de nube como subcontratista en su registro. La mayoría de los proveedores de core banking no están designados, y las obligaciones de los artículos 28 a 30 se les aplican íntegramente a través de su contrato.
Qué preguntar a su proveedor de core banking
Una plataforma de core banking soporta casi todas las funciones esenciales de una entidad de pago o EDE: cuentas, pagos, datos de clientes. Antes de firmar, o antes de su próximo ciclo del registro, consiga respuestas claras a estas preguntas.
| Pregunta | Por qué importa según DORA |
|---|---|
| ¿Dónde está alojada la plataforma, dónde se almacenan los datos y quiénes son los subcontratistas? | Las ubicaciones y la subcontratación deben constar en el contrato (art. 30, apdo. 2) y en su registro. |
| ¿Con qué rapidez nos avisarán de un incidente y por qué canal? | Tiene 4 horas desde la clasificación y 24 horas desde que tiene conocimiento para presentar la notificación inicial. |
| ¿Cuáles son los niveles de servicio, en cifras? | El artículo 30, apartado 3, exige objetivos cuantitativos que pueda supervisar. |
| ¿Podemos auditarles nosotros, nuestro auditor y nuestro supervisor? | Los derechos ilimitados de acceso, inspección y auditoría son obligatorios para los servicios esenciales. |
| ¿Qué objetivos de recuperación prueban y podemos ver los resultados? | Sus planes de continuidad dependen de las copias de seguridad y de la restauración del proveedor. |
| ¿En qué formato recuperamos nuestros datos y cuánto dura el periodo de transición? | Las estrategias de salida y la devolución de datos las exigen los artículos 28, apartado 8, y 30. |
| ¿Participarán en nuestras pruebas de resiliencia? | Las pruebas, y las TLPT si le seleccionan, también cubren los sistemas externalizados. |
Cómo encaja DORA en su solicitud de licencia
DORA llegó acompañado de una directiva modificativa, la Directiva (UE) 2022/2556, que reescribió partes del artículo 5, apartado 1, de PSD2 sobre el contenido de una solicitud. El apartado de gobierno corporativo debe describir ahora sus mecanismos para el uso de servicios TIC conforme a DORA, el procedimiento de incidentes debe reflejar las obligaciones de notificación de DORA y las medidas de seguridad deben demostrar un alto nivel de resiliencia operativa digital conforme al capítulo de DORA sobre riesgo TIC. La Directiva de dinero electrónico aplica estas reglas de autorización de PSD2 también a las EDE. Un solicitante pasa a ser entidad financiera sujeta a DORA el día en que obtiene la autorización, así que el expediente debe describir un marco que funcione desde el primer día.
- Identifique sus funciones. Decida qué funciones son esenciales o importantes y qué servicios TIC las soportan.
- Prepare pronto el registro. Su plataforma principal, la nube, el proveedor de KYC, el procesador de tarjetas y el socio bancario deben figurar en él.
- Negocie las cláusulas del artículo 30 antes de firmar. Modificar contratos después de la autorización es más lento y debilita el expediente.
- Redacte el procedimiento de incidentes con plazos reales. Incluya el compromiso de aviso del proveedor.
- Prepare el plan de salida. Muestre al supervisor cómo dejaría cada proveedor esencial.
Crassula es un proveedor tecnológico, no una entidad regulada, y en la mayoría de los casos soporta funciones esenciales de sus clientes. Para la solicitud aportamos una descripción de la arquitectura de la plataforma, el alojamiento, los controles de seguridad (acceso por roles, autenticación en dos pasos, registro de auditoría) y nuestro proceso de incidentes, que usted adapta a sus propios apartados de TIC y externalización. El back office y los endpoints de informes de la plataforma le permiten exportar datos, pero clasificar incidentes, presentar notificaciones y mantener el registro siguen siendo tareas suyas. Sobre la licencia en sí, consulte nuestra guía de la licencia de entidad de pago y nuestra guía de la licencia EDE, o solicite una demo.
Preguntas frecuentes
Sí. El artículo 2 incluye a las entidades de pago y EDE exentas en virtud de PSD2 y de la Directiva de dinero electrónico. Siguen el marco simplificado de gestión del riesgo TIC del artículo 16 en lugar de los artículos 5 a 15, pero deben mantener un registro de información y cumplir las reglas sobre notificación de incidentes y contratos TIC.
Es un registro estructurado de todos sus contratos de servicios TIC, con la plantilla fijada por el Reglamento de Ejecución (UE) 2024/2956. A partir de 2026 la fecha de referencia es el 31 de diciembre del año anterior y las autoridades nacionales remiten los registros a las AES antes del 31 de marzo. Su propio plazo lo fija su autoridad nacional y es anterior.
La notificación inicial debe presentarse en las 4 horas siguientes a clasificar el incidente como grave y, como máximo, 24 horas después de tener conocimiento de él. Le sigue un informe intermedio en 72 horas y un informe final en el plazo de un mes desde el último informe intermedio.
Solo si su autoridad competente las identifica. Las entidades exentas pequeñas y las microempresas quedan totalmente excluidas. Las demás entidades de pago y EDE necesitan igualmente un programa de pruebas, con pruebas al menos anuales de los sistemas que soportan funciones esenciales o importantes.
Probablemente no. La lista de las AES de noviembre de 2025 incluye sobre todo grandes empresas de nube y tecnología. Para usted no cambia nada: un proveedor que gestiona sus funciones esenciales sigue necesitando un contrato con las cláusulas del artículo 30, apartado 3, una estrategia de salida y un lugar en su registro.
No. DORA es derecho de la UE. Una EMI o entidad de pago británica sigue las normas de resiliencia operativa de la FCA. Si además tiene una licencia en la UE a través de una filial, esa filial sí está incluida.
Informa con antelación suficiente a su autoridad del nuevo contrato para una función esencial, actualiza el registro y sigue su plan de salida respecto al proveedor anterior. Por eso DORA exige planes de salida y cláusulas de devolución de datos antes de que los necesite.
No. Crassula aporta la tecnología y la documentación para sus apartados de TIC y externalización, además de exportaciones de datos de la plataforma. La clasificación de incidentes, la notificación a su autoridad y el registro de información siguen correspondiendo a su entidad.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo