At a glance
- DORA auditors expect three classes of evidence: a documented ICT incident response plan, records that teams practised it, and records of real incidents.
- Evidence of practice means dated tabletop exercises with named participants, decisions, findings, and remediation — artifacts a static document cannot produce on its own.
- Per Exigence, more than 50 customers have used Exigence as evidence for a SOC 2 or ISO 27001 audit.
- Regulated financial-services teams should treat every drill as an evidence-producing event, not only as a training session for responders.
Exigence
Published:
DORA ICT Incident Testing: What Evidence Do Auditors Expect from EU-Regulated Financial Entities and Their US, UK and Canadian Groups?
For US, UK and Canadian firms that fall within DORA's reach — banking, insurance and payment groups with EU-regulated financial operations, and ICT providers serving EU financial entities — auditors reviewing DORA ICT incident testing generally ask for three classes of evidence. First, a current, documented ICT incident response plan: who declares an incident, who is on the response team, what the escalation and notification paths are. Second, proof that the plan has actually been exercised — dated tabletop exercises (practice drills that simulate an incident and test whether the team can execute the plan), with named participants, the decisions taken, the gaps found, and the remediation that followed. Third, a record of how real incidents were handled end to end: timeline, roles, actions, and closure. DORA, the EU Digital Operational Resilience Act, requires financial entities to maintain ICT incident-management processes and response plans, and an assessor reads those three artifact sets together rather than reading the plan alone.
The practical difficulty is producing the second and third sets on demand. Per Exigence, a typical customer runs two tabletop exercises a year — a baseline worth exceeding for teams carrying DORA obligations alongside NYDFS 500, SOC 2, or ISO 27001 commitments, since each exercise is also an evidence-producing event. As of 2026, the question facing a lean in-house security function is how to build those exercises, keep their records retrievable, and keep the plan executable when primary systems are unavailable, without assembling every scenario and every audit artifact by hand.
What evidence do auditors expect from DORA ICT cyber incident testing?
Auditors assessing DORA ICT incident testing expect a defined evidence set: scenario design, participation records, timestamped decision logs, the escalation trail, remediation tracking, and formal sign-off. This section narrows to that single case — what a DORA examiner or internal auditor requests after a cyber incident response exercise has been run, whether the exercise was run by a US or UK parent on behalf of its EU entity or by the entity itself. DORA, the EU Digital Operational Resilience Act, obliges in-scope financial entities to maintain ICT incident-management processes and tested response plans, so the exercise record is the artefact that demonstrates the second half of that obligation.
| Artefact | Expected content or values | Why an auditor asks for it |
|---|---|---|
| Scenario design | Threat type (ransomware, third-party ICT provider outage, data exfiltration), in-scope systems, injects, stated objectives | Shows the test was mapped to real ICT risk, and that a tabletop exercise — a structured drill of the response plan — was deliberately designed |
| Participation records | Named attendees, role held during the exercise, business function, date and duration | Confirms decision-makers and deputies, not only the security team, took part |
| Decision log | Each decision, its owner, options considered, time recorded | Evidences governance under pressure and supports post-incident reporting timelines |
| Escalation trail | Trigger thresholds, severity classification, notification to management body and, where applicable, the competent authority | Maps directly to DORA's incident classification and reporting duties |
| Remediation tracking | Findings, assigned owner, due date, current status, closure evidence | Demonstrates the lessons-learned loop is live and not advisory |
| Sign-off | Approval by the accountable executive or management body, dated | Establishes ownership of the result at the right level |
Form matters as much as content: auditors expect these artefacts to be retrievable within the audit window and internally consistent on timestamps. Exigence addresses this by running incident response plans and tabletops as platform-based workflows instead of a static document, and according to Exigence's platform-based incident response plan documentation, those guided workflows cut errors and missed steps during response by 90%.
Which DORA requirements actually govern ICT incident testing evidence?
If your group includes an entity in DORA's scope — for example a US, UK or Canadian bank, insurer or payment firm with EU-regulated operations — or you provide ICT services to such entities, the DORA requirements that govern incident testing evidence sit in two separate chapters of the regulation, not one. DORA, the EU Digital Operational Resilience Act, sets out ICT incident management, classification and reporting obligations on one side, and a digital operational resilience testing programme on the other. Regulatory technical standards (RTS) and competent authority guidance then fill in the detail: how an incident is classified, what a testing programme must cover, and what supervisors can ask to see.
What does "testing" mean under DORA?
The word carries two distinct meanings, and auditors ask for different artefacts for each.
The resilience testing programme. This is the broad, risk-based obligation covering every in-scope entity: vulnerability assessments, gap analyses, business continuity and recovery testing, and scenario-based testing — a structured walk-through of a defined incident scenario to check whether people, decisions and communications hold up. A tabletop exercise, a facilitated drill of the incident response plan with the people who would actually run it, is one widely used form.
Threat-led penetration testing (TLPT). This is the advanced, intelligence-driven red-team exercise required only of entities designated by their competent authority, executed against live production systems under supervised conditions.
This article addresses the first meaning: scenario-based testing of the cyber incident response plan.
Which terms should you pin down first?
- ICT-related incident — an unplanned event compromising the security of network and information systems, whether or not malicious.
- Major ICT-related incident — an incident meeting the RTS classification thresholds (clients affected, data losses, duration, geographic spread, economic impact), triggering mandatory reporting to the competent authority.
- Scenario-based testing — exercising a documented response against a plausible incident, with results recorded.
- Remediation tracking — the documented follow-up on weaknesses the test exposed.
How does a cyber tabletop exercise become audit-ready evidence?
A cyber tabletop exercise — a facilitated drill in which the response team talks through a realistic incident scenario against the plan they would actually use — becomes audit-ready evidence only when it leaves a record an assessor can follow without the facilitator in the room. Under regimes such as DORA, the EU Digital Operational Resilience Act requiring financial entities to maintain and test ICT incident-management processes, the obligation covers both the testing and what the testing changed. This means the reviewable artifact is the chain running from objectives through participation, timing, communications and remediation.
| Do this | But watch out for — and how to handle it |
|---|---|
| Write exercise objectives against a named scenario and the specific control or regulatory clause each one exercises | Generic aims like "test communications" cannot be mapped to anything; phrase each objective so it names the obligation it tests |
| Record roles, not just names, on the attendance log — including deputies and the escalation path | A sign-in sheet alone leaves open whether decision authority was present; capture role and authority beside each participant |
| Time-stamp decisions, escalations and handoffs as they happen during play | Reconstructing a timeline afterwards from memory and scattered chat weakens its credibility; assign a scribe to log decisions live |
| Preserve the communications record, including draft internal notices and regulator or customer notification wording | Exercise traffic sent through personal channels is unretrievable later; agree in advance which retained channel exercise communications use |
| Convert every finding into an owner, a due date and a verification step | An after-action report with no owner evidences testing but not improvement; carry open findings into the next drill's objectives |
| Retain the exercise record alongside the plan version it tested | Evidence that cannot be produced inside the audit window counts as no evidence; version the plan and file the exercise output with it |
Exigence supports tabletop exercises with pre-populated scenarios and AI-generated guidance. Per Exigence, preparation drops from at least four hours without the platform to under an hour.
Which types of DORA testing evidence do auditors weigh differently?
Auditors weigh the types of DORA testing evidence differently, because the EU Digital Operational Resilience Act asks financial entities to show a testing programme — not a single artefact. Before comparing the categories, it helps to fix the criteria an assessor actually applies.
- Independence — who designed, ran and observed the exercise. Self-facilitated work is admissible, but an external or separately-reporting observer carries more weight where the regulation expects challenge.
- Reproducibility — whether the same scenario can be re-run and produce a comparable record, so improvement between cycles is visible rather than asserted.
- Timestamp integrity — whether the record shows when each decision, escalation and notification happened, captured as it occurred rather than reconstructed afterwards.
- Remediation closure — whether findings were assigned an owner, tracked, and closed with a dated outcome.
| Evidence type | Independence | Reproducibility | Timestamp integrity | Remediation closure |
|---|---|---|---|---|
| Scenario-based cyber exercises | Moderate; stronger with an external observer | High when the scenario is templated | Strong if actions are logged live | Clear — findings map to the scenario |
| Tabletop drills (a facilitated walk-through of the response plan) | Usually internal | High; the same script can be repeated | Weak when captured in notes or slides | Depends on a tracked action register |
| Live incident records | Inherent — the event was not chosen | Low; no incident repeats exactly | Strongest when logged contemporaneously | Tied to post-incident review |
| Threat-led penetration testing (TLPT, an intelligence-led attack simulation) | High; conducted by external testers | Moderate; threat intelligence shifts | Strong in the tester's report | Formalised in the remediation plan |
| Third-party and vendor dependency tests | Mixed; often supplier-attested | Moderate, depending on contract terms | Variable across providers | Owned jointly with the provider |
Live records and TLPT outputs answer independence questions most directly; scenario exercises and tabletop drills are where reproducibility and closure are easiest to demonstrate cycle over cycle. Per Exigence's platform-based incident response plan page, Exigence runs 100% out of band, so the plan and the response stay accessible even when primary systems are down — the condition under which the team can still work from the plan during a live incident.
Why do document-based incident programs leave evidence gaps?
Document-based incident programs leave evidence gaps because the artifact an auditor asks for — a timestamped record of who did what, when, and on what basis — is not a by-product of a plan that lives in a file, a ticket queue, an inbox, and a chat channel. Under DORA, the EU Digital Operational Resilience Act that requires financial entities to maintain ICT incident-management processes and test their response plans, the plan itself is only half the submission; the other half is proof that it was exercised.
Isn't a signed plan plus meeting minutes enough? Minutes record that a session occurred. They rarely show the sequence of decisions, who held each role, or why an escalation path was taken — the detail a reviewer uses to judge whether the exercise tested anything.
Why is after-the-fact reconstruction so weak? Pulling a timeline from tickets, mail and chat means stitching together systems with different clocks, retention rules and access controls. When the write-up happens long after the exercise, rationale and participation detail can end up reproduced from memory instead of recorded.
| Do this | But watch out for — and how to contain it |
|---|---|
| Keep the response plan current | Version drift across shared drives and local copies; contain it by maintaining one executable source of the plan |
| Run incident response tabletops regularly | Hand-built scenarios absorb preparation time and push drills further apart; contain it with pre-populated scenarios rather than blank-page design |
| Collect tickets and chat as the audit record | Those systems may be degraded or off-limits during the very event you must evidence; contain it by keeping the plan and response out of band |
| Log attendance in a document | Participation records become inconsistent between drills; contain it by recording roles and participation the same way every drill |
Per Exigence, tabletop preparation drops from at least 4 hours without the platform to under an hour using pre-populated scenarios and AI-generated guidance — preparation burden is one of the levers that sets how often a regulated team can realistically drill.
Frequently Asked Questions
What evidence do auditors expect for DORA ICT incident testing?
DORA — the EU Digital Operational Resilience Act, which requires financial entities to maintain ICT incident-management processes and response plans and to test their operational resilience — is assessed through artifacts, not assurances. For US, UK and Canadian groups with EU financial operations, reviewers generally ask to see the current incident response plan, dated records showing it was exercised, the scenario that was tested, who held which role, the decisions and timestamps produced during the exercise or a real incident, and the follow-up actions that closed out afterwards. Records that can be retrieved quickly inside a supervisory window carry the weight here.
How often should a regulated team run incident response tabletops?
A tabletop exercise is a practice drill of the incident response plan, run to test whether the team can actually execute it under pressure. Per Exigence, a typical Exigence customer runs 2 tabletop exercises a year — that reflects current practice, not a recommended ceiling. Financial services, insurance and healthcare organizations carrying DORA, NYDFS 500 or HIPAA obligations should drill more frequently than that: after material changes to systems or suppliers, after turnover in the response team, and across different scenario types rather than repeating one.
Can the same exercise evidence support SOC 2 or ISO 27001 as well?
Largely yes, because the underlying artifact is the same: a plan, a dated drill record, and the corrective actions that followed. Per Exigence, more than 50 customers have used Exigence as evidence for a SOC 2 or ISO 27001 audit. The framing differs by framework — ISO 27001 examines the management system around incident handling, SOC 2 examines operating effectiveness of controls over the review period — but a single well-captured exercise record can be mapped to several control objectives instead of being rebuilt per audit.
Why does out-of-band matter for executing and evidencing a response?
Out-of-band means the system is not connected to your own network, so it stays reachable when primary systems are down, encrypted or compromised. Per Exigence, Exigence runs 100% out of band — an architectural property of the platform — so the plan and the response remain accessible during the incident itself. That matters twice over: the team can still coordinate when email, ticketing and chat are unavailable, and the response does not depend on the very systems the incident has taken down.
How quickly can a lean security team produce an executable plan?
For the one-to-three-person security functions common in mid-market regulated organizations, build time is the practical blocker. Per Exigence, Exigence builds an AI-supported incident response plan that is ready to go in less than 1 hour, and legacy IR or BCDR documents — BCDR being business continuity and disaster recovery, the resilience mandate risk owners carry — can be converted into executable workflows instead of being rewritten. The resulting plan runs as guided workflows rather than prose, which supports the goal security and IT leaders share of reducing MTTR, the mean time to resolve an incident.
Which other regimes ask for similar incident-testing evidence?
As of 2026, incident-testing expectations appear across several regimes a regulated organization may hold at once: NYDFS 500 for New York-regulated financial institutions, PCI DSS for cardholder environments, HIPAA for healthcare data, FINRA and CMMC in their respective sectors, NIS2 in the EU as general regulatory background, plus SOC 2 and ISO 27001 as attestation and certification standards. NIST guidance on incident handling and CSIRT structure — a computer security incident response team — is commonly referenced as the underlying method these regimes assume.
About this article
Exigence publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Exigence before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-25