The short answer
A DORA board tabletop should test whether leaders receive usable information, make timely decisions and preserve a reliable record while operational teams manage the incident. Use a realistic disruption, separate incident classification from business urgency, and practise the actual reporting route with its distinct clocks. This guide supplies a 90-minute fictional exercise, facilitator questions, a decision log and a follow-up tracker. The format is a practical recommendation, not a prescribed DORA exercise or proof of compliance. Adapt the scenario, authority levels and reporting obligations to your financial entity before running it.
1. Test decisions, not the ability to recite the regulation
The difficult board decision in a serious technology incident is rarely “Should we take this seriously?” It is more likely to be whether to stop a business service, operate with reduced controls, fund an emergency alternative or make a customer statement while the facts remain incomplete. A tabletop exposes these tensions before a real incident.
DORA Articles 17–19 address incident management, classification and reporting. Article 17 includes escalation to relevant senior management and information for the management body about major incidents, their impact, response and additional controls. That does not make the board the operational incident commander. The exercise should test whether responsibilities and escalation work together.
Set three practical outcomes: a clear decision with an owner, a reporting task with an accountable person and a record explaining the facts available at the time. Do not award a pass simply because everybody attended. The useful result may be discovering that nobody can access the reporting portal during an identity-system failure.
The exercise below is fictional training material. It does not replace technical recovery testing, a complete resilience-testing programme or threat-led penetration testing. The 90-minute duration is a suggested format, not a regulatory minimum.
2. Separate classification, urgency and board escalation
An incident can demand executive attention before its regulatory classification is settled. Conversely, a reportable major incident may require a prompt notification while recovery work is already succeeding. Do not make either decision depend on the chair being available to approve a press release.
The detailed classification rules are in Delegated Regulation (EU) 2024/1772. Article 8 combines affected critical services with specified materiality conditions; it is not a rule that every technical outage is automatically a major incident. The rules also address recurring incidents. Use an approved classification worksheet that applies the actual criteria and thresholds, rather than improvising a traffic-light rating during the meeting.
For the exercise, give a compliance or risk participant responsibility for the classification recommendation and its supporting facts. Give the incident lead responsibility for operational priorities. Give an authorised reporting officer responsibility for preparing and submitting the relevant notification. Your real allocation of authority may differ; write it down before the first inject.
- What is known about affected services, customers, transactions and data?
- What is an estimate, what supports it and when will it be refreshed?
- Which classification criteria are met, not met or still uncertain?
- Who can decide and act if the usual accountable person is unavailable?
Record the actual awareness time and classification time separately. A later executive briefing does not restart the awareness clock. Equally, identifying an incident and concluding that it is major are distinct events that need an accurate chronology.
3. Practise the reporting clocks with a worked example
The following summary concerns major ICT-related incident reporting under Article 5 of Delegated Regulation (EU) 2025/301. Use the actual legal text and your competent authority’s reporting process for an incident.
| Stage | Ordinary timing rule |
|---|---|
| Initial notification | As early as possible; within four hours after classification as major and no later than 24 hours after awareness of the incident. |
| Later classification exception | If the incident was not classified as major within 24 hours of awareness and is classified later, notify within four hours of that later classification. |
| Intermediate report | Within 72 hours after submitting the initial notification, even if status or handling has not changed. An updated intermediate report is required without undue delay and in any case when regular activities have recovered. |
| Final report | No later than one month after the intermediate report, or the latest updated intermediate report where applicable. |
In our fictional example, awareness occurs Tuesday at 09:00 and major classification at 10:00. The ordinary initial-notification deadline is 14:00 Tuesday, subject to the duty to notify as early as possible. If submission occurs at 11:30 Tuesday, the 72-hour intermediate-report deadline runs to 11:30 Friday. A subsequent intermediate update changes the reference point for the one-month final-report deadline. One month is not shorthand for 30 days.
There is no blanket weekend pause. Where applicable, Article 5(4) allows submission by noon of the next working day when the deadline falls on a weekend or bank holiday in the reporting entity’s Member State. Paragraph 5 excludes initial and intermediate submissions by credit institutions, central counterparties, trading-venue operators and other financial entities identified as essential or important under NIS2. Under paragraph 6, authorities can also exclude other significant or systemic entities after notifying them; that decision applies to incidents reported after notification. Confirm applicability before relying on relief.
If unable to meet a deadline, inform the competent authority without undue delay and no later than the relevant deadline, explaining the reasons. This is not an automatic extension.
4. Prepare the room and the rules of play
Invite the chair or delegated executive decision-maker, a business-service owner, the incident lead, risk or compliance, legal, communications and a recorder. Include a supplier-management representative where the service depends on an external platform. One person can play several roles in a smaller organisation, but make the responsibilities explicit.
Send a short preparation pack: the relevant business service, escalation map, recovery objectives, reporting route, current contact list and a blank decision log. Ask participants to use the organisation’s real procedures. The facilitator controls fictional facts and the exercise clock. The recorder captures decisions, not a transcript of every conversation.
Keep exercise time separate from scenario time. A five-minute discussion may represent an hour in the fictional incident, but the facilitator must announce the jump. Label every message and draft “EXERCISE”. Do not send practice notifications to a regulator, customer or supplier unless participation has been arranged. Use a safe mock submission route.
Our fictional entity provides a customer payment service through an external processing platform. At 09:00 Tuesday, operations becomes aware of failed payment processing. The cause is unclear. For this exercise, the organisation has assessed the supported function as critical or important. Participants must still apply the major-incident classification criteria; the function label alone does not decide that outcome.
5. Run this 90-minute agenda
This agenda prioritises decision-making over slide presentation. The facilitator should stop lengthy technical speculation and request a decision, an information requirement or a named follow-up. Do not resolve every uncertainty for the participants: deciding what evidence is needed is part of the exercise.
| Exercise minutes | Activity | Output |
|---|---|---|
| 0–10 | Confirm scope, roles, authority and scenario facts. | Named decision-maker, incident lead and recorder. |
| 10–25 | Inject one: disruption and incomplete information. | Initial priorities, information requests and escalation decision. |
| 25–45 | Inject two: major classification and reporting route. | Recorded clocks, approved reporting responsibility and submission plan. |
| 45–65 | Inject three: recovery claim, customer pressure and supplier uncertainty. | Recovery conditions, communication decision and next review time. |
| 65–80 | Compare decisions with plans and identify gaps. | Prioritised findings with supporting observations. |
| 80–90 | Agree owners, dates and evidence for closure. | Action tracker and a targeted retest. |
If a decision is deferred, the recorder should capture who will return with which evidence and by when. “We would involve legal” is not a completed action if nobody identifies the legal contact, the question to be answered or the time available. The same standard applies to “call the provider” and “activate the recovery plan”.
6. Use three injects that force a real trade-off
Inject one: the service is failing, but the cause is uncertain
At scenario time 09:15, failed payments are increasing. The supplier acknowledges a platform problem but gives no recovery estimate. Some customers are retrying, creating a possible reconciliation problem. The operations team can temporarily restrict processing, but doing so will interrupt customers who may currently be unaffected.
Ask: which customer harm is being limited, and which new harm could the restriction create? Who has authority to change the service? What minimum facts are needed now? How will the team distinguish a delayed transaction from one that must be retried? The expected output is a bounded operational decision, a named owner and a review time, not a guess about the technical cause.
Inject two: classification is confirmed and the usual reporter is unavailable
At scenario time 10:00, the facilitator supplies an assessment showing that the affected-critical-services condition and the applicable materiality thresholds are met. For the exercise, the authorised team classifies the incident as major at 10:00. The normal reporting officer is unavailable. The deputy has never used the submission portal and does not know whether their access works.
Ask participants to identify the reporting route and complete a mock initial notification using the information available. Record unknowns honestly and assign their follow-up. What is the initial deadline? Who submits? Who confirms receipt? Can the organisation proceed without waiting for another scheduled board meeting? Use Implementing Regulation (EU) 2025/302 for the reporting templates and procedures; an exercise decision log is not a replacement for the regulatory form.
Inject three: the provider says service is back, but confidence is incomplete
At scenario time 11:15, the supplier says processing is restored. Internal reconciliation has not yet confirmed that duplicate attempts were handled correctly. A major customer requests a public assurance that no records were affected. The service owner proposes reopening immediately; the incident lead wants additional validation.
Ask what evidence supports reopening and who can accept any residual operational risk. Can the service reopen in stages? What can communications accurately say now? What update is needed for the competent authority? Set conditions for return to normal, a further validation owner and a specific next briefing. Do not reward the fastest reopening if participants cannot explain how customer records will be checked.
7. Keep a decision log that shows the reasoning
A good log makes it possible to reconstruct why a reasonable decision was made with incomplete information. It should distinguish a decision from an assumption and identify who can change it. The following example is fictional and illustrates a recording method, not a recommended response to every payment incident.
| Field | Worked example |
|---|---|
| Time and decision | 09:25: restrict new submissions through the affected channel pending reconciliation. |
| Information available | Failures increasing; provider has no recovery estimate; duplicate retries remain unconfirmed. |
| Options considered | Continue unchanged, restrict submissions, or route eligible transactions through an approved alternative. |
| Reason and authority | Limit further processing uncertainty; decision made by the authorised service executive. |
| Owner and next check | Operations lead implements and reports impact at 09:45. |
| Conditions for revision | Validated reconciliation result and an approved recovery recommendation. |
Keep awareness, classification and submission timestamps in the incident chronology alongside the log. Use a consistent time zone. Retain the source of significant facts and preserve earlier estimates when they change. A corrected customer-impact number should not silently overwrite the number on which the original decision was based.
8. Turn observations into an evidence-based action tracker
Begin the debrief with observations: what decision was delayed, which fact could not be obtained and which process could not be demonstrated? Avoid broad conclusions such as “communication was poor” without an example. Ask participants which decisions would have changed if the incident had started outside normal hours or affected their usual collaboration tools.
Retain the scenario version, attendance and roles, material decisions, classification worksheet, mock notifications, observed gaps and follow-up decisions. Protect the pack according to its sensitivity. The purpose is useful organisational learning, not unnecessary circulation of real customer information or supplier secrets.
| Observed gap | Action and owner | Suggested target | Closure evidence |
|---|---|---|---|
| Deputy could not demonstrate reporting access. | Compliance lead verifies authorised backup access and instructions. | Within two weeks. | Successful controlled access check and an updated rota. |
| Recovery approval lacked data-integrity criteria. | Service owner and operations define validation and sign-off. | Within one month. | Approved checklist used in a targeted recovery exercise. |
| Supplier updates lacked business-impact detail. | Supplier manager revises escalation questions and contact coverage. | Before the next service review. | Agreed escalation route demonstrated in a joint discussion. |
These targets are illustrative management choices, not statutory deadlines. Assign a reviewer for closure and retain unresolved residual risk. Feed material findings into the board reporting dashboard. If the exercise exposes an external dependency with no credible alternative, use the third-party risk guide to connect the finding to contracts, concentration and exit planning.
9. Connect executive learning to the next retest
The most useful follow-up is a smaller exercise that proves a corrected weakness. If the first session exposed a reporting-access problem, demonstrate the deputy’s route. If it exposed uncertainty about reopening a service, retest the approval conditions. Repeating the same presentation with the same unresolved gaps provides little new assurance.
Use the DORA board training requirements guide to connect the exercise to continuing management-body learning. BlueTeam Academy’s DORA Board & Executive Training introduces the governance concepts for leadership teams at financial entities within DORA’s scope. Course completion or an attendance record does not establish organisational compliance. Pair that foundation with your own service context, observed decisions and verified improvements.
Questions leaders ask
Does every ICT incident have to be reported as major under DORA?
No. Apply the classification rules and materiality thresholds in Delegated Regulation (EU) 2024/1772. A serious operational concern can merit internal escalation while the regulatory assessment is still developing. Record the assessment and revisit it as facts change.
Is the initial DORA reporting deadline always 24 hours?
No. The ordinary rule requires notification as early as possible, within four hours of major classification and no later than 24 hours after awareness. A specific rule applies when classification as major occurs later than 24 hours after awareness. The clocks should be recorded separately.
Does a tabletop satisfy all DORA testing requirements?
No. This board exercise practises executive decisions and coordination. It does not demonstrate technical recovery or replace the applicable resilience-testing programme, specialist tests or threat-led penetration testing.
Should the board approve every incident notification?
Use an authority model that enables timely reporting and appropriate management-body information. Do not invent an approval dependency that makes the statutory deadline unattainable. Document the authorised submitter, deputy and escalation route before an incident.
Sources and further reading
Primary legislation and supervisory material. Practical examples and templates in this guide are suggestions, not prescribed regulatory forms.
- Regulation (EU) 2022/2554: incident management, classification and reporting
- Delegated Regulation (EU) 2024/1772: classification and materiality thresholds
- Delegated Regulation (EU) 2025/301: reporting content and time limits
- Implementing Regulation (EU) 2025/302: reporting templates and procedures
This guide is educational. Confirm your entity’s scope, applicable framework and supervisory requirements with your legal and compliance team.
