DORA-Compliant Tabletop Exercises: From Regulatory Evidence to Real Operational Resilience

The EU Digital Operational Resilience Act (DORA) has changed the standard for ICT resilience in financial services. A policy that looks complete on paper is not enough. Financial entities must be able to demonstrate that critical or important functions can continue through severe disruption, that response and recovery plans work, and that lessons from testing are acted upon.

Tabletop exercises can support that objective. But accuracy matters: **DORA does not say that every financial entity must conduct a tabletop exercise by that name.** It requires a risk-based digital operational resilience testing programme, lists scenario-based tests among the appropriate testing methods, and separately requires recurring tests of ICT business continuity, response and recovery, and crisis communication plans. A tabletop is therefore one useful method within a broader programme—not a substitute for technical testing or, where applicable, threat-led penetration testing (TLPT).

What DORA actually requires

DORA has applied since 17 January 2025. The obligations are proportional to an entity’s size, overall risk profile, and the nature, scale, and complexity of its services, activities, and operations. Microenterprises and entities subject to the simplified framework receive specific treatment, so organizations should confirm scope with qualified counsel or their competent authority.

For most financial entities, the tabletop-relevant requirements include:

1. Test continuity, response, recovery, and communications

Article 11 requires financial entities to test ICT business continuity plans and ICT response and recovery plans for ICT systems supporting all functions at least yearly, and after substantive changes to ICT systems supporting critical or important functions. Crisis communication plans must also be tested.

For entities other than microenterprises, the testing plans must include cyberattack scenarios and switchovers between primary ICT infrastructure and redundant capacity, backups, and redundant facilities.

2. Maintain a risk-based testing programme

Articles 24 and 25 require a sound and comprehensive digital operational resilience testing programme. It must use an independent party—internal or external—to conduct testing, avoid conflicts of interest, prioritize and remediate findings, and validate that weaknesses have been addressed. Appropriate methods may include vulnerability assessments, source-code reviews, scenario-based tests, end-to-end tests, performance tests, and penetration tests.

Entities other than microenterprises must ensure that appropriate tests are conducted at least yearly on all ICT systems and applications supporting critical or important functions.

3. Use severe but plausible scenarios and challenge assumptions

Commission Delegated Regulation (EU) 2024/1774 makes the business-continuity testing standard more concrete. Testing should be based on an adequate set of severe but plausible disruption scenarios, include relevant third-party ICT services, challenge governance and crisis-communication assumptions, and verify that staff, providers, systems, and services can respond adequately.

Where relevant, scenarios should address third-party provider failure or insolvency and political risk in provider jurisdictions. Tests should take the business impact analysis and ICT risk assessment into account.

4. Capture evidence, deficiencies, and remediation

DORA expects testing to drive improvement. Financial entities other than microenterprises must establish procedures to prioritize, classify, and remediate issues found during testing and validate that weaknesses, deficiencies, or gaps are fully addressed. Lessons from tests and real incidents must be incorporated continuously into the ICT risk assessment process.

The delegated regulation also requires documented test results under the simplified framework, analysis and correction of deficiencies, and reporting to the management body. Even where that specific provision does not govern an entity, documented evidence and accountable remediation are sensible supervisory proof that testing influenced the resilience programme.

5. Do not confuse a tabletop with TLPT

Certain financial entities identified by competent authorities must conduct advanced TLPT at least every three years, subject to possible adjustment by the authority. TLPT is a controlled, intelligence-led test of live production systems supporting critical or important functions. A discussion-based or simulated tabletop does not satisfy TLPT requirements.

A practical DORA-aligned tabletop design

A useful tabletop should trace directly to the organization’s resilience framework rather than beginning with a generic ransomware slide deck.

Before the exercise

1. **Define scope.** Identify the critical or important functions, supporting ICT systems, information assets, business processes, and third-party dependencies being tested.

2. 2. **Connect the scenario to risk.** Use the business impact analysis, ICT risk assessment, current threat information, and lessons from incidents and previous tests.

3. 3. **Set measurable objectives.** Decide what success means for detection, escalation, incident command, containment, continuity, recovery, decision-making, regulatory reporting, and stakeholder communication.

4. 4. **Include the right participants.** Bring together ICT, security, operations, risk, legal, compliance, communications, executive leadership, and relevant third parties. DORA resilience is not an IT-only responsibility.

