The October 2025 AWS US-East-1 outage knocked Venmo, Zoom, Reddit, and Snapchat offline for hours. That’s the version that made headlines — the visible part. What rarely gets reported is the quieter, more insidious problem: what happened to sensitive data during those hours? When a cloud provider goes down, it’s not just an inconvenience. Under regulations like GDPR, an outage that renders personal data inaccessible can be viewed as a security failure, not just a technical one. For anyone working remotely — where every file, every client record, every piece of communication lives in someone else’s data center — that distinction matters.
Cloud resilience
Shared responsibility
Data privacy compliance
Backup strategy
Most of what’s documented here about outage patterns and privacy failure modes comes from StealthCloud’s structured outage tracker and NSP’s analysis of the shared responsibility model — two sources that dig into the gap between what providers promise and what actually breaks.
The Privacy Failure Modes That Don’t Make the News
When a cloud provider fails, the immediate assumption is that data sits there safely, just out of reach. Often that’s true — temporary outages don’t corrupt files. But the recovery phase is where things get messy. StealthCloud’s research catalogues seven distinct privacy-relevant failure modes that have appeared during major outages between 2020 and 2026. Among them: debug logging activated during incident response that captures request payloads and customer data; failover traffic rerouting that sends geographically constrained data through regions outside its intended jurisdiction; and recovery procedures requiring engineers to take elevated access to customer workloads — documented in the Atlassian 2022 outage and an Azure 2023 storage failure.
Each of those failure modes represents a temporary but real degradation of privacy guarantees. For data subject to GDPR, even temporary geographic misrouting or unauthorized access can constitute a reportable breach. The industry-standard SLA/uptime framing obscures this entirely — an outage that violates data residency requirements won’t show up in a provider’s uptime percentage, but it will show up in a regulator’s inquiry.
During normal operation, providers enforce access controls, encryption boundaries, and geographic constraints reliably. During recovery, those constraints are routinely relaxed — engineers need elevated access, automated systems fail open to restore availability, and debug logging captures data that production logging never does. The recovery phase is when most sensitive data exposure occurs, and it’s the least documented phase of any outage.
The Shared Responsibility Model — And the Gap That Gets You
Every major cloud provider operates under a shared responsibility model. The provider is responsible for infrastructure security and availability. The customer — that’s you — is responsible for the data, configurations, access controls, and what happens to files inside the platform. This is stated explicitly in every provider’s documentation, but most businesses assume the provider handles backups and security. That assumption is largely wrong.
NSP’s analysis uses a useful analogy: the landlord is responsible for the building structure, electricity, and common areas. The tenant is responsible for the office contents — furniture, equipment, documents. The cloud provider maintains the infrastructure; what happens to your data when something goes wrong is your responsibility. Gartner estimated that through 2025, 99% of cloud security failures would be the customer’s fault, almost all traceable to misconfiguration.
If you’ve ever felt a knot of anxiety during a service outage — refreshing status pages, hoping your files come back — that’s the gap between what you assumed was being handled and what was actually left to you. The feeling isn’t irrational. It’s the emotional signal of a structural vulnerability.
Most businesses sign up without reading the SLA. The SLA defines exactly what the provider promises and what happens when they fail — usually service credits that are a fraction of your monthly fee, rarely proportionate to the actual cost of downtime. For a remote team with $1M annual revenue and 20 staff, a single day of unplanned downtime can cost $6,500–$13,000 across lost revenue, lost productivity, and emergency IT support. That’s from NSP’s analysis, and it doesn’t include reputational damage.
Independent Backups: The Only Safety Net That Works
Here’s the scenario that catches more businesses off guard than outages: data loss from accidental deletion, corruption, or a departing employee with excessive access. This doesn’t require the provider to go down at all. Microsoft 365’s default retention for deleted emails, files, and Teams messages is limited. SharePoint and OneDrive recycle bins clear items after 93 days. After that, recovery may not be possible. Relying on a provider’s built-in retention features means working with a system designed for the provider’s operational convenience, not your recovery needs.
Industry guidance from NSP and PrivacyNeedle both converge on the same recommendation: independent, regularly tested backups held outside the provider’s environment. The 3-2-1 rule is a practical starting point — three copies of data on two different media, with one stored offsite or on another provider. But the critical step is testing. A backup that has never been restored is an assumption, not a capability.
- When was the last successful restoration test? (Date, not vague memory.)
- Is the backup stored independently of your primary provider? (If they both go down, you’re still protected.)
- Do you know your Recovery Time Objective (RTO) — how long to get back operational? And your Recovery Point Objective (RPO) — how much data you could lose in the worst case?
- Can you recover individual files, or only complete system restores?
The Atlassian 2022 outage is a sobering example: a script error permanently deleted 775 customer sites, affecting about 400,000 users. Customer data was inaccessible for 14 days. Recovery required accessing backups with elevated permissions — a privacy failure mode in itself. That incident wasn’t a cloud infrastructure failure; it was a SaaS provider’s internal error. But the consequences for those organizations were identical to a major outage.
What a Practical Cloud Outage Plan Looks Like
A business continuity plan for cloud outages doesn’t need to be elaborate. It needs to answer three questions: what do we do in the first hour, the first four hours, and the first day if our primary cloud is unavailable? Who communicates what to clients? What work continues and what stops?
During the October 2025 Azure outage, businesses that had already asked those questions knew which staff could work and how, had manual procedures ready, and had defined who had authority to invoke the plan. Businesses without plans waited, refreshed status pages, and hoped for a return. NSP’s analysis of the New Zealand context adds another layer: Chorus research from May 2025 found the average NZ business can operate 6.9 hours without internet access — down from 9.6 hours in 2022. Businesses have digitised faster than they’ve built resilience.
For remote workers, the practical question is often about file transfer infrastructure. The November 2025 Cloudflare global network disruption showed that organizations relying exclusively on web-based file transfers lost critical capabilities within minutes. Those using protocol-level alternatives like SFTP or high-performance transfer systems (such as Aspera’s FASP) maintained continuity because those tools operate independently of CDN infrastructure. A hybrid approach — cloud convenience for daily work, independent protocols for mission-critical transfers — reduces single points of failure.
Map your dependencies
List every cloud service you use for files, communication, and collaboration. Note which ones route through CDNs or infrastructure providers like Cloudflare.
Define your RTO and RPO
Be honest: how long can you be without access to client files? How much data can you afford to lose? These numbers drive everything else.
Set up independent backups
Use a third-party service or offline storage for your most critical data. Test restoration quarterly — set a calendar reminder.
Write a one-page outage playbook
Include who to contact, what to tell clients, and how to access backups. Keep it somewhere that doesn’t depend on the cloud.
The Compliance Conversation You Need to Have With Yourself
Under GDPR Article 32, data controllers must ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems. A cloud outage that renders personal data inaccessible can be viewed by regulators as a security failure — even if no data was breached. PrivacyNeedle’s analysis of the AWS outage notes that “AWS went down” is not a valid defense in a regulatory inquiry. The data controller remains accountable, not Amazon.
This has practical implications for remote workers handling client data. If a cloud outage prevents you from accessing sensitive files — say, health records or financial documents — and you haven’t documented your contingency procedures, you’re already behind. Regulators expect open communication during disruptions: real-time updates on outage impact, confirmation that no personal data was compromised, and clear recovery timelines. Transparency during downtime often does more for trust than uptime itself.
The CrowdStrike incident in July 2024 changed the calculus further. A single faulty security update crashed 8.5 million Windows devices globally, affecting airlines, hospitals, and banks. Recovery required BitLocker recovery keys, and for organizations using Microsoft-managed key escrow, Microsoft effectively controlled access to encrypted drives during recovery. That’s not a cloud provider failure — it’s a supply chain failure propagating through cloud infrastructure. But it proved that the theoretical risk of vendor lock-in is an operational reality. If you can’t get your data out of a provider’s ecosystem in a usable format on your timeline, you don’t really control it.
For remote teams, the compliance conversation starts with understanding data location. If you’re using a US-based cloud provider for client data that should stay within the EU or NZ, an outage that triggers failover routing could violate data sovereignty requirements overnight. Privacy Act 2020 in New Zealand, GDPR in Europe, CCPA in California — all impose notification obligations if personal information is accessed, exfiltrated, or lost, regardless of the incident’s origin.
I’ve seen businesses assume their cloud provider handles all this. That assumption is the most expensive mistake you can make — not because the provider is unreliable, but because reliability and resilience are different things. Reliability is uptime percentage. Resilience is what happens when that percentage doesn’t hold.
The cloud is powerful, but it’s not a safety deposit box. Treat it as infrastructure you manage, not a service you outsource responsibility to. That shift in thinking — from assuming to verifying, from hoping to testing — is what keeps sensitive files safe when the next outage hits.