Ensuring continuity of critical software is a fundamental challenge for customers procuring IT services. Losing maintenance services can have serious commercial and legal consequences. This article explains why customers should secure access to the source code of commissioned software and what to consider when negotiating a source code escrow agreement with the supplier.
Why the customer needs access to source code
Computer programs very often support businesses’ critical processes. Disruptions such as unavailability or errors present significant operational risks. They can reduce service quality or cause breaches of law, for example a personal data leak leading to a supervisory authority fine. Every customer should therefore arrange software maintenance and ensure continuity of operation.
To do so, customers usually enter into a maintenance and support agreement, known as an SLA, guaranteeing an appropriate service level and error correction within specified deadlines. Problems arise when the supplier fails to perform and the customer must terminate with immediate effect, for example because of a data leak attributable to the supplier. Termination leaves the customer without support, potentially causing a gradual deterioration of functionality and, in the case of serious errors, making further use impossible. The customer can theoretically correct errors itself, but in practice this is difficult because it usually lacks source code access.
Securing access to the source code is therefore an important safeguard. The customer should enter into an escrow agreement requiring the supplier to deposit the code in a specified place, for example with a notary, a third-party source code custodian or even directly with the customer. The customer obtains access once contractual conditions are met. Source code access substantially facilitates error correction and consequently reduces the risks of defective software or software ceasing to operate.
What the escrow agreement should specify
When drafting and negotiating an escrow agreement, consider the following aspects:
First, identify precisely the computer program and version to be deposited, usually the latest version implemented for the customer. Consider requiring the supplier to deposit accompanying documentation, such as the software architecture description, code comments and annotations, and compilation instructions.
Second, ensure that the supplier regularly updates the deposited source code. Programs are continually developed and improved, for example through security patches, so the customer should have access to the most recent version.
Third, specify the deposit procedure, including when and where code must be deposited and whether customer representatives must attend. Their attendance is recommended so the customer can verify that the correct version is deposited. The procedure may also cover testing by the customer before deposit and encryption and decryption methods.
Fourth, define precisely the events triggering release of the source code. These depend on the risk the customer wishes to address. Examples include cessation of support services, termination of the maintenance agreement for reasons attributable to the supplier, or suspension of the supplier’s business.
Fifth, identify the documents or other evidence confirming those events on which the custodian will rely when releasing code. For immediate termination, this could be the termination notice with proof of postal delivery to the supplier. For suspension of business, it could be the relevant register entry confirming suspension.
Sixth, specify how the customer may use the program after obtaining the deposited code. Although the statute[1] grants licensees rights to make certain changes, including correcting errors, the scope of the customer’s rights should be defined precisely to avoid disputes. This should include the right to authorise third parties to modify the source code.
A source code escrow agreement can effectively reduce the customer’s risks when cooperation with the supplier ends and software support is lost. Access should enable the customer to maintain the software itself or with a third party, ensuring continuity. Achieving this requires precise contractual definitions of the customer’s rights, the supplier’s obligations and the rules for access to the source code.
[1] Act of 4 February 1994 on copyright and related rights (consolidated text: Journal of Laws 2025, item 24, as amended).
