It always starts like a normal day. You grab coffee, drop your lunch in the fridge, skim through tickets and emails, maybe even snag a donut someone brought in because they were late. Then you see it: a ticket that says a client can’t print. Not urgent, but worth a look.
Hours pass, meetings stack up, and just as you’re about to open that ticket, the next thing hits. Suddenly, multiple clients are reporting the same “printer problem,” and the room shifts. What started as an everyday annoyance has just turned into the opening scene of a ransomware attack.
Last year, myself and other Galacticos spent some time with Managed Service Providers going over a scenario exactly like this one. What seemed like an innocuous problem snowballed into a full-scale cyberattack and ransomware event. Its purpose? To help these MSPs plan for an Incident before a real one occurred.
So what are we talking about? Tabletop Exercises.
Not only are they critically important for your organization, but for your clients as well. Think of it like Dungeons & Dragons for cybersecurity, except instead of fighting Displacer Beasts, you’re battling ransomware, phishing attacks, and the occasional end user who may have clicked and ran something they shouldn’t have. It’s a role-play scenario where the bad day happens on paper (or PowerPoint) instead of in your production environment.
The point isn’t to show off how fast your engineers can reboot a server. It’s to walk through the messy business of decision-making when things go wrong. That means risk owners, leadership, and the folks who hold the purse strings need to be at the table. Sure, the tech team is important, but if the CEO doesn’t know when to call for help, or if leadership freezes when deciding whether to pay a ransom, your playbook falls apart before anyone even opens their laptop.
Running a tabletop internally is like stress-testing your parachute before you jump out of the plane. You get to see if your incident response policy and playbooks actually work, if they’re just binder-filler written five years ago and never looked at again, or if there even is an Incident Response Policy and procedure to begin with! And here’s where it gets fun. The gaps you think you’ll handle always show up at the worst possible moment.
I’ve been in situations where no one even agreed on what qualified as an “incident,” so the response stalled while attackers waltzed deeper into the environment. I’ve seen middle-of-the-night alerts where nobody could wake up the right person because their personal cell number wasn’t on file. I’ve even watched HR and IT play hot potato over who was responsible for notifying employees, each assuming the other was handling it while nothing got done.
That’s why tabletops matter. They force these breakdowns to surface in a safe environment. You’re not just checking boxes for compliance, you’re proving whether your processes are battle-ready or destined to collapse the second a real incident hits.
Most MSPs think they’ll rise to the occasion when things go wrong. But here’s the uncomfortable truth: you don’t rise to the occasion, you fall back on whatever plan you’ve practiced. If you’ve never practiced? You’re gambling with your business, your clients, and maybe even your reputation.
In Part Two, we’ll dig into why running a fake incident is so much better than surviving a real one-- and why the “coffee vs. yacht” tradeoff isn’t just a clever title, it’s the real math of security.
