DORA Compliance Testing for Validating ICT Resilience Under Real-World Conditions

DORA (Digital Operational Resilience Act) has made ICT resilience testing a board-level priority for financial organisations. But for many financial firms, the challenge is not simply understanding that testing is required. It is knowing what to test, how to test it safely, and how to produce evidence that critical ICT services can withstand real-world disruption.

Why DORA compliance testing is difficult to interpret

The Digital Operational Resilience Act, known as DORA, has applied since January 17, 2025, and is intended to ensure that financial entities can withstand, respond to, and recover from ICT disruptions. This includes banks, insurers, investment firms, and other regulated financial organizations.

At a high level, this sounds straightforward. Financial firms need to be resilient. In practice, however, DORA creates a much broader testing challenge.

Operational resilience is not only about whether a system works under normal conditions. It is about how that system behaves when something goes wrong. Can payment services continue when connectivity degrades? Can data replication recover when latency increases? Can cloud-hosted applications maintain acceptable performance when packet loss appears between regions? Can teams prove that recovery plans work before a live incident exposes a weakness?

This is where many traditional approaches start to fall short. Monitoring tools can detect issues, but they do not necessarily test behavior under failure. Traffic and load testing can create volume, but they do not always recreate impaired network conditions. Production testing may provide realism, but it is difficult to control and can create unacceptable operational risk.

For DORA compliance testing, financial firms need a way to move from assumed resilience to proven resilience.

What does DORA require financial firms to test?

DORA does not prescribe one single tool or method for resilience testing. Instead, it sets expectations for a structured digital operational resilience testing programme. Article 24 states that the testing programme should include a range of assessments, methodologies, practices and tools. Article 25 then refers to appropriate tests, including scenario-based tests, compatibility testing, performance testing, end-to-end testing, penetration testing and network security assessments. For financial ICT teams, the important point is that DORA testing should not be reduced to a checklist. It needs to show whether important ICT systems, services and dependencies can continue to operate under stress. Several DORA areas are especially relevant when thinking about realistic network conditions:

Article 11 also requires financial entities to test ICT business continuity plans and ICT response and recovery plans at least yearly for ICT systems supporting all functions, as well as after substantive changes to systems supporting critical or important functions. Article 12 requires periodic testing of backup, restoration and recovery procedures. Article 28 requires ICT third-party risk to be managed as part of the ICT risk management framework.

Together, these areas point towards a practical testing need: financial firms need to understand how critical services behave when the network is no longer clean, stable or predictable.

Why real-world network conditions matter for DORA testing

In financial services, small network issues can have significant operational consequences. Payments, trading systems, fraud detection, customer-facing banking applications, data replication and disaster recovery architectures all depend on predictable connectivity.

But real networks are not perfect. They experience latency, jitter, congestion, packet loss, routing changes, bandwidth constraints and partial connectivity failures. These conditions may not cause a total outage, but they can degrade performance enough to affect customer experience, transaction completion, recovery objectives or regulatory confidence.

This is especially important for:

• • Real-time and instant payments
  • Active-active data centres
  • Disaster recovery and failover
  • Cloud and hybrid architectures
  • Data replication between sites
  • Market infrastructure and settlement systems
  • Latency-sensitive analytics and fraud detection
  • ICT services delivered by third-party providers

Our Primer, Network Resilience for Financial Services frames this as a shift from assumed resilience to proven resilience, with testing focused on realistic impairments such as latency, packet loss, jitter and bandwidth limits.

Please fill in the form to receive your Primer now.

The gap in traditional resilience testing

Many financial organisations already have mature monitoring, security and disaster recovery processes. The issue is that these approaches often answer different questions.

Monitoring answers: “Is something wrong right now?”

Load testing answers: “Can the system handle volume?”

Disaster recovery exercises answer: “Can we follow the recovery plan?”

But DORA operational resilience testing also needs to answer:

“What happens to critical ICT services when realistic network disruption is introduced in a controlled, repeatable way?”

