You need software escrow when your business depends on software that only one supplier can maintain, and you could not replace it quickly if that supplier went bankrupt or stopped supporting it. The source code, build instructions and documentation are then deposited with an independent escrow agent, who releases them to you on events agreed in advance; escrow is of little use for standard software that is easy to replace, or for SaaS without a separate continuity arrangement.
Two things decide whether it works in practice. The deposit must be complete, current and verified, and the release conditions must be objectively determinable, because an escrow agent will not decide a dispute about whether the supplier is really in default. Below we explain how escrow works under Dutch law, when it is worth the cost, how bankruptcy affects it and what to check as a customer and as a supplier.
How does software escrow work?
Three parties sign one agreement: the supplier (depositor), the customer (licensee or beneficiary) and the escrow agent. The supplier deposits the material with the agent, the agent keeps it confidential, and the agent releases it only when a release event in the agreement occurs.
Under Dutch law, the escrow agreement is a contract governed by Book 6 of the Dutch Civil Code (BW). There is no specific statute on escrow, so the agreement itself must regulate what is deposited, how often it is updated, how it is verified, when it is released and what the customer may do with it afterwards.
A usable deposit contains more than source code. It should include build scripts, a description of the development and build environment, third-party libraries and their licences, database schemas, and the technical documentation a competent developer needs to compile and maintain the software.
When is escrow necessary?
Escrow is worth considering when three conditions coincide: the software supports a critical process, it is custom-made or heavily adapted, and the supplier is small or financially vulnerable. In that situation, a bankruptcy of the supplier can stop your operations within weeks.
Typical examples are a bespoke ERP or planning system, software embedded in machines you sell to your own customers, and core systems in regulated sectors. Financial entities must have exit strategies for ICT services that support critical or important functions under Article 28(8) of the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied since 17 January 2025; escrow can be part of that strategy.
Escrow adds little for off-the-shelf software with alternative suppliers, or for open-source software where the code is already public. For SaaS, source code alone does not help: you also need the hosting environment, your data and the configuration. In that case, agree a SaaS continuity arrangement under which the agent or a third party can keep the service running for a transition period, for example six to twelve months.
Which release events should the agreement contain?
The usual release events are the supplier’s bankruptcy, a suspension of payments, the end of its business, and a persistent failure to maintain the software after written notice. The narrower and more objective each event, the faster the agent can act.
Bankruptcy and suspension of payments are easy to establish, because they are published in the Central Insolvency Register (Centraal Insolventieregister). “Failure to maintain” is not: describe it concretely, for example as failing to remedy a priority-one incident within a set number of working days after a written notice of default.
Also regulate the procedure. A common model is that the customer submits a release request with supporting documents, the supplier may object within a short period, for example ten working days, and a dispute goes to arbitration or the court. Without such a procedure, the agent will hold the deposit until the parties agree, which defeats the purpose.
Mi történik a letéti számlával, ha a beszállító csődbe megy?
From the date of the bankruptcy order, the supplier loses the right to dispose of its assets, and the trustee (curator) manages the estate (Article 23 of the Bankruptcy Act, Faillissementswet). Any act the supplier still has to perform after that date, such as granting a licence or transferring rights, no longer binds the estate.
For that reason, the licence to use the source code should be granted when the escrow agreement is signed, subject only to the release condition. The release itself should then be an act of the escrow agent, not of the supplier. A licence that the supplier promises to grant later may prove worthless once a trustee has been appointed.
The trustee may also decide not to perform the ongoing maintenance agreement (Article 37 Faillissementswet). Escrow does not prevent that; it gives you the material to arrange maintenance elsewhere. Check whether the escrow fees are prepaid, because unpaid fees can give the agent a reason to stop.
What rights do you get on release?
Escrow does not transfer copyright. Software is protected by the Dutch Copyright Act (Auteurswet), and a transfer of copyright requires a signed deed (Article 2 Auteurswet), which an escrow agreement normally does not contain.
What you get is a licence, and its scope must be in writing. Typically it allows you, or a developer you hire, to use, correct, maintain and adapt the source code for your own use of the software. It usually does not allow you to sell the software to third parties.
Without an express licence, you would depend on the limited statutory rights of a lawful user, such as correcting errors (Article 45j Auteurswet). Those rights do not cover further development, so do not rely on them.
How do you keep the deposit usable?
A deposit that is not updated with each major release loses value quickly. Agree that the supplier deposits a new version within a fixed period after each release, for example 30 days, and at least once or twice a year.
Escrow agents offer different levels of verification. An inventory check only confirms that files were deposited; a build test confirms that the code can actually be compiled into the version you are using. For critical software, a full build test at the start and after major releases is worth the cost.
Also agree who pays the agent’s fees, what happens if they are not paid, and that the customer may pay them to keep the arrangement alive. Record which version of the software is in production, so you can compare it with the deposit.
Mit kell ellenőrizned vásárlóként?
As the customer, your aim is a deposit you can actually use within days of a release event.
- Check that the deposit includes build instructions, third-party components and documentation, not just source code.
- Check that the licence on release is granted at signing and covers maintenance and adaptation by a third party.
- Check that the release events are objective and that a release dispute has a fixed procedure and deadline.
- Agree a build test at the start and an update within a fixed period after each release.
- Check that you may pay unpaid escrow fees yourself to keep the deposit in place.
- For SaaS, agree a continuity arrangement covering hosting, data and configuration.
Mit kell ellenőrizni beszállítóként?
As the supplier, you want to protect your source code and avoid a release on a disputed ground.
- Limit the licence on release to the customer’s own use, with confidentiality obligations and no right to sell.
- Describe “failure to maintain” precisely and include a notice period to remedy.
- Reserve a right to object to a release request within a set number of working days.
- Agree who bears the escrow and verification costs, and how often you must update the deposit.
- Check that the deposit does not include third-party code you are not allowed to pass on.
Mit tehetünk Önért a szoftveres letéti megbízással?
termékeink IT-jogászok advise customers and suppliers on szoftver letéti számlát and the licence and maintenance agreements around it.
- We assess whether escrow or a SaaS continuity arrangement fits your software and risk.
- We draft or review the escrow agreement, including release events, procedure and licence on release.
- We align the escrow agreement with your licence, maintenance and DORA requirements.
- We submit or oppose a release request after a bankruptcy or maintenance failure.
- We deal with the trustee on continuity of the software after the supplier’s bankruptcy.
Összegzésként
- Escrow protects you when critical, custom software depends on one supplier who may go bankrupt or stop maintaining it.
- The deposit must include build instructions and documentation, and be verified and updated after each release.
- Release events must be objective, with a fixed procedure for disputes.
- Grant the licence at signing, subject to release, because the supplier cannot bind the estate after bankruptcy (Article 23 Faillissementswet).
- For SaaS, source code alone is not enough; agree a continuity arrangement.
Gyakran Ismételt Kérdések
Does escrow make me the owner of the source code?
No. Copyright stays with the supplier unless it is transferred by signed deed (Article 2 Auteurswet). On release you receive a licence to use and maintain the code, whose scope must be set out in the agreement.
Is software escrow useful for SaaS?
Only with a broader arrangement. Source code alone does not keep a hosted service running; you also need the hosting environment, your data and the configuration. A SaaS continuity arrangement can keep the service running for a transition period.
Can the trustee block a release after bankruptcy?
A trustee can contest acts the supplier would have to perform after the bankruptcy order (Article 23 Faillissementswet). That is why the licence should be granted at signing, subject to release, and the release should be an act of the escrow agent.
How often should the deposit be updated?
After each major release, within a fixed period such as 30 days, and at least once or twice a year. A build test after major releases confirms that the deposit matches the version you use.
