PBS stations across the United States recently discovered a sobering truth: their data was “backed up” in name only. When Nine PBS, a managed IT provider serving public broadcasters, abruptly ceased operations, member stations found themselves locked out of critical systems—not because backups didn’t exist, but because they couldn’t access them without the vendor who had vanished. The incident underscores a dangerous assumption permeating enterprise IT: that vendor-managed backups guarantee data recoverability. They don’t. Backup completion logs tell you data was written somewhere; they don’t prove you can retrieve it independently when your vendor fails, files bankruptcy, or simply stops answering calls. For organizations relying on managed database services or cloud providers, the PBS crisis offers a stark lesson—your disaster recovery plan must account for the disaster where your recovery provider itself becomes unavailable. This isn’t theoretical risk management; it’s operational prudence. The question every CIO should answer today is straightforward: if your primary vendor disappeared tomorrow, could you restore your databases, application data, and configurations without their credentials, documentation, or support?
Map the Full Custody Chain: Primary and Downstream Providers
Most organizations confidently name their primary cloud or backup vendor. But they remain entirely blind to the subprocessors and downstream storage providers who actually hold their data. This visibility gap creates catastrophic exposure when a vendor fails. It also creates exposure when access is suddenly revoked.
A complete database custody chain audit starts with a deceptively simple question. Where does your data physically reside at every stage of its lifecycle? Your contract may be with a managed database provider. But that provider may use AWS or Azure for storage. It may also use a third-party replication service for disaster recovery. Long-term archival may run through an offshore facility entirely. Each link in this chain represents a potential point of failure. It’s also a potential barrier to any independent data access strategy.
What does this look like in practice?
Document every entity with custody or access rights to your data. Request explicit disclosure of all subprocessor data access rights in writing. This disclosure should include the legal jurisdictions where data resides. Many organizations discover their “US-based” provider actually stores replicas elsewhere. Those replicas often sit in data centers across three continents. Each location carries different regulatory frameworks and insolvency protections.
For mission-critical databases under managed database services, establish contractual requirements for full custody chain transparency. When working with Azure-based managed services, verify which Azure regions your vendor uses and whether they’ve implemented additional downstream providers for backup or replication.
The cloud vendor insolvency data risk extends beyond your direct provider. If your vendor uses a storage subprocessor who fails first, your data may become inaccessible even while your primary vendor remains operational. Mapping this chain isn’t optional—it’s the foundation of any viable vendor failure disaster recovery plan.
Establish Independent Access: Credentials, Keys, and Permissions
True data control requires maintaining access mechanisms that function independently of vendor portals and support channels. When a vendor experiences catastrophic failure—financial collapse, ransomware, or sudden service termination—the ability to recover your data hinges entirely on whether you control the essential access credentials outside their ecosystem.
This means retaining ownership of encryption keys, not letting them exist solely in vendor-managed key stores. It means maintaining API credentials with direct storage access rights that work even if the vendor’s management console disappears. Organizations must demand and exercise independent authentication mechanisms that bypass vendor intermediaries entirely. If your only path to data involves logging into a vendor portal, submitting a support ticket, or waiting for a third-party authentication flow, you don’t truly control your data.
A robust backup, recovery, and resilience strategy must document and regularly validate independent access pathways. This includes maintaining copies of service account credentials, understanding which storage-level permissions grant direct object access, and knowing precisely which encryption keys are required for data recoverability without vendor assistance. According to NIST Special Publication 800-57, organizations should maintain independent key management procedures with documented recovery processes that function without third-party involvement.
Test these independent access mechanisms quarterly by retrieving data without using standard vendor tools or support channels. If you cannot successfully access, decrypt, and restore data using only your independently held credentials, you have discovered a critical vulnerability in your vendor failure disaster recovery plan before disaster strikes.
Test Beyond Backup: Restoration Reality and Vendor Failure Scenarios
Backup completion notifications provide false comfort. The critical question isn’t whether your data is being backed up—it’s whether you can actually restore it when your vendor fails, disappears, or becomes legally inaccessible. Most organizations discover this gap only during crisis recovery, when it’s too late to remedy.
Restoration testing must extend beyond routine recovery drills that assume vendor availability. True resilience requires testing scenarios where the backup provider itself is compromised, insolvent, or subject to legal holds. Can your team execute a full database restoration using only the backup artifacts and access credentials you control directly? If the answer requires vendor support tickets, portal access, or technical assistance from the provider, your recovery strategy has a single point of failure.
Vendor failure scenarios should be incorporated into regular disaster recovery exercises. Test restoration from backup archives stored in your own cloud tenants or separate storage tiers. Validate that encryption keys, compression algorithms, and restoration utilities function independently of vendor infrastructure. Managed Database Services should include documented procedures for recovery without vendor participation—a capability often missing from standard service agreements.
This testing reveals uncomfortable realities: proprietary backup formats that require vendor tools, encryption keys held exclusively by the provider, or restoration processes dependent on vendor-managed infrastructure. Each dependency represents a potential data loss vector when vendor continuity breaks down. Organizations implementing database assessment frameworks must explicitly evaluate data recoverability without vendor assistance, treating backup accessibility as a distinct requirement from backup frequency or retention period.
Secure Your Exit Before You Need It: Portability and Contractual Rights
Knowing how to restore your data is meaningless without the right to retrieve it. This applies when a vendor relationship ends. It also applies when a vendor simply ceases to exist. Technical portability and contractual rights are not interchangeable concepts. One addresses capability; the other addresses permission. Both are essential components of an independent data access strategy. Both must be secured before a crisis forces the issue.
Technical portability means your backups exist in formats you can restore without proprietary tools. Standard formats include SQL dumps for databases and open-source archive formats for file systems. These allow restoration using widely available utilities. Proprietary backup formats lock you into vendor-specific restoration processes. This creates vendor lock-in data recovery dependencies that persist even after a contract ends. Before selecting a backup solution, confirm your data can export to non-proprietary formats. Also confirm you have the tools and knowledge to restore it independently.
Contractual rights govern what happens to your data when a vendor relationship terminates. This can happen through your choice, their insolvency, or regulatory action. Review your agreements carefully. What are your subprocessor data access rights if your primary vendor uses third-party storage? What guarantees exist for data retrieval if the vendor files for bankruptcy? Does your contract specify timelines and formats for data return? Many agreements contain ambiguous language around cloud vendor insolvency data risk. This leaves customers negotiating data retrieval under duress. Legal clarity established during procurement saves weeks or months during a crisis.
Your exit strategy must be documented, tested, and updated as your environment evolves. Document the exact steps—technical and contractual—required to migrate away from each vendor. Test these procedures annually, just as you test restoration. Include legal review of termination clauses and data retrieval rights in your database custody chain audit. Consider whether Backup, Recovery & Resilience services that include vendor-independent restoration capabilities would reduce your exposure to single-provider failure.
A robust disaster recovery plan accounts for vendor failure disaster recovery plan scenarios, not just infrastructure failures. PBS reminded the nonprofit sector that vendors can disappear without warning. Ensure your organization won’t disappear with them.
—
Conclusion: Build Resilience Through Independence
The PBS incident underscores a fundamental truth: backup vs. restoration testing are not equivalent exercises, and data recoverability without vendor dependency is not a default state—it’s an intentional design choice. Organizations that assume backups guarantee recovery discover too late that access, permissions, and vendor continuity matter as much as the backups themselves.
Solvaria’s Managed Database Services help ensure your data remains protected, recoverable, and under your control when it matters most.
Frequently Asked Questions
What happens to my data if my cloud vendor goes out of business?
Legally, you likely still own your data — but ownership doesn’t guarantee access. If your vendor goes under, your data typically remains on whatever infrastructure it was stored on, which may be operated by a third-party subprocessor you have no direct contract with. Recovering it can require identifying that underlying infrastructure provider, proving ownership, and in some cases pursuing legal action just to establish a retrieval process.
In practice, vendor failure plays out in a few common ways:
- The vendor’s infrastructure keeps running, but support disappears. No one answers tickets, but the systems are technically still up. You may be able to self-serve an export if you already have the right credentials — which is why independent access matters more than vendor goodwill.
- The vendor is acquired, and the new owner disclaims obligations under the original contract, slow-walks data return, or simply doesn’t honor prior commitments.
- The vendor’s infrastructure is provided by a third party (a data center operator, colocation facility, or hyperscaler) that has no direct relationship with you and no obligation to release anything to you directly — even if you can prove the data is yours.
The deciding factor in all three scenarios is almost never whether the data still physically exists. It’s whether you have pre-established, vendor-independent rights and technical means to get it.
How to test data restoration, not just backup completion
Run scheduled, full-scope restoration drills — not spot checks — that pull real data out of the backup system, into a usable, non-proprietary format, without help from the vendor’s support team. Time it, document it, and treat a failed or slow drill as an incident.
A “successful backup” only confirms one thing: data was copied somewhere. It says nothing about:
- Whether the data can be restored in a reasonable timeframe under pressure
- Whether it comes back in a usable format, or locked inside proprietary vendor tooling
- Whether your own team can execute the restore, or whether it requires vendor involvement
- Whether the restored data is actually complete and uncorrupted, not just present
A basic restoration test protocol:
- Select a dataset that reflects real production complexity — not a trivial test file.
- Restore it using only internally-held credentials and documentation, with no vendor support ticket filed.
- Measure time-to-usable-data, not time-to-download-complete.
- Validate the restored data against a checksum or known-good copy.
- Repeat on a fixed schedule (quarterly, at minimum, for critical systems) and after any vendor contract change.
If your last real restoration test predates your last vendor contract renewal, you’re operating on assumption, not evidence.
Who owns my data in a cloud storage contract?
In most standard cloud and SaaS agreements, the customer retains ownership of their data — but ownership is a separate question from access, portability, and retrieval rights, and those have to be spelled out explicitly. A contract that’s silent on retrieval mechanics can leave a rightful data owner with no practical way to get their own data back.
Three clauses determine what “ownership” actually gets you in practice:
- Data ownership clause: Confirms you retain title to your data (standard in most modern contracts, but worth verifying — older or informal agreements sometimes omit it entirely).
- Data retrieval / export clause: Specifies your right to retrieve data on demand, in what format, within what timeframe, and at what cost.
- Subprocessor / downstream provider clause: Determines whether your retrieval rights extend to any third-party infrastructure providers your vendor uses — the gap that traps data when a reseller vendor goes dark but its underlying infrastructure provider is still operating.
Owning the data and being able to retrieve it are only the same thing if the contract makes them the same thing.
Data portability clause checklist
A strong data portability clause should guarantee export rights on demand, in a non-proprietary format, within a defined timeframe, at no unreasonable cost, and extending to any subprocessor holding the data — not just the primary vendor.
Use this checklist when reviewing or negotiating a vendor contract:
A contract missing more than one or two of these is a portability risk, regardless of how strong its data ownership language sounds.
Three clauses determine what “ownership” actually gets you in practice:
- Data ownership clause: Confirms you retain title to your data (standard in most modern contracts, but worth verifying — older or informal agreements sometimes omit it entirely).
- Data retrieval / export clause: Specifies your right to retrieve data on demand, in what format, within what timeframe, and at what cost.
- Subprocessor / downstream provider clause: Determines whether your retrieval rights extend to any third-party infrastructure providers your vendor uses — the gap that traps data when a reseller vendor goes dark but its underlying infrastructure provider is still operating.
Owning the data and being able to retrieve it are only the same thing if the contract makes them the same thing.
How to exit a cloud storage vendor safely
Start the exit process before you need to, not after. Confirm technical export capability, verify contractual retrieval rights, run a live test extraction, secure a destination for the data, and only then formally notify the vendor and begin migration — with a documented fallback if the vendor becomes unresponsive mid-process.
A safer offboarding sequence:
- Audit your contract for notice periods, retrieval rights, and any early-termination or data-hold clauses before signaling intent to leave.
- Confirm technical export mechanics — file formats, API access, bulk export tooling — well before initiating the exit.
- Run a live test extraction of a representative dataset while the relationship is still active and cooperative.
- Prepare the destination environment (new vendor, on-prem system, or archive) and validate it can actually ingest the exported format.
- Formally initiate offboarding with clear, documented timelines and communication in writing.
- Monitor for vendor unresponsiveness throughout the process — treat delayed replies or missed milestones as an early warning, not a normal delay.
- Have an escalation path ready (legal counsel, contract clauses, or a subprocessor contact) in case the vendor stops cooperating before the migration completes.
The organizations that get stuck mid-exit are almost always the ones that started the technical and legal groundwork only after announcing they were leaving.
Backup completion vs. recoverability
Backup completion means data was successfully copied to a secondary location. Recoverability means that data can actually be restored, in usable form, within an acceptable timeframe — ideally without depending on the vendor’s ongoing cooperation. The two are frequently conflated, and the gap between them is where most real data loss incidents actually happen.
| Backup Completion | True Recoverability |
What it confirms | Data was copied somewhere | Data can be restored and used |
Typically measured by | Job success/failure status | Full restoration drill outcome |
Vendor dependency | Not tested | Explicitly tested |
Format usability | Assumed | Verified |
Common failure mode | Silent — looks fine until needed | Caught in advance, before a crisis |
A green checkmark on a nightly backup job is a necessary condition for data safety. It is not a sufficient one. Recoverability has to be tested on its own terms, separately, on a recurring basis.
Third-party data storage risk assessment
A third-party data storage risk assessment identifies every entity — not just your direct vendor — that has physical or technical custody of your data, and evaluates your ability to access, retrieve, and control that data independently of each one. It should cover custody mapping, access control, contractual coverage, and failure-scenario planning.
Core components of the assessment:
- Custody chain mapping — Identify the primary vendor and every downstream subprocessor or infrastructure provider actually holding the data, not just the entity you have a direct contract with.
- Independent access verification — Confirm which credentials, encryption keys, and permissions your organization holds directly, versus which are controlled solely by the vendor.
- Contractual coverage review — Check whether retrieval and portability rights are documented and whether they extend down through subprocessors.
- Restoration testing — Validate that data can actually be pulled back out and used, on a regular schedule, not just at initial setup.
- Vendor failure scenario planning — Explicitly model vendor insolvency, unresponsiveness, or acquisition as a distinct risk category, separate from technical outage or breach scenarios.
- Concentration risk review — Flag cases where multiple critical systems rely on the same vendor or the same underlying infrastructure provider, creating a single point of failure across otherwise “separate” systems.
This kind of assessment is most useful before a vendor relationship becomes strained or a contract is up for renewal — by the time a vendor has gone quiet, the assessment has already become a legal problem instead of a planning exercise.