DORA para proveedores de infraestructura: lo que realmente exige
DORA no es una lista de verificación de cumplimiento. Es una especificación de sistemas con implicaciones arquitectónicas para determinismo, trazabilidad y resiliencia.
DORA para Proveedores de Infraestructura Financiera: Lo Que Realmente Necesita Construir
Los equipos de compliance escriben políticas. Los equipos de ingeniería construyen sistemas. En la mayoría de las fintechs, ambos producen documentos separados, presentan a audiencias separadas, y rara vez se reconcilian. DORA fuerza la reconciliación.
La Ley de Resiliencia Operativa Digital (Reglamento 2022/2554) está en vigor desde el 17 de enero de 2025. Se aplica a entidades financieras en toda la UE, bancos, instituciones de pago, instituciones de dinero electrónico, firmas de inversión. Pero también alcanza a sus proveedores de tecnología. El Artículo 15 establece requisitos de supervisión para "proveedores de servicios TIC terceros críticos." Si usted construye infraestructura de la que dependen entidades reguladas, está dentro del alcance. No como algo deseable. Como una expectativa regulatoria que sus clientes deben hacer cumplir.
La mayoría de las fintechs leen DORA como un ejercicio de políticas: actualizar el registro de riesgos, añadir una sección a la narrativa de SOC 2, capacitar al equipo. Eso pierde el punto. DORA es una especificación de sistemas. Define propiedades arquitectónicas que su tecnología debe exhibir. Las políticas describen intención. La arquitectura entrega capacidad.
Cinco Requisitos Arquitectónicos Que la Mayoría de las Fintechs Pasan por Alto
DORA abarca 64 artículos en 9 capítulos. No todos tienen implicaciones arquitectónicas. Cinco sí.
1. Sistemas Deterministas (Art. 5-6: Gestión de Riesgo TIC)
DORA requiere que las entidades financieras "identifiquen, clasifiquen y documenten adecuadamente todas las funciones de negocio soportadas por TIC" y mantengan sistemas que sean "fiables y resilientes." En términos de ingeniería: su sistema debe comportarse predeciblemente bajo todas las condiciones, incluyendo fallos.
Lo que esto significa para la arquitectura:
- Sin pausas de recolección de basura durante ventanas de settlement. Un evento stop-the-world del GC durante un lote de pagos es un fallo no determinista que el marco de riesgos de DORA le requiere evaluar y mitigar.
- Caminos de código auditables. Un auditor externo debe poder rastrear una transacción específica desde la ingesta de API hasta el commitment en el ledger. Si el camino depende de condiciones de runtime que no se registran, el sistema no está adecuadamente documentado.
- Presupuestos de recursos estáticos. Uso de memoria, pools de hilos, límites de conexiones, todos acotados y predecibles al inicio. Un crash por falta de memoria durante carga pico es un fallo de resiliencia.
Nada de esto requiere una tecnología específica. Requieren disciplina arquitectónica. Un sistema construido en cualquier lenguaje puede satisfacer estos requisitos, si el equipo diseña para ellos explícitamente.
2. Superficie de Ataque Mínima (Art. 9: Protección y Prevención)
El Artículo 9 requiere "medidas de protección y prevención" incluyendo "la seguridad de los sistemas de redes e información." La medida de protección más efectiva en software no es un firewall ni una librería de cifrado. Es un árbol de dependencias pequeño.
Cada dependencia externa es un vector de ataque potencial. El ecosistema npm lo ha demostrado repetidamente: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022). Cada incidente fue un ataque a la cadena de suministro que afectó a miles de proyectos downstream.
La comparación de dependencias es contundente:
| Stack | Deps externas | Deps transitivas | Esfuerzo de auditoría |
|---|---|---|---|
| Servicio Node.js típico | 80-200 | 1,000-5,000+ | Muy alto, prácticamente imposible auditar cada paquete |
| Servicio Go | 20-50 | 50-150 | Moderado, manejable con herramientas |
| Servicio Rust | 15-40 | 50-120 | Moderado, cargo-audit cubre CVEs conocidos |
| Servicio Zig | 5-15 | 15-30 | Bajo, cada dependencia puede revisarse individualmente |
DORA no obliga un lenguaje específico. Obliga a que pueda evaluar su riesgo de cadena de suministro. Si su conteo de dependencias transitivas es 5,000, no puede afirmar honestamente haberlo evaluado. El esfuerzo de auditoría excede lo que cualquier equipo puede sostener.
Recomendación concreta: cuente sus dependencias transitivas. Ejecute npm ls | wc -l o el equivalente para su stack. Si el número excede lo que su equipo de seguridad puede revisar anualmente, tiene una exposición bajo DORA Art. 9.
3. Trazabilidad Completa (Art. 11-12: Respuesta y Recuperación)
Los Artículos 11 y 12 requieren "gestión estricta de incidentes relacionados con TIC" con "planes de respuesta y recuperación." Esto no se trata de tener un runbook. Se trata de trazabilidad arquitectónica: la capacidad de reconstruir el historial completo de cualquier operación después de un fallo.
Lo que requiere la trazabilidad:
- IDs de correlación. Cada operación que cambia estado lleva un identificador único que se propaga a través de cada servicio que toca. Un auditor puede rastrear un pago desde el inicio hasta el settlement, o hasta la compensación, desde un solo ID.
- Ejecución journalizada. Cada paso de un proceso multi-paso se registra antes de la ejecución. Si el proceso se interrumpe (crash, timeout, caída de proveedor), el journal indica exactamente dónde se detuvo y qué ya se ha committeado.
- Recuperación determinista. "Recuperación" significa reanudar desde el punto exacto de interrupción, no reintentar desde el principio, no reproducir con efectos secundarios potencialmente diferentes. El journal es el mecanismo de recuperación.
Los motores de ejecución durable proporcionan las tres propiedades arquitectónicamente. El journal del workflow ES la trilha de auditoría. El ID de correlación ES el ID del workflow. La recuperación ES la reproducción del journal. No se atornilla trazabilidad al sistema después del hecho, el modelo de ejecución la produce como subproducto.
Las alternativas tradicionales, colas de reintento, dead-letter queues, eventos de compensación saga, pueden lograr resultados similares, pero la trazabilidad debe ingeniarse por separado. El journal es implícito en ejecución durable; es explícito (y a menudo incompleto) en arquitecturas dirigidas por eventos.
4. Evaluación de Riesgo de Terceros (Art. 15: Riesgo TIC de Terceros)
El Artículo 15 requiere que las entidades financieras evalúen y monitoreen los riesgos que presentan sus proveedores de TIC terceros. Esta obligación fluye downstream: sus clientes deben evaluarlo a usted, y usted debe ser evaluable.
Ser evaluable significa:
- Inventario de dependencias publicado. No "usamos herramientas estándar de la industria." Una lista concreta: estas son nuestras dependencias, estas son sus versiones, este es el grafo transitivo.
- Mecanismos de recuperación documentados. Si su servicio se cae, ¿qué pasa con las transacciones en vuelo? ¿Se pierden? ¿Se reintentan? ¿Se encolan durablemente? La respuesta debe ser arquitectónica, no aspiracional.
- Evidencia de respuesta a incidentes. No un documento de políticas que diga "responderemos dentro de 4 horas." Evidencia de que su sistema detecta, registra y permite la investigación de incidentes operativos. Logs de auditoría con hash SHA-256 encadenado que no pueden modificarse retroactivamente son una señal fuerte.
La posición más fuerte: haga fácil su evaluación. Publique su conteo de dependencias. Documente su arquitectura. Muestre su formato de trilha de auditoría. Cuanto más rápido el equipo de compliance de un cliente pueda evaluarlo, más rápido cierra el negocio.
5. Resiliencia Comprobable (Art. 24-27: Pruebas de Resiliencia)
Los Artículos 24 a 27 requieren "pruebas de resiliencia operativa digital" incluyendo, para entidades financieras significativas, "pruebas de penetración guiadas por amenazas." Para proveedores de infraestructura, la implicación es: su sistema debe ser comprobable bajo condiciones de fallo.
Esto va más allá de tests unitarios y tests de integración. Las pruebas de resiliencia alineadas con DORA significan:
- Escenarios de fallo reproducibles. ¿Puede simular un fallo de base de datos, una partición de red, un timeout de proveedor, y verificar que el sistema se comporta correctamente? Si el escenario de fallo no es reproducible, la prueba no es significativa.
- Simulación determinista. El estándar de oro: inyectar miles de combinaciones de fallos (crashes, particiones, desfase de reloj, corrupción de disco) en un entorno simulado y verificar la corrección. Si el sistema es determinista, cada ejecución de simulación produce resultados idénticos para la misma semilla, haciendo los bugs reproducibles y corregibles.
- Verificación continua. La resiliencia no es un ejercicio trimestral. El sistema debería probarse continuamente bajo condiciones de fallo como parte del pipeline CI/CD. Cada release se valida contra los mismos escenarios de fallo.
Pocas organizaciones logran pruebas de simulación determinista. Pero la dirección es clara: DORA recompensa arquitecturas que son inherentemente comprobables, deterministas, reproducibles y susceptibles a inyección automatizada de fallos.
Lo Que "Compatible con DORA" Realmente Significa
Un proveedor de tecnología no puede afirmar "compatible con DORA." DORA se aplica a entidades financieras reguladas y su supervisión de proveedores TIC. No existe certificación DORA para productos de software.
Lo que puede hacer:
- Demostrar alineación arquitectónica. Mostrar que su diseño aborda los artículos listados arriba. Mapear sus decisiones de arquitectura a requisitos específicos de DORA. Esto es lo que los equipos de compliance de sus clientes necesitan durante la evaluación de proveedores.
- Publicar su evidencia. Inventario de dependencias. Mecanismos de recuperación. Formato de trilha de auditoría. Metodología de pruebas de resiliencia. Haga esto disponible en un centro de confianza o página de documentación de seguridad, no detrás de una llamada comercial.
- Usar lenguaje honesto. "Diseñado para alineación con DORA" es defendible. "Compatible con DORA" no lo es. "Arquitectónicamente alineado con DORA Art. 11-12" es preciso. "Cumple todos los requisitos de DORA" es una afirmación que no puede hacer.
La honestidad es la señal de confianza. Un proveedor que reconoce lo que DORA requiere y demuestra cómo su arquitectura lo aborda, sin exagerar, es más creíble que uno que estampa "compatible con DORA" en una landing page.
La infraestructura financiera es un negocio de confianza. Las regulaciones existen porque la confianza debe ser verificable. Construya sistemas que sean verificables por construcción. Documente lo que ha construido. Deje que la arquitectura hable por sí misma.
Leer más: Seguridad y Compliance | Workflows, Motor de Ejecución Durable
Fuentes:
- DORA, Reglamento (UE) 2022/2554, Art. 5-6 (Gestión de Riesgo TIC), Art. 9 (Protección y Prevención), Art. 11-12 (Respuesta y Recuperación), Art. 15 (Riesgo de Terceros), Art. 24-27 (Pruebas de Resiliencia)
- EUR-Lex: 2022/2554
- Incidentes de cadena de suministro npm: left-pad (2016), event-stream (2018), ua-parser-js (2021), colors.js (2022)