According to the report O Estado do Ransomware no Brasil 2026, from Sophos, released in July 2026 with 71 Brazilian companies hit by a data-hijacking attack, 58% of them were back up and running within one week. Another 18% took between one and six months. A backup existed in both groups — 85% used it to bring the scrambled files back. What separated the fast ones from the ones stuck for months was not having a backup. It was how long it took to bring that backup back.
This is not only about attacks. A dead disk, a server that will not boot, someone deleting the wrong folder — any of these put a company in the same line: find the copy, bring the data volume back, reinstall whatever is needed, check that everything is right before handing it back to the team. The incident changes; the time bill is the same.
For whoever decides, that bill usually shows up at the worst moment. The company knows it has a backup and assumes "coming back" is a matter of minutes — like opening a file. Nobody timed how long it really takes until someone has to measure it under pressure, with operations stopped and losses growing by the hour.
How long it really takes
In Sophos's global report, the average time for a company to fully recover from a data-hijacking attack was three weeks — the same level as the previous year, but down from five weeks in 2024. Looking at the distribution: 55% of companies were back within one week (16% in less than a day), 83% within one month, and only 3% took longer than three months.
That three-week average hides a wide range, and it is not luck: it depends on the volume of data that has to come back and the speed it can travel at. Bringing a few gigabytes back over an ordinary connection takes minutes. Bringing a few terabytes back over that same connection — the one the company uses every day for e-mail and browsing, not a dedicated line built to move large volumes — can take hours just for the download, before any system is even running again.
Where the copy is stored also enters that math. A copy kept inside the building tends to come back faster, because it does not depend on the internet link. A copy in the cloud is safer against a fire or a theft on site, but bringing a large volume of it back depends entirely on that connection's download speed — and most business links were contracted for everyday use, not for pulling terabytes at once.
Once the data arrives, the clock does not stop. There is still the operating system to reinstall when the hardware also had to be replaced, each piece of software to reconnect to the systems it integrates with, licenses to reactivate, and every piece of information to check before handing it back to the team. Which systems come back first is a separate decision — an important one, but a subject for another day; what matters here is that each of these steps eats real time, measured in hours, not minutes.
The average cost for a Brazilian company to recover from a data-hijacking attack, not counting any ransom paid, was US$ 1.05 million in 2026, according to the same Sophos survey — downtime, staff time, equipment, network and lost business added up. The longer the restore takes, the bigger that bill grows.
Why the usual approach falls short
The usual approach is to set up the backup, see it run every night without errors, and stop there. The copy exists, it is intact, last night's report shows success — and the company concludes, without ever having tested it, that "restoring" is a matter of pressing a button.
Except nobody timed how long it takes to bring a real data volume back over the real connection the company has. The number leadership imagines — "a few hours", "a day at most" — was never measured; it was guessed out of optimism. Finding out the real timeline is days, not hours, in the middle of a stopped operation is the worst possible moment for that surprise.
Another version of the same problem is storing the copy wherever is cheapest, without ever asking how long it would take to bring it back from there. Storage and restore speed are different things: a place can be great for keeping data and terrible for handing a large volume of it back quickly.
What has to be in place
An environment ready for that moment treats restore time as a measured number, not an assumption.
A timed restore drill, not just a copy that "runs without errors". It is the only way to know how many hours — or days — the company's real data volume takes to come back over its real connection.
A written plan stating how long it takes the company to be back up and running. Not a verbal hope repeated in a meeting, a number that survived a test.
Connection and capacity sized for today's volume, not for the volume from when the backup was set up — the company grows, its data volume grows with it, and the link is often left behind.
More than one place holding the copy, with at least one off the company's physical site, balancing protection against fire or theft with the speed of bringing the data back when needed.
A named owner and a written playbook for the restore, instead of depending on someone who "knows how" from memory and might be on vacation the day something breaks.
This is how Skills IT works: with periodic recovery drills and a plan that puts in writing how long a restore really takes.
The gain for the business
The gain from measuring that timeline beforehand is not that disaster never happens — it is that the company stops improvising during it. Once the restore time is a known number, decision-makers can tell whether that timeline is acceptable for the business or whether it is worth investing in a better link, a local copy in addition to the cloud one, or a contingency plan to keep operating another way while the data comes back.
Organizations that maintained robust backup systems recovered encrypted data at near-record rates over the past year.
Without that measured number, every decision during the outage is made in the dark: promising a client a deadline nobody verified, deciding on the spot whether to wait or switch to another setup, guessing how much each hour of downtime costs. With the number in hand, the same decision takes minutes, and the team is free to work instead of trying to guess how much longer it will take.
It is also about money: the sooner a company knows the real timeline, the sooner it can weigh that cost against investing in a faster link or a second, more accessible copy — a calculation that is cheaper made outside the pressure of an incident than in the middle of one.
Questions to bring to the next meeting
- Has anyone timed a full restore, using the data volume the company has today? If the answer is "we never tested it", the timeline everyone imagines is a guess.
- Can the connection used to restore handle that volume, or is it the same one that serves everyday e-mail and browsing? Sending an attachment is one thing; bringing terabytes back is another.
- Is there more than one copy, in different places, or does everything depend on a single point? A fire or a theft on site cannot be the end of the only copy that existed.
- Is the restore timeline written down somewhere, or only in the head of whoever runs IT today? If that person leaves on vacation or changes jobs, the number cannot leave with them.
- If the worst outage happened tomorrow, does the company know in how many days — not how many hours of optimism — it would be back? That is the question worth answering before, not during.
