TLDR: Most tabletop exercises are built around scenarios that don’t reflect how breaches actually happen. The 2026 Verizon Data Breach Investigations Report, drawing on more than 22,000 confirmed breaches, shows that attackers are getting in through vulnerability exploitation more than anything else, that ransomware victims are often telegraphing their compromise weeks before it hits, and that nearly half of all breaches now involve a third party. If your tabletop doesn’t account for any of that, you’re rehearsing for the wrong incident.

Tabletop exercises have become a fixture of security programs across almost every industry. Compliance frameworks require them. Regulators ask about them. Boards find comfort in hearing that one happened recently. On paper, they represent exactly the kind of proactive thinking that separates a mature security program from a reactive one.

The problem is that most of them are built on assumptions that haven’t been true for a while.

We run tabletops and we conduct offensive assessments, and the gap between what organizations rehearse and how breaches actually unfold is one of the more consistent things we see across engagements. The 2026 Verizon Data Breach Investigations Report, released this year and covering more than 22,000 confirmed breaches across 145 countries, puts hard numbers to what we observe firsthand. The picture it paints is not one that most tabletop scripts are designed to address.

The Scenario Problem

The majority of tabletop exercises open with a phishing email. Someone clicks a link, credentials get stolen, and the scenario proceeds from there. The team works through detection, escalation, containment, and communication. It is a reasonable scenario. It is also increasingly not how attackers are getting in.

According to the 2026 DBIR, exploitation of vulnerabilities has become the single most common initial access vector, now appearing in 31% of breaches, a 55% increase from the prior year. Credential abuse, which held the top spot for years, has fallen to 13% as the first-observed initial action. Phishing remains significant, but when your exercise opens with a phishing email every single time, you are training your team to respond to a scenario that represents a shrinking share of how real intrusions begin.

This matters because the response is different. A phishing-initiated compromise typically involves a user device, moves laterally from there, and involves a timeline shaped by what the attacker can do with stolen credentials. A vulnerability exploitation event often hits internet-facing infrastructure directly: web servers, VPN appliances, remote access platforms. That path can result in the attacker operating at a higher privilege level from the start. The detection signatures, the affected systems, the escalation path, and the containment strategy are all different. If your team has only rehearsed one of these, they have a gap.

The Warning Signs You’re Not Looking For

One of the more striking findings in this year’s DBIR involves the relationship between credential theft and ransomware. The data shows that among ransomware victims where prior activity could be traced, 50% had a credential or infostealer event occur within 95 days before the ransomware attack. The breach, in other words, was not a sudden event. It was the visible end of a sequence that started weeks or months earlier, often with credentials quietly stolen and sold or used to establish access.

Tabletop exercises almost universally begin at the moment of detection: the alert fires, someone notices something wrong, and the team responds from there. That framing skips the part of the story that matters most for prevention: the quiet phase before detonation. A more useful exercise asks a different set of questions. What would we have seen in the 90 days before this incident? Where in our environment would an infostealer have found credentials worth taking? Do we have visibility into credential exposure on third-party leak sources? Would anyone have noticed?

Most teams cannot answer those questions with confidence, not because they lack capability, but because they have never been asked to think through that part of the problem in a structured way.

Your Third Parties Are In the Scenario Whether You Include Them or Not

Third-party involvement in breaches increased 60% year over year in this year’s DBIR, reaching 48% of all confirmed breaches. Nearly half of all breaches now have a third party somewhere in the chain: either as the initial access point, as the custodian of compromised data, or as the network connection that let an attacker move from a vendor environment into yours.

The DBIR identifies three distinct archetypes here: a vulnerability in a vendor’s software that serves as the entry point; a vendor hosting your data whose environment is breached directly; and a vendor with a connection to your environment that gets exploited for lateral movement. Each of these involves different response considerations, different notification obligations, and different containment options.

Most tabletop exercises treat the organization as a closed system. The scenario happens inside your perimeter, your team responds, and third parties appear only as notification recipients: legal counsel, a cyber insurer, maybe a regulator. The exercise does not contemplate the scenario where your security team is not the initial victim, where you have limited visibility into what happened on your vendor’s side, or where your ability to contain the incident is constrained by what a third party is willing to share or how quickly they move.

