DORA Resilience Testing: Can Your Incident Response Plan Survive a Payment Disruption?

A bank's payment queue is growing. The SOC has identified suspicious activity involving a privileged account, but isolating it could interrupt transactions that customers are waiting to complete.

The security team wants to contain the threat. Payment operations wants to understand the consequences. The supplier responsible for the integration hasn't confirmed whether its own systems are affected.

Who makes the call?

These are the decisions that matter when a cyber incident threatens a financial service.

What DORA Expects Financial Institutions to Test

DORA has applied since 17 January 2025, establishing a common framework for managing information and communication technology (ICT) risks across the EU financial sector.

It covers banks, insurers, payment institutions, investment firms and other financial entities within its scope, with requirements that vary according to the type and size of organisation.

For security and operational resilience leaders, the important distinction is between having an incident response plan and demonstrating that the organisation can carry it out.

Under Articles 24 and 25 of DORA, financial entities other than microenterprises must establish a risk-based digital operational resilience testing programme. This includes:

• Testing ICT systems and applications supporting critical or important functions at least annually, using appropriate tests.
• Using suitable methods, which may include scenario-based testing, vulnerability assessments, end-to-end testing and penetration testing.
• Arranging independent internal or external testing, with conflicts of interest appropriately managed.
• Prioritising, correcting and validating weaknesses identified through testing.

Microenterprises have proportionate testing requirements under Article 25.

There is also a more advanced requirement under Article 26. Financial entities selected by their competent authorities must undertake threat-led penetration testing (TLPT) at least every three years, subject to supervisory adjustment.

That involves a specific regulatory process, including testing on live production systems supporting critical or important functions. The detailed requirements are set out in Commission Delegated Regulation (EU) 2025/1190.

A tabletop exercise or simulated breach can support a broader DORA resilience testing programme by identifying response weaknesses and developing operational capability.

Its regulatory treatment depends on the applicable requirements and how the exercise is designed, governed and evidenced.

The practical opportunity is to use targeted exercises to uncover weaknesses before a real disruption exposes them.

Start With the Service You Cannot Afford to Lose

Security teams often design exercises around an attack technique, for example, ransomware, credential theft or a compromised administrator account.

For financial institutions, the more useful starting point is often the business service affected.

Consider these three examples:

(1) A bank needs to maintain payment processing and establish whether queued transactions are still valid.

(2) An insurer needs claims handlers to continue processing urgent cases despite disruption to its identity provider.

(3) An investment firm needs to assess the consequences of losing access to a market-data service during trading hours.

Each scenario creates different operational decisions, dependencies and recovery requirements. Choose a service that your organisation has identified as critical or important, then work backwards.

Identify the applications, identities, infrastructure and third-party providers supporting it. Review the service's established recovery objectives and determine which decisions could affect customers or other financial counterparties.

For a payment-processing exercise, the objective might be:

That is a practical exercise objective, rather than a regulatory definition of successful DORA testing.

It gives the team a clear problem to investigate.

The aim is to understand whether the institution can protect the service and recover it safely, even when the incident doesn't unfold exactly as the response plan anticipated.

Why Recovery Deserves as Much Attention as Detection

The European Central Bank's 2024 cyber resilience stress test offers a useful precedent.

It examined 109 directly supervised banks, with 28 undergoing more extensive testing that included an actual IT recovery test.

The scenario assumed a successful cyberattack had disrupted core banking systems. Banks had to demonstrate how they would respond and recover.

ECB concluded that banks had response and recovery frameworks in place, while identifying areas requiring improvement.

This is important for exercise planning. A team may detect an attack quickly yet struggle to restore the affected service, coordinate with a supplier or establish whether the recovered information can be trusted.

Put Your Payment Response Plan Through a Realistic Scenario

Let's say there's a fictional bank whose payment-processing service depends on an integration maintained by an external technology provider.

The SOC detects unusual activity involving a privileged integration account. The same account also performs legitimate scheduled jobs, making the initial evidence difficult to interpret.

Payment operations then reports that transactions are beginning to queue.

The supplier acknowledges the security alert but cannot immediately confirm whether its environment is affected.

The incident commander now has a difficult decision: restrict access and risk interrupting the payment flow, or continue operating while the team investigates.

A useful exercise introduces information in stages so participants have to reassess their decisions as the incident develops.

The scenario creates room for several valid decisions, depending on the evidence.

The security team might recommend restricting only the affected credential while preserving other authorised payment flows. That response would need to be assessed against the account's actual permissions and technical dependencies.

Alternatively, the evidence may justify pausing the integration while payment operations activates a documented contingency process.

