Find the Executive Sponsor for an Incident Tabletop

An incident tabletop needs a business purpose before anyone receives an invitation. An MDR consultant should learn which operating decision or coordination question a customer wants to examine.

Start with a question about work, not anxiety. “What decision should this exercise make easier?” gives a customer an opening to name a real concern. An executive might want clarity about notification during service disruption. A technology leader might want to test who owns a handoff between teams. A security leader might want to surface assumptions before updating an internal process. Each answer calls for a different scenario boundary and different people in the room.

Avoid presenting a tabletop as proof of readiness. An exercise gives participants a chance to inspect a chosen workflow. People often find unclear contacts, missing information, or conflicting expectations. Those observations are useful. They do not establish how every future incident will unfold. A consultant should keep language measured and ask the customer how observations will turn into owned follow up work.

Consider a fictional online education company. Sam, a security leader, tells Riley, an MDR consultant, “Our executive team wants to know who contacts them when our learning system has a serious availability issue.” Riley does not begin with a library of attack stories. Riley asks, “What would leaders need to decide or do once they receive a notice?” Sam says leaders need a clear owner for the update, a plain description of the service effect, and a point where business operations joins the discussion.

Those answers reveal a purpose: examine executive notification during a serious learning system availability issue. Riley repeats the purpose in a short sentence and asks Sam whether wording fits. Sam changes “serious” to “sustained,” because brief interruptions follow a separate path. One correction narrows the scenario boundary. Participants will discuss a fictional service issue lasting beyond an agreed threshold chosen by the customer, rather than every possible technical event.

Next, identify an executive sponsor. A sponsor is more than a senior attendee. This person agrees the question matters, helps secure participation, and receives the action record afterward. Ask, “Who has enough responsibility for this operating decision to sponsor the exercise and review what comes from the exercise?” Sam names Dana, the chief operations officer, because Dana owns continuity decisions for the learning service. Riley asks whether Dana already understands the purpose or needs a short briefing first.

A sponsor briefing should be practical. In the fictional example, Sam schedules fifteen minutes with Dana. Riley prepares three questions for Sam to use: Does the notification question describe a decision you own? Which leaders need to participate? What form should the review record take after the exercise? Dana says the purpose fits. Dana asks for technology operations, security, communications, and an academic operations representative. Dana wants a short action record with owners and dates, delivered within five business days.

The consultant should not claim Dana has approved details before Dana says so. Record the approval precisely. For example, “Dana agreed to sponsor a discussion of executive notification for a fictional sustained learning system disruption.” Keep separate items marked as open questions. Perhaps Dana has not chosen a date, or academic operations has not named a participant. Precise records protect the customer from assumed commitments.

Choose participants by handoff, not job title alone. Riley asks Sam, “Where does information need to move during this situation?” Sam describes an initial technical assessment from technology operations, an impact view from academic operations, a security update, and an executive notice. This sequence suggests a small group. One person from each handoff point is more useful than a long invitation list of observers. Each participant should know why their voice belongs in the discussion.

Roles need plain definitions. Technology operations describes service condition in the fictional scenario. Security explains what information is known and what remains uncertain. Academic operations explains impact on teaching schedules. Communications considers internal wording after customer leadership chooses a path. Dana observes decision points and reviews actions after the session. The customer should approve each role description. Riley should ask whether any role duplicates work already assigned elsewhere.

Set a safe scenario boundary before writing prompts. A tabletop does not require sensitive records, production access, customer data, or a recreation of a real incident. In this practice situation, Riley proposes a fictional notice at 9:10 on a Tuesday: users report inability to enter a learning portal, and technology operations has confirmed a sustained availability issue. The prompt stops there. Participants discuss who receives information, what each role needs, and when Dana should receive an update. They do not investigate a real system.

Ask when participants have time to think rather than react to current demands. Sam says a ninety minute workshop on a Thursday morning would work, provided invitations arrive two weeks beforehand. Dana requests a twenty minute review the following Tuesday. Riley notes dates only after Sam and Dana agree.

Before the workshop, send a purpose statement and narrow preparation request. Participants do not need a large packet. Riley asks each attendee to bring the current contact route they use for a service disruption and one question they need answered before escalating to an executive. The invitation states the scenario is fictional, identifies Dana as sponsor, and says the group will examine notification and handoffs. Sam reviews language before Riley sends anything.

During the tabletop, keep discussion tied to decisions. Riley begins: “At 9:10, a fictional sustained availability issue affects the learning portal. Who first confirms the service effect, and who needs required information next?” Technology operations says they would contact the on duty service lead. Academic operations says they need an estimate of which courses face disruption before updating program leaders. Dana asks who decides when executives receive notice. The group identifies an open point: no one owns the first executive update.

Riley should capture observations without deciding customer policy. Instead of saying, “Your organization needs a new notification rule,” Riley writes, “Participants reported no agreed owner for the first executive update.” Riley then asks who should take the observation into a follow up discussion. Dana names Sam and the technology operations director. Both agree to draft options before the review date. Ownership comes from the customer, not the consultant.

Keep an action record simple enough for use. In the fictional session, one row records the observation, one names the owner, one lists a due date selected by the owner, and one notes what Dana will review. Sam takes responsibility for an executive notification draft by the next Tuesday. The technology operations director agrees to confirm current contact paths by Friday. Academic operations agrees to describe the information program leaders need during sustained disruption. These are fictional workshop decisions, not a prescribed model for every customer.

Use a practice situation with Sam, Dana, and Riley. Sam wants a tabletop after a recent concern, Dana agrees to sponsor executive notification, and academic operations has not chosen an attendee. Riley should ask Sam who will name an attendee and by what date. Then draft the first invitation for a Thursday session, state the fictional 9:10 portal scenario, name the handoff question, and leave the academic operations seat marked pending until Sam supplies the contact.