Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →A tabletop is the only proof your incident plan works when you have had no incidents. This is how to run one, and what the record has to contain before an auditor will accept it.
A tabletop is a facilitated discussion of a realistic incident, run against your written plan, with a scribe capturing decisions and times. Most teams need one a year at minimum, two if you are regulated or hold a lot of customer data, and the session itself takes 90 to 120 minutes plus about the same again in preparation. The exercise itself is the easy part. What gets a tabletop rejected as evidence is the record: undated, no attendee list, no decisions, no findings, and no corrective actions with owners. A tabletop is a contemporaneous record, which means it only exists if it was made at the time. A period you did not exercise cannot be back-filled later, only shortened or qualified.
A tabletop exercise is a facilitated discussion in which a small group is walked through a realistic incident scenario and asked, at each step, what they would do, who they would call, and what they would decide. Nothing is executed. No systems are touched, no failover is triggered, no customer is notified. The output is a record of decisions, gaps and disagreements.
The reason it exists in a compliance program is narrow and worth stating plainly. Having a written incident response plan proves that somebody wrote a plan. It does not prove the plan works, that the people named in it know they are named in it, or that anyone can find the on-call number at 2am. The exercise is what turns a document into a control that has been shown to operate.
This matters most for the organization that has had no incidents. Teams routinely assume a clean year is the strongest possible evidence. It is the opposite. Having no incidents is not evidence of a working process, it is an absence of evidence, and an auditor testing incident response against a year with zero incidents has nothing to sample unless you ran an exercise. The exercise record is the sample.
Both of the frameworks most startups run into expect this. The ISO 27001 control set asks for incident response to be planned, prepared and exercised, and the practical guidance we work from is to run at least one tabletop a year against a realistic scenario for your business. SOC 2 does not prescribe a frequency in the criteria themselves, but audit firms routinely ask for evidence that the incident process has been tested inside the observation window, and an untested plan is a common source of a management letter comment even when it does not become an exception.
The most common mistake is picking a scenario because it sounds serious rather than because it is plausible for your business. A twelve-person SaaS company running a tabletop on a nation-state actor pivoting through an air-gapped OT network has learned nothing and produced a record that reads as theatre. The scenario should be something that could credibly happen to you next month.
Pick from what your own risk assessment already says. If your register lists cloud account compromise, a leaked long-lived API key, and a critical vendor outage as your top risks, those are your first three years of tabletops. This linkage is worth doing deliberately, because it also answers the auditor question about whether your exercise program is risk-driven or arbitrary. A scenario chosen from the risk register makes that connection on the page.
A good scenario has three properties. It crosses at least two teams, so the exercise tests handoffs rather than one person's competence. It has an ambiguous middle, where the group has to decide with incomplete information, because that is where real incidents go wrong. And it reaches a decision with a business consequence attached, such as whether to notify customers, whether to take the product offline, or whether to pay.
Rotate scenarios year on year. Running the same ransomware tabletop three years running produces three records that look identical, and an auditor reading three identical records reasonably asks whether the exercise happened or was copied. Rotation also surfaces different gaps, because the gaps in a data exposure scenario are legal and communications gaps, while the gaps in a ransomware scenario are backup and authority gaps.
The right size is five to nine participants plus a facilitator and a scribe. Below five you cannot test a handoff. Above nine the quiet people stop speaking and the record becomes a transcript of the two loudest attendees.
The non-negotiable seats are the person who declares an incident, the person who can authorise taking production offline, the person who owns the affected systems, and someone who speaks for customers or contracts. In a small company one human may hold two of those, which is fine and should be written down, but a tabletop where all four roles are the same person has tested nothing about coordination and you should say so honestly in the record rather than pretending otherwise.
Include an executive. Not as a courtesy, because most tabletops fail at exactly the point where a decision exceeds the authority of the people in the room, and if the executive is absent the group papers over that gap with "we would escalate". Escalate to whom, reachable how, with what decision rights, is the finding you are trying to surface.
Invite the people who will actually be on call, not their managers. A tabletop staffed by team leads produces a plan that team leads understand. The engineer who gets paged has different questions, and those questions are usually the useful ones.
If you retain an external incident response firm or have an insurer with a mandatory notification clause, involve them at least once. Many retainers include a facilitated exercise, and the exercise is often the most valuable thing in the contract. We wrote separately about what to look for in an incident response retainer, and exercise inclusion is one of the terms worth negotiating for.
The facilitator owns the clock and the scenario. They introduce the situation, release injects on a schedule, refuse to answer questions the scenario does not answer, and push the group toward decisions rather than discussion. The single most important facilitator skill is tolerating silence for long enough that someone commits to a course of action.
Critically, the facilitator should not be the person who would run the real incident. If your incident commander facilitates, you have removed your incident commander from the exercise and tested the deputy without meaning to. That is a legitimate exercise design, but it is not the one most teams think they are running. The usual arrangement is that an external party or someone from an adjacent function facilitates, and the incident commander participates.
The scribe does nothing else. They are not a participant. They capture, with timestamps, what was decided, who decided it, what the group could not answer, and every moment where somebody said "I do not know where that is". Those moments are the findings. A tabletop without a dedicated scribe reliably produces a record written from memory two days later, and a record written from memory two days later contains conclusions instead of observations.
For a first exercise, running the session with an outside facilitator is worth the cost, because the failure mode of an internal facilitator is generosity. They know what the group means, they fill in the gaps, and the exercise passes. An outsider asks the follow-up question, and the follow-up question is where the finding lives.
Preparation is roughly equal to the session in effort, and skipping it is why exercises drift into unstructured conversation. Budget two to four hours for a scenario you have run before, and a full day for a new one written from scratch.
You need the current incident response plan in front of everyone, because the exercise is testing the plan and not the group's general competence. If the plan is out of date, note that before you start rather than discovering it as a finding, and record the version number you exercised against. An auditor comparing the plan version in the exercise record to the plan version on file is a routine check, and a mismatch is an easy finding to avoid.
You need the scenario written out with a start state, a sequence of injects, and the questions each inject is designed to provoke. Write the questions down in advance. A facilitator improvising questions asks the ones the group can answer.
You need to decide in advance what is out of scope. Tabletops sprawl. If the scenario is a credential leak, decide beforehand that you are not going to spend forty minutes redesigning the secrets management architecture, and hold the line on the day by parking it as a finding.
Do not send the scenario to participants in advance. Send the date, the duration, the fact that it is a tabletop and not a test of individuals, and the plan document. Sending the scenario produces rehearsed answers and a record that shows an organization performing rather than an organization thinking.
An inject is a new piece of information released partway through the exercise that changes the situation. Injects are what separate a tabletop from a meeting about incidents. Four to seven injects over ninety minutes is the usual range, released roughly every ten to fifteen minutes.
Injects should do work. Each one should either escalate scope, introduce ambiguity, apply time pressure, or remove a resource the group was relying on. The most useful inject in almost every exercise is the one that removes a person: the named incident commander is on a flight, the one engineer who understands the billing database is unreachable. That inject alone finds more gaps than the technical content of the scenario.
Include at least one external pressure inject. A customer emails asking why the service is slow. A journalist calls. A researcher who reported the flaw asks for a status update and mentions a disclosure deadline. Communications is where small companies are least prepared, and an exercise that stays inside engineering never reaches it.
Include one inject that tests an obligation with a clock on it. Cyber insurance policies frequently require notification within a defined period, and contractual breach notification windows in enterprise agreements are commonly 24, 48 or 72 hours. Whether the group knows those windows exist, and where the contract lives, is a genuine and frequently failed test.
Resist making injects unfair. An inject that is impossible to respond to produces frustration and no finding. The goal is a hard exercise, not an unwinnable one.
Open by stating the rules out loud and having the scribe record that you did. This is not a test of individuals. Nothing said in the room is used in a performance review. Where you do not know, say you do not know, because "I do not know" is the finding and covering it is the only failure available today. Teams that skip this produce confident, useless exercises.
Start the clock at a specific fictional time and keep the timeline visible. Real incidents are governed by elapsed time, and a tabletop that never mentions time will not surface the fact that your detection path takes four hours. State scenario time at every inject.
Push for decisions, not descriptions. When somebody says "we would look at the logs", the follow-up is which logs, who has access at 3am, how far back do they go, and what would you conclude if they are empty. Three of those four questions usually produce a finding.
Track two things on a visible list as you go: decisions made, and open questions. The open questions list is the raw material for the findings. Do not resolve items on it during the session, because resolving them is remediation work and it will consume the exercise.
Reserve the last fifteen minutes for a structured debrief while everyone is still in the room. Ask each participant for one thing that surprised them and one thing they want changed. This is the highest-yield fifteen minutes of the entire exercise and it is the first thing cut when the session runs long, so protect it by ending the scenario early rather than ending the debrief.
This is where most tabletops fail, and the failure is entirely avoidable. The exercise happened, the team learned something, and the artifact handed to the auditor is a four-line calendar invite and a slide deck with no date on it. That evidences a meeting, not a control.
The pattern that works is the same one we use for every other assessment instrument: a dated document naming who ran it, listing every item covered with a result and a note, filed as evidence against the controls it speaks to, with every failure opening a tracked remediation item that has an owner and a due date. A walkthrough with three failures is evidence that the walkthrough happened, not evidence that the control is in place, and the same distinction applies to a tabletop. An exercise that surfaced six gaps is good evidence of a functioning exercise program and bad evidence of a mature incident capability, and the record should let the auditor see both.
Write the record within 48 hours. The scribe's notes decay fast, and a record produced a month later has visibly lost the detail that made it credible. Circulate it to attendees for correction, which also produces a second dated artifact showing participants confirmed the account.
Keep the record for as long as you keep other audit evidence, which in practice means at least through the next two audit cycles. A common request during a second-year SOC 2 audit is the exercise from the prior year, to establish that the cadence is real rather than something you started when the auditor was hired.
A finding that does not become a tracked item with an owner and a date is a finding you have documented and ignored, and documenting a gap you then failed to close is materially worse than not having noticed it. The auditor now has written evidence that you knew.
Convert every open question and every failure into a remediation item at the point the record is written. Give it a named individual, not a team. Give it a due date, and prefer 30 days for anything procedural. Track it in whatever system already holds your remediation work, so that it appears in the same list as findings from assessments, internal audit and vulnerability management, rather than living in a document nobody reopens.
Rank the findings by what they block rather than by dramatic severity. A missing contact list blocks every scenario and takes an hour to fix. An architectural change to shorten detection time is a quarter of engineering work. Order the list so the cheap blockers close first, which is the same principle we apply when sequencing remediation on an engagement.
Close the loop visibly. The next exercise record should open with the status of the findings from the previous one. That single paragraph is what converts a series of exercises into a demonstrable improvement cycle, and it is the thing an ISO auditor is looking for when they ask how the management system got better this year. The same loop applies more broadly: exercises and incidents feed corrective actions, and corrective actions land on the management review agenda.
If a finding is accepted rather than fixed, record the acceptance, who accepted it, and why. An open finding with a documented acceptance from someone with the authority to accept it is a defensible position. An open finding with no decision on it is not.
Annual is the floor. Twice a year is the right answer for a company holding regulated data, running a high-availability commitment, or carrying cyber insurance with an exercise requirement. Quarterly is rarely justified for a small team and tends to degrade into a repeated conversation.
The scheduling rule that matters is about the observation window. A tabletop is a contemporaneous record. It only exists if it was made at the time, and unlike a policy or a network diagram it cannot be produced afterwards. If your SOC 2 Type II window runs from 1 January to 31 December and you did not exercise inside it, there is no remedy in December. The options are a shorter window, a later report date, or an exception in the report.
The practical consequence is that the exercise gets scheduled when the window is planned, not when someone finds time. Put it in the first third of the window. An exercise in month two leaves room to close the findings and, if it goes badly enough, to run a second one inside the same period, which is a much stronger evidence position than one exercise in month eleven.
If you are running SOC 2 and ISO 27001 together, one well-documented exercise generally serves both, because the underlying activity is identical and only the mapping differs. Collect once and map to many is the whole efficiency argument for running frameworks in parallel, and it applies to exercises as directly as it applies to policies. Our comparison of the two frameworks covers where that overlap holds and where it does not.
A tabletop is a discussion. A functional test executes part of the response for real, such as actually restoring a database from backup or actually rotating a production credential, without committing to a full switchover. A live failover moves real traffic to a secondary environment.
These are not interchangeable as evidence. A tabletop evidences that the plan is understood and the decision path works. It does not evidence that the technical recovery works, and no amount of discussion establishes that a backup is restorable. If your control claims you can recover a system inside a stated objective, the tabletop is not the evidence for that claim and an auditor will ask for a restore test with an elapsed time on it.
The reverse is also true. A successful restore test proves the mechanism works and says nothing about whether anyone would have decided to invoke it, or who would have told the customers. Most small teams need both, and the honest scoping answer is that the tabletop is annual and cheap while restore testing is more frequent and separately evidenced. The continuity and disaster recovery testing guide covers that side in detail.
Run them in that order when you are starting from nothing. The tabletop is cheap, finds the organizational gaps, and tells you which technical test is worth the engineering time.
The request usually arrives worded as evidence that the incident response plan was tested during the period. What lands on the reviewer's desk should be the exercise record, the attendee list, the scenario, the findings, and the current status of the corrective actions those findings produced.
Rejections cluster. Undated records are the most common, followed by records with no attendee list, which make it impossible to establish that the right roles participated. Next is the record with findings but no owners, which fails the corrective action test rather than the exercise test. Then there is the record dated outside the observation window, which is a scheduling failure rather than an evidence failure and cannot be fixed by rewriting anything.
The subtler rejection is the record that reads as generic. If the scenario, the findings and the language would apply equally to any company, a reviewer will suspect a template was completed rather than an exercise run. Specificity is the defence: name the systems, name the roles, quote the actual open questions, and include the things that went badly. A record where everything went well is less credible than one with six findings, not more.
One more failure worth naming. Teams sometimes produce a beautiful exercise record and then cannot produce the incident response plan version it refers to, because the plan has been rewritten since. Archive the plan version you exercised against alongside the record.
Run internally, a tabletop costs the preparation time plus the room. Two to four hours of preparation, a two hour session with seven people, and three to four hours to write the record and open the corrective actions. Call it fifteen to twenty person-hours in total, most of it senior.
Facilitated externally, a single scenario tabletop for a small company is commonly quoted in the low four figures, with the price moving on scenario development, whether an executive session is included, and whether the deliverable is a formal report or a set of notes. Retainer-based incident response providers frequently bundle one exercise a year, and where that is available it is usually the cheapest way to get an outside facilitator.
The comparison worth making is not against zero. It is against the cost of discovering the same gaps during a real incident, where the missing contact list costs hours of downtime rather than a line in a findings table.
| Field | What it has to contain | Why records get rejected on it |
|---|---|---|
| Date and duration | The actual calendar date the exercise was held, with start and end times. | Undated records are the single most common rejection. Without a date the reviewer cannot place the exercise inside the observation window, and a record outside the window evidences nothing for that period. |
| Attendees and roles | Full names, job titles, and the incident role each person held during the exercise. Note anyone invited who did not attend. | A list of first names proves nothing about whether the people with authority participated. Reviewers check that the decision-maker was in the room. |
| Facilitator and scribe | Who ran it and who recorded it, named, including whether either was external. | Anonymous records read as reconstructed. Naming the facilitator also shows the incident commander was a participant rather than the person running the session. |
| Plan version exercised | The document name and version or revision date of the incident response plan the group worked from. | If the version does not match a plan on file, the reviewer cannot tell what was tested. This is easy to get right and frequently missed. |
| Scenario and injects | The starting situation and each inject with the scenario time it was released. | A one-line scenario description reads as a template. Injects with times are what distinguish an exercise from a discussion about incidents. |
| Decision log | Each decision, the scenario time it was made, and who made it. Include decisions the group declined to make. | Without decisions there is no evidence the response process was exercised, only that the topic was discussed. |
| Findings | Every gap and open question, stated as an observation rather than a conclusion. Six findings is a healthy number. | A record with no findings is less credible than one with several. Reviewers read a clean exercise as a soft one. |
| Corrective actions | One tracked item per finding, each with a named individual owner and a due date. | Findings with no owner fail the corrective action test. Documenting a gap and not assigning it is worse than not finding it. |
| Prior findings status | The state of every corrective action from the previous exercise, closed or open with a reason. | Its absence means the exercises are a series of isolated events rather than an improvement cycle, which is what an ISO auditor is looking for. |
| Distribution and confirmation | Who the record was sent to and when, ideally with attendee confirmation that it is accurate. | Confirmation from participants makes the record much harder to challenge and produces a second dated artifact at no extra effort. |
Once a year is the working floor for most organizations, and it is the frequency we advise for a small company running SOC 2 or ISO 27001. Twice a year is appropriate if you hold regulated data, carry availability commitments in customer contracts, or have a cyber insurance policy with an exercise requirement. What matters more than the headline frequency is that the exercise falls inside your audit observation window, because the record is contemporaneous and a period you did not exercise cannot be back-filled afterwards.
Often yes, and sometimes it is stronger evidence, but only if you documented it properly at the time. A real incident with a full timeline, a decision log, a post-incident review and tracked corrective actions demonstrates the process operated under real conditions. An incident that was handled well and written up in three sentences afterwards does not. Many teams choose to keep the annual exercise even in a year with a real incident, because the exercise lets you test a scenario you have not experienced.
A tabletop is discussion only. Nobody touches a system, and the output is a record of decisions. A simulation or functional test executes part of the response for real, such as restoring a database from backup, isolating a host, or rotating a production credential. They evidence different things. A tabletop shows the decision path and the plan are understood. Only a functional test shows the technical recovery actually works, so if a control claims a recovery capability, the tabletop is not the evidence for it.
Somebody other than the person who would command the real incident. If your incident commander facilitates, they are removed from the exercise and you have unintentionally tested the deputy. An adjacent function, a board member, or an external facilitator all work. The advantage of an outsider is that internal facilitators tend to be generous, filling in gaps the group left open, which is exactly the behaviour that turns an exercise into a formality.
Ninety minutes to two hours for the scenario, plus a protected fifteen minute debrief at the end. Longer sessions lose the room, and shorter ones do not get past the first two injects. Preparation is roughly equal to the session for a scenario you have run before, and considerably more for a new one written from scratch. Writing the record and opening the corrective actions afterwards is another three to four hours.
That is a good outcome and you should record it as it happened. An exercise that produces six findings is stronger evidence of a functioning exercise program than one where everything went smoothly, because reviewers read a clean record as a soft exercise. The risk is not in surfacing gaps, it is in surfacing them and then failing to assign owners and dates. A documented gap with no corrective action against it is the one situation that leaves you worse off than before.
Generally yes. The underlying activity is the same and only the control mapping differs, so a single well-documented exercise can be filed against the incident response requirements in both frameworks. This is the same collect-once-map-to-many principle that makes running the two frameworks in parallel much less than twice the work. Keep the record framework-neutral in its wording and map it afterwards rather than writing two versions.
Yes, and the exercise is usually more revealing at that size, not less. With five people the same person frequently holds the roles of detector, decision-maker and communicator, and the exercise makes that concentration visible along with the question of what happens when that person is unavailable. Record the role overlap honestly rather than pretending the roles are separate. An auditor reading a small company record expects overlap and is looking for whether you have acknowledged it and planned for the absence.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We facilitate the scenario, keep the record an auditor will accept, and hand you the findings as tracked work with owners and dates.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.