Software Escrow Clauses: Negotiating Verification Rights...

Ask in-house counsel which part of a software escrow agreement took the longest to negotiate, and the answer is nearly always the release triggers. Insolvency, cessation of trade, failure to support, change of control – these events are debated line by line because they decide when the beneficiary gains access to the source code.

Far less time goes on a simpler question. When release happens, will the deposit actually work?

A release trigger gives the beneficiary a right to receive material. It says nothing about whether that material is complete, current, or capable of being rebuilt into the application the business depends on. Verification rights answer that question, yet in many contracts they are missing altogether or reduced to a single line permitting testing “by agreement”. This article explains why verification rights deserve the same drafting attention as release triggers, and sets out the four points counsel should negotiate: the level of testing, who pays, how often it happens, and what the depositor must do to cooperate and fix gaps.

The gap between an escrow agreement and a usable deposit

Software escrow agreements are often treated as a procurement formality: the licence is signed, the escrow agreement follows, and a deposit is made. What is rarely checked is what that deposit contains.

Deposits fail for ordinary reasons. Build scripts are missing. Third-party dependencies are undocumented. The deposited version is two releases behind production. Configuration details or credentials sit with a single developer. None of these problems is visible from the agreement itself. They surface at the point of release, when the depositor may no longer be available to help.

An escrow agreement alone does not prove a deposit is complete, accurate, or functional. Verification does. For counsel, that means the clause governing testing carries as much risk weight as the clause governing release.

Why does the UK legal context raise the stakes?

Three frameworks are worth keeping in view when drafting.

UK contract law rewards precision

English courts generally give effect to the words the parties chose and are reluctant to imply terms simply because they would make a bargain work better. Where a verification right is vague, for example a general obligation on the depositor to “provide reasonable assistance”, the beneficiary may find there is little of substance to enforce. Express obligations with a defined scope, timescales and consequences are far easier to rely on. The choice between reasonable endeavours, all reasonable endeavours and an absolute obligation also matters here, and is worth settling deliberately rather than by default.

CIGA 2020 changed the insolvency landscape

The Corporate Insolvency and Governance Act 2020 introduced a standalone moratorium for companies in financial difficulty and new restrictions on terminating supply contracts by reason of a counterparty’s insolvency. How these provisions affect a particular escrow arrangement depends on the facts and the drafting. The broader lesson for counsel is that insolvency-linked release triggers are more complex to rely on than they once were, and an insolvency process can introduce delay at the moment the beneficiary most needs certainty. If the route to release may be slowed or contested, confidence that the deposit works once released becomes more valuable.

DORA Article 30 for financial entities

For financial entities within the scope of the EU Digital Operational Resilience Act, Article 30 sets out key contractual provisions for ICT services contracts. For services supporting critical or important functions, these include rights to monitor the provider’s performance, covering access, inspection and audit, together with exit strategies that allow an adequate transition period. Verification rights in an escrow clause sit naturally alongside these obligations. Verification does not in itself make a firm compliant, but PRAXIS supports evidence for exit strategies by giving the beneficiary a documented record that its recovery material has been tested. Our earlier article on verifying escrow deposits in financial services covers this in more detail.

Negotiate verification rights before signature

Leverage is at its highest before the agreement is signed. At that stage, verification is one term among many, and a depositor confident in its code has little reason to resist reasonable testing. Once the contract is in place, the depositor has no commercial incentive to agree to additional testing, cost or cooperation, and a later request from the beneficiary is likely to be met with a quotation and a delay.

In practice, this means raising verification in the first draft of the escrow schedule, rather than after the main licence terms have been agreed. It also helps to involve IT and procurement early, since they are best placed to judge what level of testing the application warrants. If a depositor refuses verification outright at this stage, that refusal is useful information in its own right.

What to negotiate: four points

1. The level of testing

A clause that refers only to “technical verification as agreed between the parties” leaves the most important detail open. Defining the level in the contract removes that ambiguity. PRAXIS Technical Verification follows a four-level ladder:

