What Happens to Your Data If Your Cloud Provider Goes Down?

On 30 October 2025, Microsoft's Azure platform went down. Air New Zealand's payment processing stopped working. Boarding systems had to be managed manually. Customers were stuck in queues while ground staff worked through a situation their technology was supposed to have eliminated.

It wasn't an isolated event. Just ten days earlier, AWS's US-East-1 region experienced a cascading failure that took down Netflix, Atlassian, Slack, Coinbase, and Expedia simultaneously. Engineering teams worldwide watched their monitoring dashboards light up red and found their runbook procedures were useless - the AWS management consoles they needed to diagnose and fix the problem were also offline.

Two of the world's three largest cloud providers, down within ten days of each other. Both incidents caused by configuration errors, not dramatic attacks.

If your business runs on cloud services and most New Zealand businesses do - these events should prompt a question you probably haven't asked yourself directly: if your cloud provider went down tomorrow, what would actually happen to your data, your operations, and your ability to serve clients?

The answer most businesses discover when they ask this question honestly is not as expected.

The Assumption That Gets Businesses Into Trouble

Most business owners operate with an assumption about cloud services: that moving to the cloud means someone else is taking care of it. Microsoft is looking after the emails. Google is looking after the files. The provider is handling the backups, the security, the availability - that's the whole point of paying for the service.

It's a reasonable assumption. It's also largely wrong, and the gap between what cloud providers actually take responsibility for and what most customers assume they're covered for is where the damage happens.

Every major cloud provider - Microsoft, AWS, Google - operates under what the industry calls a shared responsibility model. The concept is simple: the provider is responsible for the security and availability of the infrastructure, and the customer is responsible for the data, the configurations, and the access controls that sit on top of it.

In practice, this means:

Microsoft keeps Azure running. You're responsible for what happens to your data inside Azure.

Google keeps Workspace available. You're responsible for whether your files can be recovered if they're deleted or corrupted.

AWS keeps the infrastructure online. You're responsible for whether your applications and data can survive a regional failure.

This isn't buried in fine print. It's stated explicitly in every provider's documentation. But it runs completely counter to how most businesses experience cloud services day-to-day - because most of the time, everything just works, and the question of who's responsible for what never comes up.

Until it does.

What Happens When a Cloud Provider Goes Down

The October and November 2025 outages are good case studies because they were real events affecting real businesses, including New Zealand ones.

When Microsoft's Azure went down in October, businesses that had built their operations around Microsoft 365 and Azure services lost access to email, file storage, collaboration tools, and in Air NZ's case, payment processing and boarding systems. The outage lasted hours. For businesses without any fallback capability, those hours were simply unproductive - staff sitting at desks, unable to work, waiting for a multinational corporation to fix a problem on the other side of the world.

The AWS failure the week before was technically more significant. The failure originated in a DNS misconfiguration that cascaded through core services - when DynamoDB's DNS record was deleted, it broke service discovery, internal routing, health monitoring, and failover systems simultaneously. Businesses that had implemented what they believed were resilient multi-availability-zone architectures found those architectures offered no protection because the failure was at the control plane level, not the application level. Even well-designed redundancy failed.

Here's the number that puts this in context for NZ businesses specifically: Chorus research published in May 2025 found that the average New Zealand business can now operate for just 6.9 hours without internet access - down from 9.6 hours in 2022. That number has been falling because businesses have digitalised faster than they've built resilience. Cloud accounting. Cloud CRM. Cloud communications. Cloud file storage. Every one of those systems goes dark in an outage.

For a business doing $1 million in annual revenue with 20 staff, a single day of unplanned downtime costs between $6,500 and $13,000 - split across lost revenue, lost productivity, and emergency IT support. That's the cost of a day. Extended outages cost proportionally more, and the reputational damage - clients who couldn't be served, deadlines missed, communications that went dark - doesn't show up cleanly in a dollar figure.

The Three Scenarios You Need to Plan For

"Cloud provider goes down" covers a range of situations with meaningfully different implications. Understanding which scenario you're dealing with changes what your response options are.

Scenario 1: Temporary outage - provider comes back online

