The Building Tech Tabletop: Rehearsing Outages Across Ops, IT & Tenants

Rehearse the Decisions Before an Outage Forces Them

A building technology incident rarely affects one system at a time. A carrier link can fail during business hours while generator transfer takes longer than expected. Phone lines may drop, access control can lose cloud connectivity, and tenant services can become intermittent. The central question is not only whether technology fails over. It is who makes the decisions, who communicates with tenants, and who owns the next action when assumptions break.

This episode examines the building technology tabletop: a short, structured exercise that lets facilities, IT, security, vendors, property management, and tenant representatives rehearse realistic outage scenarios without disrupting production systems. The goal is to uncover gaps in ownership, escalation, dependencies, and communications before those gaps become tenant-facing downtime.

Start With a Focused Objective

A useful tabletop does not begin with a long list of hypothetical failures. It begins with a one-sentence objective that defines what the team needs to validate. One example discussed in the episode is verifying decision ownership and tenant notification during a simultaneous carrier outage and generator failure.

• Write one clear objective before designing the session.
• Select two realistic scenarios that directly support that objective.
• Focus on prioritized risks, such as carrier loss, delayed generator transfer, or partial power transfer.
• Identify the affected business systems, including access control, HVAC, phone services, and tenant technology.

The objective should drive the scenarios, not the other way around. This keeps the exercise from becoming an unfocused technical discussion and makes it easier to produce clear actions at the end.

Use Functional Dependency Mapping

Tabletops do not need IP addresses, single-line electrical diagrams, or every technical configuration detail. They do need enough information to force operational decisions. Functional dependency mapping shows participants which systems rely on which services and where a single failure can create broader impact.

For example, a team may identify that access control uses a primary carrier for cloud connectivity and a secondary carrier for synchronization. It may also identify that generator power supports life-safety loads unless someone manually switches other loads. Those facts create meaningful questions: What fails over? What does not? Who is authorized to act? What is communicated to tenants while the issue is being resolved?

• Map systems at a functional level rather than documenting every technical detail in the room.
• Use the map to identify dependencies and single points of failure.
• Capture technical questions that require a deeper review as follow-up actions.
• Keep the exercise moving instead of allowing technical minutia to consume the available time.

Put Decision Makers in the Room

A tabletop is most valuable when the people who must make decisions during an incident are present. The recommended participant group includes facilities, IT, security, vendor representatives, and a tenant liaison. Each participant should have an explicit role before the exercise begins.

Facilities may own generator procedures. IT may be responsible for validating secondary carrier routing. Property management may own tenant notification procedures and contact lists. Vendor representatives can clarify capabilities and known failure modes. A tenant liaison can help test whether communications and priorities reflect tenant needs.

Without the right people in the room, a tabletop can identify problems but fail to create accountable solutions. The exercise should reveal where authority is unclear and turn that uncertainty into named ownership.

Run a Time-Boxed, Escalating Scenario

The episode recommends a 60- to 90-minute tabletop, including a 10-minute pre-brief and a 10-minute after-action commitment period. This format can fit into a lunch-hour-style session while still producing practical results.

The facilitator should own the clock and the flow, not provide the answers. A clear script with staged injects keeps the discussion focused. An exercise might begin with a carrier outage, add a delayed generator transfer after 15 minutes, and then introduce a vendor that cannot reach its technical contact. Each inject should force a decision and reveal whether escalation paths work in practice.

• Begin with a clear pre-brief covering the objective, scope, roles, and rules.
• Use short injects that increase the operational pressure in stages.
• Ask vendors to state capabilities and failure modes upfront.
• Limit vendor participation during the scenario to clarifying questions.
• Record decisions in real time on a visible board.

Visible decision tracking matters because it makes accountability clear to everyone in the room. It also creates the raw material for the after-action report.

Use Controlled Surprises

Unannounced elements can test communication and escalation, but they should be controlled. The purpose is to test the organization, not embarrass participants or create unnecessary legal or tenant-relations risk.

Teams should publicly define what is in scope and what is off limits. Public exercise materials should be sanitized, while sensitive remediation plans should remain in secure channels. Controlled surprises are especially useful for testing whether the right people can be reached, whether escalation contacts are current, and whether communications can be coordinated under pressure.

Choose Walkthroughs or Live Drills Deliberately

Walkthroughs are the recommended starting point when tenant risk is high or time is limited. They reveal ownership and escalation gaps without touching production systems. Live drills can validate physical responses and operating procedures, but they require more coordination, maintenance windows, and executive support.

