We tend to think that once we have the right tools—EDR, XDR, SIEM—we’re safe. That detection is protection. That visibility equals control.
But here’s the catch: when ransomware hits, it doesn’t test your tools first.
It tests your people.
And more specifically, your team’s ability to work through chaos with clarity.
Because detection is just the beginning. What happens next is where most of the risk lives.
A Runbook Isn’t a Response
Many companies—especially midsize teams with growing infrastructure—do have incident response runbooks. These are useful. They provide a starting point. A structure.
But a runbook is a document. It doesn’t tell you how people react under pressure. It doesn’t help you notice the subtle gaps—the ones that don’t show up in a checklist but do show up in the middle of a real-world incident.
That’s where simulation becomes valuable.
It’s not about testing individual knowledge. It’s about observing the system as a whole—how people communicate, where decisions slow down, what assumptions no longer hold.
What a Ransomware Simulation Actually Looks Like
Let’s say you start with something familiar:
Your DevOps team receives a Slack message at 9:17 a.m.
“Staging is down. Jenkins jobs are failing. S3 snapshots look… off.”
What do you do?
You don’t have to take real systems offline to find value. You just follow the thread:
- Who declares the incident?
- What systems need to be locked down first?
- How fast can you verify the integrity of backups?
- What happens if the attacker already has keys to the CI pipeline?
You’ll find that the biggest insights come not from failure—but from hesitation.
From the “wait—who owns that again?” moment.
What Mid-Sized Teams Can Do in Two Weeks
You don’t need to build a red team. You don’t need to overhaul your IR program.
Most of the value comes from one or two focused sessions.
Here’s what we’ve seen work:
- Bring together the people who build and maintain product infrastructure—not just security.
- Walk through a single, realistic ransomware scenario.
- Use your real architecture—don’t simulate a fake environment.
- Map the response paths: who notices, who acts, who gets left out.
- Debrief not on who was slow, but where the system was unclear.
By the end, you’ll have more than a plan—you’ll have alignment.
Why This Matters More Than a New Tool
Ransomware is fast. But recovery is always slower than we expect—unless we’ve already practiced.
It’s one thing to know your systems. It’s another to test them in motion, with humans involved.
Detection tells you something’s wrong.
Simulation helps you understand what comes next—and what to fix before it matters.
If you’re leading a product or infra team and you’ve never practiced a ransomware scenario, this is worth exploring.
Not to fear the worst, but to build the clarity you’ll need if it ever happens.
