Resiliencia operativa · Gestión de riesgos TIC · Servicios financieros
El Reglamento de Resiliencia Operativa Digital (DORA), Reglamento (UE) 2022/2554, se ha aplicado a las entidades financieras de la Unión Europea desde el 17 de enero de 2025. Entre sus objetivos centrales está el requisito de que las empresas detecten incidentes TIC (tecnologías de la información y comunicaciones) de manera rápida y mantengan la disponibilidad de los servicios que apoyan funciones críticas o importantes.
Cumplir ese objetivo requiere un monitoreo que refleje la disponibilidad real de los servicios orientados al cliente, no solo la salud interna de los sistemas detrás de ellos. Las herramientas internas de observabilidad reportan sobre la infraestructura desde dentro de la red corporativa. No confirman si un servicio es accesible y funcional desde la posición de un usuario externo. El monitoreo sintético externo aborda esto ejecutando transacciones programadas contra servicios en producción desde ubicaciones fuera de la red, con un horario definido.
Este artículo identifica las obligaciones específicas de DORA que inciden en el monitoreo continuo y la detección, y expone cómo el monitoreo sintético externo, y la plataforma Dotcom-Monitor en particular, abordan cada una de ellas.
Obligaciones de Detección y Disponibilidad de DORA
DORA se basa en resultados en lugar de prescribir herramientas específicas. No obliga a un producto de monitoreo específico ni a una frecuencia fija de comprobaciones. Establece obligaciones para la detección, la disponibilidad y la supervisión, y el monitoreo es el control operativo a través del cual se cumplen varias de esas obligaciones. Cuatro disposiciones son las más relevantes.
Artículo 9 (Protección y Prevención) requiere que las entidades financieras monitoreen y controlen continuamente la seguridad y funcionamiento de los sistemas y herramientas TIC. La obligación es continua, lo que excluye que las comprobaciones periódicas o manuales sean un control suficiente por sí solas.
Artículo 10 (Detección) exige mecanismos para detectar rápidamente actividades anómalas, incluidos problemas de rendimiento de la red TIC e incidentes relacionados con TIC, e identificar posibles puntos únicos de falla material. El Artículo 10(2) exige además que los mecanismos de detección permitan múltiples capas de control, definan umbrales de alerta e incluyan alertas automáticas para el personal responsable de la respuesta a incidentes.
“Las entidades financieras deberán disponer de mecanismos para detectar rápidamente actividades anómalas, incluidos problemas de rendimiento de red TIC e incidentes relacionados con TIC.”
DORA, Artículo 10 (Detección)
Artículos 17 y 19 (Gestión y Reporte de Incidentes) requieren un proceso documentado para gestionar incidentes relacionados con TIC y, para los incidentes clasificados como mayores, notificar a la autoridad competente dentro de un plazo fijado por el regulador medido en horas y no en días. La velocidad de esa notificación depende directamente de la rapidez de la detección.
Artículo 28 (Riesgo de Terceros TIC) exige que las entidades gestionen y monitoreen el riesgo derivado de los proveedores terceros TIC. Cuando un proveedor apoya una función crítica o importante, su disponibilidad está dentro de la responsabilidad de monitoreo de la entidad.
De estas disposiciones se derivan cinco capacidades de monitoreo requeridas: monitoreo continuo, detección rápida de incidentes, validación de disponibilidad, supervisión de terceros TIC y alerta temprana de degradación del servicio. Las secciones siguientes abordan cada una en orden.
El Rol de la Verificación Externa
Las herramientas internas, incluyendo la gestión del rendimiento de aplicaciones (APM), métricas de servidores y análisis de registros, observan sistemas desde dentro de la red. Reportan con precisión el estado de la infraestructura pero no detectan una categoría de fallos que ocurren entre el usuario y los servidores. Estos incluyen:
- Cambios en DNS que resuelven incorrectamente para usuarios en una región o red específica.
- Certificados TLS expirados o mal configurados que los clientes rechazan.
- Fallas en el enrutamiento del CDN o ISP en el camino hacia el centro de datos.
- Scripts o APIs de terceros que se detienen e impiden la finalización de la página.
- Balanceadores de carga que responden válidamente a una comprobación de salud pero fallan en una transacción completa de usuario.
En cada una de estas condiciones, el monitoreo interno reporta operación normal mientras el servicio no está disponible para los usuarios. El monitoreo sintético externo ejecuta la transacción del usuario desde fuera de la red y por lo tanto registra la falla en el punto en que afecta a los usuarios.
La verificación externa también tiene valor probatorio para el cumplimiento. Un registro de disponibilidad es más creíble para un examinador cuando la medición se origina fuera del sistema medido. Los datos de disponibilidad independientes y con marca temporal respaldan las obligaciones de auditoría e informes que acompañan los requisitos de detección de DORA.
Mapeo de los Requisitos de DORA con las Capacidades de Dotcom-Monitor
Las subsecciones siguientes establecen cada requisito y la capacidad correspondiente que lo aborda. Dotcom-Monitor es una plataforma de monitoreo sintético que realiza comprobaciones desde fuera de la red, lo cual se alinea con las obligaciones de detección y disponibilidad mencionadas arriba.
Monitoreo Continuo (Artículo 9)
Requisito. Monitorizar y controlar continuamente el funcionamiento de los sistemas TIC que soportan servicios orientados al cliente.
Cómo se aborda. Comprobaciones sintéticas programadas que se ejecutan a intervalos definidos, tan frecuentes como cada minuto, proporcionando cobertura ininterrumpida de los servicios monitoreados. El monitoreo de aplicaciones web carga el servicio en un navegador real y mide el resultado renderizado, en lugar de solo confirmar que un servidor responde. Esto provee un registro continuo de si el servicio funciona como lo encontraría un usuario.
Detección Rápida de Actividades Anómalas (Artículo 10)
Requisito. Detectar rápidamente actividades anómalas, incluidas problemas de rendimiento de red TIC e incidentes, e identificar puntos únicos de falla materiales.
Cómo se aborda. Una transacción sintética que falla o que excede un límite definido de tiempo de respuesta, identifica la condición en el ciclo de comprobación en que ocurre, independientemente de los reportes de usuarios. La programación de viajes completos con el grabador EveryStep extiende la detección más allá de la disponibilidad de la página hacia procesos multi-paso como autenticación, pago y apertura de cuenta, donde un solo paso fallido constituye un incidente.
Umbrales de Alerta y Alertas Automáticas (Artículo 10(2))
Requisito. Definir umbrales de alerta y proporcionar alertas automáticas al personal responsable de la respuesta a incidentes.
Cómo se aborda. Alertas configurables que se activan por condiciones definidas, incluyendo tiempo de respuesta superior al límite establecido, una respuesta de error o un paso fallido en la transacción. Las alertas se envían automáticamente a correo electrónico, SMS o herramientas integradas de gestión de incidentes, dirigiendo la notificación a los respondedores designados en lugar de a una cola compartida. Las alertas basadas en umbrales sobre degradación, no solo sobre interrupción completa, soportan las múltiples capas de control que exige el Artículo 10(2).
Validación de Disponibilidad y Evidencia de Auditoría
Requisito. Demostrar que los servicios que apoyan funciones críticas o importantes se mantuvieron disponibles, con registros adecuados para auditoría y revisión post-incidente.
Cómo se aborda. Los informes de tiempo activo y SLA proporcionan un historial de disponibilidad con marca de tiempo para cada servicio monitoreado. Debido a que la medición se origina fuera de la red, el registro resultante constituye evidencia independiente de disponibilidad y del momento y duración de cualquier interrupción. Estos registros respaldan tanto revisiones internas como solicitudes de examinandos. Los objetivos de disponibilidad relacionados se discuten en los recursos de monitoreo de tiempo activo de la plataforma.
Supervisión de Terceros TIC (Artículo 28)
Requisito. Monitorear la disponibilidad y el rendimiento de proveedores terceros TIC que apoyan funciones críticas o importantes.
Cómo se aborda. El monitoreo de API verifica los endpoints REST, SOAP y GraphQL de los que depende una aplicación, incluyendo los operados por terceros. Para aplicaciones alojadas utilizadas en operaciones, el monitoreo SaaS rastrea directamente la disponibilidad del proveedor, brindando a la entidad visibilidad independiente de una dependencia en lugar de confiar en sus propios reportes de estado.
Alerta Temprana y Reporte de Incidentes (Artículos 10, 17, 19)
Requisito. Proporcionar alerta temprana de la degradación del servicio y detectar incidentes mayores a tiempo para cumplir con los plazos de reporte.
Cómo se aborda. Debido a que las comprobaciones se ejecutan continuamente desde fuera de la red, la degradación y la interrupción se detectan cerca del punto de ocurrencia, lo que acorta el intervalo entre el inicio del incidente y su detección. Ese intervalo es material para los Artículos 17 y 19, donde el plazo de notificación para un incidente mayor se mide en horas. La detección anticipada aumenta el tiempo disponible para clasificar, responder y reportar un incidente. La misma capacidad soporta la detección temprana de interrupciones y se examina más a fondo en el contexto del monitoreo sintético en servicios financieros.
Cobertura de Sistemas Internos
Requisito. Monitorear aplicaciones internas que apoyan funciones críticas o importantes, además de los servicios públicos.
Cómo se aborda. Los servicios públicos se verifican desde la red global de monitoreo. Las aplicaciones internas detrás del firewall se verifican mediante agentes privados desplegados dentro del entorno de la entidad, aplicando las mismas comprobaciones a sistemas internos y externos desde una única plataforma.
Resumen de Requisitos a Capacidades
La tabla consolida el mapeo expuesto arriba.
| Disposición DORA | Requisito | Capacidad de Dotcom-Monitor |
|---|---|---|
| Artículo 9 | Monitoreo continuo de sistemas TIC | Comprobaciones programadas en navegador real a intervalos tan cortos como un minuto |
| Artículo 10(1) | Detección rápida de actividades anómalas | Transacciones sintéticas que marcan fallas y superación de umbrales por ciclo |
| Artículo 10(2) | Umbrales de alerta y alertas automáticas | Alertas configurables a respondedores designados por error o degradación |
| Artículos 17, 19 | Detección oportuna de incidentes para reporte | Detección externa continua que acorta tiempo hasta conocimiento |
| Artículo 28 | Supervisión de terceros TIC | Monitoreo de API y SaaS de dependencias externas |
| Auditoría y revisión | Evidencia de disponibilidad | Informes con marca de tiempo de uptime y SLA desde fuera de la red |
Brechas Ilustrativas de Detección
Dos condiciones de fallo demuestran por qué se requiere verificación externa. Ambas son indetectables solo con monitoreo interno.
Configuración incorrecta regional de DNS. Un cambio en DNS se resuelve incorrectamente para un único proveedor de servicios de internet. Las métricas del servidor permanecen normales, porque las solicitudes afectadas no llegan a la infraestructura. Una comprobación externa ejecutada desde la región afectada registra la falla en su siguiente ciclo y emite una alerta, con una indicación de la ubicación afectada.
Latencia en la autenticación de un tercero. Un proveedor externo de identidad permanece disponible pero responde lentamente, añadiendo varios segundos a cada autenticación. No se genera error interno. Una transacción sintética que completa el inicio de sesión mide el tiempo de respuesta elevado, supera su umbral configurado e identifica la dependencia como la fuente. Esta es la visibilidad que exige el Artículo 28 para proveedores terceros.
Configuración Recomendada de Monitoreo
La siguiente configuración establece una línea base de monitoreo alineada con las obligaciones de detección y disponibilidad arriba mencionadas. Prioriza los caminos críticos más que la cobertura exhaustiva.
Paso 1: Identificar funciones críticas o importantes. Enumerar los servicios orientados al cliente cuyo fallo requeriría un reporte de incidente, como autenticación, pagos, transferencias, apertura de cuenta y acceso a estados de cuenta. Estos definen la prioridad del monitoreo.
Paso 2: Programar recorridos de usuario completos. Para cada función, grabar el flujo completo del usuario con el grabador EveryStep, concluyendo en un paso que confirme que el servicio cumplió su función, como una transferencia completada o una vista de cuenta cargada. Una comprobación limitada a la página principal no detectará fallos en pasos posteriores.
Paso 3: Monitorear desde ubicaciones relevantes. Seleccionar ubicaciones de monitoreo que correspondan con la geografía de clientes de la entidad a través de la red global de monitoreo, para detectar fallos regionales.
Paso 4: Monitorear dependencias de terceros. Configurar comprobaciones separadas para las APIs de terceros y aplicaciones alojadas de las que dependen funciones críticas, de modo que la fuente de un fallo pueda atribuirse a la entidad o al proveedor.
Paso 5: Definir umbrales y rutas de alerta. Establecer umbrales de alerta para tiempo de respuesta y condiciones de error, y dirigir las alertas a respondedores designados y sistemas de gestión de incidentes. Configurar alertas tanto para degradación como para interrupción completa.
Paso 6: Conservar registros de disponibilidad. Habilitar desde el inicio los informes de uptime y SLA, para que el historial de disponibilidad se acumule automáticamente y esté disponible para auditoría y revisión post-incidente.
Paso 7: Extender cobertura a sistemas internos. Desplegar agentes privados para aplicaciones internas que apoyan funciones críticas, de modo que esos sistemas reciban comprobaciones continuas equivalentes.
Alcance y Limitaciones
El monitoreo sintético externo es un control dentro de un programa DORA y no satisface por sí solo la regulación en su totalidad. Proporciona validación de disponibilidad y detección rápida. No provee gobernanza del riesgo TIC, clasificación y procedimientos de reporte de incidentes, pruebas de penetración dirigidas por amenazas, respaldo y recuperación, ni los arreglos contractuales para proveedores terceros que DORA también exige. Estas obligaciones las cumplen otros controles dentro del programa de resiliencia de la entidad.
El monitoreo sintético también verifica solo las transacciones que han sido programadas. Un recorrido de usuario que no se haya configurado no se monitorea, por lo que la cobertura de monitoreo debe mantenerse a medida que los servicios cambian. Dentro de este ámbito definido, el monitoreo sintético externo proporciona evidencia de detección y disponibilidad que pocos otros controles generan.
Conclusión
DORA exige que las entidades financieras detecten incidentes TIC rápidamente y mantengan, y evidencien, la disponibilidad de servicios que soportan funciones críticas o importantes. El monitoreo interno reporta el estado de la infraestructura y no detecta fallos que ocurren entre el usuario y los servidores. El monitoreo sintético externo verifica continuamente la transacción completa del usuario, desde fuera de la red y a través de las regiones relevantes, incluyendo dependencias de terceros, y conserva registros con marca de tiempo del resultado.
Estas capacidades corresponden directamente con la obligación de monitoreo continuo del Artículo 9, las obligaciones de detección y alerta del Artículo 10, la oportunidad requerida por los Artículos 17 y 19, y la supervisión de terceros requerida por el Artículo 28. El monitoreo sintético externo no constituye por sí mismo el cumplimiento de DORA, pero es un medio directo y documentado para cumplir con los requisitos de detección y disponibilidad que establece el reglamento.