The important part is whether the team can explain its decision, follow the correct approval route and verify the result. An exercise should expose the consequences of those choices without giving participants the answer in advance.

Different Questions Need Different Exercises

A discussion-based tabletop is useful when the main uncertainty concerns authority, coordination or business impact.

It can reveal whether the incident commander knows who can suspend a payment service, whether the supplier's escalation contact is available, and how customer-facing teams receive an update.

But a tabletop depends heavily on what participants say they would do. Hands-on exercises reveal a different set of weaknesses.

They can demonstrate whether analysts can retrieve the right evidence, investigate related activity and carry out authorised response actions.

For financial institutions, combining both methods often produces the best results.

Tabletop: Test the Decision

Present participants with the suspected compromise and its operational consequences.

Ask the relevant teams to use their existing procedures.

If the incident commander wants to revoke a privileged integration account, the service owner should be able to explain what depends on it and whether a narrower response is possible.

Observers can assess whether the decision was supported by the available evidence and the organisation's delegated authority.

Hands-On Simulation: Test the Execution

Take the technical actions identified during the tabletop and recreate them in a controlled environment.

For example, analysts could investigate simulated authentication and application logs, identify the compromised identity and demonstrate the relevant containment procedure. Then test the information that reaches the next responder.

Does the case record show what was contained? Can the receiving analyst identify which access remains under investigation?

A successful tabletop decision does not establish that the corresponding production control would work as expected. The hands-on test needs its own scope and evidence, with remaining production dependencies assessed separately.

The two methods complement each other because they examine different parts of the response.

What Evidence Would Convince a Reviewer?

A polished exercise report is useful only when it reflects what participants actually demonstrated.

Capture the significant decisions, the evidence available at each point and the result of the action taken.

1. What was tested?

Identify the service, supporting systems, scenario, scope and relevant procedures. Record important exclusions so the result isn't interpreted more broadly than the exercise supports.

2. Who made the decision?

Document the accountable role, the information used and the approval route followed. If a participant needed authority from another team, record whether that authority was obtained through the normal process.

3. What did the team demonstrate?

Separate statements of intent from observed performance.

"The SOC would revoke the credential" establishes a proposed action.

"The responder identified the credential, executed a simulated revocation and verified the resulting state" demonstrates a narrower, observable capability.

4. What delayed or weakened the response?

Record missing information, inaccessible systems, unavailable decision-makers and unclear procedures.

These details can explain why a technically competent team struggled to progress.

5. What needs to happen next?

Connect material findings to remediation owners and a method for validating the correction.

The resulting evidence can support internal assurance and inform the broader resilience testing programme, subject to the organisation's governance and applicable regulatory requirements.

Keep sensitive technical records appropriately controlled, with summaries tailored to the stakeholders who need them.

Where TryHackMe Fits Into Financial Services Resilience Testing

For financial institutions, exercises need to become part of regular operational preparation rather than occasional events organised around an audit deadline.

TryHackMe provides two complementary ways to develop and assess those capabilities.

Test Coordination With Tabletop Exercises

TryHackMe Tabletop Exercises let teams build scenarios around their environment, security threats and incident response procedures.

For a financial-services organisation, that could mean designing a scenario involving compromised privileged access, disruption to a payment service or a third-party outage.

Participants work through the decisions while the platform records responses, exposes differences in judgement and provides a structured report for follow-up.

The approach is useful for examining escalation paths, communication and cross-functional responsibilities.

Put Responders to Work With Live Breach

When the concern is whether technical teams can execute the response, Live Breach Exercises provide a more hands-on assessment.

TryHackMe builds controlled environments around the organisation's relevant tooling, threats and workflows.

Teams investigate realistic attack activity, work through containment and eradication, and make recovery and handover decisions.

The exercise produces evidence-led findings that can inform training priorities and improvements to operational procedures.

These activities support the development and assessment of response capability. They should be placed within the institution's wider testing and assurance programme according to the applicable regulatory requirements.

For banks and other financial institutions, the strongest use is to target a specific resilience question and connect the exercise result to a measurable improvement.

The Test Is What Happens After the Alert

A financial institution's resilience depends on decisions that extend far beyond detecting malicious activity.

The SOC needs reliable evidence. Incident leaders need clear authority. Service owners need to understand the business consequences of containment. Recovery teams need confidence that systems and transactions can be trusted again.

DORA gives institutions a reason to examine those capabilities systematically.

A well-designed exercise gives them something more immediate: evidence of how their people and processes would perform when a critical service is disrupted.

And that evidence is most useful when it leads to a stronger response before the next incident.