Your recovery plan has a security-tool blind spot

My favorite question to CISOs has always been a simple one. I ask them to walk me through what they do when something happens.

Nobody enjoys that question, and I understand why, because I would not enjoy it either. CISOs carry more than almost anyone in the company, and they answer for systems they do not even run.

When we go through it together, step by step, the conversation moves from backups to applications to the order everything comes back in. Yet one part almost never comes up. It's the security stack itself that keeps everything else safe.

The layer your recovery plan leaves out

In an earlier post I described recovery as a three-layer problem. Infrastructure, data and application all have to come back, in the right order and configured correctly, for the business to function.

Security tools sit inside the infrastructure layer. The EDR policies, the firewall rules and the zero-trust configuration that ties them together are as much a part of the running business as the servers they protect.

Yet most recovery plans leave them out. Recovery plans grew out of disaster recovery, which was written for data and servers, so security tools were never in scope and nobody wrote them in.

For a CISO, I would say this is one of the most practical gaps to close. Your team already knows these tools better than anyone..

Years of judgment in one place

An organization running 83 security solutions has 83 sets of rules, exclusions and integrations. Many of those exclusions exist because someone on your team investigated a false positive at midnight and made a call.

Together they hold years of judgment from people who knew the business, and some of those people have since moved on.

Your backups hold your data, and your IaC holds the part of your estate you managed to codify. Some security configuration lives in IaC too, but not every setting is supported there, and what is codified can drift from what is running. The rest usually lives only inside the tools themselves, with no second copy.

The security layer moves first

Disruption comes in two forms: a cyber attack, or a failure with no attacker at all. In both, the security layer is often the first thing to change.

In an attack, the security layer is changed on purpose, to bypass defenses and remove fingerprints. Cisco Talos and Trend Micro documented the Qilin and Warlock groups using vulnerable drivers to shut down more than 300 EDR tools. Encryption came roughly six days after first access, plenty of time to change a policy or add a quiet exclusion.

Without an attacker, the tools themselves can be the cause.  In July 2024, a faulty CrowdStrike content update crashed 8.5 million Windows devices. In November 2025, a Cloudflare Bot Management configuration file doubled in size and caused widespread errors across sites on its network for about three hours. Cloudflare confirmed it was not a cyber attack.

These tools are powerful enough to stop an attack, and that same power is why they need a way back.

Where the rebuild gets hard

Picture the recovery call on day three. Your data is back and the core applications are coming up. People are exhausted, and for the first time in days somebody sounds hopeful.

Later someone asks whether the EDR policies on the restored servers match what was there before, and the room goes quiet. Here is the mechanism behind that silence.

The order matters. Identity and security controls have to come back before the business applications that depend on them. Nobody wants to bring the ordering system back online into a network where the EDR is off and the firewall rules were edited by the attacker.

The right state is hard to pin down. Most of us could not say with confidence what our EDR policy set looked like last Tuesday.

The restore breaks the links. A restored cloud workload often comes back with new identifiers, such as a new IP address, a new DNS name or a new resource ID. Security rules that pointed at the old values now point at nothing, so the application is up and running without the protection it had yesterday.

The rebuild is manual. Someone opens 29 vendor consoles and rebuilds the rules from memory, under pressure, during the worst week of the year.

Nobody got this wrong. Security tools were built to detect and block, and they do that well. But rebuilding a tool from zero, in order, alongside the rest of the estate was never part of their job. A rebuild from memory also loses the years of judgment stored in those rules. So the way back has to live in the recovery plan.

Last known good state. The most recent configuration of a system that you know was correct and trusted. For a security tool, that means the policies, rules, exclusions and integrations as they stood before an incident or a bad change.. Restoring to that state only works if the configuration was recorded before the incident.

Four questions to add to your recovery plan

I would add these four to any recovery plan this quarter, and none of them is quick to answer.

1. Which security tools does each business application depend on to run safely? Map the policies behind each critical application.
2. What is the last known good configuration of each tool, and where is it written down? If the only copy lives inside the tool, you lose it the moment the tool is changed or compromised.
3. In what order do they come back? Put identity and security controls in the runbook ahead of the applications that need them.
4. Who rebuilds them, and how long does that take today? If the answer is "one person, from memory, over a few days (if at all)," that number belongs in your recovery time.

A CISO who can answer these four walks into the board meeting with something rare. They can show how the business keeps running or comes back fast, protected and in the right order, including the layer most recovery plans leave out..

Why this is a mapping problem

Every organization connects its security stack to its business differently, which kept this hard to solve for a long time. The configuration sits in dozens of consoles and the dependencies sit in people's heads.

At Gambit we treat this as the same problem as the rest of recovery. You map how the business actually runs across infrastructure, data and application. You track Infrastructure Drift between what was intended and what is running. And you know the last known good state before the day you need it.

You built that stack, rule by rule. It deserves a way back.

‍

Want to see how recovery holds up in your own environment? Book your Resilience Assessment.