This is what happened with Azure in October and AWS in November. The service went down, it was embarrassing and disruptive, and it came back within hours. Your data wasn't lost - it was just inaccessible for a period.

For businesses without a continuity plan, this scenario results in unproductive hours and frustrated clients. For businesses with a continuity plan - defined procedures for operating at reduced capacity, offline backups of critical information, communication protocols for clients - it's a manageable inconvenience.

The question isn't whether major cloud providers will experience outages. They will - SLAs promise 99.9% uptime, not 100%, and even 99.9% allows for 8.76 hours of downtime per year. The question is whether your business has a plan for those hours.

Scenario 2: Data loss from accidental deletion or corruption

This scenario catches more businesses off guard than outages do, because it doesn't require the provider to go down at all.

Here's something most Microsoft 365 users don't know: Microsoft's default retention settings for deleted emails, files, and Teams messages are limited. Deleted items in SharePoint and OneDrive have a recycle bin - but items cleared from the recycle bin may only be recoverable for 93 days after deletion. After that, they're gone. Permanently.

The same applies to accidentally overwritten files, corrupted data, and content deleted by a departing staff member who had broader access than they should have. If you're relying on Microsoft to back up your data, you're working with the platform's built-in retention features - which were designed for the provider's operational convenience, not your recovery needs.

SaaS providers in general do not concern themselves with fully protecting your files. They maintain the uptime of the service and the security of the infrastructure. The data inside that service - and whether it can be recovered in the timeframe and format you need - is your responsibility.

This is the scenario that most often results in actual permanent data loss. Not dramatic outages. Quiet deletions that nobody notices until someone needs the file that isn't there anymore.

Scenario 3: Provider insolvency or service discontinuation

Less common but worth planning for: what happens if your cloud provider discontinues the service you depend on, is acquired, or - in the case of smaller or regional providers - ceases to operate?

Your data is held in their systems. The practical question is whether you can get it out, in a format you can actually use, on a timeline that doesn't destroy your business.

Vendor lock-in is a real risk in cloud services. Some providers use proprietary data formats or make export unnecessarily complicated. Some charge significant fees for data egress. Some simply don't have a clean exit process.

This is why asking the question "how would we leave this provider if we needed to?" before you commit is important - and why understanding what format your data is stored in matters more than most businesses realise until the moment they need to switch.

The Shared Responsibility Model

The concept of shared responsibility sounds bureaucratic. The practical reality of it is simpler and more important than the name suggests.

Think of it this way. When you rent office space, the landlord is responsible for the building structure, the electricity supply, and the common areas. You're responsible for what's inside your office - the furniture, the equipment, the documents in the filing cabinet. If the building loses power, the landlord is responsible for fixing it. Whether your documents survive a flood is your responsibility - that's what contents insurance is for.

Cloud services work the same way. The provider maintains the building (the infrastructure). What happens to your contents (your data) when something goes wrong is your responsibility.

Specifically, you remain responsible for:

Your data. What's in the cloud is yours. Protecting it, backing it up independently, and being able to recover it on your timeline - not the provider's - is your job.

Your configurations. How your cloud environment is set up - who has access to what, whether security settings are correctly configured, whether data retention policies match your actual needs - is on you. Gartner estimated that through 2025, 99% of cloud security failures would be the customer's fault, almost all of them traceable to misconfiguration.

Your access controls. Multi-factor authentication, user permissions, admin access - these are yours to manage. If a staff member's credentials are compromised and data is exfiltrated, the provider's SLA doesn't cover the consequences.

Your recovery capability. How quickly you can restore operations after an outage or data loss event depends on decisions you make before the event, not after it.

The provider's SLA promises availability of the platform. It doesn't promise that your data will be intact and recoverable in the way you need, on the timeline you need, when something goes wrong.

What "Good" Cloud Resilience Looks Like

Understanding the problem is useful. Knowing what to do about it is more useful.

Independent backups of SaaS data

If your business relies on Microsoft 365, Google Workspace, Salesforce, or any other SaaS platform, you need backups that are independent of the platform itself.

Not Microsoft's built-in retention policies. Not Google's recycle bin. An independent, regularly tested backup that holds a copy of your data outside the provider's environment - so that if the provider's systems are compromised, your data recovery doesn't depend on the provider's recovery.

