Picture a Monday morning when a critical SaaS supplier misses a payment to its cloud hosting provider. There is no public announcement and no insolvency notice yet. The hosting account is simply suspended, and the platform your teams rely on for billing, case management, or customer onboarding stops responding.
This is exactly the scenario their SaaS escrow agreement was put in place to cover for many organisations. The harder question is whether the deposit held in escrow could actually bring that service back. With traditional on-premises software, a release usually hands you source code you can compile and run on infrastructure you already control. With SaaS, the infrastructure itself disappears along with the supplier.
Why cloud makes supplier failure riskier
Cloud has made software faster to buy and easier to scale. It has also changed what happens when a supplier gets into difficulty.
When an on-premises vendor fails, the application usually keeps running on your own servers while you plan next steps. With SaaS, the application, the data, and the hosting environment all sit with the supplier. If the hosting bill goes unpaid, the cloud provider can suspend the account, and in some cases the service can go dark within days.
That compresses your decision window from months to days. Recovery then depends on one thing: whether someone can recreate a working copy of the platform elsewhere, quickly, using only what was deposited.
More moving parts, more that can go missing
Recovering a cloud platform takes far more than source code. A recoverable SaaS deposit typically needs to include:
- Source code for every service and component in the platform.
- Deployment scripts and infrastructure-as-code templates that define each environment.
- Configuration files, environment variables, and secrets management details.
- Third-party dependencies, libraries, and container images, including anything held in private registries.
- Database schemas and current data exports.
- Credentials and access for hosting accounts, DNS, certificates, and connected services.
- Build and deployment instructions written clearly enough for someone outside the supplier to follow.
Each item is a link in a chain. A missing deployment script, an expired certificate, an unavailable dependency, or a credential that was never deposited can stop recovery on its own. The more distributed the architecture, the more places a gap can hide.
SaaS deposits also go out of date quickly. Cloud teams release frequently, so a deposit that was complete in January may no longer match production by March.
What the CrowdStrike outage showed European organisations
On 19 July 2024, a faulty content update to CrowdStrike’s Falcon sensor caused Windows systems to crash worldwide. Microsoft estimated that around 8.5 million devices were affected. Within hours, airlines, airports, hospitals, banks and broadcasters across Europe were dealing with disruption.
That incident was an operational failure rather than a supplier going out of business, and escrow would not have prevented it. Its relevance here is the speed. It showed how quickly a single supplier issue can cascade through organisations that depend on the same technology, and how little time there is to respond once a widely used service stops working.
Many boards came away asking a direct question: if a critical supplier went down and did not come back, what is our plan, and has anyone tested it?
The regulatory stakes: EU Data Act, DORA and NIS2
European regulation is moving in the same direction. Organisations are increasingly expected to show that they can exit, switch or recover from critical technology suppliers, and to evidence that capability.
EU Data Act. Applicable from 12 September 2025, the Data Act sets rules for switching between data processing services, including cloud and SaaS. Providers must remove obstacles to switching and support customers moving their data and digital assets elsewhere. Switching rights are valuable while a supplier is trading and cooperative. They offer much less protection once the supplier has stopped operating, and that is the gap a verified escrow deposit is designed to close.
DORA. For financial entities in scope, DORA has applied since 17 January 2025. It requires exit strategies for ICT services supporting critical functions, along with contractual provisions covering transition. An exit strategy that relies on an untested deposit is difficult to defend. PRAXIS verification supports the evidence firms need for those exit strategies, as covered in our guide to verified exit plans under DORA.
NIS2. NIS2 extends cybersecurity risk management obligations across a wide range of essential entities in the EU. Its required measures include supply chain security, business continuity, backup management and disaster recovery. For organisations delivering essential services through SaaS platforms, the ability to recover a critical supplier’s platform belongs within that continuity planning.
UK organisations serving EU markets or operating EU entities may fall within the scope of these regimes, and UK regulators are pursuing closely aligned operational resilience objectives.
Why SaaS escrow needs verification more than traditional software
An unverified deposit is a risk with traditional software escrow. With SaaS escrow, it is closer to an assumption nobody has checked.
The PRAXIS Technical Verification ladder is built to close that gap in stages:
- Level 1, Deposit Index and Accessibility: confirms the deposit can be opened and catalogues what it contains.
- Level 2, Inventory and Analysis: reviews the contents against what the application should require.
- Level 3, Remote Compile Evaluation: confirms the code can be built.
- Level 4, Simulated Release: rebuilds and deploys the application from the deposit and its instructions alone.
Levels 1 and 2 provide the foundation. For SaaS, the destination is the full rebuild standard of Levels 3 and 4, because a platform that cannot be redeployed into a working environment cannot be recovered, however complete the source code looks. You can read more about how the Level 1 audit and software escrow verification rights fit into your agreement.
The question to ask every critical SaaS supplier
If you take one action after reading this, make it this one. Ask each critical SaaS supplier:
Has anyone independently rebuilt your platform from the deposit?
The answer tells you a great deal. Useful follow-up questions include:
- When was the last independent rebuild, and which version of the platform did it cover?
- Did the deposit include deployment scripts and infrastructure-as-code templates?
- How are hosting credentials and account access protected and made available on release?
- How is the deposit kept current as the platform changes?
A supplier confident in its deposit will welcome the conversation. Hesitation is useful information too, and gives you a clear starting point for remediation.
How PRAXIS verification makes SaaS recovery real
PRAXIS Level 4 Simulated Release testing replicates the SaaS application using only the deposit and its accompanying instructions. Any missing script, dependency, or access requirement surfaces during testing rather than during a crisis, so the supplier can remediate while there is still time to do so calmly.
Once a deposit is verified, SaaS Continuity provides a managed Recovery Environment where the platform can be restored and run if a release is triggered. SaaS Credential Escrow secures the hosting and account access needed to keep the service available.
Keeping that position current is just as important. Automated Escrow captures updates as the supplier releases them, and the Infinite Retention Policy ensures verified deposits remain recoverable over time. Escrow Assurance, SOC 2-certified operations and all-inclusive pricing give procurement and risk teams a clear, predictable foundation for continuity planning.
Explore PRAXIS SaaS verification and continuity
Cloud-first strategies work best when they are verify-first as well. If your organisation depends on SaaS suppliers for critical services, PRAXIS can help you confirm that those platforms can actually be recovered.
FAQs
SaaS escrow is an arrangement where a supplier deposits the code, deployment materials, data, and access needed to recover a cloud application with an independent third party.
SaaS deposits contain more moving parts, such as deployment scripts, environments, credentials, and data, so there are more points where a gap can stop recovery.
Level 4 Simulated Release testing rebuilds and deploys the application using only the deposit and its instructions, confirming it can be recovered in practice.
The EU Data Act strengthens cloud switching rights, but those rights depend on a functioning supplier, so verified escrow remains important if the supplier stops operating.
PRAXIS does not provide DORA compliance, but its verification and continuity services support the evidence firms need for their ICT exit strategies.
Ask whether anyone has independently rebuilt their platform from the escrow deposit, and when that rebuild last took place.
Glossary of Terms
An escrow arrangement covering a cloud-hosted application, including code, deployment materials, data, and access needed for recovery.
The highest PRAXIS verification level, in which the application is rebuilt and deployed from the deposit and its instructions alone.
A managed environment, provided through PRAXIS SaaS Continuity, where a verified SaaS platform can be restored and run following a release.
A PRAXIS service that secures hosting account credentials and access so the platform can be kept available if the supplier cannot operate it.
Scripts and templates that define and provision cloud environments automatically, which are essential for rebuilding a SaaS platform.
A documented, tested plan for transitioning away from an ICT supplier, required under DORA for services supporting critical or important functions.
Praxis Editorial Team Author
Chris Smith is the Founder and CEO of PRAXIS Technology Escrow and a recognized leader in software and SaaS escrow with more than 20 years of industry experience. He pioneered the first automated escrow solution in 2016, transforming how escrow supports Agile development, SaaS platforms, and emerging technologies.