Ask any leader if their company has backups, and the answer comes quickly: yes, of course. Ask how long it would actually take to get the business running again after an attack, and the room usually goes quiet. That quiet is the problem. Backups are easy to buy and easy to report on. Knowing your real restore time, the number of hours it truly takes to get back to work, is much harder, and almost nobody has actually tested it.
The numbers bear this out. A Data Trust and Resilience Report of 2026, drawn from more than 900 senior IT, security and risk leaders, found that 90% were confident they could recover from a cyber incident within their stated recovery time objectives – yet among organisations actually hit by ransomware, only 28% fully recovered their affected data, and 44% recovered less than three quarters of it. Confidence and capability are not the same thing. That gap is where most recovery plans fall apart, usually at the worst possible moment.
Backup vs Recovery: Why Having a Copy Is Not the Same as Being Able to Restore
A backup is just a copy of your data sitting somewhere safe. Recovery is something bigger: it is the proven ability to turn that copy back into a working business, in the right order, with the right people able to log in and use it. A company can tick every box on backup coverage and still have no real ability to recover, simply because nobody has ever timed how long the rebuild actually takes under real pressure. Coverage tells you data exists somewhere. It tells you nothing about how fast you get it back.
Two Kinds of Protection, Solving Two Different Problems
For years, having a copy of your data in another location was considered enough. It protects you if a building floods or a data centre goes down. But it does very little against today’s biggest threat: an attacker who has already stolen valid login credentials and can reach your backup copies the same way your own team does. This is why more companies are moving toward immutable backups – copies that cannot be changed or deleted once written, for the length of a defined retention period, even by someone with administrator access. Think of it as the difference between storing your valuables in a second house versus storing them in a vault that even you cannot open early. Both matter. Confusing one for the other is an expensive mistake.
This is also why the familiar 3-2-1 backup rule is being extended. The versions gaining ground now are 3-2-1-1, which adds one immutable or air-gapped copy, and 3-2-1-1-0, which adds a zero: no errors, verified through actual restore testing rather than backup success reports.
The Order You Restore In Matters More Than People Realise
Most recovery plans list the systems that need to come back, but not the order they need to come back in, and that gap gets discovered live, during a crisis, usually argued out loud by exhausted people. In practice, there is a natural sequence. The system that lets people log in and prove who they are has to come back first, because nothing else works without it. After that comes the shared foundation everything else sits on, then the core business systems, and only then the smaller applications. Skip a step, and you simply end up doing the work twice.
The industry is catching up to this. Gartner now predicts that by 2030, 70% of organisations will prioritise the recoverability of identity systems alongside their preventive identity and access controls – up from less than 15% in 2026. The companies that recover fastest are the ones that agreed on this order calmly, months before anything went wrong, and actually rehearsed it.
Who Should Set RTO and RPO? Let the Business Decide
Too often, it is the technology team that quietly decides how quickly a system should be restored, based on what the backup tools can manage rather than what the business can survive. That is backwards. A factory line that stops the moment scheduling software goes down needs a very different answer than a marketing website. A finance team closing the books can rarely tolerate losing even a day of data, while a training system probably can. These are business calls, not technical ones. The people who depend on a system should decide how much downtime and data loss they can live with, and technology should be built to meet that promise, not the other way around.
The Gap Nobody Talks About
Most companies can tell you the recovery time they have promised on paper. Very few can tell you the recovery time they actually deliver when tested for real, and the space between those two numbers is where the real risk hides. A promise of four hours, never once tested, is not really a four-hour capability. It is a hope dressed up as a plan. The simplest thing any leadership team can do this year is start asking for that gap, honestly, and track it the same way they track any other business risk.
Two Recent Wake-Up Calls
On 14 July 2026, Romania’s national land registry went dark. Attackers reached the systems of ANCPI, the National Agency for Cadastre and Land Registration, and the country’s property market froze behind them — notaries could not authenticate sales, and citizens could not obtain proof of ownership. Romania’s National Cyber Security Directorate said afterwards that the attack was not complex and could have been prevented, pointing to leaked credentials combined with known vulnerabilities the directorate had recently flagged to the agency.
Accounts of the damage differ. A Threat intelligence firm and several security outlets reported that the attacker deleted the land registry database outright after a failed extortion attempt; ANCPI maintained that its core legal and technical databases were never compromised, and that offline backups held at several locations survived. On 27 July the government confirmed a ransomware attack in which part of the virtualisation infrastructure was encrypted and deleted. What is not in dispute is the clock. The e-Terra system came back in stages from 11 August, twenty-eight days after it went down, and only for internal staff, notaries and authorised surveyors at first. Public-facing platforms, including the payments application, were still offline. Roughly 94,000 requests had been left pending. Throughout early August, officials could not give citizens a date.
A similar lesson played out years earlier at the shipping giant Maersk, hit by the NotPetya attack in June 2017. The company had backups of individual servers scattered worldwide, but every copy of the system that let staff log in — its domain controllers — was destroyed as the malware tore through the network, everywhere except one office in Accra, Ghana that happened to be disconnected due to a power cut. That accidental survivor became the seed for the entire rebuild. Even then, recovering it was its own ordeal: the Ghanaian data centre’s bandwidth was too slow to transmit the backup, and the attempt to fly a staff member to London collapsed over visas, forcing a physical relay. Maersk reinstalled roughly 4,000 servers, 45,000 PCs and 2,500 applications in ten days, at a cost of $250–300 million — and it only worked because of luck, not planning.
Both stories point to the same lesson: a business can have plenty of backups and still have no real, timed way back if nobody ever rehearsed it.
The One Rehearsal Worth Doing Every Quarter
The only way to really know your restore time is to test it, honestly and on the clock. Set aside half a day every quarter, pick one important system, and actually restore it into a clean environment as if it were a real attack. Time everything, from the moment the decision is made to the moment people can genuinely use the system again, not just the moment it looks technically online.
These rehearsals almost always turn up the same surprises: a password stored on the very system being rebuilt, a license server nobody remembered, a network connection too slow to move the data in time, or a runbook that is quietly out of date. Maersk discovered its bandwidth problem in the middle of a global crisis. You can discover yours on a quiet Tuesday afternoon. Every one of those surprises found in a rehearsal is a crisis that did not happen for real.
Conclusion
Backup reports are comfortable because they only measure whether data exists somewhere. Restore time is uncomfortable because it can only be proven by testing it, and testing it usually reveals something broken. That discomfort is exactly why it matters. The next step is simple: stop asking whether backups exist, and start asking how long it actually takes to bring the business back, tested and timed, not estimated. That single number, brought honestly to the next leadership meeting, will tell you more about your real resilience than any coverage report ever could.