This is a gap that surprises a lot of businesses when they first encounter it. The assumption is that because it's Microsoft, the data is safe. The reality is that Microsoft backs up its infrastructure to ensure the service stays available. What happens to your specific data if it's accidentally deleted, corrupted, or exfiltrated is a separate question and the answer depends on what backup arrangements you've made independently.

For cloud storage and backup that's genuinely independent of your primary provider, this is the baseline every business should have in place.

Tested recovery procedures with defined RTOs and RPOs

A Recovery Time Objective (RTO) is how long it takes your business to get back to operational after an incident. A Recovery Point Objective (RPO) is how much data you could lose in a worst-case scenario - measured in time.

Most businesses haven't defined either. They have a vague sense that backups exist and that things could be restored "fairly quickly." That vagueness is expensive when it gets tested by a real event.

Defining your RTO and RPO forces the right conversation: how long can your business actually afford to be down? How much data can you afford to lose? Once you've answered those questions honestly, you can assess whether your current backup and recovery arrangements would actually meet those requirements and build toward it if they don't.

The test is the thing. Backup and disaster recovery that's never been tested is an assumption, not a capability. Recovery procedures that have been run, timed, and verified are the real thing.

Understanding your SLAs - actually reading them

Most businesses sign up for cloud services without reading the SLA. This is understandable. SLAs are long, technical, and not designed to be engaging reading material.

But the SLA is the document that defines exactly what the provider is promising you and what happens when they fail to deliver it. Key things to understand:

What counts as downtime for SLA purposes? Some providers only count complete unavailability - degraded performance doesn't trigger the SLA. Some require a minimum outage duration before they consider it a breach.

What compensation is available for SLA breaches? Most providers offer service credits - a proportion of your monthly fee back. That's rarely proportionate to the actual cost of an outage to your business.

What is explicitly excluded? Read the exclusions carefully. Scheduled maintenance is typically excluded. Events described as "force majeure" are typically excluded. Some providers' SLAs are structured in ways that make it difficult to ever successfully claim a breach.

Understanding what you're actually covered for - and where the gaps are - is the starting point for building genuine resilience.

A business continuity plan for cloud outages

When Azure went down in October 2025, businesses with continuity plans knew what to do. They had defined procedures for what happens when cloud services are unavailable - which staff could still work and how, how to communicate with clients, which processes could continue manually and which couldn't, and when to invoke the plan and who had authority to do so.

Businesses without continuity plans did the same thing most of us do when something unexpected happens: they waited, they refreshed status pages, and they hoped it would come back soon.

A continuity plan for cloud outages doesn't need to be elaborate. It needs to answer: what do we do for the first hour, the first four hours, and the first day if our primary cloud services are unavailable? Who communicates what to clients? What work can continue and what stops?

The businesses that fared best in October and November 2025 were the ones that had already asked those questions.

Multi-region or multi-provider considerations

For businesses where cloud availability is genuinely mission-critical - where even a few hours of downtime has severe financial or reputational consequences - single-provider dependency is a risk worth addressing architecturally.

This doesn't necessarily mean running everything across multiple cloud providers simultaneously, which adds significant complexity. It means designing with portability in mind: using open standards where possible, understanding your provider-specific dependencies, and having a clear picture of what a migration to an alternative provider would require if it became necessary.

For most NZ SMEs, the more practical question is geographic redundancy within a single provider - ensuring that if one region experiences an outage, your services can fail over to another. The October AWS failure showed that even this isn't a complete answer to catastrophic control-plane failures, but it addresses the more common scenario of regional disruptions.

What the NZ Context Adds

New Zealand businesses have some specific considerations that global cloud resilience guidance doesn't always account for.

Geographic distance from major data centres - Most major cloud providers have their nearest data centres in Australia. Latency to Australian regions is manageable, but it's worth understanding that "Asia Pacific" routing for your data may mean Sydney or Singapore, not Auckland. For data sovereignty purposes under the Privacy Act 2020, understanding where your data physically resides matters.

