In the middle of a recent incident triage, a familiar theme surfaced, one that comes up far too often in cyber discussions:
Many companies say they have backups. Far fewer have confidence they can actually recover.
These are not the same thing.
Backups, on their own, are a control. Recovery is an outcome.
And in a real incident (especially ransomware) the only thing that matters is whether the business can restore operations quickly, predictably, and with minimal disruption.
The gap between those two ideas is where risk lives.
The Illusion of Safety
It’s easy for organizations to feel reassured when backups are in place. There may be dashboards showing successful jobs, retention policies configured, and even third-party tools managing the process.
But when you ask a few simple questions, that confidence often starts to erode:
- When was the last time restoration was tested?
- How long would recovery actually take?
- Who decides when to initiate recovery, and how quickly can they act?
- What systems or dependencies could slow the process down?
- Are backups truly isolated from the production environment?
- Can the business operate while recovery is happening?
These are not technical edge cases. They are operational realities that determine whether a business can survive a cyber event without significant disruption.
Where Things Break Down
Consider a common scenario: a company experiences a ransomware attack and decides to restore from backups. On paper, everything looks fine, backups are recent and complete.
In practice, recovery stalls.
Why? Because critical dependencies weren’t accounted for. Perhaps identity systems (like Active Directory) are compromised, making it difficult to authenticate users during restoration. Or maybe key applications rely on third-party integrations that aren’t easily reconnected. In some cases, backups themselves are discovered to be incomplete or corrupted.
Another frequent issue is access control. Many organizations claim their backups are “immutable,” but in reality, administrative accounts still have the ability to delete or alter them. If an attacker compromises an admin account (as they often do!) those backups may be at risk.
The Importance of True Isolation
A resilient backup strategy requires meaningful separation from the production environment. This might include offline storage, strict access controls, or immutability mechanisms that prevent deletion, even by privileged users.
But even then, the question remains: has this been tested under realistic conditions?
Testing is what turns a backup into a recovery capability.
Recovery Is a Business Decision
Recovery is not just a technical process, it’s a business decision made under pressure. Who has the authority to trigger restoration? How quickly can that decision be made? What is the acceptable level of downtime?
For private equity-backed businesses, these questions carry even more weight. Downtime translates directly into lost revenue, operational disruption, and potential reputational damage. In some cases, it can even impact deal value or exit timelines.
What Good Looks Like
This is where structured approaches, such as portfolio-wide resilience frameworks like The Cyber Poverty Line can play a role. By standardizing how recovery readiness is assessed, tested, and improved across portfolio companies, firms can move from inconsistent assumptions to repeatable confidence.
Strong organizations focus less on having the most advanced tooling and more on having a proven, documented recovery process.
They run restoration tests regularly.
They understand their recovery time in real terms, not estimates.
They identify and plan for dependencies.
They ensure backups are genuinely protected from compromise.
And they align recovery plans with business priorities.
In short, they replace assumptions with evidence. Because in a real incident, there is no credit for having backups, only for being able to recover.
If you’ve had an incident and need a confidential, no-obligation review, get in touch and we’ll be happy to help.