• Level 1: Deposit Index and Accessibility. Confirms the deposit has been received, can be accessed, and is indexed. This is the Level 1 audit, a practical annual baseline.
• Level 2: Inventory and Analysis. Reviews the contents of the deposit in more depth to identify gaps in components, documentation and dependencies.
• Level 3: Remote Compile Evaluation. Tests whether the source code can be compiled.
• Level 4: Simulated Release. Rebuilds the application under conditions that simulate a real release. This is the full rebuild standard.

Levels 1 and 2 form the foundation of the verification ladder, while Levels 3 and 4 are the rebuild standard destination. A workable drafting approach is to name a minimum level, such as an annual Level 1 audit, and give the beneficiary the right to escalate to a Level 4 Simulated Release on defined events, such as a major version release, a change in hosting or architecture, or a failed lower-level test.

2. Who pays

Cost allocation is one of the most common sticking points, and it is easier to resolve before signature. Typical positions include the beneficiary funding all testing, the depositor funding all testing, or a split. Whichever baseline is agreed, counsel should consider a separate provision that places the cost of remediation and retesting on the depositor where verification identifies deficiencies. That keeps the incentive where it belongs: with the party responsible for the quality of the deposit.

PRAXIS all-inclusive pricing helps keep the cost of verification predictable, which makes allocation simpler to agree at the negotiation stage.

3. How often

A single test at the start of the relationship tells the beneficiary what the deposit looked like on one day. Software changes constantly, so frequency matters. A sensible structure combines a regular cycle, usually an annual Level 1 audit, with event-driven testing after major releases, significant architectural changes, or a previous failed verification.

Frequency of testing works best alongside frequency of deposit. Automated Escrow keeps deposits current between verification cycles, and Infinite Retention preserves the full history of deposits, so earlier versions remain available if they are ever needed.

4. The depositor’s duty to cooperate and fix gaps

Verification depends on the depositor’s participation, so the clause should say exactly what that participation involves. Three obligations are worth setting out expressly:

• to complete a verification questionnaire within a defined number of business days of a request;
• to provide reasonable access to personnel and technical information needed to carry out testing;
• to remedy any deficiencies identified within a defined period, make a corrected deposit, and support a retest.

Counsel should also consider what happens if the depositor persistently fails to remedy. Some agreements treat this as a material breach of the licence or support agreement; others link it to the escrow release conditions. The right answer depends on the commercial relationship, but leaving it silent removes most of the clause’s practical force.

Depositors sometimes raise intellectual property concerns about testing. It helps to explain that verification takes place under the escrow agent’s controls, and PRAXIS has a complete SOC 2 audit, which gives both parties independent assurance over how deposit material is handled.

Referencing a defined process in the clause

One reason verification clauses end up vague is that counsel has no clear process to refer to. PRAXIS verification follows four defined steps:

1. The beneficiary requests testing.
2. The depositor completes a questionnaire.
3. Testing runs at the agreed level.
4. Findings are reported.

Because each step is defined, the clause can reference the process directly and attach timescales to the stages that depend on the depositor, particularly the questionnaire and any remediation that follows the findings. The result is a clause that is specific enough to enforce and practical enough to operate.

PRAXIS agreements are structured to comply with UK contract law, and the Attorney Resource Center supports counsel drafting verification terms, including model language and guidance on how verification rights fit alongside release conditions. For ongoing oversight across the life of the agreement, Escrow Assurance gives beneficiaries continued visibility of deposit status. Where the application is delivered as a service, SaaS Continuity extends the same principles to hosted environments.

A short drafting checklist

Before the escrow schedule is finalised, counsel may find it useful to confirm that the agreement:

1. names the verification level or levels by name, with a minimum baseline;
2. gives the beneficiary a right to escalate testing on defined events;
3. allocates the cost of routine testing and, separately, the cost of remediation and retesting;
4. sets a testing frequency tied to both a regular cycle and material changes;
5. obliges the depositor to complete the questionnaire, support testing and remedy deficiencies within stated timescales;
6. states the consequence of a persistent failure to remedy.

Release triggers decide when. Verification decides whether it is worth having.

Release triggers will always deserve careful negotiation. They determine when a beneficiary can act. But verification rights determine whether acting will achieve anything. Given that leverage disappears once the contract is signed, the time to secure them is during the same negotiation that settles the triggers.

If you are drafting or reviewing escrow terms and would like to discuss how verification rights could be structured for a specific agreement, contact the PRAXIS team.