Desde el 17 de enero de 2025, la resiliencia operativa digital ya no es una aspiración para el sector financiero europeo.
El problema no es conocer las siglas. Es conectar las obligaciones con el entorno real.
La entidad, sus funciones críticas o importantes y las dependencias TIC que soportan el negocio.
La continuidad entre riesgo, incidente, proveedor, contrato, prueba y evidencia.
Que cada obligación tiene propietario, proceso operativo y registros recuperables.
| Clave | Qué revisar | Qué debería demostrar |
|---|---|---|
| AL-01 | Entidad y base de aplicabilidad | Categoría jurídica, exclusiones y criterio documentado. |
| AL-02 | Funciones críticas o importantes | Relación entre servicio de negocio, impacto y dependencia TIC. |
| AL-03 | Marco de riesgo TIC | Políticas, roles, responsabilidades, revisión y mejora. |
| AL-04 | Terceros TIC | Contratos, concentración, subcontratación y estrategia de salida. |
| AL-05 | Incidentes y pruebas | Capacidad de clasificar, reportar, aprender y probar resiliencia. |
| Ref. | Evidencia | Qué debería demostrar |
|---|---|---|
| DO-01 | Análisis de aplicabilidad | Qué entidades y servicios están en alcance y por qué. |
| DO-02 | Mapa de funciones y dependencias | Qué tecnología y terceros sostienen funciones críticas o importantes. |
| DO-03 | Marco de gestión del riesgo TIC | Gobierno, políticas, responsabilidades y revisión. |
| DO-04 | Inventario de obligaciones operativas | Incidentes, pruebas, terceros y reporting con propietario. |
| DO-05 | Plan de brechas priorizado | Qué falta, qué riesgo mantiene y qué evidencia cerrará la desviación. |
| DO-06 | Reporting a dirección | Que la supervisión del marco se apoya en información concreta. |
Determinar que una entidad está incluida en DORA no resuelve el trabajo. El siguiente paso es traducir esa conclusión jurídica a un mapa operativo: qué sociedades están afectadas, qué funciones críticas o importantes presta cada una, qué servicios TIC las soportan y qué terceros participan en su prestación. Sin esa cadena, el programa acaba convertido en una colección de políticas sin relación clara con la arquitectura que debe proteger.
Yo construiría el alcance en cuatro capas. La primera es la entidad regulada y su base de aplicabilidad. La segunda son los servicios de negocio, procesos y funciones críticas o importantes. La tercera son los activos, aplicaciones, datos, identidades e infraestructuras que soportan esas funciones. La cuarta son los proveedores TIC, subcontratistas y localizaciones desde las que se presta el servicio. Cada obligación de DORA debería poder trazarse hasta una o varias de esas capas.
Esta trazabilidad evita dos errores habituales. El primero es aplicar el reglamento únicamente al departamento de tecnología, dejando fuera decisiones de contratación, continuidad, negocio o cumplimiento. El segundo es declarar que toda la organización está en alcance sin distinguir criticidades, lo que produce controles homogéneos, documentación excesiva y poca capacidad para priorizar.
| Capa | Pregunta de control | Evidencia útil |
|---|---|---|
| Entidad | ¿Cuál es la categoría regulatoria y qué criterio determina la aplicabilidad? | Informe jurídico, mapa societario y decisión formal de alcance. |
| Función | ¿Qué actividad no puede degradarse sin afectar clientes, mercado u obligaciones? | Catálogo de servicios, BIA y criterios de función crítica o importante. |
| Tecnología | ¿Qué aplicaciones, datos, identidades e infraestructura soportan la función? | CMDB, diagramas de arquitectura y relaciones servicio-activo. |
| Terceros | ¿Qué proveedor o subcontratista participa y qué dependencia introduce? | Registro de Información, contratos, SLA y cadena de subcontratación. |
Imaginemos una entidad que presta un servicio de pagos mediante una aplicación web alojada en cloud. El inventario inicial incluye la aplicación y la base de datos, pero omite el proveedor de identidad, el servicio DNS, el sistema antifraude, la pasarela de mensajería, la herramienta de monitorización y el equipo externo que opera el entorno. Desde una lectura superficial, el alcance parece controlado; desde una lectura DORA, existen varias dependencias que pueden interrumpir la función o impedir su recuperación.
El análisis debería documentar al menos: flujo de autenticación, regiones cloud, repositorios de código, pipelines de despliegue, secretos, copias, telemetría, comunicaciones con terceros, procedimientos de recuperación y responsables de decisión. También debería identificar qué ocurre si falla cada componente, cuánto tiempo puede mantenerse el servicio, qué alternativa existe y quién puede autorizar una degradación controlada.
El resultado no es un diagrama bonito. Es una base para clasificar incidentes, diseñar pruebas, revisar contratos, justificar RTO y RPO y demostrar que el órgano de dirección conoce las dependencias que pueden afectar a la resiliencia operativa digital.
Lo demuestra cuando puede conectar una obligación regulatoria con una función de negocio, una dependencia TIC, un responsable, una prueba y una evidencia verificable.
1. Coherencia societaria. La entidad incluida en el análisis debe coincidir con la que presta el servicio, firma contratos y responde ante el supervisor. Los grupos complejos suelen mezclar sociedades reguladas, prestadores internos y centros de servicio compartido.
2. Funciones críticas o importantes. La clasificación debe tener criterio, propietario y evidencia. No debería depender de una etiqueta heredada en una hoja de cálculo.
3. Dependencias tecnológicas. El inventario debe cubrir identidades, comunicaciones, datos, integraciones, operación y recuperación, no solo servidores y aplicaciones.
4. Terceros y subcontratación. Hay que identificar quién presta realmente cada componente y qué partes de la cadena no controla directamente la entidad.
5. Cambios. El alcance debe actualizarse cuando cambia una función, se incorpora una plataforma, se externaliza un servicio o se reorganiza el grupo. Un alcance correcto en enero puede quedar obsoleto en junio.
La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.
En DORA: qué exige y a quién aplica de verdad, el análisis debería cubrir al menos servicios financieros, acuerdos contractuales, funciones TIC, proveedores directos, subcontratistas, países de prestación, criticidad y dependencia. Esto exige coordinar a Dirección, Riesgo TIC, Continuidad, Seguridad, Operaciones, Compras, Legal y propietarios del servicio y trabajar sobre servicios, funciones TIC, contratos, proveedores, subcontratistas, ubicaciones, datos, dependencias y estrategias de salida. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.
Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.
Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.
La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.
| Dimensión | Qué debe quedar definido | Evidencia esperada |
|---|---|---|
| Alcance | Procesos, servicios, sistemas y terceros incluidos en «DORA: qué exige y a quién aplica de verdad». | Alcance aprobado, inventario y exclusiones justificadas. |
| Responsabilidad | Quién decide, ejecuta, valida y acepta desviaciones. | RACI, actas, aprobaciones y propietarios nominativos. |
| Operación | Actividades repetibles, entradas, salidas, plazos y escalados. | Procedimiento, tickets, registros, alertas y métricas. |
| Eficacia | Cómo se comprueba que el control cambia el riesgo o el resultado. | Pruebas, tendencias, incidencias, muestreo y acciones. |
Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.
El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.