The practical question is whether the risk of disruption is greater than the risk of never testing a change. Systems supporting critical tenant services may justify a controlled live drill, but the episode recommends successful walkthroughs first.

Turn Findings Into Owned Work

The most common failure mode is treating a tabletop as an interesting conversation instead of an operational improvement process. Every significant finding needs a named owner and deadline in the after-action report.

• Assign facilities to update generator transfer procedures by a defined date.
• Assign IT to validate secondary carrier routing by a defined date.
• Assign property management to update tenant notification procedures and confirm contact lists.
• Schedule follow-up validation before the next exercise.

The episode highlights two examples: a downtown office tower where a single unreachable vendor contact exposed a carrier-handoff gap, and a mixed-use campus where automatic transfer priorities left critical tenant IT closets on non-priority panels. The resulting changes included a documented escalation matrix, a vendor SLA amendment, a capital project to redistribute loads, and standardized interim manual-transfer steps and permissions.

Metrics for Measurable Improvement

Track the number of named actions closed on time, the number of critical dependencies identified, and mean time to decision during the tabletop. These measures help convert discussion into documented, budgetable work and measurable resilience improvements.

Use the episode resources to run a first tabletop within 30 days, assign owners before the session ends, and validate that the identified actions have actually been completed.

Why Building Technology Tabletop Exercises Matter

Technology outages in commercial properties are rarely clean, isolated events. A carrier failure can affect cloud-connected access control, phones, tenant services, and operational communications. A delayed generator transfer can add another layer of uncertainty. When those failures overlap, teams must make decisions quickly: what should fail over, what systems receive priority, who contacts vendors, and what should tenants be told?

Those decisions should not be made for the first time in the middle of an outage. A building technology tabletop exercise provides a practical way for operations, IT, security, vendors, property management, and tenant representatives to rehearse them in advance. It is not an abstract compliance activity. It is a focused process for finding brittle assumptions, unclear ownership, and weak escalation paths before tenants experience the consequences.

A well-run tabletop does not require shutting down production systems or assembling every technical diagram in the building. It requires a realistic scenario, the people who can make decisions, a disciplined facilitator, and a commitment to turn findings into assigned work.

Begin With the Decision You Need to Validate

The most effective tabletops start with a concise objective. Instead of saying the team will “test continuity,” define the exact decision area to be exercised. For example: verify decision ownership and tenant notification during a simultaneous carrier and generator failure.

That one sentence creates discipline. It tells the team what scenarios to select, which people need to attend, and what a successful exercise should reveal. Without an objective, tabletop discussions can drift toward broad technical speculation or become a list of unrelated concerns that never result in action.

Choose two realistic, prioritized scenarios that support the objective. A carrier outage that overlaps with delayed generator transfer is useful because it creates decisions across several functions. A partial power transfer that affects access control and HVAC can expose different dependencies and priorities. The point is not to create the most dramatic hypothetical event. The point is to create conditions that require participants to make the operational choices they would face in a real incident.

Map Dependencies at the Right Level

Owners and operators may hesitate to run technology exercises because they assume the conversation will become too technical. A tabletop should not require IP addresses or single-line diagrams to be useful. It should include enough technical detail to clarify dependencies and force trade-offs.

Consider the difference between a vague statement that “access control depends on the network” and a functional dependency statement: access control uses a primary carrier for cloud connectivity and a secondary carrier for synchronization. Similarly, it is important to know that a generator supports life-safety loads unless another load is manually switched. Those facts are enough to prompt meaningful questions about continuity, authority, and tenant impact.

Functional mapping helps teams identify single points of failure without losing the purpose of the session. If the discussion reaches a technical question that requires deeper analysis, record it as an action and move on. The tabletop is designed to expose what needs to be resolved, not to solve every engineering question in real time.

Invite the People Who Own the Outcome

Building technology crosses organizational boundaries. Facilities may own generator procedures. IT may manage carrier routing and technology dependencies. Security may oversee access-control implications. Property management may lead tenant communications. Vendors may be essential to restoration, and tenant representatives can help ensure that priorities and communications reflect actual tenant needs.

For that reason, the participant list should include decision makers from facilities, IT, security, vendor representatives, and a tenant liaison. Roles should be explicit before the exercise begins. If no one knows who has authority to make a particular call, that uncertainty is a valuable finding—but it needs to become a documented ownership decision afterward.

