DORA se lee como una ley. Lo que audita es tu arquitectura.
Desde el 17 de enero de 2025, la UE califica el software financiero igual que lo haría un SRE: no por si falla, sino por cómo se comporta mientras falla. El reglamento es DORA — el Reglamento de Resiliencia Operativa Digital, Reglamento (UE) 2022/2554 — y, año y medio después, sigo encontrando equipos de ingeniería fintech que lo tratan como un documento que pertenece a su asesoría jurídica y del que ya les informarán en algún momento.
Antes de nada, una colisión de nombres que los buscadores no van a resolver por ti: este DORA no es DevOps Research and Assessment. Si venías buscando frecuencia de despliegue y lead time, mi reseña de Accelerate cubre esas cuatro métricas; este DORA viene con supervisores incluidos.
También conviene decir qué soy y qué no soy. No soy abogado, y nada de esto es asesoramiento jurídico. Llevo dos décadas en operaciones enterprise, años de ellos en salas de crisis a escala Clarivate, y DORA es la primera pieza de regulación financiera que leo que parece escrita por alguien a quien han despertado los avisos a las 3 de la madrugada. Desde ahí escribo este post: desde el lado del ingeniero que tiene que construir bajo las reglas y las lee como si fueran una especificación.
El reglamento asume que tu sistema fallará — y lo que puntúa es la respuesta
DORA se apoya en cinco pilares: un marco de gestión del riesgo TIC (artículos 5–16), clasificación y notificación de incidentes (17–23), pruebas de resiliencia (24–27), riesgo de terceros TIC (28–30) e intercambio de información. Si le quitas el andamiaje jurídico, el capítulo II es un manual de SRE: identificar, proteger, detectar, responder, recuperar, aprender. La premisa que sostiene los cinco pilares es la que la gente de operaciones interiorizó hace años: el fallo es una propiedad del sistema, no una anomalía. Lo que añade el reglamento es que tu respuesta al fallo ahora tiene que ser legible desde fuera: documentada, cronometrada y reproducible cuando te la pidan.
Todo el cambio está en esa palabra: legible. La mayoría de los equipos de ingeniería ya hace alguna versión de este trabajo. Pocos pueden demostrarlo al ritmo que marca el calendario de un supervisor.
Un reloj de 4 horas es un requisito de observabilidad disfrazado de artículo
La notificación de un incidente grave se rige por tres relojes: una notificación inicial en las 4 horas siguientes a clasificar el incidente como grave (y nunca más de 24 horas desde la detección), un informe intermedio a las 72 horas y un informe final en el plazo de un mes.
Léelo como ingeniero y la dependencia salta a la vista: no puedes clasificar un incidente en horas si la clasificación es un juicio que se toma en una reunión. Los criterios de clasificación de DORA — clientes y contrapartes afectados, duración y caída del servicio, alcance geográfico, pérdida de datos, criticidad de los servicios — tienen que poder calcularse, lo que significa que tu monitorización ya sabe a cuántos clientes toca una caída y tu tooling de incidentes puede producir ese número con el incidente todavía abierto. Una hoja de cálculo y una revisión los martes no sostienen un reloj de 4 horas. La instrumentación, sí.
Hay una sutileza que merece ingeniería propia: el reloj de 4 horas arranca en la clasificación, no en la detección. Un proceso de clasificación difuso no te hace ganar tiempo — solo traslada el riesgo a una discusión con el supervisor sobre cuándo deberías haber clasificado. Los equipos que lo tienen resuelto tratan los umbrales de severidad como umbrales de alerta: definidos de antemano, evaluados por máquinas y escalados a humanos para confirmar, no para debatir.
Y el informe va a tu autoridad nacional competente en su plantilla, no a un buzón en prosa. Suena trivial hasta que has intentado rellenar una plantilla regulatoria estructurada en la hora tres de una caída, con las personas que saben las respuestas ocupadas arreglando la caída. La solución es la misma que usamos para las status pages: el registro del incidente es la fuente de datos del informe, y la presentación la lleva alguien que no está en la sala de crisis. Decidir eso durante el incidente es la manera de perder una hora de las cuatro que te dieron.
Alguien atacará tu sistema de producción, con permiso
El tercer pilar incluye las pruebas de penetración guiadas por amenazas (TLPT) para las entidades que superan el umbral: un red team, alineado con el marco TIBER-EU, atacando producción en vivo, aproximadamente cada tres años.
Ahí se acaba la cultura del pentest solo-en-staging. Cuando el objetivo del test es producción, cada ficción cómoda pasa a poder comprobarse: la segmentación de red que existe en el diagrama, la cuenta break-glass que nadie ha rotado, la regla de detección que dispara en staging porque allí apenas hay ruido de fondo. He visto incidentes de producción destapar las tres; lo que hace el TLPT es adelantar ese descubrimiento a un momento en el que todavía te lo puedes permitir.
Tu lista de proveedores se ha convertido en un artefacto regulado
El pilar con más consecuencias cotidianas para cómo construyes es el riesgo de terceros. Cada acuerdo TIC entra en un registro de información: qué función soporta, cómo de crítica es esa función, si el proveedor es sustituible y a quién subcontratan ellos. Ese último campo es el que sorprende a los equipos de ingeniería — el registro quiere la cadena, no el primer eslabón. Tu base de datos gestionada corre sobre un hyperscaler; tu API de scoring de fraude llama a un proveedor de modelos; el registro espera que lo sepas, y los supervisores llevan recogiendo estos registros de las entidades financieras desde 2025. En la práctica es un grafo de dependencias — el mismo artefacto que construirías para revisar la disponibilidad a fondo, y esa es la idea. Los contratos con proveedores críticos deben incluir derechos de auditoría, niveles de servicio, asistencia a la terminación y una estrategia de salida probada (artículo 28). Los supervisores pueden hacer, y hacen, la pregunta de concentración: ¿qué te pasa si esta región cloud, o este proveedor, tiene un mal día? La caída de CrowdStrike de julio de 2024 — 8,5 millones de sistemas fuera de servicio por la actualización de un solo proveedor — es el caso práctico que los reguladores ya no necesitan imaginar.
Aquí es también donde aparece un partner de ingeniería externo, y declaro el interés sin rodeos: Conectia integra ingenieros en clientes regulados, así que somos una entrada en registros como estos. Un engagement con una fintech tiene que encajar en este pilar desde el primer día — quién tiene qué acceso, bajo qué contrato y qué produce la salida. Es parte de por qué nuestros engagements terminan con un handover documentado y un borrado seguro: cada credencial, buzón y acceso a repositorio contabilizado y cerrado. En un contexto DORA eso no es cortesía. Es la evidencia a la que apunta tu registro cuando alguien audita la salida.
El contraargumento honesto: cumplir no es ser resiliente
Ahora la concesión, porque es real: puedes cumplir DORA sobre el papel y seguir siendo frágil. Un registro puede estar completo y desactualizado. Un plan de salida probado puede haberse probado contra la arquitectura del año pasado. La proporcionalidad (artículo 4) implica que una fintech de 20 personas no va a correr ejercicios TIBER-EU, y el incidente que te tumbe puede llegar igualmente a través de un proveedor que cumple — entre las víctimas de CrowdStrike había instituciones con el papeleo impecable.
¿Por qué lo defiendo entonces? Porque DORA hace que el trabajo de resiliencia sea financiable. Todos los ingenieros de operaciones hemos perdido la discusión de presupuesto por la observabilidad, por una segunda región, por la auditoría de desaprovisionamiento — trabajo que no lleva ninguna feature asociada. DORA te ahorra esa discusión: el consejo que no financiaba el tooling de incidentes como higiene de ingeniería lo financiará como plazo regulatorio, y el trabajo es idéntico. Aprovecha el presupuesto.
Qué haría este trimestre si dirigiera ingeniería en una fintech
- Conecta los criterios de clasificación a la monitorización. Clientes afectados, downtime, pérdida de datos: campos calculados en el registro del incidente, no prosa escrita después.
- Haz un simulacro de notificación. Coge un sev-1 pasado, reprodúcelo contra los relojes de 4h / 72h / 1 mes con la plantilla real de reporte y cronometra cada paso. Los huecos que encuentres son tu backlog.
- Construye el registro como datos, no como documento. Un inventario de proveedores en control de versiones, con campos de responsable, criticidad y subcontratistas, revisado con cadencia — el registro desactualizado es el modo de fallo.
- Pide a cada proveedor crítico que te cuente su salida, paso a paso. Y ejecuta una de verdad: restaura el backup, exporta los datos, reconstruye el pipeline. Una estrategia de salida que nunca se ha ejecutado es una hipótesis.
- Haz que el offboarding produzca evidencia. Cada salida — empleado o externo — debería cerrarse con una checklist de accesos que alguien firma. Es en los finales donde mueren los audit trails.
Dieciocho meses después de DORA, los equipos que sufren son sobre todo los que siguen traduciéndolo de legal a ingeniería, memorando a memorando. Léelo tú mismo, una vez, con ojos de operador. Se lee como una ley. Lo que audita es tu arquitectura.
Si tienes por delante trabajo de resiliencia con plazos regulatorios y quieres ingenieros que ya han operado bajo auditoría, habla con un CTO.