5. 5. **Protect independence.** Ensure that the people assessing performance can challenge the plan and are not simply validating their own work.

During the exercise

1. **Use a severe but plausible disruption.** Make the facts specific to the entity’s real environment and business model.

2. 2. **Challenge assumptions.** Test incomplete information, conflicting priorities, unavailable personnel, degraded tools, third-party failure, and pressure from customers, regulators, and the media.

3. 3. **Exercise decisions, not recollection.** Participants should make choices, communicate, escalate, and trade off containment against continuity—not merely explain what the plan says.

4. 4. **Test communications.** Force the team to produce internal updates and credible external messages while the technical picture is still changing.

5. 5. **Capture evidence.** Record decisions, timestamps, assumptions, communications, observed consequences, and the plan or control being tested.

After the exercise

1. **Document results.** Preserve the scenario, objectives, participants, timeline, decisions, findings, and supporting evidence.

2. 2. **Classify deficiencies.** Link each finding to affected functions, systems, plans, controls, owners, and risk.

3. 3. **Assign remediation.** Give each action an accountable owner, due date, priority, and validation method.

4. 4. **Report upward.** Give the management body a concise view of material gaps, business impact, investment needs, and residual risk.

5. 5. **Retest.** Confirm that corrective actions work. Closing a ticket is not the same as validating resilience.

Traditional tabletops versus Reflex Security

Traditional tabletops can meet an important need. A skilled facilitator, a credible scenario, and disciplined documentation can produce valuable discussion and support DORA evidence. The problem is that many exercises are static, generic, and optimized for completion rather than learning.

How Reflex supports DORA—and goes beyond compliance

Reflex is not a certification authority, and no software platform can make an organization DORA-compliant by itself. Compliance depends on scope, governance, the complete testing programme, remediation, documentation, and supervisory expectations. Reflex contributes where DORA and operational readiness overlap: realistic scenario-based testing of people, decisions, coordination, and communications.

Organization-specific, severe-but-plausible scenarios

Generic scenarios struggle to expose real dependencies. Reflex creates tailored scenarios from the organization’s actual environment, tools, and threat context. That helps teams examine critical functions, third-party relationships, governance assumptions, and plausible business consequences instead of rehearsing a breach that could belong to anyone.

Adaptive pressure instead of predetermined discussion

In a static tabletop, the facilitator knows the path and participants can often talk around hard decisions. Reflex uses an adaptive adversary and pressured stakeholder agents that respond to what the team actually does. A containment choice can affect operations. Silence can increase customer or media pressure. Weak escalation can leave executives acting on stale information.

changes the question from “Does the plan contain the right steps?” to “Can this team execute when facts are incomplete and priorities collide?”

Evidence at the level of decisions

A traditional after-action report often reflects the facilitator’s notes and memory. Reflex generates an evidence-backed report when the exercise ends, tracing findings to moments in the simulation. This can strengthen internal review, management reporting, remediation decisions, and proof that the exercise tested more than attendance.

More practice, not merely one annual event

An annual test may satisfy a minimum frequency for a specific requirement, but teams do not build durable crisis capability with one conversation a year. Because Reflex reduces scenario-writing, facilitation, and reporting effort, organizations can run narrower exercises throughout the year: third-party outage, destructive ransomware, identity compromise, backup failure, executive communications, or regulatory notification.

Frequent repetitions allow leaders to determine whether performance is improving, whether the same coordination gaps recur, and whether remediation changed behavior.

Operational value that compliance alone cannot provide

A DORA-aligned exercise can produce an audit trail. A high-quality simulation should also produce better incident outcomes. Reflex helps customers:

• expose unclear decision rights before a real crisis;

• - test coordination among technical, legal, communications, operations, and executives;

• - surface hidden dependencies and unrealistic recovery assumptions;

• - practice difficult containment-versus-continuity tradeoffs;

• - improve the quality and speed of stakeholder communications;

• - identify coaching needs at the team and role level;

• - validate remediation through repeated simulations; and

• - give leadership evidence for targeted resilience investments.

That is the difference between documenting preparedness and developing it.

The bottom line

A DORA-compliant testing programme is broader than a tabletop, and a tabletop is broader than a compliance meeting. The strongest exercises connect risk, critical functions, third-party dependencies, recovery, governance, and communications; create severe but plausible pressure; document what happened; and drive validated remediation.

Traditional tabletops can support those goals when they are designed and facilitated well. Reflex makes the same discipline