What do financial institutions get wrong about testing for DORA readiness?

A common mistake is treating resilience testing as a compliance exercise rather than a way to expose real weaknesses. The article shows why assumed safety is dangerous: segmentation gaps, weak containment, and poor recovery planning can leave large parts of the environment exposed. Effective testing should simulate attacker movement, validate containment, and confirm critical services can recover under pressure.

What financial institutions usually misread about DORA testing

DORA readiness testing fails when institutions treat it like a checklist for proving the programme exists, rather than a way to expose whether the business can actually withstand disruption. The most common blind spot is assuming that documented controls equal operational resilience, even when segmentation, containment, recovery sequencing, or dependency mapping has never been challenged under realistic pressure.

The better test design starts from failure modes, not policy statements. If an environment can be moved laterally, if critical services depend on brittle shared services, or if recovery steps are unclear, the institution has not really demonstrated resilience, only paperwork compliance. That is why tests need to reflect how systems behave when an attacker, outage, or control failure forces the organisation to contain and recover at speed.

That distinction is especially important in financial services because DORA is about proving operational robustness in practice. A resilience exercise that never tests blast radius, escalation paths, or service restoration order can leave a firm believing it is prepared when it is only prepared to describe its controls.

What a useful DORA test should prove

A meaningful test should answer three practitioner questions: can the institution limit spread, can it sustain essential operations, and can it restore critical services within a tolerable time? Those questions are more demanding than “did the team execute the scenario,” because they force evidence about control effectiveness, not just participation.

Good exercises also separate technical recovery from business recovery. It is not enough for a system to come back online if user access, downstream interfaces, data reconciliation, or manual workaround steps still prevent the institution from serving customers or meeting obligations. In other words, recovery is only real when service, not just infrastructure, is back.

For financial institutions, the test design should also reflect third-party and shared-platform dependencies because those are often where hidden concentration risk lives. If a service depends on external providers, common administrative paths, or shared tooling, the exercise should verify what remains controllable when one layer is unavailable or compromised.

For deeper background on the identity and secret-management weaknesses that often undermine resilience, see Ultimate Guide to NHIs and its Regulatory and Audit Perspectives. For the underlying regulatory baseline, the EU Digital Operational Resilience Act (DORA) is the relevant authority reference.

Risk and Threat Considerations

The main risk is false confidence. If testing only validates planned behaviour, weak containment can remain invisible until an actual incident turns a small fault into a broader outage, data exposure event, or prolonged recovery failure. The same problem appears when dependency chains are not stress-tested, because correlated failures can disable multiple services at once.

Failure mechanism: A resilience test that does not simulate realistic movement, isolation failure, or recovery pressure will miss the conditions under which segmentation breaks down and critical services cannot be restored in the correct order.

Impact: The institution may pass a compliance review while still being unable to contain an incident, maintain essential operations, or recover within the time its business and regulators would expect.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	RC.RP-1 — Recovery Plan Executed	Tests must prove services can recover under pressure.
	PR.AC-4 — Access Permissions and Authorizations Managed	Containment depends on enforcing boundaries during disruption.
	ID.BE-4 — Dependencies and Critical Functions Identified	DORA testing depends on knowing which services and dependencies matter most.
Recommendation — Exercise recovery steps until critical services meet recovery expectations. Verify access boundaries still constrain movement during failure. Map critical dependencies before running resilience scenarios.
DORA	Article 24 — Digital operational resilience testing	The question is specifically about testing readiness under DORA.
	Article 25 — Advanced testing	Material scenarios should reflect realistic operational stress and control failure.
	Article 3 — ICT risk management	Readiness testing is part of managing ICT risk across the institution.
Recommendation — Design tests to prove operational resilience, not just compliance completion. Use realistic scenario-based testing where risk and scale justify it. Treat resilience testing as validation of ICT risk controls.
CIS Controls v8	5 — Account Management	Weak account control can undermine containment and recovery during tests.
	12 — Network Infrastructure Management	Segmentation gaps are a key failure mode in resilience testing.
	17 — Incident Response Management	Recovery exercises should validate response and restoration coordination.
Recommendation — Audit privileged and service accounts before relying on test results. Validate segmentation and isolation controls under stress scenarios. Run exercises that test escalation, containment, and restoration together.

Practitioner Guidance

What to verify: Validate the specific control outcome, not the exercise attendance record. The test should prove that containment works, dependencies are known, and restoration can happen in a sequenced, repeatable way under stress.

What practitioners underestimate: Recovery is often blocked by the “last mile” of operations, such as manual approvals, identity dependencies, reconciliation, or external service coordination. If those steps are not exercised, the organisation is still guessing about real recoverability.

Decision rule: If a scenario does not challenge segmentation, privilege boundaries, and restore order, treat it as a documentation exercise, not a resilience test.

Practitioner takeaway: DORA readiness is demonstrated by surviving a believable failure, not by completing a scripted exercise.