When half of breaches involve a third party, a tabletop that never puts the team in that situation is leaving a significant portion of your actual risk unexamined.

What Happens After Initial Access

Even when a tabletop exercise starts with a realistic initial access scenario, most of them collapse the middle of the attack. The attacker gets in, the team detects it, and the exercise moves quickly to response and recovery. The lateral movement, privilege escalation, and target identification phases, the parts where an attacker does the most damage and where defenders have the most opportunities to stop them, are often treated as a brief narrative summary rather than something the team has to actually reason through.

The DBIR’s deep dive on privilege escalation this year identifies credential dumping from LSASS memory as one of the most common techniques observed across real incidents, appearing in 20% of cases. Service accounts with misconfigured passwords and weak hashing protocols are a consistent target. Attackers are not simply walking in and running ransomware. They are moving through environments, elevating privileges, and identifying what’s worth taking or encrypting before they act.

A tabletop that skips this phase also skips the questions your team most needs to practice: Where would an attacker find elevated credentials in our environment? Which service accounts have excessive permissions? If an attacker had been operating in our network for two weeks before we detected anything, what would they have accessed? These are uncomfortable questions, and they tend to produce more useful conversations than a scenario that moves from initial access to ransomware detonation in a single narrative step.

Designing an Exercise That Reflects Reality

None of this means tabletops are not worth doing. They are, provided they are built to reflect the threat environment your organization actually faces rather than the one that was common several years ago.

A few things that make exercises more useful in practice:

Start the scenario before the detection. Build in a phase where the team has to reason backward from evidence: a threat intelligence tip, an anomalous authentication log, a vendor disclosure, and determine whether an intrusion may already be in progress. This tests detection and analysis capability rather than just response procedure.

Use a third-party breach as the initiating event at least some of the time. Your vendor calls you on a Friday afternoon and tells you they have experienced a breach that may have involved your data or your network connections. What do you do? Who makes decisions? What are your contractual rights? How do you assess your own exposure when the initial activity did not happen in your environment?

Make the team answer hard questions about their own environment. Rather than presenting a generic scenario, base the exercise on your actual attack surface: your real vendors, your real remote access infrastructure, your actual credential management practices. This is where an offensive assessment done prior to the tabletop becomes genuinely useful: the findings give the exercise real specificity, and the team is reasoning about actual gaps rather than hypothetical ones.

Build the scenario around your most consequential systems, not your most convenient ones. A ransomware scenario that encrypts a file share is a different conversation than one that hits your core operational systems or your most sensitive data. The harder scenario is the one worth running.

The Purpose of the Exercise

The value of a tabletop is not in completing it. It is in the gaps it surfaces: the decisions that stall, the ownership questions that nobody can answer, the systems where the team realizes they have no visibility. A well-designed exercise should leave the team with a prioritized list of things to fix, not a completed checklist.

The data on how breaches actually happen is more specific and more actionable than it has ever been. The gap between that data and what most organizations rehearse is one that shows up, eventually, in real incidents. Closing it does not require a perfect exercise program. It requires an honest one.

Where to Start

If this surfaced some gaps worth addressing, a few concrete starting points:

• Read your last tabletop report and note how the scenario began. If it opened with a phishing email and stayed inside your own environment, you now know what it did not test.
• Ask your IT team or MSP when your most critical internet-facing systems were last assessed for exploitable vulnerabilities. Not scanned. Assessed.
• List your top vendors with access to your systems or data and ask, for each one, how you would find out if they were breached and how quickly.
• Check how many accounts in your environment carry administrative privileges and whether any belong to former employees or service accounts with stale credentials.
• Run a short tabletop with your actual decision-makers, including legal, finance, and communications, using a vendor breach as the opening scenario rather than an internal one.

Satine Technologies is a veteran-owned offensive cybersecurity firm founded by former military cyber operators. We help organizations understand their security from an attacker’s perspective through assessment, IR preparedness, strategic advisory, and response.