DORA (Digital Operational Resilience Act, Reglamento UE 2022/2554) es aplicable desde el 17 de enero de 2025 y se aplica directamente sin transposición nacional. Afecta a aproximadamente 22.000 entidades financieras de la UE — bancos, aseguradoras, empresas de inversión, plataformas de criptoactivos, entidades de pago — y de forma significativa también a sus proveedores TIC third-party, incluidos los proveedores SaaS de ERP/CRM. Los cinco pilares de DORA cubren la gestión del riesgo TIC, la notificación de incidentes, las pruebas de resiliencia, el riesgo de terceros y el intercambio de información. Las sanciones pueden llegar al 1 % del volumen de negocio diario durante el período de infracción.
Este artículo es parte de la serie Seguridad y compliance en cloud ERP. Explica a quiénes afecta DORA directamente, a quiénes de forma indirecta a través de la cadena de suministro, y qué requisitos concretos debe cumplir un SaaS ERP que sirva a entidades financieras reguladas.
Por qué DORA y en qué se diferencia de otras regulaciones
Antes de DORA, la resiliencia digital de las entidades financieras estaba regulada de forma fragmentada — directrices de la EBA para los bancos, de la EIOPA para las aseguradoras, de la ESMA para las empresas de inversión. DORA unifica todo esto en un único reglamento con eficacia directa en toda la UE.
Novedades clave:
- Regulación directa de los proveedores TIC third-party. Si usted es un proveedor TIC “crítico” para el sector financiero, las autoridades de la UE pueden supervisarle directamente (a través del nuevo Joint Oversight Forum).
- Pruebas de penetración basadas en amenazas (TLPT). Las grandes entidades financieras deben realizar TLPT cada 3 años.
- Notificación de incidentes estandarizada con umbrales armonizados.
- Registro de información — registro obligatorio de todos los acuerdos contractuales TIC.
DORA se diferencia de NIS2 en dos aspectos principales: es sectorial (solo financiero) y más estricta (lex specialis). Si usted es un banco, ambos regímenes le aplican, pero DORA prevalece.
A quiénes afecta DORA
Entidades directamente reguladas
DORA enumera en el art. 2 más de 20 tipos de entidades. Para el contexto europeo, las más relevantes son:
- Entidades de crédito (bancos)
- Entidades de pago e instituciones de dinero electrónico
- Empresas de servicios de inversión
- Entidades aseguradoras y reaseguradoras
- Fondos de pensiones y gestoras de activos
- Proveedores de servicios de criptoactivos (CASP según MiCA)
- Mercados de valores y depositarios centrales
- Plataformas de financiación participativa
- Auditores y asesores (parcialmente, solo notificación)
Indirectamente, a través de la cadena de suministro
DORA introduce el concepto de proveedor TIC third-party. Si presta servicios TIC a una entidad financiera — incluidos SaaS ERP, CRM, cloud hosting, email, proveedor de identidad, monitorización — su cliente le aplica los requisitos DORA a través del contrato.
Esto significa que aunque no sea un banco, si sus clientes son bancos/aseguradoras, en la práctica debe ser DORA-compliant a nivel tecnológico y documental.
Proveedores TIC críticos (CTPP)
Las autoridades de la UE (EBA, EIOPA, ESMA) designan anualmente una lista de proveedores TIC third-party críticos (CTPP) — típicamente los grandes hyperscalers (AWS, Azure, GCP) con una cuota significativa del mercado financiero. Estos están sujetos a supervisión directa de las autoridades europeas, incluidas inspecciones in situ y sanciones.
Para los proveedores de SaaS ERP para pymes es improbable que sean designados como CTPP — sin embargo, están regulados a través de sus clientes.
Los cinco pilares de DORA
Pilar 1: Marco de gestión del riesgo TIC
Marco integral con los siguientes elementos:
- Gobernanza — responsabilidad a nivel de consejo, roles definidos.
- Identificación — inventario de activos TIC, mapa de dependencias.
- Protección y prevención — políticas, controles técnicos, segmentación.
- Detección — monitorización, SIEM, detección de anomalías.
- Respuesta y recuperación — respuesta a incidentes, BCP, DRP.
- Aprendizaje y evolución — revisiones post-incidente, inteligencia sobre amenazas.
Para las pequeñas entidades financieras existe un marco simplificado, pero igualmente requiere documentación formalizada.
Pilar 2: Gestión de incidentes relacionados con TIC
Proceso estandarizado:
| Plazo | Acción |
|---|---|
| 4 horas desde la clasificación | Notificación inicial a la autoridad competente (Banco de España, BCE) |
| 72 horas | Informe intermedio |
| 1 mes | Informe final |
La clasificación de un incidente como grave se realiza según criterios como el número de clientes afectados, el daño financiero, la interrupción de servicios críticos y el alcance geográfico. Las RTS (Regulatory Technical Standards) definen exactamente los umbrales.
Pilar 3: Pruebas de resiliencia operativa digital
Dos tipos de pruebas:
- Pruebas estándar (anualmente) — evaluaciones de vulnerabilidades, revisiones de código fuente, pruebas de penetración, pruebas basadas en escenarios.
- TLPT (Threat-Led Penetration Testing) — solo para las grandes entidades, cada 3 años. Ataque red-team realista según la metodología TIBER-EU.
Los proveedores TIC utilizados por entidades reguladas deben proporcionar entornos de prueba y cooperar en las pruebas.
Pilar 4: Gestión del riesgo de terceros TIC
El pilar más complejo y ambicioso. Requiere:
- Registro de información — lista completa de todos los acuerdos TIC.
- Evaluación precontractual — due diligence antes de celebrar el contrato.
- Requisitos contractuales — cláusulas DORA explícitas en los contratos.
- Estrategias de salida — plan definido para terminar la relación con un proveedor TIC.
- Monitorización del riesgo de concentración — seguimiento de la dependencia de un único proveedor.
El contrato con el proveedor TIC debe contener según el art. 30 como mínimo:
- Descripción de servicios y SLA
- Ubicaciones del tratamiento de datos (debe ser la UE para funciones críticas)
- Estándares de seguridad
- Derecho a auditar al proveedor
- Normas de subcontratación
- Notificación de incidentes al cliente
- Plazos de terminación y soporte de salida
- Cooperación con los reguladores
- Provisiones en caso de insolvencia
Pilar 5: Intercambio de información
Voluntario, pero fomentado — las entidades financieras pueden compartir inteligencia sobre amenazas en el seno de comunidades ISAC/ISAO.
Checklist práctico para el proveedor de SaaS ERP que se dirige al sector financiero
Si desarrolla o vende ERP a bancos, aseguradoras o empresas fintech en la UE, aquí tiene el checklist de preparación para DORA:
A) Arquitectura e infraestructura
- Hosting exclusivo en la UE (sin datos fuera de la UE para funciones críticas)
- Despliegue multirregión con failover automático
- RTO < 4 horas, RPO < 1 hora (para servicios financieros críticos)
- Backups air-gapped (inmutables, resistentes a ransomware)
- Segmentación de red (producción vs. staging vs. gestión)
- Cifrado en reposo y en tránsito (AES-256, TLS 1.3)
- Módulos de Seguridad Hardware (HSM) para la gestión de claves
- Gestión de Acceso Privilegiado (PAM) para cuentas de administrador
B) Seguridad de la aplicación
- MFA obligatorio para todos los usuarios
- Soporte SSO (SAML 2.0, OIDC)
- Control de acceso basado en roles con permisos granulares
- Gestión de sesiones (timeout, reautenticación para operaciones sensibles)
- Validación de entrada y codificación de salida (OWASP Top 10)
- Seguridad de API (rate limiting, OAuth 2.0, rotación de API keys)
- Análisis de vulnerabilidades en el pipeline CI/CD
- Revisión de código fuente de forma periódica
C) Monitorización y respuesta a incidentes
- Integración SIEM (posibilidad de exportar logs para el cliente)
- Audit log para todos los cambios (inmutable, retención mín. 12 meses)
- Detección de anomalías en tiempo real
- Equipo de respuesta a incidentes 24/7 (o SLA con servicio externo)
- Notificación de incidentes al cliente en 4 horas
- Capacidad forense en el análisis post-incidente
D) Documentación y certificaciones
- Certificación ISO 27001 (mínimo)
- SOC 2 Type II (ideal para contexto US/internacional)
- Informe de prueba de penetración (anual, externo)
- DPA conforme al art. 28 del RGPD
- Plantillas contractuales DORA-compliant con cláusulas del art. 30
- Lista de subencargados con proceso de aprobación previa
- Documentación BCP y DRP (compartida con el cliente)
- Prueba DR periódica (mín. 2 veces al año, documentada)
E) Colaboración con el cliente y el regulador
- El cliente tiene derecho a auditar (contractualmente establecido)
- Cooperación con TLPT — entornos de prueba, colaboración con el red team
- Soporte de salida — exportación de datos, transferencia de conocimiento (SLA definido)
- Cooperación con los reguladores — preparación para solicitudes directas de EBA/ESMA
- Provisiones de insolvencia — continuidad del servicio en caso de insolvencia del proveedor
Modulario y DORA
Modulario no está orientado principalmente a entidades financieras reguladas (bancos, aseguradoras) — el foco está en las pymes de sectores no financieros (fabricación, servicios, comercio minorista, transporte, construcción). Sin embargo, en el segmento de fintech, servicios de pago y asesoramiento financiero proporcionamos implantaciones que deben ser DORA-compatibles.
Nuestras capacidades relevantes para DORA:
- Hosting exclusivo en la UE (Frankfurt + Praga, multirregión)
- Certificación ISO 27001 desde 2024
- Audit log en cada módulo
- DPA estandarizado + lista pública de subencargados
- Soporte MFA / SSO (TOTP, WebAuthn, SAML, OIDC)
- Seguridad de API con OAuth 2.0 y rate limiting
- BCP/DRP con RTO < 8h y RPO < 1h (para despliegues estándar; para despliegues DORA-críticos, SLA más cortos bajo petición)
- Soporte de salida — exportación completa de datos en formatos estándar (CSV, JSON, API)
Para entidades reguladas proporcionamos plantillas contractuales DORA-compliant y SLA específicos. Más detalles en la página de Seguridad y en el artículo pilar de seguridad cloud ERP.
Sanciones y responsabilidad personal
DORA no establece un máximo fijo en una sola cifra (a diferencia del RGPD), sino que otorga a los reguladores el derecho a imponer:
- Pagos de sanción periódicos — hasta el 1 % del volumen de negocio diario mundial durante el período de infracción (máx. 6 meses).
- Sanciones administrativas según la legislación nacional.
- Amonestaciones públicas — identificación pública.
- Retirada de la autorización — revocación de la licencia para infracciones graves.
Para los proveedores TIC third-party críticos (CTPP), la ESA puede imponer pagos de sanción periódicos de hasta el 1 % del volumen de negocio diario directamente, sin la mediación del regulador nacional.
Responsabilidad personal: el equipo directivo de la entidad financiera asume la responsabilidad última del cumplimiento de DORA.
Relación entre DORA, NIS2 y RGPD
| Aspecto | DORA | NIS2 | RGPD |
|---|---|---|---|
| Tipo | Reglamento | Directiva | Reglamento |
| Sector | Financiero | 18 sectores | Todos |
| Lex specialis | Sí (para el financiero) | No | No |
| Eficacia directa | Sí | No (transposición) | Sí |
| Terceros TIC | Supervisión directa | A través de la cadena | A través de DPA |
| Plazos de notificación | 4h / 72h / 1 mes | 24h / 72h / 1 mes | 72h |
| Sanciones máximas | 1 % del vol. de negocio diario | 10 M EUR / 2 % | 20 M EUR / 4 % |
Un banco de la UE está sujeto a los tres simultáneamente. DORA es el primero para operaciones TIC, NIS2 para el marco cibernético más amplio, y RGPD para los datos personales de los clientes.
Preguntas frecuentes
Somos una pequeña fintech con 8 empleados que ofrecemos servicios de pago. ¿Nos afecta DORA? Sí. DORA no establece umbrales de tamaño tan estrictos como NIS2. Las entidades de pago están explícitamente incluidas en el art. 2. Para las entidades pequeñas existe un marco simplificado (proporcionalidad), pero los requisitos básicos son aplicables. Planifique al menos 2-4 meses para el proceso de compliance.
Nuestro proveedor de ERP no es DORA-compliant. ¿Podemos seguir usándolo? Para funciones no críticas sí, para las críticas no. DORA exige que clasifique las funciones TIC según su criticidad y que para las críticas utilice únicamente proveedores que cumplan los requisitos DORA. Si su ERP contiene datos de core banking o procesamiento de pagos en tiempo real, debe ser DORA-ready.
¿Cuál es la diferencia entre DORA y TIBER-EU? TIBER-EU es el marco de pruebas de penetración basadas en amenazas desarrollado por el BCE, utilizado antes de DORA de forma voluntaria. Las TLPT de DORA (art. 26) lo adoptaron como metodología de referencia y lo hicieron obligatorio para las grandes entidades financieras. Los reguladores europeos utilizan variantes adaptadas a sus jurisdicciones.
¿Con qué frecuencia debo actualizar el registro de contratos TIC? El registro de información (RoI) debe actualizarse de forma continua (con cada cambio en un contrato) y reportarse al regulador nacional en formato estandarizado al menos una vez al año. Las RTS definen el formato exacto (XBRL).