Veeam’s Data Trust and Resilience Report, published in April 2026 from responses by more than 900 senior IT, security and risk leaders, contains a pairing that ought to stop any backup team mid-sentence. Ninety percent of organizations expressed confidence in their ability to recover from a cyber incident. Among those actually hit by ransomware, 28% fully recovered all affected data.
The easy interpretation is that executives are overconfident. That reading is available, and it is not entirely wrong, but it is not very useful — telling people to be less confident does not improve recovery outcomes. The more productive reading is that these two numbers are measuring different things, and the gap between them is where most data-protection programmes quietly fail.
What “recovered” turns out to mean
The middle of the distribution is more instructive than either headline. Organizations recovered, on average, 72% of affected data. Forty-four percent recovered less than three quarters of it. So the common outcome after a ransomware incident is not total loss and not clean recovery — it is a substantial partial restore, with a remainder that is gone.
This is the specific failure mode confidence surveys cannot capture. Asked “can you recover?”, an administrator who knows the backup jobs are green and the retention policy is sound answers yes, correctly. The question that predicts the 28% is different: can you recover everything, inside the RTO, when the restore is happening under incident conditions across every affected system simultaneously? Almost nobody has evidence for that, because almost nobody tests at that scale.
Veeam’s own framing of the gap is that stronger organizations do not assume recovery will work under pressure — they test restores and validate the outcome. The confidence figure measures belief in a capability. The 28% measures the capability. Belief is calibrated by successful individual restores, which are common and easy; the capability is exercised only by a full-scale event, which is rare and hard.
The RTO alignment problem underneath it
One further pair of numbers explains part of the mechanism. Ninety percent were confident of recovering within their recovery time objectives — but only 69% said their RTOs were fully aligned with business continuity goals.
That is a roughly twenty-point gap between confidence in hitting a target and confidence that the target is the right one. An RTO that was set by the infrastructure team based on what the backup system can deliver, rather than derived from what the business can absorb, is a number you can hit while still failing. Meeting a 24-hour RTO on a system the business needed back in four hours is a green metric and a red outcome.
This is why the business-impact figures in the same report look worse than the confidence figures would predict. Among organizations that experienced a cyber incident, 42% reported customer or constituent disruption, 41% reported financial loss or revenue impact, and 38% reported extended downtime of critical systems. Those are the consequences of recovery that technically succeeded against the wrong target, or succeeded for 72% of the data.
Budget correlates with outcome, but through measurement
The report splits its population almost evenly on spending: 49% increased cybersecurity budgets year over year, while 51% held flat or cut. The outcome difference between those groups is the most actionable finding in the document. Organizations that increased budgets were roughly 2.5 times more likely to fully recover all affected data — 40% versus 16%.
What makes this more than a “spend more money” conclusion is what the higher-budget group did differently. They tracked recovery-relevant metrics far more often:
- RTOs tracked: 78% versus 56%
- Time to isolate or contain an incident: 47% versus 36%
- Automated or orchestrated recovery: 32% versus 14%
The automation gap is more than double, and it is the one most directly tied to the 72%-average-recovery problem. Manual restore at incident scale is where partial recovery comes from — a human-paced sequence of dependency-ordered restores, under time pressure, with imperfect documentation of what depended on what. Orchestration is what turns a tested runbook into a repeatable outcome rather than a best effort.
Notably, none of these three are storage purchases. They are instrumentation and process. The correlation with budget is real, but the mechanism appears to run through measurement discipline as much as through hardware.
The AI exposure the report flags
The 2026 edition adds a category that did not meaningfully exist in earlier surveys, and it maps onto a recovery problem rather than only a security one. Forty-three percent said AI adoption is outpacing their ability to secure data, 42% reported limited visibility into all the AI tools in use, 40% said security policies have not been updated for AI risks, and 25% named shadow IT and unauthorized AI tool usage as a primary concern.
For backup and DR specifically, the relevant consequence is scope. Data protection depends on knowing where the data is. Vector stores, fine-tuning datasets, prompt and retrieval logs, and the working data inside unsanctioned tools are all business data that a recovery plan has probably never enumerated. An organization with 42% visibility into its AI tooling has an unknown fraction of its data outside the backup scope entirely — which is one plausible contributor to a 72% average recovery rate.
What to take from it
The report is best read as an argument for replacing confidence with evidence, and it suggests three specific substitutions:
- Replace “backups are green” with a scale-realistic restore test. Green jobs prove data was written. They say nothing about parallel restore throughput, dependency ordering, or whether the runbook survives contact with an incident. Test the multi-system case, on a schedule, and record the actual elapsed time.
- Re-derive RTOs from the business, then check you can hit them. The 90%-versus-69% gap means a large minority know their targets are not the right targets. An RTO inherited from infrastructure capability is a description of the tooling, not a requirement.
- Instrument recovery, then automate it. The higher-recovery cohort tracked RTOs, containment time and orchestrated recovery at markedly higher rates. Measurement is what makes the 72% visible before an incident rather than during one.
The uncomfortable conclusion is that most of these organizations are not wrong to be confident about individual restores. They are confident about the wrong test. Only 28% have passed the one that counts, and the difference between the two groups looks less like spending and more like having actually tried.
Source: Veeam, Data Trust and Resilience Report 2026 (900+ senior IT, security and risk leaders; published April 2026).