Revolgy blog

Cloud security in 2026: From shared responsibility to shared fate

Written by Jana Brnakova | December 2, 2025

If you are still using a security strategy from 2023, you have a problem. The old idea that the cloud provider handles the hard stuff is no longer true.

The last two years taught us a hard lesson: major crashes don’t usually happen because of super-advanced hackers. They happen because of small mistakes in settings that nobody noticed.

In this article, we look at why the old shared responsibility model is failing, how much a mistake really costs, and why smart teams are moving to a shared fate approach.

The real cost of a breach

Making a security mistake has always been expensive. But today, the cost depends heavily on where your company is.

  • Global average: The average cost of a data breach is around $4.44 million.
  • US: If you operate in the US, that cost jumps to over $10 million per incident.

Why the difference? It is mostly due to legal fees, fines, and the cost of notifying customers in countries with strict laws.

Plus, where you store your data matters. Breaches in public clouds can be more expensive — averaging $5.17 million — simply because investigating complex, distributed environments is hard.

On average, it takes almost eight months (241 days) to just find a breach and stop it. That means attackers could be inside your system for most of a year before you notice.

But this doesn’t mean the cloud is unsafe; it means the cloud requires specialized skills to manage effectively.

3 lessons that changed how we think

To understand the risks in 2026, we need to look at three major events from the last few years.

1. UniSuper, or why you need a backup plan

In May 2024, the unthinkable happened to UniSuper, a huge Australian pension fund worth $125 billion. Because of one blank setting in an internal tool, the automated system deleted UniSuper’s entire private cloud subscription.

For two weeks, 620,000 members could not access their accounts. The only reason UniSuper survived was that they had backups with a secondary provider. This proved that no cloud provider is too big to fail. You need a backup plan that works without them.

The takeaway here isn’t that cloud is unreliable; it’s that redundancy is non-negotiable. True resilience means being prepared for any scenario, no matter how unlikely.

2. Toyota’s risk of “drift”

Toyota had a different problem. A simple cloud setting was marked “public” instead of “private”.

Because of this small error, data on 2.15 million customers was publicly accessible for ten years (2013–2023). This happened because no automated tool was checking for these changes. It proved that manual checks are not enough to catch mistakes over time.

It wasn’t a sophisticated cyber-attack. It was just a simple setting left on “public” that nobody noticed. This happens often: when teams change, and you add new features, small details get missed. If you aren’t scanning for these errors automatically, they can stay hidden for years.

3. Snowflake and the “default” security

In mid-2024, attackers accessed accounts at over 165 major organizations using valid credentials without Multi-Factor Authentication (MFA). They simply logged in with valid usernames and passwords. The victims had not turned on MFA because, at the time, it was rather optional.

This one proves that if a security feature is critical, it must be on by default.

 

Are you worried about your own setup? After reading this, you might be asking yourself: “Are we sure MFA is on for everyone?” or “Do we have an old admin account that nobody uses anymore?”

You don’t have to check this manually. We can run a Security Health Check on your environment, including your Google Workspace settings, to find these gaps before they become a problem. It is a quick, practical way to see exactly where you stand.

 

 

 

Why shared responsibility often fails

For a long time, we used the shared responsibility model. The idea is that the cloud provider (like Amazon or Google) secures the hardware, and you secure the data inside it.

But the Toyota and Snowflake stories show why this model is broken. It assumes your team knows exactly how to configure these complex systems perfectly, every time.

In reality, most teams are overwhelmed. Statistics show that about 99% of cloud security failures are the customer’s fault. Cloud platforms have endless settings, and teams often take shortcuts just to get things working.

This suggests we need to close the competence gap.

Could shared fate be the solution?

Forward-thinking leaders and providers are now moving to a shared fate model, changing the relationship from “that is your problem” to “we are in this together”.

In this model, cloud providers and partners (like Revolgy) don’t just give you the tools and that’s it. They (we) help you build the solution — provide active help, secure blueprints, and expert guidance (even 24/7).

Bringing in external expertise and resources can really reduce the burden on your internal teams and the likelihood of an error.

New laws and regulations

Mandatory survival through DORA 

The Digital Operational Resilience Act (DORA) has been fully active since January 2025. It requires financial entities to withstand, respond to, and recover from all types of ICT-related disruptions and threats.

  • It’s not just Europe; and even as a US cloud provider, if you serve financial clients in Europe, this law affects you.
  • Major clouds like AWS and Google Cloud are now considered Critical Third-Party Providers (CTPPs), and regulators can check them directly.
  • You cannot just sign a contract and hope for the best. You legally need a plan for what to do if your cloud provider fails.

Check out the DORA Compliance Checklist [Cloud edition] from our partner WIZ

Managing the supply chain with ISO 27001:2022 

While DORA is huge for finance, ISO 27001 remains the gold standard for everyone else. By 2026, the transition period ends, and the 2022 version becomes mandatory.

This new standard adds 11 new controls designed specifically for a modern, cloud-connected world. Three of them directly address the problems we just described above:

  • Control 5.23 (Cloud Services): In the past, cloud providers were just treated like any other supplier. Now, you need a specific process for buying, using, and even exiting cloud services. It’s supposed to stop shadow IT, where teams sign up for random software without security checks
  • Control 8.9 (Configuration Management): This relates to the Toyota issue, as you simply can’t set your security settings once and then forget them. It requires you to monitor your settings constantly to spot drift (when things change accidentally over time).
  • Control 5.7 (Threat Intelligence): Moving security from being reactive to proactive. You are required to actively collect and analyze information about attackers, which means you have to be looking for threats before they become real problems.

What’s next?

The thing is, you are only as secure as your weakest configuration. The solution here isn’t to leave the cloud, but to partner with experts who can help you find your way through the cloud maze.

What we’re saying is that you should go for a collaborative approach that guarantees resilience, whatever the size or industry of your company.

So, now that we have the strategy, how do we build the architecture?

Now that we have covered the strategy and the regulations, the next step is building the system to support it.

If you are ready to get into the technical details — specifically, why Identity is now more important than your firewall, and how to manage the confusing differences between AWS and Google Cloud — we have a dedicated guide on that topic.

Read next: Cloud security architecture & identity

And remember, you don’t have to figure this out by yourself. Whether you need to validate your DORA compliance or you want to move toward a shared fate model, Revolgy is ready to partner with you. Contact us for a free consultation.