DORA no es solo un registro gestionado por el área de riesgos. Para los equipos backend, la resiliencia se concreta en límites de servicio, dependencias visibles, cronómetros de incidentes, recuperación probada y evidencia de que el sistema se comportó según lo previsto.
La Ley de Resiliencia Operativa Digital (DORA, Reglamento UE 2022/2554) se aplica desde el 17 de enero de 2025 a las entidades financieras incluidas en su ámbito. Establece requisitos de gestión del riesgo ICT, gestión y notificación de incidentes, pruebas de resiliencia y riesgo de terceros ICT. Las obligaciones concretas dependen del tipo de entidad, la proporcionalidad y las normas técnicas aplicables. Este artículo traduce el marco a patrones de ingeniería; no es asesoramiento jurídico ni sustituye la evaluación de controles de una entidad regulada.
Una transferencia, operación o servicio de siniestros depende de más que los pods de la aplicación. Mapea identidad, secretos, DNS, API financieras, colas, bases de datos, observabilidad, plano de despliegue, regiones cloud, soporte y subcontratistas. Vincula cada dependencia con el servicio de negocio y la función crítica o importante que respalda. El nombre del proveedor no basta: registra servicio, ubicación, datos, sustituibilidad, supuestos de recuperación y responsable contractual.
El Artículo 28 de DORA exige que las entidades cubiertas mantengan un registro de información sobre acuerdos contractuales de servicios ICT, con vistas por entidad y consolidadas cuando corresponda. Sirve para supervisión y seguimiento; no debería ser una hoja de cálculo que queda obsoleta entre revisiones anuales de compras. Modela relaciones canónicas de proveedor, servicio, contrato y subcontratación; genera las plantillas regulatorias desde datos gobernados.
Ofrece a cada responsable un flujo para confirmar cambios de proveedor, alcance, ubicación de tratamiento, cadena de subcontratación, criticidad y plan de salida. Concilia compras con inventario cloud, catálogo de arquitectura, facturas, endpoints y dependencias de incidentes. Valida identificadores y campos antes de generar los envíos según las instrucciones ITS vigentes.
Ingeniería debe detectar y preservar evidencia pronto; las funciones responsables de la entidad regulada deciden la clasificación y notificación. No codifiques una decisión jurídica de gravedad en una única alerta de errores. DORA exige clasificar incidentes con criterios de impacto y notificar incidentes ICT graves según el marco aplicable. Usa plantillas y plazos actuales de la autoridad competente y normas técnicas; el proceso debe permitir evaluación por etapas y actualizaciones.
| Etapa | Acción del sistema | Evidencia que conservar |
|---|---|---|
| Detectar | Correlacionar alertas de aplicación, seguridad, infraestructura y proveedor. | Primera hora conocida, IDs de eventos y servicios afectados. |
| Delimitar | Resolver el grafo servicio-dependencia y segmentos afectados. | Transacciones, regiones, clases de datos, duración e impacto posterior. |
| Clasificar | Presentar hechos frente a criterios gobernados para revisión responsable. | Datos de clasificación, justificación, revisor y marcas de tiempo. |
| Notificar / actualizar | Preparar comunicaciones a regulador y clientes por canales aprobados. | Versiones enviadas, acuses, actualizaciones y responsables. |
| Recuperar / cerrar | Restaurar servicio, conciliar datos y verificar correcciones. | Línea temporal, impacto, causa y evidencia correctiva. |
Mantén separados los relojes: detección técnica, conocimiento organizativo, clasificación, aprobación y envío formal son marcas relacionadas, pero distintas. Usa un registro duradero con historial append-only, relojes sincronizados y control de acceso. Elimina datos personales y de pago de trazas rutinarias, conservando la evidencia forense necesaria.
DORA requiere un programa de pruebas de resiliencia digital; la combinación debe ser proporcional a la entidad y al riesgo. El reglamento contempla evaluaciones de vulnerabilidades, escenarios, pruebas end-to-end, rendimiento y penetración, entre otros métodos. También exige pruebas apropiadas al menos anualmente en los sistemas ICT que sostienen funciones críticas o importantes (Artículo 24). TLPT basado en amenazas se aplica a las entidades identificadas según el reglamento; no es un requisito anual universal para todas las empresas.
Los ejercicios backend deben incluir pérdida de dependencias, caída regional, credenciales comprometidas, acumulación de cola, corrupción de datos, rollback, recuperación ante ransomware y caída de proveedores. No pruebes solo “¿funciona el failover?”: comprueba saldos coherentes, eventos sin duplicados, permisos correctos, comunicación al cliente y estado de controles auditable.
Crearía un plano de control de resiliencia respaldado por catálogo de servicios y grafo de dependencias. Cada función crítica enlazaría API, datos, recursos cloud, proveedores, objetivos de recuperación, evidencia de pruebas y playbooks. Los eventos incluirían identificadores de servicio/dependencia para producir un mapa de impacto rápidamente. Un exportador de registros validaría los datos canónicos de proveedores según el esquema regulatorio vigente, en vez de mantener copias manuales.
En CI/CD, los cambios en dependencias críticas activarían revisión del responsable y pruebas de resiliencia específicas. El sistema de incidentes iniciaría una cronología duradera, ofrecería una ficha estructurada de impacto y prepararía borradores para aprobación humana responsable. El panel mostraría brechas de control, correcciones vencidas, cobertura de recuperación probada y concentración de terceros, no una insignia simplista de “cumplimiento DORA”.
| Fallo | Señal | Control técnico |
|---|---|---|
| El registro no coincide con producción | Aparece una API, cuenta cloud o subcontratista no catalogado durante un incidente. | Concilia contratos con inventario en ejecución y solicita confirmación del responsable. |
| Failover restaura cómputo, no estado de negocio | Transacciones duplicadas, ausentes o desordenadas tras recuperar. | Prueba replay, idempotencia, conciliación de ledger y consistencia visible al cliente. |
| La notificación empieza sin datos suficientes | El alcance y las horas se reconstruyen después desde chats. | Automatiza captura de evidencia y conserva una cronología revisable. |
| Los hallazgos de pruebas no se cierran | Problemas repetidos sin propietario o evidencia de retesteo. | Asigna plazos, escalamiento y criterios verificables de cierre. |
| La salida del proveedor solo existe en contrato | La exportación no se puede restaurar o no hay capacidad alternativa. | Ensaya salida técnica y cuantifica dependencias de transición. |
DORA convierte la resiliencia en una disciplina de ciclo de vida: conocer los servicios y proveedores que sostienen funciones importantes, detectar y clasificar incidentes con evidencia, probar la recuperación ante fallos realistas y vincular las correcciones a responsables. La ingeniería backend aporta mapas, telemetría, automatización y pruebas repetibles; gobernanza y legal determinan la interpretación y las notificaciones de cada entidad.
Nota editorial: DORA y las normas técnicas relacionadas pueden recibir complementos y aclaraciones. Este resumen de ingeniería se revisó el 28 de septiembre de 2026 y no es asesoramiento jurídico. Confirma los requisitos actuales con la autoridad competente y especialistas cualificados.