Operational resilience · ICT risk management · Financial services
The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied to European Union financial entities since 17 January 2025. Among its central objectives is the requirement that firms detect ICT (information and communications technology) incidents promptly and maintain the availability of services that support critical or important functions.
Meeting that objective requires monitoring that reflects the actual availability of customer-facing services, not only the internal health of the systems behind them. Internal observability tools report on infrastructure from within the corporate network. They do not confirm whether a service is reachable and functional from the position of an external user. External synthetic monitoring addresses this by executing scripted transactions against production services from locations outside the network, on a defined schedule.
This article identifies the specific DORA obligations that bear on continuous monitoring and detection, and sets out how external synthetic monitoring, and the Dotcom-Monitor platform in particular, addresses each of them.
DORA Detection and Availability Obligations
DORA is outcome-based rather than prescriptive about tools. It does not mandate a specific monitoring product or check frequency. It establishes obligations for detection, availability, and oversight, and monitoring is the operational control through which several of those obligations are met. Four provisions are most relevant.
Article 9 (Protection and Prevention) requires financial entities to continuously monitor and control the security and functioning of ICT systems and tools. The obligation is continuous, which excludes periodic or manual checks as a sufficient control on their own.
Article 10 (Detection) requires mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure. Article 10(2) further requires that detection mechanisms enable multiple layers of control, define alert thresholds, and include automatic alerts for the staff responsible for incident response.
“Financial entities shall have in place mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents.”
DORA, Article 10 (Detection)
Articles 17 and 19 (Incident Management and Reporting) require a documented process for managing ICT-related incidents and, for incidents classified as major, notification of the competent authority on a regulator-set deadline measured in hours rather than days. The speed of that notification depends directly on the speed of detection.
Article 28 (ICT Third-Party Risk) requires entities to manage and monitor the risk arising from ICT third-party service providers. Where a provider supports a critical or important function, its availability falls within the entity’s monitoring responsibility.
From these provisions, five monitoring capabilities are required: continuous monitoring, prompt incident detection, availability validation, third-party ICT oversight, and early warning of service degradation. The sections below address each in turn.
The Role of External Verification
Internal tools, including application performance management (APM), server metrics, and log analysis, observe systems from within the network. They report accurately on infrastructure state but do not detect a category of failures that occur between the user and the servers. These include:
- DNS changes that resolve incorrectly for users in a specific region or network.
- Expired or misconfigured TLS certificates that clients reject.
- CDN or ISP routing faults on the path into the data center.
- Third-party scripts or APIs that stall and prevent page completion.
- Load balancers that return a valid response to a health check but fail a complete user transaction.
In each of these conditions, internal monitoring reports normal operation while the service is unavailable to users. External synthetic monitoring executes the user transaction from outside the network and therefore registers the failure at the point at which it affects users.
External verification also carries evidentiary value for compliance. A record of availability is more credible to an examiner when the measurement originates outside the system being measured. Independent, timestamped availability data supports the audit and reporting obligations that accompany DORA’s detection requirements.
Mapping DORA Requirements to Dotcom-Monitor Capabilities
The following subsections state each requirement and the corresponding capability that addresses it. Dotcom-Monitor is a synthetic monitoring platform that performs checks from outside the network, which aligns with the detection and availability obligations set out above.
Continuous Monitoring (Article 9)
Requirement. Continuously monitor and control the functioning of ICT systems that support customer-facing services.
How it is addressed. Scheduled synthetic checks run at defined intervals, as frequent as one minute, providing uninterrupted coverage of monitored services. Web application monitoring loads the service in a real browser and measures the rendered result, rather than confirming only that a server responds. This provides a continuous record of whether the service functions as a user would encounter it.
Prompt Detection of Anomalous Activities (Article 10)
Requirement. Promptly detect anomalous activities, including ICT network performance issues and incidents, and identify material single points of failure.
How it is addressed. A synthetic transaction that fails, or that exceeds a defined response-time limit, identifies the condition on the check cycle in which it occurs, independent of user reports. Scripting complete journeys with the EveryStep recorder extends detection beyond page availability to multi-step processes such as authentication, payment, and account opening, where a single failed step constitutes an incident.
Alert Thresholds and Automatic Alerts (Article 10(2))
Requirement. Define alert thresholds and provide automatic alerts to the staff responsible for incident response.
How it is addressed. Configurable alerting triggers on defined conditions, including response time above a set limit, an error response, or a failed transaction step. Alerts route automatically to email, SMS, or integrated incident-management tools, directing notification to designated responders rather than a shared queue. Threshold-based alerting on degradation, not only on complete outage, supports the multiple layers of control that Article 10(2) requires.
Availability Validation and Audit Evidence
Requirement. Demonstrate that services supporting critical or important functions remained available, with records suitable for audit and post-incident review.
How it is addressed. Uptime and SLA reports provide timestamped availability history for each monitored service. Because the measurement originates outside the network, the resulting record constitutes independent evidence of availability and of the timing and duration of any interruption. These records support both internal review and examiner requests. Related availability targets are discussed in the platform’s uptime monitoring resources.
ICT Third-Party Oversight (Article 28)
Requirement. Monitor the availability and performance of ICT third-party providers that support critical or important functions.
How it is addressed. API monitoring checks the REST, SOAP, and GraphQL endpoints on which an application depends, including those operated by third parties. For hosted applications used in operations, SaaS monitoring tracks provider availability directly, giving the entity independent visibility of a dependency rather than reliance on the provider’s own status reporting.
Early Warning and Incident Reporting (Articles 10, 17, 19)
Requirement. Provide early warning of service degradation, and detect major incidents in time to meet reporting deadlines.
How it is addressed. Because checks run continuously from outside the network, degradation and outage are detected close to the point of occurrence, which shortens the interval between incident onset and detection. That interval is material to Articles 17 and 19, where the notification deadline for a major incident is measured in hours. Earlier detection increases the time available to classify, respond to, and report an incident. The same capability supports early outage detection and is examined further in the context of synthetic monitoring in financial services.
Coverage of Internal Systems
Requirement. Monitor internal applications that support critical or important functions, in addition to public services.
How it is addressed. Public services are checked from the global monitoring network. Internal applications behind the firewall are checked by private agents deployed within the entity’s environment, applying the same checks to internal and external systems from a single platform.
Requirement-to-Capability Summary
The table consolidates the mapping set out above.
| DORA provision | Requirement | Dotcom-Monitor capability |
|---|---|---|
| Article 9 | Continuous monitoring of ICT systems | Scheduled real-browser checks at intervals as short as one minute |
| Article 10(1) | Prompt detection of anomalous activities | Synthetic transactions that flag failures and threshold breaches per cycle |
| Article 10(2) | Alert thresholds and automatic alerts | Configurable alerting to designated responders on error or degradation |
| Articles 17, 19 | Timely incident detection for reporting | Continuous external detection that shortens time to awareness |
| Article 28 | ICT third-party oversight | API and SaaS monitoring of external dependencies |
| Audit and review | Evidence of availability | Timestamped uptime and SLA reports from outside the network |
Illustrative Detection Gaps
Two failure conditions demonstrate why external verification is required. Both are undetectable by internal monitoring alone.
Regional DNS misconfiguration. A DNS change resolves incorrectly for a single internet service provider. Server-side metrics remain nominal, because affected requests do not reach the infrastructure. An external check executed from the affected region records the failure on its next cycle and issues an alert, with an indication of the affected location.
Third-party authentication latency. An external identity provider remains available but responds slowly, adding several seconds to each authentication. No internal error is raised. A synthetic transaction that completes the full login measures the elevated response time, crosses its configured threshold, and identifies the dependency as the source. This is the visibility Article 28 requires for third-party providers.
Recommended Monitoring Configuration
The following configuration establishes a monitoring baseline aligned with the detection and availability obligations above. It prioritizes critical paths rather than exhaustive coverage.
Step 1: Identify critical or important functions. Enumerate the customer-facing services whose failure would require an incident report, such as authentication, payments, transfers, account opening, and statement access. These define monitoring priority.
Step 2: Script complete user journeys. For each function, record the full user flow with the EveryStep recorder, concluding at a step that confirms the service performed its function, such as a completed transfer or a loaded account view. A check limited to the home page will not detect a failure in a later step.
Step 3: Monitor from relevant locations. Select monitoring locations that correspond to the entity’s customer geography across the global monitoring network, so that regional failures are detected.
Step 4: Monitor third-party dependencies. Configure separate checks for the third-party APIs and hosted applications on which critical functions depend, so that the source of a failure can be attributed to the entity or to a provider.
Step 5: Define thresholds and alert routing. Set alert thresholds for response time and error conditions, and route alerts to designated responders and incident-management systems. Configure alerts on degradation as well as on complete outage.
Step 6: Retain availability records. Enable uptime and SLA reporting from the outset, so that availability history accumulates automatically and is available for audit and post-incident review.
Step 7: Extend coverage to internal systems. Deploy private agents for internal applications that support critical functions, so that those systems receive equivalent continuous checks.
Scope and Limitations
External synthetic monitoring is one control within a DORA program and does not, on its own, satisfy the regulation in full. It provides availability validation and prompt detection. It does not provide ICT risk governance, incident classification and reporting procedures, threat-led penetration testing, backup and recovery, or the contractual arrangements for third-party providers that DORA also requires. These obligations are met by other controls within the entity’s resilience program.
Synthetic monitoring also verifies only the transactions that have been scripted. A user journey that has not been configured is not monitored, so monitoring coverage must be maintained as services change. Within this defined scope, external synthetic monitoring provides detection and availability evidence that few other controls produce.
Conclusion
DORA requires financial entities to detect ICT incidents promptly and to maintain, and evidence, the availability of services supporting critical or important functions. Internal monitoring reports on infrastructure state and does not detect failures that occur between the user and the servers. External synthetic monitoring verifies the complete user transaction continuously, from outside the network and across relevant regions, including third-party dependencies, and retains timestamped records of the result.
These capabilities correspond directly to the continuous monitoring obligation of Article 9, the detection and alerting obligations of Article 10, the timeliness required by Articles 17 and 19, and the third-party oversight required by Article 28. External synthetic monitoring does not constitute DORA compliance in itself, but it is a direct and evidenced means of meeting the detection and availability requirements the regulation sets.
