Which roles to put in the room
The planning conversation reaches the participant list, and it is usually treated as an invitation problem. It is not. It is the decision that determines what the exercise is capable of finding, and it has a real cost on the other side.
What another role buys
An incident does not stay inside one team. It starts somewhere, is recognized somewhere else, and its consequences land in places that have nothing to do with computers.
A role that is missing from the room does not merely go unrepresented. Its part of the response gets assumed, and assumptions in an exercise are generous in a way that real people are not.
The first thing to get right is that "IT" is not a role. In most organizations of any size it is several groups with different tools, different on-call rotations and different managers, and the incident crosses all of them:
- Network operations. Frequently the group that can actually stop lateral movement while it is happening, by taking segments apart. If containment is going to be tested at all, somebody who can do it has to be present.
- Server administration, which owns the systems being restored and the real numbers about how long that takes.
- Endpoint administration, which owns the machines where most incidents begin.
- Security, and in larger organizations security operations as a separate function with its own tooling and its own queue.
- The helpdesk, which is where most incidents are first visible, usually as something that does not look like an incident.
- Identity administration, which holds the accounts and the authority to disable them.
- Compliance, where it exists as its own group rather than as somebody's additional duty.
Then the parts of the organization that are not IT at all, and where the exercise usually finds its most durable material:
- Management, which holds the decisions that cost money. A room without somebody who can commit the organization stalls at the first real choice.
- Contracts. Worth separating two questions that sound like one. What data is on this system is usually answerable in the room: the project manager knows, and so does whoever uses the system daily, which is one of the better arguments for having an actual user present rather than only their manager. What reporting obligations attach to that data is a different question, and contracts is where it lives. That one stalls a room, and it is worth building into a scenario deliberately.
- Legal, for the questions the contracts do not settle.
- Communications. Somebody has to write what is said to customers, staff and regulators, and doing that badly is its own incident. Joint guidance from CISA, the FBI and four partner agencies recommends designating an incident lead, a communications lead and a spokesperson with predefined approval paths, and recommends exercising that structure through tabletop exercises specifically. Where a plan names those roles and no exercise ever tests them, the plan is untested at its most visible point.
- Human resources, for anything involving a person rather than a system.
- Finance, for emergency spending and for the question of what the outage is costing.
- Physical security, wherever premises, media or access badges are involved.
- The application owner, who is the only person who knows what a system is actually used for and therefore whether an outage is survivable.
If the organization uses a managed service provider, they should be in the room. For many small organizations the provider is the response capability, and an exercise that models their part rather than involving them is exercising a guess. Their contract is also the thing that determines how fast they arrive, which is worth discovering in a planning conversation rather than at two in the morning.
What a missing role actually costs, and one it does not
The value of a role is not uniform, and it is worth being precise rather than arguing that everyone should attend.
Take reporting obligations, which are often used to argue for legal counsel. For a defense contractor this is one of the clearer areas rather than one of the murkier ones. The clause is DFARS 252.204-7012, and it is unusually specific about all three. It defines what counts as a reportable cyber incident. It requires the contractor to rapidly report one to DoD, which paragraph (a) defines as within 72 hours of discovery. And it requires, separately, that images of the affected systems and the relevant monitoring data be preserved for at least 90 days from the report, so that the department can ask for the media or decline it. The reporting portal is dibnet.dod.mil and can be visited in advance, so an organization can know before any incident exactly what it will be asked for.
That makes the obligation a preparation question rather than a legal one, and the exercise finding is usually not "we needed a lawyer" but "nobody had read it, and nobody had looked at the form." Both are fixable in an afternoon by somebody who is already on staff.
A related observation belongs in the report when it applies: an organization that has been in the defense industrial base for years and has never filed a report is not describing an unusually quiet decade. Laptops get stolen. People click things. A clean history of that length more often means the reporting threshold was never understood than that nothing ever crossed it.
Contracts is the opposite case. "Which agreements cover the data on this system" is not knowable from the IR plan, not knowable by IT, and not knowable at half past five in the evening. That absence changes what the room can do.
What another role costs
Half a working day, at least, once the pre-exercise briefing is counted. That is the honest number, and it is per person.
For a small organization this is not a rounding error. Six people out for half a day is a meaningful piece of a week's capacity, and the people whose presence would help most are frequently the hardest to release, because they are the same people holding operations together while the exercise runs.
What that cost is not, in practice, is travel. Organizations do not fly people in for a tabletop exercise, and they are right not to: with travel either side it becomes a three-day commitment plus expenses, for half a day of participation. Where somebody is not local, having them attend remotely is nearly as good and costs a fraction as much. A remote participant is a slightly diminished participant rather than an absent one, and that trade is almost always better than dropping the role.
There is a second cost that is easier to miss. A room that is too large stops being a discussion. Participants with no part in the current inject disengage, and a disengaged participant is not merely idle. They are reading email, and the injects continue while they do. When the discussion reaches something they could have contributed to—and it does, because that is why they were invited—they have missed the moment. The exercise then records a gap that was not really a gap, or misses one that was.
A room that is too large also changes character: the people still engaged start performing for an audience rather than working the problem.
So more roles is not monotonically better, even ignoring the money.
Deciding rather than inviting
The useful reframing is that the scenario determines the roster, not the org chart. This is not a principle to be taken on trust—it is visible in any scenario library that has been built deliberately, and it is worth looking at before planning a particular exercise.
The scenario library Ultimate TTX builds for subscribers shows the pattern plainly. Across those scenarios three roles appear almost everywhere:
- A ransomware with exfiltration scenario reaches ten roles, including the helpdesk, backup administration and endpoint administration, because the response spans first contact, containment, restoration and disclosure.
- A business email compromise scenario reaches five, and finance is central to all of them. Backup administration has no part in it at all.
- An insider data theft scenario brings in human resources and drops IT operations.
- A physical access and removable media scenario needs physical security, which appears nowhere in the financial or identity scenarios.
- A service provider compromise scenario needs network operations and the application owner, and much of it is about somebody else's environment.
Build one standing invitation list and reuse it, and some exercises carry passengers while others are missing the person who mattered. Read the scenario first; it will tell you who has to be there.
Two practical devices help.
Name the role, not the person. The question is which functions have to be represented; who fills each one is a scheduling problem after that. It also makes substitution visible, and substitution matters: a deputy who does not hold the authority will answer as though they do.
Absence is a finding. When a role cannot be released, the exercise still runs, and the report records that the response was modeled without it. That is more useful than quietly proceeding, because "we could not free the only person who can authorize an emergency shutdown" deserves management's attention, and it recurs during real incidents for exactly the same reason.
One role is not on the scenario's list, and it belongs in every room: whoever would coordinate the response. The scenario decides which functions the incident touches; coordination is not one of those functions, it is the thing that sequences the rest of them. Sending a deputy is worse here than anywhere else on the roster, because the exercise cannot then observe whether the arrangement works—it observes a stand-in improvising one. Why that role matters, and what it has to not be doing, is a subject of its own.
Communications is the other role worth arguing for beyond first principles. Where a scenario requires the organization to say anything to anyone outside the response team, the function that says it should be present rather than represented by whoever is nearest—and the joint guidance Communicating Under Pressure, published by six agencies in September 2026, recommends exercising communication plans through "simulated tabletop exercises" and naming communications teams specifically.
The roster shapes the report, not just the day
Choosing the room is also choosing what the report can say, and it is worth thinking about at planning time rather than discovering afterward.
A finding about a role that was not represented is weaker, and it should be: nobody from that function was there to explain what actually happens. The report has to say so, and a reader is entitled to discount it. Conversely, a finding that rests on two functions contradicting each other in the room—the backup administrator and the person who would be woken up, say, or IT and contracts—is among the strongest material an exercise produces, and it is only available if both were present.
The recommendations divide along the same lines. A finding whose fix is political, requiring somebody senior to settle a disagreement between two groups, lands very differently depending on whether both groups were in the room and heard it emerge.
This is also the strongest argument for management attending rather than being briefed afterward. The recommendations needing an executive decision are exactly the ones that arrive in a report as a surprise, and an executive who watched the disagreement happen does not have to be persuaded that it is real.
The failure mode worth avoiding
The version that wastes everyone's time is the room built from whoever was available, running a scenario chosen independently of them. It produces a pleasant discussion, a report with thin findings, and a general impression that tabletop exercises are a compliance ritual.
Who is in the room is part of the scenario design. Choosing deliberately is most of what separates an exercise that finds something from one that fills a requirement.
Ultimate TTX plans facilitated exercises from the scenario outward, including which roles have to be in the room for it to be worth running.