Recovery versus availability: the call only an executive can make

In the middle of an identity breach, the loudest pressure on a leader is to bring services back. That instinct, applied too early, can hand the environment back to the attacker. This is a decision a technical lead cannot own alone. It is an executive call.

The conflict

Availability says restore now: the business is down and every hour costs money. Recovery says not yet: if identity was compromised, reconnecting before trust is verified reinstates whatever access the attacker planted. Both pressures are legitimate. They point in opposite directions, and someone with authority over the business impact has to choose.

What recovery actually means

Recovery is not the moment services appear to work again. It is the moment identity is verified, monitored, and trusted to enforce access decisions. Systems looking functional is not the same as systems being trustworthy. Premature closure, declaring victory because the lights are back on, is how attacker access survives an incident.

The questions an executive should ask before reconnecting

Has the krbtgt account been reset, twice, where Kerberos was in scope. Has the persistence been found and removed, not just the obvious entry point. Is monitoring tuned to catch a return. Can the team show evidence, not assurance, that trust is restored. If the answer to any of these is not yet, restoring availability is accepting measurable risk, and that acceptance should be a documented, timestamped decision.

Why document it

The board will later ask when you knew and what you did. A recorded decision, with the tradeoff stated, is both better governance and your defensible record.

Practice it

We built this as an executive pressure-test scenario in GraphLattice Range, so leaders rehearse the recovery-versus-availability call before they have to make it for real.