What is software escrow?
Types of software escrow
Software escrow takes several forms, and the right arrangement depends on how your software is built and hosted.
Traditional/On-premises software escrow
SaaS escrow
Continuity escrow
AI escrow
You'll come across several terms used interchangeably with software escrow.
- Source code escrow refers specifically to the protection of source code and is the most common variant.
- Technology escrow is broader, covering non-software assets like formulas, algorithms, and design documentation.
- IP escrow focuses on intellectual property protection.
- Escrow as a Service (EaaS), or SaaS escrow, describes cloud-based escrow delivery models.
But for most purposes, software escrow and source code escrow mean the same thing.
Why companies use software escrow
Most businesses don't think about software risk until something goes wrong. A vendor goes quiet, a support contract quietly lapses, or a company gets acquired, and the new owner has different priorities. By then, the leverage is gone.
The core problem is straightforward: software that isn't protected is under constant threat — from vendor failure, from neglect, from the quiet business risks that don't announce themselves until they've already done damage. If the vendor stops operating, bugs can't be fixed, changes can't be made, and the software can't be moved somewhere else. All you can do is start over.
That's expensive. Rebuilding mission-critical software from scratch takes time and money most organizations haven't budgeted for. In regulated industries, there are penalties to factor in too.
Software escrow gives you a fallback if things go wrong. The source code, documentation, and everything else needed to maintain the software independently are held securely by a neutral third party, ready to be released if the conditions in your agreement are met.
And it works both ways. For the businesses that depend on software, that's risk management. For the vendors who build it, it's also a commercial advantage. Offering escrow signals stability and seriousness, especially in enterprise and regulated markets where procurement teams routinely ask for it. It's one of the more credible ways a vendor can tell a prospective customer: we're not going anywhere, but if we do, you're protected.
Codekeeper works with vendors who want to offer that assurance at scale, without it becoming an administrative burden.
How software escrow works
A software escrow arrangement involves three parties: the software vendor (the depositor), the business using the software (the beneficiary), and a neutral escrow agent, like Codekeeper, who sits in the middle and manages everything.
1. The agreement
2. The deposit
Deposits are updated on a regular schedule, often automatically, via integrations with the vendor's development tools and repositories, so the materials in escrow always reflect the current state of the software.
3. Secure storage
4. Verification
Depositing materials gets you legal protection. Verification gives you certainty. Verification is the process of independently testing the deposited materials to confirm they're complete, current, and usable. It's an optional step, but an important one. More on this in the verification section below.
5. Release
If a qualifying event occurs, the beneficiary notifies the escrow agent and requests a release. The agent manages the process, including a notification period and a window for the vendor to dispute the claim if they believe the release conditions haven't been met. If the release proceeds, the materials are delivered securely to the beneficiary, who can then use them to maintain or rebuild the software independently.
The whole arrangement is designed to be hands-off under normal circumstances. Most software escrow agreements run quietly in the background for years. The value isn't in using it; it's in knowing it's there.
What triggers a release?
Release conditions are the specific events that give a beneficiary the right to request the deposited materials. They're defined in the escrow agreement upfront, and nothing gets released outside of them.
The most common release triggers are:
- Vendor insolvency or bankruptcy
- Cessation of business operations
- Failure to provide maintenance or support
- Material breach of the license agreement
- A change of ownership where the new owner doesn't honor existing support obligations
- An end-of-life announcement
- Persistent failure to meet agreed SLAs after the issue has been raised in writing
These can be customized. Depending on the nature of the software and the relationship between the parties, additional triggers can be negotiated into the agreement, which is one reason it's worth getting software escrow terms right at the start.
When a beneficiary believes a release condition has been met, they notify the escrow agent and submit a formal request. The agent then notifies the vendor, who has a defined window to dispute the claim. If the vendor disputes it, the matter typically moves to arbitration. If they don't — or if the dispute is resolved in the beneficiary's favor — the escrow agent coordinates secure delivery of the materials.
This process protects vendors from bad-faith release requests while giving beneficiaries a clear, enforceable path when something genuinely goes wrong.
Note: Receiving the deposited materials doesn't transfer ownership of the software or grant new licensing rights. What the beneficiary gets is the right to use the source code and related materials for the specific purpose of maintaining and operating the application, as defined in the original license agreement. The vendor retains their intellectual property. Make sure your agreement reflects this clearly.
Who needs software escrow?
The short answer is anyone on either side of a software agreement where continuity matters needs software escrow.
If you're using software someone else built, the question is simple: Is it protected? Could your operations survive if this vendor disappeared tomorrow? If the honest answer is, "We'd be in serious trouble," that's the case for escrow. It's particularly relevant when:
-
Your software is mission-critical
-
Your systems have been customized for your specific environment or processes
-
Your vendor is small, venture-backed, or operating in a consolidating market
-
You've made a significant financial investment in the implementation
-
You're in a regulated industry where third-party software risk is subject to scrutiny
In financial services, healthcare, energy, the public sector, and legal services, regulators and auditors increasingly expect organizations to have documented controls around the software they depend on. Software escrow is one of the more concrete ways to demonstrate those controls exist. We cover the regulatory dimension in more detail below.
If you're a software vendor, escrow serves a different but equally practical purpose. Enterprise buyers — especially in regulated industries — often won't sign without it. Having software escrow in place removes a common objection late in the sales cycle, and signals something that's hard to fake: that you're confident enough in your own continuity to put it in writing.
When vendors enter a software escrow agreement, they take on specific obligations, such as depositing complete and current materials, keeping deposits updated as the software evolves, and providing warranties for what's held. In practice, this is less burdensome than it sounds. Codekeeper's integrations connect directly to most major repositories and CI/CD pipelines, so deposits happen automatically as part of the normal development workflow.
Software escrow and regulatory compliance
Regulators across jurisdictions are converging on the same expectation: know your software dependencies, document your controls, and be able to demonstrate resilience if a vendor relationship breaks down. No single regulation universally mandates software escrow by name, but several frameworks create obligations — around third-party risk management, business continuity, and exit planning — that escrow directly satisfies. For organizations in regulated industries, it's become less of an optional control and more of an assumed one.
The frameworks where this comes up most often:
DORA (EU Digital Operational Resilience Act)
DORA requires financial entities in the EU to manage ICT third-party risk in a structured, documented way. This includes contractual provisions for exit strategies and the ability to continue operations if a critical technology provider fails. Software escrow is a tangible, auditable control that demonstrates your continuity arrangements don't depend on a vendor staying solvent.
FFIEC (US financial services)
The FFIEC's guidance on technology outsourcing and business continuity has long implied the kind of vendor risk controls that software escrow provides. Financial institutions subject to FFIEC examination are expected to demonstrate they can maintain critical systems through vendor disruptions — escrow is a recognized mechanism for doing that.
PRA SS2/21 (UK banking)
The Prudential Regulation Authority's supervisory statement on operational resilience sets expectations for UK-regulated firms around third-party dependencies and exit planning. Firms are expected to identify their important business services, map their software dependencies, and have arrangements in place to maintain continuity. Software escrow fits squarely within that framework.
ISO 22301 (Business continuity management)
ISO 22301 requires organizations to identify and control risks that could disrupt their operations, including risks arising from third-party software dependencies. Software escrow is a recognized control within business continuity management systems, supporting both the planning and evidence requirements of the standard.
ISO 27001 (Information security management)
Supplier relationships and third-party risk are a named control domain within ISO 27001. Software escrow contributes to those controls by ensuring that critical software assets remain accessible even if a supplier relationship ends unexpectedly.
SOC 2
SOC 2 is an auditing framework that evaluates how organizations manage customer data and system availability across five trust service criteria. Availability is one of them. It t covers whether systems are operational and accessible to licensed parties, as agreed. Software escrow supports this by demonstrating that critical software has a continuity path, which is relevant both to vendors proving their own resilience to customers and to organizations proving they've managed their third-party software dependencies responsibly.
Escrow isn't a compliance silver bullet, but it's a practical, well-understood mechanism that satisfies a major part of what auditors are looking for.
Verification and certification
Setting up a software escrow agreement gives you the legal right to access your software if something goes wrong. Verification goes a step further; it gives you the confidence that when you exercise that right, everything will work as expected.
The two things are related but distinct. An escrow agreement without verification is legally sound. But until someone has tested the deposited materials, you're taking on trust that the source code is complete, the build instructions are accurate, and the dependencies are all there.
Verification is an independent technical review of the deposited materials. The depth of that review depends on the level you choose.
Codekeeper offers three, plus a tailored option. Validated confirms that materials have been deposited and checks file integrity, a good starting point for lower-risk software. Verified adds automated analysis of the deposit's content and development activity, giving a clearer picture of what's been stored and how current it is. Certified adds expert human review and a full build test, where specialists compile and run the software from the deposited materials to confirm it produces a working application. Custom verification is tailored around the specific architecture and requirements of your software, for situations where standard tiers don't cover what you need.
Each level produces a Software Resilience Certificate — a formal document that records what was tested, what was found, and what the outcome was.
For vendors, it's a credible signal to prospective customers that your escrow arrangement is real and tested. For buyers in regulated industries, it's evidence that your continuity planning holds up under scrutiny. The further you go up the verification tiers, the stronger that evidence becomes.
How much does software escrow cost?
Software escrow is typically priced as an annual subscription, and the cost varies depending on the type of escrow, the verification level, the number of beneficiaries, and how complex the agreement is to set up. SaaS and continuity escrow involve more technical complexity than protection for traditional on-premises systems, so they cost more to run.
The more useful question isn't what software escrow costs, but what you're comparing it to. When a vendor fails without software escrow in place, rebuilding doesn't just mean finding new software; it means finding a new vendor, migrating data, retraining staff, and keeping the business running through all of it. That process runs to orders of magnitude more than an annual escrow subscription. In regulated industries, add potential penalties on top of that.
For most organizations, it ends up being one of the cheaper line items in their risk management budget.
See Codekeeper's pricing or talk to the team about the right arrangement for your situation.
How to set up software escrow
Activating software escrow protection is simpler than most people expect. The main effort is upfront, getting the agreement right and making sure the right materials are deposited. After that, it largely runs itself.
1. Map your dependencies
Which applications would cause serious operational or financial damage if they became unavailable? Which of those are built and maintained by a third party? That's your starting list. If you want a structured way to do this, Codekeeper's risk assessment walks you through it and produces a report you can act on.
2. Choose the right type of escrow
Once you know what you're protecting, the type of escrow follows naturally. On-premise software points to traditional source code escrow. Cloud-hosted applications need SaaS escrow. For systems where any downtime is unacceptable, continuity escrow is worth considering. If you're unsure, chat with Codekeeper's escrow specialists before committing to anything.
3. Agree on terms
The software escrow agreement needs to cover deposit schedules, release conditions, and each party's obligations. The right time to do this is when the license agreement is being negotiated, not after — it's much easier to get alignment before the contract is signed than to retrofit it once the software is already embedded in operations. If the conversation needs a nudge, Codekeeper can help facilitate.
4. Set your verification level
Choose based on how critical the software is and what level of assurance you need — for your own confidence and for any external stakeholders like auditors or regulators.
5. Automate your deposits
Codekeeper integrates directly with GitHub, GitLab, Bitbucket, and most major CI/CD pipelines, so new versions are deposited automatically as part of the normal development workflow. From there, schedule your verification reviews in line with your agreement terms and any audit cycles you're working to. The ongoing overhead is minimal.
Software protection starts with escrow
Software is always at risk — from vendor failure, insolvency, acquisition, or simply neglect. Most organizations don't think about that risk until they're already dealing with the consequences, and by then, the options are limited. Without protection in place, a vendor going dark or a cloud service shutting down can leave your operations exposed, your team scrambling, and your recovery timeline uncertain.
Software escrow is that protection. It's a secure, legally enforceable arrangement that ensures the source code, data, configurations, and everything else needed to keep your software running stays accessible and maintainable, whatever happens. It works across software types — traditional applications, cloud services, AI systems — and it gives everyone in the agreement the confidence that continuity is built in from the start.
