News and updates from Maple

What July's Google Cloud outage and a grim ransomware statistic have in common image

What July's Google Cloud outage and a grim ransomware statistic have in common

Two unrelated stories landed within a few weeks of each other this summer, and together they say something worth paying attention to about where resilience risk actually sits right now.

The first: in July, a Google Cloud data centre in the Netherlands lost power and cooling for close to fifteen hours. Services across that European region went down with it. It wasn't an attack, it wasn't a cyber incident, it was a physical infrastructure failure of exactly the boring, unglamorous kind that's easy to assume "someone else has handled" simply because a hyperscaler is running the show.

The second: recent research into ransomware attacks found that the overwhelming majority now specifically target backup repositories as the first move, not the last one. Attackers have worked out that a business with a working backup can usually shrug off a ransom demand. So increasingly, disabling or corrupting the backup happens before the encryption does.

On the surface these are different categories of problem, one is physical infrastructure, the other is a deliberate attack. Underneath, they're the same lesson wearing two different outfits: the thing you're relying on to save you needs to actually be tested against the specific way it's most likely to fail, not just assumed to be fine because it exists.

"It's in the cloud" was never the whole answer

A lot of businesses treat moving to the cloud as the resilience plan itself, full stop. It isn't, it's one part of a resilience plan. Cloud infrastructure fails. Regions go down. Providers have bad days, same as anyone. The question that actually matters isn't "are we in the cloud", it's "what happens to us specifically when the cloud we're in has a bad day."

"We have backups" was never the whole answer either

Similarly, having backups isn't the same as having tested, protected, genuinely recoverable backups. If an attacker who's already inside your systems can also reach and disable your backup, the backup was never really separate from the risk it was meant to protect against.

The practical takeaway

Neither of these stories is a reason to panic, and neither is really new information dressed up as breaking news. They're both reminders that resilience only counts once it's been tested against the failure mode that's actually likely, a corrupted or reachable backup, a cloud region that goes dark for half a day, rather than the failure mode that's easiest to imagine.

If you haven't asked your provider how your specific setup would hold up against either of these scenarios this year, it's a reasonable moment to ask. Not because something's about to go wrong, but because the businesses in the strongest position afterwards are always the ones who asked beforehand.