Blog/Cybersecurity
Attackers go after your backups before they encrypt anything, and when they succeed the ransom gets paid and recovery costs multiply. Design the backup as a target, then prove it restores.
The ransom note is the end of the story, not the beginning. By the time it appears on a screen, the crew has usually been inside the network for days, and one of the things they spent that time doing was finding and ruining your backups. They understand the economics better than most boards do: a clean, fast restore is the single thing that lets a victim walk away without paying, so taking the backups off the table is how they make sure the ransom gets paid.
The data backs up what we see on engagements. In a Sophos study of nearly 3,000 organizations that had been hit by ransomware, surveyed in early 2024, 94% said the attackers tried to compromise their backups during the attack (Sophos). That number reframes the whole problem. Far from being a safety net sitting off to one side of the incident, the backup is one of the first things in the attacker’s path, so it has to be designed as a target.
In short
Ransomware frequency dipped and the cost of cleaning up rose. In Sophos’s broader State of Ransomware 2024 survey of 5,000 IT and cybersecurity leaders, 59% of organizations were hit in the prior year, down from 66% the year before, and 56% of those whose data was encrypted paid the ransom to get it back (Sophos). Fewer attacks, but the ones that land still push a majority of encrypted victims into paying.
The recovery cost is the number that should get a CFO’s attention, because it excludes the ransom entirely. The average cost to recover, not counting anything paid to the attacker, rose to $2.73 million, up from $1.82 million the year before (Sophos).
The finding that ties the backups to the money is the sharpest of all. In the Sophos study of nearly 3,000 victims, where the backups were successfully compromised, victims were almost twice as likely to pay the ransom, and their overall recovery cost was eight times higher than for organizations whose backups came through intact (Sophos). The backup, in other words, sits close to the center of the incident rather than off to its side.
For a board, the practical reading of that eight-times figure is that backup design is a financial control as much as a technical one. The money separating a victim whose backups held from one whose did not is large enough to dwarf the cost of doing the backup properly in the first place, and it lands as unplanned recovery spend on top of the revenue lost while the business was down. The case for investing ahead of time tends to make itself once those numbers sit on the same slide.
The reason backups get compromised is usually boring: they live inside the same trust boundary as everything else. The backup server is on the production domain, reachable with the same credentials, and once the attacker has domain admin they can reach the backup console and delete or encrypt the copies right alongside the live data. An offline or immutable copy breaks that, because a credential, however powerful, cannot delete something it has no path to.
Note
3-2-1-1-0 is a widely used industry rule of thumb, not a formal standard: three copies of the data, on two different media, one of them off-site, one immutable or offline, and zero errors on a verified restore test. CISA’s #StopRansomware Guide makes the core of this concrete, recommending that organizations maintain offline, encrypted backups of critical data and regularly test their availability and integrity.
Immutable means the copy cannot be altered or deleted for a defined retention window, enforced by the storage itself rather than by a policy someone can change. Object storage with an object-lock mode, or a purpose-built appliance that holds immutable restore points, gives you that. Offline, or air-gapped, means a copy with no live network path to production at all, which at the low-tech end can still mean tape rotated to a vault. You want at least one of these, and for anything a regulated financial institution would call critical, ideally both, so that a single clever move against one does not take out the other.
The test of an immutability claim is adversarial, and it is exactly what we probe on engagements: can the account that runs production, or the most privileged account in the environment, delete or shorten the retention on a restore point? If the answer is yes, the copy is not immutable in any way that survives a real ransomware actor who will have that account. CISA’s #StopRansomware Guide puts the same idea plainly: the backups have to be out of reach, and you have to test that they are.
Encrypt the backups as well, which the same CISA guidance calls for, and then think carefully about where the keys live. A backup encrypted with a key sitting in the directory the attacker just took over protects you against a lost tape and against nothing else. Keep the backup encryption keys in a separate system with their own access controls, so that compromising production does not hand over both the data and the means to read every copy of it.
The most common single reason backups get wiped is that the same identity that administers the domain also administers the backups. Compromise one account and you own both. Breaking that link is cheap and it changes the outcome of the incident.
Run the backup system on its own identity, with its own credentials, in its own authentication boundary wherever the product allows it, so that domain admin on the production environment is not backup admin. Use separate, strong, multi-factor-protected accounts for the backup console, do not join the backup server to the same directory it is protecting if you can avoid it, and keep break-glass credentials for recovery stored offline. The goal is that the account the attacker worked so hard to steal simply does not open the door to the backups, because it was never a key to that door.
This is also where least privilege earns its keep in a way people can see. The backup service account needs rights to read data and write restore points, and nothing like the rights to delete the entire repository. Scope it down, and a compromise of that account becomes an inconvenience rather than the end of your recovery option.
Immutability and a separate identity make the backups hard to destroy. Monitoring tells you when someone is trying, which is often the clearest early warning you will get that an attacker is in the environment and preparing to detonate.
Treat these as security events, not as backup-admin housekeeping: mass deletion of restore points, a sudden shortening of a retention policy, immutability being disabled or a lock window reduced, a spike in failed logins against the backup console, backup jobs being disabled wholesale. Route them to the same place your security team watches everything else, and alert on them loudly. An attacker attempting to shorten your retention from thirty days to one is doing reconnaissance on your recovery capability, and catching that attempt is a chance to respond before the encryption starts rather than after.
Here is the uncomfortable part, and the reason most of this article exists. A backup job that reports success tells you a file was copied. It tells you nothing about whether you can rebuild a working business from it under pressure, and the gap between those two things is where organizations with “good backups” still end up paying.
The fix is to restore on a schedule and measure what it actually costs you. Recovery time objective, RTO, is the wall-clock time from the decision to recover to a validated, working system. Recovery point objective, RPO, is how much data you lose, the distance between your last good restore point and the moment of the incident. Both are promises until a drill turns them into measurements, and the first real drill often reveals that the true RTO is several times the number in the plan, because nobody counted the hours spent finding credentials, standing up clean infrastructure and discovering that one critical system had never been in the backup scope at all.
The drill also shows you what you forgot to back up. A working system is more than its database: it needs its configuration, its secrets and certificates, the infrastructure-as-code that defines it, and often the runbook that tells a tired engineer how to bring it up. Teams discover during the first honest drill that one of those was never in scope, so the restored database has nothing to run on. Put the whole system in scope, then prove it by rebuilding from backups alone with the production environment treated as gone.
Run this quarterly for critical systems, rotate which systems you exercise so you are not drilling the same easy one every time, and make the measured RTO and RPO visible to the people who set the targets, so the plan and the measurement stop drifting apart.
When the real event comes, the order you rebuild in decides whether the recovery is hours or days, and the instinct to restore the most visible business system first is usually wrong. Nothing authenticates without identity, so identity comes first.
Two conditions sit under that sequence. Restore into a clean environment, not the one that was encrypted, because restoring good data onto a network the attacker still holds hands them the restored copy as well. And know your dependency order in advance, because working it out live, under the pressure of a business that is down and a board that wants a time, is how teams restore things in the wrong order and have to start over.
Restoring into a clean environment means more than a fresh network. Rebuild hosts from known-good images rather than from the encrypted machines, so you do not carry the attacker’s foothold back in alongside the data, and restore data in a form that lets you scan it before it rejoins production. The point of the whole exercise is to come back onto ground the attacker no longer holds, and a clean room that stays wired to the compromised domain is not clean.
For regulated organizations in Saudi Arabia, the resilience work has to be demonstrable, not merely done. NCA’s ECC-2:2024 includes a cybersecurity resilience domain, and a reviewer will want to see that your recovery capability is real and tested rather than described in a policy. The good news is that a proper restore drill produces exactly the evidence that satisfies this, as a by-product.
Keep the dated drill records: what was restored, the measured RTO and RPO, what failed and what you fixed. Keep proof that immutable copies exist and that privileged production accounts cannot delete them. Keep the monitoring alerts you configured for retention and deletion changes. That file answers the resilience questions directly, and it is far more convincing than a diagram, because it shows the organization actually recovering on a Tuesday in a quarter nobody was being assessed. Work from the official NCA text for exactly what your organization must demonstrate, rather than a summary, and map your drill evidence to it.
The place to start is the measurement, not the architecture. Pick your most critical system, restore it into an isolated environment this month, and time it honestly from decision to validated service. Whatever number you get is your real RTO today, and it is almost certainly the most useful thing you will learn about your ransomware readiness all year.
Cybersecurity
A chatbot or RAG copilot inside a banking app is a new attack surface running on old failure modes. The OWASP LLM Top 10 names them; here is how we design and test around the ones with no clean fix.
ReadCybersecurity
Broken object level authorization is the finding we raise most often on API engagements, and one of the few you can design out for good rather than patch endpoint by endpoint.
ReadCybersecurity
A banking app runs on a device the customer, and sometimes an attacker, fully controls. MASVS v2 gives you eight control groups to check; here is what each means for a Saudi wallet or banking app.
ReadEhsanLab
Tell us what you are building and what worries you about it. A specialist replies within one business day.