Connectivity dependency - The 6.9 hours figure from Chorus research reflects something specific about NZ businesses: the extent to which operations have moved online without equivalent investment in resilience. A Chorus fibre outage and an Azure outage have very similar operational consequences for a business that's moved everything to cloud - in both cases, the systems stop working. Most businesses have only one internet connection. When that connection goes, so does everything cloud-based.

Privacy Act 2020 obligations - If a cloud provider incident results in personal information about your clients or staff being accessed, exfiltrated, or lost, you have notification obligations under New Zealand law regardless of whether the incident originated with you or with the provider. Understanding your data's location, the provider's incident notification practices, and your own response obligations before an incident makes meeting those obligations far more manageable.

Frequently Asked Questions About Cloud Outages and Data Protection

If Microsoft or Google goes down, is my data at risk?

Temporary outages typically don't put data at risk - the data is still there, it's just inaccessible while the service is down. What creates genuine data risk is accidental deletion, accidental overwriting, account compromise, or ransomware that encrypts your cloud files. These scenarios aren't dependent on the provider having an outage - they can happen at any time. Independent backups are the protection against data loss; continuity planning is the protection against outage impact.

Doesn't Microsoft 365 back up my data automatically?

Microsoft maintains backups of their infrastructure to ensure the service remains available. For your specific data, Microsoft provides retention and recovery features — but these have time limits and are designed for the platform's operational needs, not necessarily yours. Items deleted from SharePoint or OneDrive can be recovered from the recycle bin for a limited period; after that window closes, recovery may not be possible. Independent third-party backup of your Microsoft 365 data is the standard recommendation for businesses that can't afford to lose email history, file archives, or Teams conversations.

What does an SLA actually guarantee?

An SLA typically guarantees a percentage of uptime - 99.9% is common, which translates to roughly 8.76 hours of downtime per year. It defines what counts as an outage, how the provider measures compliance, and what compensation is available if they fall short (usually service credits). SLAs do not guarantee data integrity, data recovery timeframes, or protection against customer-caused issues like accidental deletion or misconfiguration. Read your SLA specifically to understand what the provider is and isn't promising.

What's the difference between cloud backup and cloud storage?

Cloud storage (OneDrive, SharePoint, Google Drive, Dropbox) is where your files live. Cloud backup is an independent copy of those files held somewhere separate - so that if your cloud storage is compromised, corrupted, or accidentally deleted, you can restore from a clean copy. Most businesses use cloud storage. Far fewer have genuine cloud backup that's independent of their primary provider. These are different things serving different purposes, and you need both.

We're a small business - do we really need all this?

The question isn't whether you're large enough to need resilience. It's whether you can afford the consequences of not having it. For a small business, a significant data loss event or a week of operational disruption is proportionally more damaging than it would be for a large enterprise with more resources to absorb the hit. The investment in basic resilience - independent backups, tested recovery procedures, a simple continuity plan - is modest compared to the cost of needing it and not having it.

How do I know if our current cloud backup is actually adequate?

Ask these questions: When was the backup last tested with a successful restoration? Is the backup stored independently of our primary cloud provider? Do we know how long recovery would take if we needed it? Can we recover individual files, or only complete system restores? If you can't answer all of those confidently, a conversation with your IT provider or managed services partner is the right next step. If you're not sure whether you need an MSP to handle this, our post on whether you need a managed service provider is a practical place to start.

What questions should I ask my cloud provider?

Our post on 10 critical questions to ask your cloud provider covers this in detail - including specific questions about backup, recovery, data sovereignty, and SLA terms that most businesses never think to ask until after something goes wrong.

Is Your Business Protected?

Most businesses find out they weren't when it's too late.

A free consultation with NSP takes 30 minutes. We'll look at your current cloud setup honestly - where your data lives, what your recovery options are, and what it would take to get to a position where a cloud outage or data loss event is a manageable inconvenience rather than a business crisis.

Book your free consultation →

Or call us directly: 0508 010 101

Related Reading

• 10 Critical Questions to Ask Your Cloud Provider
• How Secure Cloud Migration Reduces Your Risk of Platform-Based Attacks
• Do You Need an MSP?
• Cloud Storage & Backup — NSP
• Data Backup — NSP
• Cloud Migration — NSP