Muscle Memory in the Boardroom: Why One-Size-Fits-All Tabletops Fail

From the Boardroom to the Battleground.

No professional sports team takes the field without practice. They don’t just read the playbook; they run the drills until the movement is instinctual. They build muscle memory.

Yet, in cybersecurity, we often expect our organizations to perform perfectly during a crisis with nothing more than a paper plan and a once-a-year generic drill.

I’ve run tabletop exercises (TTX) across various organizations, from technical deep dives to board-level simulations. I’ve learned that you cannot build resilience with a single, monolithic exercise. You need a tiered approach that builds rigor from the server room to the boardroom.

Here is how effective leaders build muscle memory across the entire business.

It Starts Before the Exercise (The Interview)

The success of a tabletop isn't determined in the room; it’s determined during the CISO’s interview process.

When I interview for a role, I look for sponsorship. I don’t necessarily expect the entire Board to sit through a four-hour simulation, that is rarely logistically possible. However, I do ask: Is there active participation from the Audit or Risk Committee? Will the CEO or CFO engage in the executive session?

The answer to this question acts as a litmus test for the organization's culture. If they hesitate or view these exercises as a mere compliance requirement, I know I will be fighting an uphill battle. But if they show genuine interest in testing their readiness, it signals that security is viewed as a business risk, not just a "checkbox." You need to know before you join if you have the air cover to build real rigor.

The Three-Tiered Approach

You cannot put a sysadmin and a Board member in the same tabletop and expect a productive outcome. Their "muscle groups" are different. A successful strategy requires three distinct, overlapping layers of rigorous practice.

1. The Technical Layer: The Reality Check

This is where we build the "defense" and "offense" logic.

• The Players: Incident Response (IR) teams, Security Engineering, IT Operations.

• The Goal: Stress-test the tools and the technical playbooks. Can we actually isolate that VLAN? Do the backups actually restore in time?

• The Overlap: I often have members of the Crisis Management Team (CMT) listen in. It might be "boring" for them technically, but they need to hear the friction. They need to understand what the team is up against so they don't make impossible demands later.

  
  

2. The Operational Layer: The Business Decision

Once we know the technical reality, we move to the business layer (SVPs, VPs, Senior Directors).

• The Players: Business Unit leaders, Legal, HR, Communications.

• The Goal: Focusing on business continuity. If systems are down, do we have manual workarounds? Do we have a week’s worth of product in the warehouse we can ship, or is our supply chain halted?

• The Strategy: We use the outputs of the Technical TTX as the inputs for this session. We don't give them a hypothetical scenario; we give them the mess the technical team just uncovered.

  
  

3. The Executive Layer: The Strategic Pivot

This is the most critical and difficult layer.

• The Players: CEO, CFO, and representatives from the Audit or Risk Committee.

• The Goal: Brand reputation, regulatory maneuvering, and "bet-the-company" decisions.

• The Facilitator: You cannot have a technical vendor run this. You need a facilitator with Executive Presence, someone who understands risk tolerance, business acumen, and can hold their own with a CEO.

• The Inject: This must be hyper-realistic. It cannot be a copy-paste scenario from another company. It has to attack our specific fears.

  
  

The "All or Nothing" Lightbulb Moment

The value of this tiered approach is finding the gaps in understanding. I recall one organization where leadership believed we had a flexible, "fractional" Disaster Recovery (DR) plan, meaning we could restore specific critical systems piecemeal while others remained offline.

During a tabletop, the reality surfaced: Our DR was "All or Nothing."

There were two reasons for this, and both shocked the executives:

1. The Cloud Trap: Because of how we had moved to the cloud, a "lift and shift" rather than a cloud-native adoption, our IP address dependencies and DNS propagation rules meant we couldn't just spin up one system in the recovery environment. We had to fail over everything (Tier 1 systems) or nothing.

2. The Human Constraint: The executives asked, "Well, if we can't fail over just one system, can't we just rebuild it in place?" Ideally, yes. But the tabletop simulation revealed a capacity flaw. A rebuild isn't instant; it requires spare compute, memory, and time. If we had a major outage affecting multiple systems, we physically didn't have the "feet on the street"—the sheer number of engineers required, to rebuild every system simultaneously within our 4-hour recovery target.

   
   

The plan worked on paper for a single server. But at the scale of a major attack, the "Rebuild in Place" strategy collapsed under the weight of resource constraints.

The executives were shocked. "I thought we could just bring up the billing system?"

No. The plan worked, but not the way they thought it did. This misalignment usually happens because of leadership churn, new executives come in, the "tribal knowledge" of why the system was built that way leaves, and assumptions fill the void.

The tabletop exposed this gap before a real crisis did. It forced us to re-evaluate our risk acceptance and update our cloud strategy.

Developing the Narrative

Finally, muscle memory includes communication. A major failure in tabletops is forgetting the "White Collar" impact.

• Internal: If the network is cut, how do we tell 5,000 employees not to come to work? Do we have their personal emails?

• External: What do we tell the regulators vs. the media?

  
  

By weaving these communication injects into the Executive and Operational tabletops, we ensure that when the bad day comes, we aren't writing press releases from scratch.

Conclusion: Confidence in the Chaos

Building rigor takes time. You start with the technical teams, you let those lessons bleed into the business tier, and you validate the risks at the executive tier.

When you do this right, you aren't just testing a plan; you are teaching the organization how to think. You are building the muscle memory required to take a hit, stay standing, and fight back.