DORA para fintech e insurtech: guía práctica y checklist de 90 días
El Reglamento de Resiliencia Operativa Digital (Digital Operational Resilience Act: reglamento UE 2022/2554 sobre resiliencia operativa digital. Exige a entidades financieras de la UE resistir, responder y recuperarse de incidentes TIC. En vigor desde 17 enero 2025. Leer más → DORA) lleva en vigor desde enero de 2025 y su impacto sobre las entidades europeas sigue siendo, en muchos casos, mal comprendido. No es una norma de ciberseguridad en el sentido clásico. Es un marco de gestión del riesgo operativo que exige evidencias técnicas documentadas, no políticas de intenciones.
Para una fintech o insurtech en crecimiento, el reto no es de voluntad sino de recursos: los equipos son pequeños, el ritmo de desarrollo es alto y la deuda técnica acumulada suele estar justamente en los puntos donde DORA pone el foco. Sistemas de logging insuficientes, dependencias de terceros sin contratos de nivel de servicio adecuados, procesos de recuperación nunca probados.
Esta guía desglosa los cinco pilares de DORA, traduce cada uno a controles técnicos concretos y propone un camino de implementación realista para entidades que no tienen un equipo de compliance de quince personas. La conclusión principal: DORA es alcanzable con una arquitectura bien pensada. El problema no es el volumen de requisitos; es empezar por los que tienen mayor impacto y pueden implementarse sin paralizar el negocio.
Contexto regulatorio: qué es DORA y a quién aplica
El alcance real del reglamento
DORA (Reglamento (UE) 2022/2554) es de aplicación directa en todos los estados miembros de la Unión Europea desde el 17 de enero de 2025. A diferencia de las directivas, no requiere transposición nacional: su texto es la norma.
Aplica a una lista amplia de entidades financieras y aseguradoras: entidades de crédito, empresas de servicios de inversión, entidades de pago, entidades de dinero electrónico, proveedores de servicios de criptoactivos bajo MiCA, gestoras de fondos y plataformas de financiación alternativa, entre otras. Si una entidad está regulada por el Banco de España, la DGSFP o la CNMV en algún ramo financiero, es muy probable que DORA le aplique directamente o en un futuro muy próximo.
Proporcionalidad: modula, no exime
Las obligaciones se modulan en función del tamaño, perfil de riesgo y complejidad de la entidad, y determinadas entidades pequeñas o exentas aplican el marco simplificado de gestión del riesgo TIC del artículo 16. La proporcionalidad ajusta la profundidad de implementación exigida; no descuenta pilares.
Los cinco pilares de DORA
El reglamento se organiza en torno a cinco áreas:
- Gestión del riesgo TIC (artículos 5 a 16): marco de gobierno, identificación y clasificación de activos, controles de acceso, gestión de incidentes.
- Notificación de incidentes (artículos 17 a 23): taxonomía de incidentes y plazos estrictos: notificación inicial en menos de 4 horas desde la clasificación del incidente como grave (y máximo 24 horas desde la detección), informe intermedio en 72 horas, informe final en un mes.
- Pruebas de resiliencia (artículos 24 a 27): pruebas básicas anuales para todas las entidades; TLPT (pruebas de penetración basadas en inteligencia de amenazas) para entidades significativas cada tres años.
- Gestión del riesgo de terceros TIC (artículos 28 a 30): contratos con proveedores críticos, cláusulas de auditoría, estrategia de salida y el Registro de Información de acuerdos contractuales. Los artículos 31 a 44 son el marco de supervisión de los proveedores críticos: aplican al proveedor, no a la entidad.
- Intercambio de información (artículo 45): participación voluntaria en esquemas de intercambio de inteligencia sobre amenazas.
De pilar a control: la traducción técnica
La promesa de esta guía en una tabla: qué control técnico responde a cada pilar y qué evidencia genera ese control cuando está bien implementado. Las secciones siguientes desarrollan cada fila.
| Pilar | Control técnico | Evidencia que genera |
|---|---|---|
| Gestión del riesgo TIC (arts. 5-16) | Inventario de activos sincronizado con la infraestructura real (infrastructure as code como fuente de verdad); MFA y cuentas individuales con registro de sesión para el acceso privilegiado | Inventario versionado con histórico; registro de cada evento de autenticación y autorización |
| Notificación de incidentes (arts. 17-23) | Logging estructurado y centralizado con correlación de eventos; alertas con objetivo de respuesta inferior a 30 minutos; escalada documentada | Cronología reconstruible del incidente; cadena de custodia de logs válida ante un auditor |
| Pruebas de resiliencia (arts. 24-27) | Escaneo de vulnerabilidades programado; prueba tabletop anual; game days sobre los planes de continuidad | Informes de prueba fechados, con acciones de mejora, responsable y plazo |
| Riesgo de terceros TIC (arts. 28-30) | Registro de Información estructurado y versionado; checklist contractual aplicada en cada alta o renovación | Registro presentable al supervisor; contratos con ANS, auditoría y plan de salida |
| Intercambio de información (art. 45) | Participación en esquemas sectoriales de inteligencia de amenazas, con los feeds integrados en la detección | Reglas de detección derivadas de inteligencia compartida, con origen documentado |
Dónde falla la mayoría de fintech e insurtech en crecimiento
El patrón de riesgo que aparece de forma sistemática en entidades de tamaño medio es el siguiente: no es que desconozcan DORA; es que su arquitectura técnica y sus procesos operativos no estaban pensados con este nivel de exigencia desde el principio.
Ausencia de un inventario de activos TIC real
DORA exige identificar, clasificar y mantener actualizado un inventario de todos los activos TIC: hardware, software, datos, servicios en la nube y dependencias de terceros. La realidad habitual en una fintech o insurtech de crecimiento rápido es un inventario fragmentado: la arquitectura está en Confluence o similar, o en la mente de los ingenieros que llevan más tiempo, y cambia más rápido que cualquier documento.
Este gap no es menor. Sin un inventario preciso, es imposible hacer una evaluación de riesgo coherente ni asignar responsabilidades de control por activo.
Logging y monitorización insuficientes para la notificación de incidentes
Los plazos de DORA para la notificación de incidentes graves son estrictos: menos de 4 horas para la notificación inicial al supervisor desde la clasificación, 72 horas para el informe intermedio. Cumplir esos plazos requiere ser capaz de detectar el incidente, clasificarlo como grave y reconstruir su cronología en un tiempo muy corto. El caso práctico de un incidente DORA recorre ese reloj minuto a minuto.
La mayoría de las fintech e insurtech tienen logging de nivel aplicación, pero no siempre una correlación de eventos que permita detectar un incidente de seguridad o de disponibilidad en cuestión de minutos. Y menos aún una cadena de custodia de logs que sea válida como evidencia ante un auditor.
Dependencias de terceros no contractualizadas correctamente
Las fintech e insurtech construyen sobre pilas de servicios en la nube, APIs de terceros y proveedores de infraestructura. DORA exige que los contratos con proveedores críticos de TIC incluyan cláusulas específicas: niveles de servicio, derecho de auditoría, planes de salida, notificación de incidentes por parte del proveedor.
Los contratos estándar de los grandes proveedores cloud no incluyen estas cláusulas por defecto. Y los acuerdos con proveedores más pequeños (pasarelas de pago, proveedores de identidad, servicios de KYC) suelen ser aún más deficientes desde una perspectiva DORA.
Planes de continuidad nunca probados
DORA no solo exige tener un plan de continuidad de negocio y un plan de recuperación ante desastres: exige haberlos probado. Las pruebas deben ser periódicas, documentadas, y sus resultados deben incorporarse a las mejoras del plan. Un PDF en una carpeta compartida que nadie ha leído en dos años no es un plan de continuidad en términos DORA.
Acceso privilegiado sin control granular
El artículo 9 de DORA exige controles de acceso estrictos sobre sistemas críticos, con especial atención al acceso privilegiado. En muchas entidades el acceso a producción está gestionado de forma relativamente laxa: credenciales compartidas, ausencia de registro de sesiones de administración, tokens con permisos excesivos y sin rotación sistemática.
El enfoque: cómo construir cumplimiento DORA sin paralizarse
El cumplimiento de DORA no es un proyecto de un trimestre ni un esfuerzo puntual. Es un estado operativo sostenido. La clave para una fintech o insurtech en crecimiento es priorizar los controles de mayor impacto y construir sobre una arquitectura que genere evidencias de cumplimiento de forma nativa, sin procesos manuales adicionales.
Principio 1: la arquitectura como generador de evidencias
Un control que requiere un proceso manual para generar evidencias es un control frágil. Cuando los ingenieros están en modo de entrega, los procesos manuales se omiten o se posponen. La alternativa es diseñar la arquitectura para que las evidencias de cumplimiento sean un subproducto del funcionamiento normal del sistema.
Esto significa: logging estructurado e inmutable por defecto en todos los componentes, con retención configurable según el tipo de dato; gestión de identidad y acceso centralizada, con registro automático de cada evento de autenticación y autorización; inventario de activos TIC sincronizado con la infraestructura real (infrastructure as code como fuente de verdad), no con un documento separado.
Principio 2: Zero Trust como base del control de acceso
La arquitectura Modelo arquitectónico bajo el axioma "nunca confíes, verifica siempre". Cada acceso se verifica individualmente con identidad criptográfica, en cada interacción — sin importar si la petición viene de dentro o fuera de la red. Leer más → Zero Trust, descrita en detalle en el artículo sobre Zero Trust en banca, no es solo una mejora de seguridad: es una forma natural de cumplir los requisitos de control de acceso de DORA. Cuando cada servicio debe autenticarse antes de comunicarse con otro, cuando el acceso privilegiado requiere justificación y genera un registro de sesión, y cuando no existe una zona de confianza implícita en la red interna, los controles del artículo 9 están implementados como característica arquitectónica, no como capa adicional.
Principio 3: gestión de terceros como proceso continuo
El Registro de Información que exige DORA (artículo 28) no es un documento estático. Es un proceso de gestión que requiere: identificar los proveedores críticos de TIC, revisar los contratos vigentes contra la lista de cláusulas requeridas, negociar las adiciones necesarias y mantener el registro actualizado cuando cambian los proveedores o las condiciones.
Una entidad en crecimiento puede estructurar este proceso con un inventario de proveedores en un sistema de gestión de activos y una lista de verificación contractual aplicada en cada nueva contratación o renovación. El esfuerzo inicial es significativo; el mantenimiento continuo, si el proceso está bien diseñado, es manejable.
Principio 4: pruebas de resiliencia como hábito de ingeniería
Las pruebas de resiliencia que exige DORA se integran de forma natural en culturas de ingeniería que ya practican chaos engineering, game days o runbooks de respuesta a incidentes. Si la entidad no tiene estas prácticas, DORA es una razón estructural para adoptarlas.
Las pruebas básicas anuales incluyen: pruebas de seguridad de la red, evaluaciones de vulnerabilidades, análisis de brecha frente a los controles definidos, pruebas de los planes de continuidad. Para entidades no significativas, estas pruebas pueden ser internas con documentación adecuada.
Principio 5: un core que genera trazabilidad por diseño
El núcleo del sistema de procesamiento, ya sea propio o de terceros, es el activo TIC más crítico desde la perspectiva de DORA. La resiliencia, la trazabilidad de transacciones y la capacidad de auditoría del core no son opcionales: son requisitos regulatorios.
Los cores tradicionales de terceros ofrecen trazabilidad a nivel de negocio, pero su arquitectura de integración suele crear complejidades en la auditoría técnica de extremo a extremo. Los cores modernos con trazabilidad nativa en cada capa de proceso simplifican significativamente la generación de evidencias para DORA.
Checklist accionable: los primeros 90 días hacia DORA
El siguiente checklist está diseñado para entidades que están iniciando su proceso de cumplimiento DORA o que necesitan evaluar su posición actual. No es exhaustivo, pero cubre los controles de mayor impacto y mayor riesgo de incumplimiento en entidades de tamaño medio.
Semanas 1 a 2: inventario y clasificación
- [ ] Levantar un inventario de todos los sistemas y servicios en producción (propios y de terceros) con responsable técnico asignado.
- [ ] Clasificar cada activo según su criticidad para la continuidad del negocio (crítico, importante, auxiliar).
- [ ] Identificar las dependencias entre activos y los terceros proveedores de servicios TIC.
- [ ] Documentar qué datos procesa cada sistema y bajo qué régimen regulatorio (datos de clientes, de transacciones, de acceso).
Semanas 3 a 4: gestión de acceso privilegiado
- [ ] Auditar todos los accesos de nivel administrador a sistemas en producción.
- [ ] Eliminar credenciales compartidas y reemplazarlas por cuentas individuales con registro de actividad.
- [ ] Implementar MFA obligatorio para todo acceso a sistemas críticos.
- [ ] Establecer un proceso de rotación de secretos (API keys, tokens, contraseñas de bases de datos) con frecuencia y responsable definidos.
- [ ] Evaluar la grabación de sesiones de acceso privilegiado para los sistemas más críticos.
Semanas 5 a 6: logging y detección
- [ ] Verificar que todos los sistemas en producción generan logs estructurados con timestamp, identificador de usuario, acción y resultado.
- [ ] Centralizar los logs en un sistema con retención mínima de un año y acceso restringido y auditado.
- [ ] Definir los tipos de eventos que constituyen un incidente grave según la taxonomía de DORA.
- [ ] Establecer alertas automáticas para los eventos de mayor severidad con tiempo de respuesta objetivo inferior a 30 minutos.
- [ ] Designar un responsable de la notificación de incidentes al supervisor y documentar el proceso de escalada.
Semanas 7 a 8: contratos con terceros
- [ ] Identificar los proveedores que DORA califica como críticos (aquellos cuya interrupción impediría la prestación de servicios financieros).
- [ ] Revisar cada contrato crítico contra la lista de cláusulas requeridas por DORA (ANS, auditoría, notificación de incidentes, plan de salida).
- [ ] Iniciar negociaciones con los proveedores críticos que no cumplen los requisitos contractuales.
- [ ] Crear el Registro de Información centralizado de todos los acuerdos contractuales con terceros TIC, con fecha de revisión periódica.
Semanas 9 a 12: resiliencia y pruebas
- [ ] Documentar o actualizar el Plan de Continuidad de Negocio (BCP) y el Plan de Recuperación ante Desastres (DRP) con escenarios concretos.
- [ ] Definir los objetivos de recuperación (RTO y RPO) para cada sistema crítico.
- [ ] Planificar y ejecutar una prueba tabletop (simulación de incidente) con los equipos técnicos y de negocio relevantes.
- [ ] Documentar los resultados de la prueba y las acciones de mejora con responsable y fecha.
- [ ] Programar las pruebas de vulnerabilidades anuales requeridas por DORA.
Conclusión: DORA como ventaja competitiva, no solo como obligación
Las entidades que tratan DORA como una obligación regulatoria más tienden a implementar el mínimo suficiente para pasar una auditoría. Las que lo tratan como una oportunidad de madurez operativa tienden a construir sistemas más resilientes, con menor deuda técnica y mayor capacidad de escala.
La diferencia no es filosófica; es práctica. Una arquitectura que genera evidencias de cumplimiento de forma nativa, con gestión de acceso rigurosa, logging completo y terceros contractualizados correctamente, es también una arquitectura más fácil de operar, más fácil de depurar cuando algo falla y más fácil de escalar cuando llega el crecimiento.
Para una fintech o insurtech que aspira a crecer en el mercado europeo regulado, la pregunta no es si cumplir DORA; es cómo hacerlo de forma que refuerce la arquitectura en lugar de añadir capas de complejidad encima de una base frágil.
El checklist de los primeros 90 días es un punto de partida. La implementación completa requiere un ciclo continuo de evaluación, mejora y prueba. Lo que cambia con una arquitectura bien pensada es el coste de ese ciclo: cuando los controles son nativos, el mantenimiento del cumplimiento es una parte normal del trabajo de ingeniería, no un proyecto separado que compite por recursos con el desarrollo de producto.
Si tu fintech o insurtech está evaluando su posición frente a DORA o busca reducir la fricción entre cumplimiento y velocidad de desarrollo, BlueUP combina BlueUP Core (motor financiero en Rust con trazabilidad nativa), una arquitectura Zero Trust construida sobre OpenZiti y compliance nativo para DORA y Servicio Ejecutivo de la Comisión de Prevención del Blanqueo de Capitales e Infracciones Monetarias. Unidad de inteligencia financiera de España (FIU), receptor oficial de las comunicaciones de operativa sospechosa de las entidades obligadas.SEPBLAC. Empieza por evaluar tu madurez con la Calculadora DORA o hablemos de tu caso.
¿Quieres evaluar tu posición frente a DORA?
Evaluación inicial sin compromiso: te mostramos la plataforma configurada para tu sector con datos representativos.
Lecturas relacionadas
- DORA 2026: guía práctica para entidades financieras — El marco completo, con checklist por departamento.
- Registro de Información DORA: por qué casi nadie lo pasa a la primera — El pilar de terceros TIC en detalle: la obligación anual del artículo 28.
- Anatomía de un incidente DORA: del indicio a la notificación — El reloj de las 4 horas, recorrido minuto a minuto.
- Zero Trust en banca: por qué las VPN ya no son suficientes — La base arquitectónica del control de acceso del artículo 9.