[INDIA] RBI, SEBI and IRDAI · Source-code escrow and continuity obligations for critical applications[EU DORA] ICT third-party risk testing required · In force Jan 2025[PRA] SS2/21 UK · Vendor recovery evidence required[MAS] Singapore TRM · Independent vendor recoverability expected[APRA] CPS 230 Australia · Third-party continuity obligations in force[FFIEC] United States · Source-code access and software escrow addressed in third-party contracts[ENTERPRISE] Mission-critical software procurement increasingly requires continuity evidence before contract
[INDIA] RBI, SEBI and IRDAI · Source-code escrow and continuity obligations for critical applications[EU DORA] ICT third-party risk testing required · In force Jan 2025[PRA] SS2/21 UK · Vendor recovery evidence required[MAS] Singapore TRM · Independent vendor recoverability expected[APRA] CPS 230 Australia · Third-party continuity obligations in force[FFIEC] United States · Source-code access and software escrow addressed in third-party contracts[ENTERPRISE] Mission-critical software procurement increasingly requires continuity evidence before contract
DISCONTINUED

Support is dropped. You have two weeks. The clock is running

In September 2013, enterprise cloud-storage provider Nirvanix told customers that its service would shut down within roughly two weeks. The platform reportedly hosted around 40 petabytes of data, while some large customers stored 10–20 petabytes each. Customers had to turn exit planning into emergency execution.

What happened

Nirvanix was not a marginal startup. It had raised more than $70 million and partnered with IBM while positioning itself as an enterprise cloud-storage provider. In September 2013, it failed to secure further funding and began winding down.

Customers were initially told to retrieve or migrate their data by the end of the month. Reports described more than 1,000 customers and around 40 petabytes hosted on the platform. Some of the largest deployments held 10–20 petabytes, volumes that were difficult to move in a two-week window.

The shutdown forced migration planning that should have existed before the vendor was contracted.

Incident at a glance

Initial notice
Roughly 14 days
Funding raised
$70M+
Hosted data reported
~40 petabytes
Large customer deployments
10–20 petabytes
Customers reported
1,000+
Alternative providers named
IBM, AWS, Google, Microsoft

The root cause

Two weeks to move petabytes is not simply a migration problem. It is an evidence problem. Organisations with a current inventory, verified custody record and tested extraction procedure can begin immediately. Those without them lose critical days discovering what they hold and how to move it.

The same logic applies to every software dependency in the estate. The question is not whether the vendor provides adequate notice. It is whether the enterprise has verified evidence to act on whatever notice it receives.

What would Proof of Recovery have changed?

  • A current inventory and verified custody record would have confirmed what assets were stored and in what format.
  • A tested deployment or extraction runbook would have defined the migration procedure before the shutdown announcement.
  • Migration to an alternative platform could have started on day one rather than after emergency discovery.
  • Verified recoverability evidence converts a short notice period from chaos into execution.

The data belonged to the customers. But the procedure for extracting it at scale, under pressure, had not been proven before the shutdown notice arrived

The regulatory consequence

Nirvanix was not the last enterprise technology provider to close, merge or discontinue services. Regulators including MAS, APRA and RBI now expect critical institutions to maintain exit and recovery procedures before a third-party disruption occurs.

If your most critical vendor discontinued tomorrow, how fast could you act?

Book a briefing