That is a different testing requirement. It requires the ability to introduce network conditions safely, observe how real systems respond, repeat the same scenario, and collect evidence that can inform remediation, reporting and future testing.

This is where network emulation becomes relevant.

Where network emulation fits into DORA compliance testing

A network emulator allows teams to recreate real-world network conditions in a controlled test environment. It can sit between systems, sites, devices or applications and introduce impairments such as latency, packet loss, jitter, bandwidth constraints and more.

For DORA testing, this gives financial firms a practical way to validate how ICT services behave under disruption without deliberately impairing production systems.

Network emulation can support DORA resilience testing by helping teams:

• Build realistic disruption scenarios
• Test failover and recovery plans safely
• Validate performance under degraded connectivity
• Recreate third-party or cloud connectivity issues
• Measure service behaviour before and after remediation
• Produce repeatable evidence for internal reporting and audit discussions

This matters because DORA is not only asking whether policies exist. It is pushing financial firms to demonstrate that ICT services can withstand, respond to and recover from disruption.

Example DORA testing scenarios where network emulation can help

A practical DORA testing programme may include scenarios such as:

Payment service degradation

A payment platform may work perfectly under normal conditions but begin to fail when latency or packet loss increases. Network emulation allows teams to test how payment flows behave under degraded network conditions and understand the thresholds where service quality or transaction completion is affected.

Data centre interconnect disruption

Many banks and financial infrastructure providers rely on multi-site architectures. Network emulation can help test how replication, synchronisation and failover behave when the connection between sites experiences delay, loss, congestion or asymmetry.

Cloud and hybrid application performance

Cloud and hybrid environments introduce dependencies across regions, providers and APIs. Network emulation can help teams validate how applications behave when cloud connectivity is unstable, rather than assuming production paths will always perform as expected.

Disaster recovery and failover validation

Recovery objectives can look achievable on paper but fail under real network stress. By applying controlled impairment, teams can test whether recovery time objectives, recovery point objectives and service continuity expectations remain realistic when the network is degraded.

ICT third-party dependency testing

DORA places significant emphasis on ICT third-party risk. Network emulation can help financial entities and their providers test the impact of degraded connectivity to outsourced platforms, managed services, data centres, cloud providers or payment infrastructure.

What comprehensive DORA resilience testing looks like

A strong approach to DORA operational resilience testing should be structured, repeatable and evidence-led.

It should include:

• Defined scenarios linked to critical or important functions
• Clear test objectives and success criteria
• Realistic network conditions, not only synthetic load
• Safe test environments that avoid unnecessary production risk
• Repeatable testing before and after remediation
• Evidence that can support internal governance, audit and compliance discussions.

The aim is not to create disruption for its own sake. The aim is to understand how critical ICT services behave under stress before a real incident occurs.

For network and infrastructure teams, this creates a more practical conversation with risk and compliance stakeholders. Instead of only saying “the recovery plan exists”, teams can show what was tested, what conditions were applied, what happened, what improved and where further action is needed.

How Calnex network emulation supports financial resilience testing

Calnex network emulation solutions, including the SNE and SNE-X range, help financial organizations test network and application performance under controlled, repeatable conditions.

For financial services, this is especially relevant where teams need to test across:

• 1G, 10G, 100G and 400G environments
• Data centre and multi-site architectures
• Cloud and hybrid networks
• Payment infrastructure
• Disaster recovery and failover paths
• High-speed financial infrastructure

By recreating real-world network disruption in a controlled environment, network emulation helps financial firms validate resilience before production systems are exposed to the same conditions.

DORA compliance testing should not be treated as a one-off regulatory exercise. The organisations that benefit most will use it as an opportunity to improve operational confidence.

That means asking more practical questions:

• Can critical ICT services continue under degraded conditions?
• Can recovery plans be proven, not just documented?
• Can third-party dependencies be tested before they become incident points?
• Can resilience testing produce repeatable evidence for future audits and internal risk reviews?

For many financial firms, the next step is to look beyond policy and monitoring, and begin testing the conditions that real networks actually experience.