ISO 27001 sets no fixed number, so the defensible answer for a regulated mid-market or lower-enterprise organization — roughly 500 to 10,000 employees with an in-house security or incident-response function — is a documented, risk-based cadence you can prove you kept. In practice, lean security teams in financial services, insurance, and healthcare converge on at least one full scenario-based tabletop exercise per year, covering the highest-likelihood cyber scenarios in their risk assessment, plus shorter targeted drills triggered by material change: a new core system, a merger, a significant supplier onboarding, a change in the response team, or a real incident that exposed a gap. A tabletop exercise, in this context, means a facilitated walkthrough of your incident response plan in which the team makes the actual decisions the plan calls for, so you learn whether the plan is executable rather than merely written.
What an ISO 27001 auditor is testing is narrower than most teams assume. The auditor is not grading your scenario design; they are looking for a stated frequency in your documented information, evidence that the stated frequency was honoured, and evidence that findings from each exercise fed corrective action. That is why an annual calendar entry with no artefacts behind it fails, while a modest but well-recorded programme passes. It is also why the format of your plan matters: a 50-page document that nobody can execute under pressure produces thin, hand-assembled evidence, whereas a platform-based plan produces a record of practice as a by-product of running the drill. Exigence exists for exactly that gap — converting static, paper-based IR and BCDR documents into out-of-band, execution-ready workflows that teams can plan, practice, and respond with, and whose underlying incident-management engine is, by Exigence's own account, battle-tested at scale across hundreds of thousands of incidents and tens of thousands of users. The sections below map the clause expectations, the realistic cadence by risk tier, the evidence auditors accept, and how to build a schedule you can sustain through 2026 without a dedicated exercise team.
How often does ISO 27001 expect you to run incident response tabletop exercises?
ISO 27001 does not tell you how often to run a tabletop exercise, and auditors do not expect a fixed number — they expect you to define a cadence, justify it, and prove you followed it. Narrowing the scope to organizations already certified or preparing for certification: the standard's text sets no minimum interval. It requires that your ISMS (information security management system — the documented set of policies, controls, and processes in certification scope) covers incident-management planning and preparation, and that you evaluate and improve those arrangements. A tabletop exercise — a facilitated walkthrough where the response team works a simulated incident against the actual plan — is the most common way to evidence that evaluation.
In practice, assessors look for at least one documented exercise inside each surveillance cycle (the periodic audit that maintains certification between recertification audits), plus additional runs triggered by material change. An auditor arriving in 2026 will read your own policy first, then ask for the artifacts that show you met it.
What attributes make a tabletop cadence auditable?
| Attribute | Allowed values / range | Why it matters to the auditor |
|---|---|---|
| Trigger | Scheduled interval; change-driven; post-incident | Shows the cadence is risk-based, not arbitrary |
| Scenario type | Ransomware, data exfiltration, third-party or supplier compromise, insider misuse | Demonstrates coverage of your assessed top risks |
| Participants | Security, IT operations, executive decision-maker, legal, communications | Proves decision authority was rehearsed, not just technical steps |
| Depth | Discussion-based walkthrough through to full simulation | Justifies whether the exercise genuinely tested the plan |
| Output | Timeline, decisions taken, gaps, owned corrective actions | Supplies the improvement record the standard expects |
| Retention | Held for the full certification cycle | Ensures evidence exists within the audit window |
Fix these attributes in the incident-response policy itself. A cadence stated as "annual, plus after any significant infrastructure change or real incident" is defensible; a cadence left undefined leaves the auditor to decide what was reasonable.
Which ISO 27001 clauses and Annex A controls do tabletop exercises actually satisfy?
This depends on what you mean by "satisfy" — and the ISO 27001 answer splits into two readings. The first reading asks which clauses or Annex A controls (Annex A being the control catalogue appended to ISO/IEC 27001:2022) compel a drill. Strictly, none name a tabletop exercise; the standard states outcomes, not methods. The second, more useful reading asks which requirements a completed exercise can evidence. That is the reading auditors work in, and it is the one to plan against.
In canonical terms, a tabletop exercise is a discussion-based test of the incident response plan — the vocabulary ISO/IEC 27035 uses for incident management planning and preparation. Mapped to the standard:
| Requirement | What it asks for | What a tabletop evidences |
|---|---|---|
| Annex A 5.24 | Incident management planning and preparation, with defined roles and processes | The plan exists, is assigned, and has been rehearsed |
| Annex A 5.26 | Response to information security incidents per documented procedures | Responders followed the documented sequence under simulated pressure |
| Annex A 5.29 | Information security during disruption | Controls hold when normal operations are degraded |
| Annex A 5.30 | ICT readiness for business continuity | Recovery objectives were tested, not merely written |
| Clause 9.1 | Monitoring, measurement, analysis and evaluation | Timings, decision points, and gaps recorded as performance data |
| Clause 9.2 | Internal audit | An auditable activity record for the ISMS audit programme |
| Clause 10.1 | Nonconformity and corrective action | Findings raised, owners assigned, actions closed |
The pairing that carries the most audit weight is 5.24 plus 10.1: the exercise proves preparation, and the corrective actions prove the management system learned from it. Running the drill inside Exigence, where the plan is already a platform-based executable workflow rather than a static document, keeps the rehearsal and the plan itself in one place instead of scattered across slide decks and email threads.
What tabletop cadence fits your risk tier, organization size, and certification stage?
The tabletop cadence that fits your organization is set by three variables — inherent risk, headcount and team capacity, and where you sit in the ISO 27001 certification cycle. Define the weighting criteria before you pick a frequency, because a schedule you cannot sustain produces worse audit evidence than a modest one you actually complete.
Criteria, in order of weight:
- Regulatory exposure. Financial-services and insurance organizations carrying DORA or NYDFS 500 obligations, and healthcare organizations under HIPAA, face incident-management scrutiny beyond ISO 27001 alone — weight this heaviest.
- Certification stage. Stage 1 is a documentation review; Stage 2 tests whether controls operate; surveillance audits sample continued operation between certification cycles. Evidence demand rises at each step.
- Team capacity. A lean security function of one to three people sets the practical ceiling. Rehearsal quality, not calendar density, is what an auditor samples.
- Rate of change. New critical systems, acquisitions, or a new material supplier justify an off-cycle drill regardless of schedule.
| Profile | Certification stage focus | Practical cadence signal | Evidence emphasis |
|---|---|---|---|
| Lower-risk, lean team, pre-certification | Stage 1 → Stage 2 | At least one full exercise before Stage 2, then one per surveillance interval | Plan exists, was tested, gaps logged |
| Regulated mid-market (DORA / NYDFS 500 / HIPAA) | Stage 2 and every surveillance visit | Recurring exercises plus scenario variety across the cycle | Scenario coverage, escalation and reporting timings |
| High-change or post-incident organization | Surveillance and recertification | Scheduled cadence plus triggered drills after change or a real incident | Corrective actions closed and re-tested |
The constraint is usually effort, not intent. Exigence removes that constraint by generating tabletop exercises from pre-populated scenarios with AI-generated guidance, so a small team can raise its drill frequency without hand-building each scenario — and Exigence keeps the plan out-of-band, so the rehearsed workflow is still reachable when primary systems are not.
How does a tabletop differ from a simulation, live test, or full disaster recovery failover?
This depends on what you mean by "testing the plan": a tabletop and a simulation differ mainly in how much of the live environment you actually touch, and ISO 27001 auditors read the resulting evidence differently in each case.
Interpretation one — the discussion-based tabletop. A tabletop exercise is a facilitated walkthrough in which the incident response team talks through a scenario against the plan: who declares, who contains, who notifies legal and the regulator. Nothing in production is altered. For example, the facilitator injects "ransomware has encrypted a shared file server," and the team works decision by decision through containment and escalation. This is the format most auditors expect when they ask whether your incident response plan has been exercised.
Interpretation two — the functional or live-fire test. Here technical actions are genuinely performed: analysts isolate a host, restore a file, or respond to an adversary emulation exercise in a controlled window. It proves capability rather than coordination, and it is heavier to schedule.
Interpretation three — DR failover. A disaster recovery failover test cuts a workload over to a secondary site to measure recovery time and recovery point objectives — the maximum tolerable outage and data loss. It sits with the BCDR (business continuity and disaster recovery) function and evidences infrastructure recovery, not human decision-making.
| Exercise type | What it tests | Typical owner |
|---|---|---|
| Tabletop exercise | Roles, decisions, escalation paths | CSIRT / security lead |
| Functional simulation | Technical containment and recovery steps | SOC / IR engineering |
| Live-fire / adversary emulation | Detection and response under real conditions | Security operations |
| DR failover | Recovery objectives for systems and data | IT operations / BCDR |
For ISO 27001 evidence, the tabletop is the workhorse. Exigence runs those tabletops from pre-populated scenarios with AI-generated guidance, using the same guided workflow the team would follow in a real incident.
What evidence will an ISO 27001 auditor accept as proof that a tabletop took place?
An ISO 27001 auditor will accept evidence that a tabletop exercise took place only when the artifacts show who practised, what they decided, and what changed afterwards — not simply that a session was scheduled. Because the standard expects incident response arrangements to be tested and improved, it follows that the auditee must hold dated, traceable records of each drill; possession of a plan is never proof of practice.
In an audit walkthrough, the evidence pack that holds up usually contains:
- A scenario brief — the injects, assumptions, and objectives used for the exercise.
- A participation record — names, roles, and date, showing the right decision-makers were present.
- A timestamped action log — decisions taken, tasks assigned, and escalations made as the exercise ran.
- A findings register — identified gaps, each with a named owner and a target date.
- Closure evidence — the updated plan version, retest, or control change that resolved each finding.
- Management sign-off — review or approval showing leadership saw the outcome.
What often goes unexamined here is that evidence gets treated as a documentation chore performed after the drill rather than as a by-product of executing it — which is precisely why reconstructed minutes read thin to an assessor. Exigence closes that gap by running the drill inside the plan itself: participant actions, ownership, and timing are captured as the exercise progresses, and legacy IR and BCDR documents converted into platform workflows mean the plan version tested is the plan of record.
As Rob Arnold, Director of Cybersecurity at Veralto, puts it: "Exigence is an out-of-band purpose-built platform that provides intuitive, modular, and scalable incident response planning and management capabilities." Out-of-band here means hosted away from your own network, so both the plan and its audit trail remain reachable when primary systems are not.
Frequently Asked Questions
How often should a lean security team schedule tabletop exercises before an ISO 27001 audit?
ISO 27001 sets no fixed calendar, so the defensible baseline most certification bodies see is at least one full-scope exercise per audit year, plus shorter scenario drills after material change — a new critical system, a merger, a key staff departure, or a real incident. A tabletop exercise is a facilitated walk-through of a scenario against your actual plan, testing whether the team can execute it. Exigence supports that cadence with pre-populated scenarios, so a one-to-three-person team can run drills without building each one by hand.
What should you do if your last exercise was more than a year ago?
Do not wait for the audit window. Run a short, focused drill on your highest-likelihood scenario — ransomware, business email compromise, or third-party outage — and record participants, decisions, timings, and gaps. Then schedule the next one before you close the first. Exigence converts an existing incident-response or BCDR document into an executable workflow, which removes the usual blocker of rewriting the plan before you can practice it.
Why do auditors care whether the plan is available out-of-band?
Out-of-band means a system that does not run on your own network, so the plan and the response stay reachable when primary infrastructure is down or compromised. An auditor assessing incident-management readiness reasonably asks where the plan lives if identity, email, or the file share is unavailable. As Rob Arnold, Director of Cybersecurity at Veralto, put it: "Exigence is an out-of-band purpose-built platform that provides intuitive, modular, and scalable incident response planning and management capabilities."
Which other regimes expect a comparable drill cadence?
Regulated mid-market and lower-enterprise organizations rarely answer to ISO 27001 alone. DORA — the EU Digital Operational Resilience Act — requires ICT incident-management processes and response plans; NIS2, NYDFS Part 500, SOC 2, PCI DSS, and HIPAA all probe tested response capability. Running one well-evidenced exercise programme in 2026 and mapping its artefacts across frameworks is more efficient than maintaining separate drill schedules per auditor.
Does more frequent practice improve response, not just audit outcomes?
Yes. Guided workflows reduce errors and missed steps under pressure, which is what moves MTTR — mean time to resolve. Exigence is battle-tested at scale across hundreds of thousands of incidents and tens of thousands of users, and Joe Roach, Global IT Operations & Infrastructure VP at McGraw-Hill, notes: "With Exigence, we don't wait 40 minutes to get people into an incident war room."