Vendor participation is important, but it should be structured. Ask vendor representatives to state their capabilities and likely failure modes before the scenario begins. During the exercise, limit their participation to clarifying questions. This prevents vendors from taking over the discussion while ensuring that the room understands what outside support can and cannot provide during an incident.

Keep the Session Short, Structured, and Realistic

A tabletop can fit into 60 to 90 minutes when it is designed around a clear structure. The episode recommends a 10-minute pre-brief, a time-boxed exercise, and a 10-minute after-action commitment period. This makes the format accessible for busy owners and operators while protecting the time needed to create accountable follow-up.

The facilitator should use a script and staged injects. The facilitator manages time and flow; they are not responsible for supplying the right answer. A scenario can begin with a carrier outage. After 15 minutes, a delayed generator transfer is introduced. Later, the team learns that a vendor cannot reach a technical contact. The sequence raises pressure and requires participants to decide what to do next.

This approach avoids a common tabletop failure: allowing conversation to spin without decisions. Each inject should create a practical question. Who is responsible for escalation? What is the immediate tenant communication? Which systems are prioritized? Who can authorize manual transfer steps? What happens if a vendor contact is unavailable?

Record the answers on a visible board as they are made. Real-time decision recording helps participants see who owns what, reveals contradictions immediately, and creates a usable record for the after-action report.

Use Surprises Carefully

Controlled surprises can be valuable because they test communication and escalation under changing conditions. However, surprises should not be used to embarrass attendees or create unnecessary risk. Introducing an unexpected vendor failure without appropriate pre-briefing can create legal or tenant-relations concerns rather than meaningful learning.

Define the exercise scope publicly, including what is off limits. Sanitize public materials and keep sensitive remediation plans on secure channels. Within those boundaries, surprises can test whether contact lists are current, whether decision makers can be reached, and whether teams can coordinate a response when the situation changes.

Walkthroughs First, Live Drills When Appropriate

Not every organization needs to begin with a live drill. Walkthroughs are often the right starting point, especially when tenant risk is high or available time is limited. They can reveal unclear decision ownership, communication gaps, and escalation problems without affecting production systems.

Live drills have a different purpose. They validate procedures and physical responses, but they require more coordination, maintenance windows, and executive buy-in. The decision should weigh the risk of disrupting tenants against the risk of never testing a change. If a system supports critical tenant services, a controlled live drill may ultimately be appropriate—but only after the organization has completed a couple of successful walkthroughs and resolved the most obvious ownership and process gaps.

What Real Exercises Can Reveal

Two examples in the episode show why tabletop findings matter. In a downtown office tower, the carrier handoff process depended on a single vendor contact who was unreachable during business hours. The corrective action was straightforward: document an escalation matrix and amend the vendor SLA. The change stopped tenant-facing outages caused by that gap.

In a mixed-use campus, an exercise found that the automatic transfer switch prioritized life-safety loads while critical tenant IT closets remained on non-priority panels. The finding led to a capital project to redistribute loads. It also produced an interim workaround: standardized manual transfer steps and clear permissions for who could use them.

Neither result was merely a meeting note. Each became operational work with a business purpose: reducing avoidable tenant downtime. That is the standard a tabletop should meet.

Make Follow-Through Part of the Exercise

The most common tabletop failure is the absence of follow-through. Teams may have a productive discussion, identify meaningful gaps, and then leave without named owners or deadlines. In that case, the exercise becomes an interesting conversation rather than a resilience improvement program.

Assign ownership explicitly in the after-action report. Facilities might own updates to generator-transfer procedures. IT might own validation of secondary carrier routing. Property management might own revisions to tenant notification procedures and contact-list confirmation. Each item needs an owner and a date.

Then schedule a follow-up to verify action completion before the next exercise. Track the number of named actions closed on time, the number of critical dependencies identified, and mean time to decision during the tabletop. These metrics make improvement visible and help translate resilience needs into prioritized, budgetable work.

Run the First Tabletop Within 30 Days

A first tabletop does not need to be perfect. It needs a clear objective, two realistic scenarios, the right decision makers, staged injects, and an after-action process that names owners and deadlines. Start with a walkthrough, keep technical detail functional, and use the results to improve the next session.

For more practical guidance on rehearsing outages across building operations, IT, security, vendors, and tenants, listen to this episode of Built, Wired & Secured and use the available tabletop, facilitator, and after-action resources to begin.