{"id":34272,"date":"2026-07-24T20:28:29","date_gmt":"2026-07-24T20:28:29","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/external-synthetic-monitoring-dora\/"},"modified":"2026-07-24T20:28:29","modified_gmt":"2026-07-24T20:28:29","slug":"external-synthetic-monitoring-dora","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/external-synthetic-monitoring-dora\/","title":{"rendered":"Monitoreo Sint\u00e9tico Externo para la Resiliencia Operativa DORA"},"content":{"rendered":"
Resiliencia operativa \u00b7 Gesti\u00f3n de riesgos TIC \u00b7 Servicios financieros<\/em><\/p>\n El Reglamento de Resiliencia Operativa Digital (DORA), Reglamento (UE) 2022\/2554<\/a>, se ha aplicado a las entidades financieras de la Uni\u00f3n Europea desde el 17 de enero de 2025. Entre sus objetivos centrales est\u00e1 el requisito de que las empresas detecten incidentes TIC (tecnolog\u00edas de la informaci\u00f3n y comunicaciones) de manera r\u00e1pida y mantengan la disponibilidad de los servicios que apoyan funciones cr\u00edticas o importantes.<\/p>\n 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\u00e1s 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\u00f3n de un usuario externo. El monitoreo sint\u00e9tico externo aborda esto ejecutando transacciones programadas contra servicios en producci\u00f3n desde ubicaciones fuera de la red, con un horario definido.<\/p>\n Este art\u00edculo identifica las obligaciones espec\u00edficas de DORA que inciden en el monitoreo continuo y la detecci\u00f3n, y expone c\u00f3mo el monitoreo sint\u00e9tico externo<\/a>, y la plataforma Dotcom-Monitor en particular, abordan cada una de ellas.<\/p>\n DORA se basa en resultados en lugar de prescribir herramientas espec\u00edficas. No obliga a un producto de monitoreo espec\u00edfico ni a una frecuencia fija de comprobaciones. Establece obligaciones para la detecci\u00f3n, la disponibilidad y la supervisi\u00f3n, y el monitoreo es el control operativo a trav\u00e9s del cual se cumplen varias de esas obligaciones. Cuatro disposiciones son las m\u00e1s relevantes.<\/p>\n Art\u00edculo 9 (Protecci\u00f3n y Prevenci\u00f3n)<\/strong> requiere que las entidades financieras monitoreen y controlen continuamente la seguridad y funcionamiento de los sistemas y herramientas TIC. La obligaci\u00f3n es continua, lo que excluye que las comprobaciones peri\u00f3dicas o manuales sean un control suficiente por s\u00ed solas.<\/p>\n Art\u00edculo 10 (Detecci\u00f3n)<\/strong> exige mecanismos para detectar r\u00e1pidamente actividades an\u00f3malas, incluidos problemas de rendimiento de la red TIC e incidentes relacionados con TIC, e identificar posibles puntos \u00fanicos de falla material. El Art\u00edculo 10(2) exige adem\u00e1s que los mecanismos de detecci\u00f3n permitan m\u00faltiples capas de control, definan umbrales de alerta e incluyan alertas autom\u00e1ticas para el personal responsable de la respuesta a incidentes.<\/p>\n “Las entidades financieras deber\u00e1n disponer de mecanismos para detectar r\u00e1pidamente actividades an\u00f3malas, incluidos problemas de rendimiento de red TIC e incidentes relacionados con TIC.” Art\u00edculos 17 y 19 (Gesti\u00f3n y Reporte de Incidentes)<\/strong> 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\u00edas. La velocidad de esa notificaci\u00f3n depende directamente de la rapidez de la detecci\u00f3n.<\/p>\n Art\u00edculo 28 (Riesgo de Terceros TIC)<\/strong> exige que las entidades gestionen y monitoreen el riesgo derivado de los proveedores terceros TIC. Cuando un proveedor apoya una funci\u00f3n cr\u00edtica o importante, su disponibilidad est\u00e1 dentro de la responsabilidad de monitoreo de la entidad.<\/p>\n De estas disposiciones se derivan cinco capacidades de monitoreo requeridas: monitoreo continuo, detecci\u00f3n r\u00e1pida de incidentes, validaci\u00f3n de disponibilidad, supervisi\u00f3n de terceros TIC y alerta temprana de degradaci\u00f3n del servicio. Las secciones siguientes abordan cada una en orden.<\/p>\n Las herramientas internas, incluyendo la gesti\u00f3n del rendimiento de aplicaciones (APM), m\u00e9tricas de servidores y an\u00e1lisis de registros, observan sistemas desde dentro de la red. Reportan con precisi\u00f3n el estado de la infraestructura pero no detectan una categor\u00eda de fallos que ocurren entre el usuario y los servidores. Estos incluyen:<\/p>\n En cada una de estas condiciones, el monitoreo interno reporta operaci\u00f3n normal mientras el servicio no est\u00e1 disponible para los usuarios. El monitoreo sint\u00e9tico externo ejecuta la transacci\u00f3n del usuario desde fuera de la red y por lo tanto registra la falla en el punto en que afecta a los usuarios.<\/p>\n La verificaci\u00f3n externa tambi\u00e9n tiene valor probatorio para el cumplimiento. Un registro de disponibilidad es m\u00e1s cre\u00edble para un examinador cuando la medici\u00f3n se origina fuera del sistema medido. Los datos de disponibilidad independientes y con marca temporal respaldan las obligaciones de auditor\u00eda e informes que acompa\u00f1an los requisitos de detecci\u00f3n de DORA.<\/p>\n Las subsecciones siguientes establecen cada requisito y la capacidad correspondiente que lo aborda. Dotcom-Monitor es una plataforma de monitoreo sint\u00e9tico que realiza comprobaciones desde fuera de la red, lo cual se alinea con las obligaciones de detecci\u00f3n y disponibilidad mencionadas arriba.<\/p>\n Requisito.<\/strong> Monitorizar y controlar continuamente el funcionamiento de los sistemas TIC que soportan servicios orientados al cliente.<\/p>\n C\u00f3mo se aborda.<\/strong> Comprobaciones sint\u00e9ticas programadas que se ejecutan a intervalos definidos, tan frecuentes como cada minuto, proporcionando cobertura ininterrumpida de los servicios monitoreados. El monitoreo de aplicaciones web<\/a> 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\u00eda un usuario.<\/p>\n Requisito.<\/strong> Detectar r\u00e1pidamente actividades an\u00f3malas, incluidas problemas de rendimiento de red TIC e incidentes, e identificar puntos \u00fanicos de falla materiales.<\/p>\n C\u00f3mo se aborda.<\/strong> Una transacci\u00f3n sint\u00e9tica que falla o que excede un l\u00edmite definido de tiempo de respuesta, identifica la condici\u00f3n en el ciclo de comprobaci\u00f3n en que ocurre, independientemente de los reportes de usuarios. La programaci\u00f3n de viajes completos con el grabador EveryStep<\/a> extiende la detecci\u00f3n m\u00e1s all\u00e1 de la disponibilidad de la p\u00e1gina hacia procesos multi-paso como autenticaci\u00f3n, pago y apertura de cuenta, donde un solo paso fallido constituye un incidente.<\/p>\n Requisito.<\/strong> Definir umbrales de alerta y proporcionar alertas autom\u00e1ticas al personal responsable de la respuesta a incidentes.<\/p>\n C\u00f3mo se aborda.<\/strong> Alertas configurables<\/a> que se activan por condiciones definidas, incluyendo tiempo de respuesta superior al l\u00edmite establecido, una respuesta de error o un paso fallido en la transacci\u00f3n. Las alertas se env\u00edan autom\u00e1ticamente a correo electr\u00f3nico, SMS o herramientas integradas de gesti\u00f3n de incidentes, dirigiendo la notificaci\u00f3n a los respondedores designados en lugar de a una cola compartida. Las alertas basadas en umbrales sobre degradaci\u00f3n, no solo sobre interrupci\u00f3n completa, soportan las m\u00faltiples capas de control que exige el Art\u00edculo 10(2).<\/p>\n Requisito.<\/strong> Demostrar que los servicios que apoyan funciones cr\u00edticas o importantes se mantuvieron disponibles, con registros adecuados para auditor\u00eda y revisi\u00f3n post-incidente.<\/p>\n C\u00f3mo se aborda.<\/strong> Los informes de tiempo activo y SLA<\/a> proporcionan un historial de disponibilidad con marca de tiempo para cada servicio monitoreado. Debido a que la medici\u00f3n se origina fuera de la red, el registro resultante constituye evidencia independiente de disponibilidad y del momento y duraci\u00f3n de cualquier interrupci\u00f3n. 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<\/a> de la plataforma.<\/p>\n Requisito.<\/strong> Monitorear la disponibilidad y el rendimiento de proveedores terceros TIC que apoyan funciones cr\u00edticas o importantes.<\/p>\n C\u00f3mo se aborda.<\/strong> El monitoreo de API<\/a> verifica los endpoints REST, SOAP y GraphQL de los que depende una aplicaci\u00f3n, incluyendo los operados por terceros. Para aplicaciones alojadas utilizadas en operaciones, el monitoreo SaaS<\/a> 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.<\/p>\n Requisito.<\/strong> Proporcionar alerta temprana de la degradaci\u00f3n del servicio y detectar incidentes mayores a tiempo para cumplir con los plazos de reporte.<\/p>\n C\u00f3mo se aborda.<\/strong> Debido a que las comprobaciones se ejecutan continuamente desde fuera de la red, la degradaci\u00f3n y la interrupci\u00f3n se detectan cerca del punto de ocurrencia, lo que acorta el intervalo entre el inicio del incidente y su detecci\u00f3n. Ese intervalo es material para los Art\u00edculos 17 y 19, donde el plazo de notificaci\u00f3n para un incidente mayor se mide en horas. La detecci\u00f3n anticipada aumenta el tiempo disponible para clasificar, responder y reportar un incidente. La misma capacidad soporta la detecci\u00f3n temprana de interrupciones<\/a> y se examina m\u00e1s a fondo en el contexto del monitoreo sint\u00e9tico en servicios financieros<\/a>.<\/p>\n Requisito.<\/strong> Monitorear aplicaciones internas que apoyan funciones cr\u00edticas o importantes, adem\u00e1s de los servicios p\u00fablicos.<\/p>\n C\u00f3mo se aborda.<\/strong> Los servicios p\u00fablicos se verifican desde la red global de monitoreo<\/a>. Las aplicaciones internas detr\u00e1s del firewall se verifican mediante agentes privados<\/a> desplegados dentro del entorno de la entidad, aplicando las mismas comprobaciones a sistemas internos y externos desde una \u00fanica plataforma.<\/p>\n La tabla consolida el mapeo expuesto arriba.<\/p>\n Dos condiciones de fallo demuestran por qu\u00e9 se requiere verificaci\u00f3n externa. Ambas son indetectables solo con monitoreo interno.<\/p>\n Configuraci\u00f3n incorrecta regional de DNS.<\/strong> Un cambio en DNS se resuelve incorrectamente para un \u00fanico proveedor de servicios de internet. Las m\u00e9tricas del servidor permanecen normales, porque las solicitudes afectadas no llegan a la infraestructura. Una comprobaci\u00f3n externa ejecutada desde la regi\u00f3n afectada registra la falla en su siguiente ciclo y emite una alerta, con una indicaci\u00f3n de la ubicaci\u00f3n afectada.<\/p>\n Latencia en la autenticaci\u00f3n de un tercero.<\/strong> Un proveedor externo de identidad permanece disponible pero responde lentamente, a\u00f1adiendo varios segundos a cada autenticaci\u00f3n. No se genera error interno. Una transacci\u00f3n sint\u00e9tica que completa el inicio de sesi\u00f3n 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\u00edculo 28 para proveedores terceros.<\/p>\n La siguiente configuraci\u00f3n establece una l\u00ednea base de monitoreo alineada con las obligaciones de detecci\u00f3n y disponibilidad arriba mencionadas. Prioriza los caminos cr\u00edticos m\u00e1s que la cobertura exhaustiva.<\/p>\n Paso 1: Identificar funciones cr\u00edticas o importantes.<\/strong> Enumerar los servicios orientados al cliente cuyo fallo requerir\u00eda un reporte de incidente, como autenticaci\u00f3n, pagos, transferencias, apertura de cuenta y acceso a estados de cuenta. Estos definen la prioridad del monitoreo.<\/p>\n Paso 2: Programar recorridos de usuario completos.<\/strong> Para cada funci\u00f3n, grabar el flujo completo del usuario con el grabador EveryStep, concluyendo en un paso que confirme que el servicio cumpli\u00f3 su funci\u00f3n, como una transferencia completada o una vista de cuenta cargada. Una comprobaci\u00f3n limitada a la p\u00e1gina principal no detectar\u00e1 fallos en pasos posteriores.<\/p>\n Paso 3: Monitorear desde ubicaciones relevantes.<\/strong> Seleccionar ubicaciones de monitoreo que correspondan con la geograf\u00eda de clientes de la entidad a trav\u00e9s de la red global de monitoreo, para detectar fallos regionales.<\/p>\n Paso 4: Monitorear dependencias de terceros.<\/strong> Configurar comprobaciones separadas para las APIs de terceros y aplicaciones alojadas de las que dependen funciones cr\u00edticas, de modo que la fuente de un fallo pueda atribuirse a la entidad o al proveedor.<\/p>\n Paso 5: Definir umbrales y rutas de alerta.<\/strong> Establecer umbrales de alerta para tiempo de respuesta y condiciones de error, y dirigir las alertas a respondedores designados y sistemas de gesti\u00f3n de incidentes. Configurar alertas tanto para degradaci\u00f3n como para interrupci\u00f3n completa.<\/p>\n Paso 6: Conservar registros de disponibilidad.<\/strong> Habilitar desde el inicio los informes de uptime y SLA, para que el historial de disponibilidad se acumule autom\u00e1ticamente y est\u00e9 disponible para auditor\u00eda y revisi\u00f3n post-incidente.<\/p>\n Paso 7: Extender cobertura a sistemas internos.<\/strong> Desplegar agentes privados para aplicaciones internas que apoyan funciones cr\u00edticas, de modo que esos sistemas reciban comprobaciones continuas equivalentes.<\/p>\n El monitoreo sint\u00e9tico externo es un control dentro de un programa DORA y no satisface por s\u00ed solo la regulaci\u00f3n en su totalidad. Proporciona validaci\u00f3n de disponibilidad y detecci\u00f3n r\u00e1pida. No provee gobernanza del riesgo TIC, clasificaci\u00f3n y procedimientos de reporte de incidentes, pruebas de penetraci\u00f3n dirigidas por amenazas, respaldo y recuperaci\u00f3n, ni los arreglos contractuales para proveedores terceros que DORA tambi\u00e9n exige. Estas obligaciones las cumplen otros controles dentro del programa de resiliencia de la entidad.<\/p>\n El monitoreo sint\u00e9tico tambi\u00e9n 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 \u00e1mbito definido, el monitoreo sint\u00e9tico externo proporciona evidencia de detecci\u00f3n y disponibilidad que pocos otros controles generan.<\/p>\n DORA exige que las entidades financieras detecten incidentes TIC r\u00e1pidamente y mantengan, y evidencien, la disponibilidad de servicios que soportan funciones cr\u00edticas 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\u00e9tico externo verifica continuamente la transacci\u00f3n completa del usuario, desde fuera de la red y a trav\u00e9s de las regiones relevantes, incluyendo dependencias de terceros, y conserva registros con marca de tiempo del resultado.<\/p>\n Estas capacidades corresponden directamente con la obligaci\u00f3n de monitoreo continuo del Art\u00edculo 9, las obligaciones de detecci\u00f3n y alerta del Art\u00edculo 10, la oportunidad requerida por los Art\u00edculos 17 y 19, y la supervisi\u00f3n de terceros requerida por el Art\u00edculo 28. El monitoreo sint\u00e9tico externo no constituye por s\u00ed mismo el cumplimiento de DORA, pero es un medio directo y documentado para cumplir con los requisitos de detecci\u00f3n y disponibilidad que establece el reglamento.<\/p>\n C\u00f3mo el monitoreo sint\u00e9tico externo cumple con las obligaciones de detecci\u00f3n y disponibilidad de DORA, requisito por requisito.<\/p>\n","protected":false},"author":39,"featured_media":34258,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34272","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/34272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=34272"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/34272\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/34258"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=34272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=34272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=34272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Obligaciones de Detecci\u00f3n y Disponibilidad de DORA<\/h2>\n
\nDORA, Art\u00edculo 10 (Detecci\u00f3n)<\/cite><\/p><\/blockquote>\nEl Rol de la Verificaci\u00f3n Externa<\/h2>\n
\n

Mapeo de los Requisitos de DORA con las Capacidades de Dotcom-Monitor<\/h2>\n
Monitoreo Continuo (Art\u00edculo 9)<\/h3>\n
Detecci\u00f3n R\u00e1pida de Actividades An\u00f3malas (Art\u00edculo 10)<\/h3>\n
Umbrales de Alerta y Alertas Autom\u00e1ticas (Art\u00edculo 10(2))<\/h3>\n
Validaci\u00f3n de Disponibilidad y Evidencia de Auditor\u00eda<\/h3>\n
Supervisi\u00f3n de Terceros TIC (Art\u00edculo 28)<\/h3>\n
Alerta Temprana y Reporte de Incidentes (Art\u00edculos 10, 17, 19)<\/h3>\n
Cobertura de Sistemas Internos<\/h3>\n
Resumen de Requisitos a Capacidades<\/h2>\n
\n\n
\n \nDisposici\u00f3n DORA<\/th>\n Requisito<\/th>\n Capacidad de Dotcom-Monitor<\/th>\n<\/tr>\n<\/thead>\n \n Art\u00edculo 9<\/td>\n Monitoreo continuo de sistemas TIC<\/td>\n Comprobaciones programadas en navegador real a intervalos tan cortos como un minuto<\/td>\n<\/tr>\n \n Art\u00edculo 10(1)<\/td>\n Detecci\u00f3n r\u00e1pida de actividades an\u00f3malas<\/td>\n Transacciones sint\u00e9ticas que marcan fallas y superaci\u00f3n de umbrales por ciclo<\/td>\n<\/tr>\n \n Art\u00edculo 10(2)<\/td>\n Umbrales de alerta y alertas autom\u00e1ticas<\/td>\n Alertas configurables a respondedores designados por error o degradaci\u00f3n<\/td>\n<\/tr>\n \n Art\u00edculos 17, 19<\/td>\n Detecci\u00f3n oportuna de incidentes para reporte<\/td>\n Detecci\u00f3n externa continua que acorta tiempo hasta conocimiento<\/td>\n<\/tr>\n \n Art\u00edculo 28<\/td>\n Supervisi\u00f3n de terceros TIC<\/td>\n Monitoreo de API y SaaS de dependencias externas<\/td>\n<\/tr>\n \n Auditor\u00eda y revisi\u00f3n<\/td>\n Evidencia de disponibilidad<\/td>\n Informes con marca de tiempo de uptime y SLA desde fuera de la red<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Brechas Ilustrativas de Detecci\u00f3n<\/h3>\n
Configuraci\u00f3n Recomendada de Monitoreo<\/h2>\n
Alcance y Limitaciones<\/h2>\n
Conclusi\u00f3n<\/h2>\n