How to Review a Software Escrow Agreement (2026 Checklist)

A software escrow agreement protects a licensee who depends on software it does not own the source code for. A neutral escrow agent holds a deposit of the source code and the materials needed to build and maintain it. If agreed events happen (the vendor fails, stops trading, or stops supporting the software) the deposit is released so the licensee can keep the system running. It is a three-party arrangement between the vendor, the licensee and the agent. Reviewing one well means checking that the deposit is real and current, that verification happens, and that the release and licence terms actually let you use what you receive. This is general guidance, not legal advice. ## The fast answer: what to check first Four questions decide whether an escrow is worth having. What exactly is deposited (and is it kept up to date). Is the deposit verified, so you know it builds. What triggers release, and how contested is the release process. What rights do you get on release, and do they survive the vendor's insolvency. A deposit that is stale, unverified, hard to release or useless once received is a false comfort. ## Clause-by-clause review checklist ### Parties and the escrow agent Confirm the three parties and the agent's role. The agent should be independent and experienced in secure storage. Check the agent's duties, standard of care, and what happens if the agent itself fails or is acquired. A well-known specialist agent is usually worth more than the lowest fee. ### Deposit materials This is the foundation. The agreement should list exactly what is deposited: current source code, build and compile instructions, documentation, configuration, tools and environment details, and any third-party or open-source dependencies needed to build and run the software. A deposit of source code alone, with no build instructions or dependencies, often cannot be rebuilt. ### Deposit updates Software changes, so the deposit must too. Check how often the vendor must refresh the deposit (for example on each major release or at set intervals) and how you are told it has been done. An escrow that was deposited once at signing and never updated protects an old version you no longer run. ### Verification Verification is where many escrows are weak. Look for the level of verification: a basic file-listing check, a build test that compiles the deposit into working software, or a full functional test. The stronger the verification, the more confidence that the deposit is usable. Confirm who performs it, how often, and who pays. A vendor may insist verification is done by the agent or an independent party to avoid exposing source code early, which is reasonable. ### Release conditions (triggers) Read the triggers carefully. Common ones are the vendor's insolvency, bankruptcy or winding up, ceasing business, or failing to provide the maintenance and support it is obliged to provide. Check the triggers are objective and match situations where you truly could not keep the software running. Avoid triggers so narrow they almost never fire. ### Release procedure and disputes Check how release is requested, how the vendor can object, and how a dispute is resolved. A fair process gives the vendor a short window to object on stated grounds and then releases if the objection is unfounded. Beware procedures that let the vendor block release indefinitely by simply objecting, which can leave you without the code at the very moment you need it. ### Licence granted on release Deposit is useless without the right to use it. The agreement should grant you a licence, on release, to use, copy, modify and maintain the source code for your internal purposes to keep the software running. Check the scope matches what you actually need (for example the right to engage a third party to maintain it) and that it is not limited to passive viewing. ### Bankruptcy and insolvency protection A key risk is that the vendor's insolvency practitioner tries to undo the licence. In the US, section 365(n) of the Bankruptcy Code lets an IP licensee keep its rights if the vendor's estate rejects the contract; other countries have different rules. Check the agreement is drafted so your release and licence rights survive the vendor's insolvency under the governing law, and take local advice where this is critical. ### Confidentiality and security The deposit is the vendor's crown jewels, so expect strong confidentiality and secure storage terms. Check your use of released materials is confidential too, and that security of the deposit (encryption, access control) is addressed. ### Fees and term Check who pays the agent's set-up, storage and verification fees, the term, renewal, and what happens to the deposit if the agreement ends or fees are unpaid. ## Red flags to push back on A deposit with no build instructions or dependencies. No deposit updates, or no proof they happen. No verification, or only a file-count check. Release triggers so narrow they never fire. A release process the vendor can stall indefinitely. A release licence that only lets you view, not maintain. No thought given to surviving the vendor's insolvency. ## How the law changes by jurisdiction Contract law is national, so the same words do not behave the same everywhere. In common-law systems (India, the UK, Singapore, Australia, the US) courts lean on the written terms and read ambiguity against the drafter. Governing-law and jurisdiction clauses decide which country's rules apply and where disputes are heard; check they match where the parties and the assets actually are. In India, stamp duty and, for many instruments, registration are live concerns, and the Indian Contract Act 1872 governs formation. In the US, state law varies and the Uniform Commercial Code may apply where goods are involved. Across the EU and UK, data and consumer rules add mandatory terms you cannot contract out of. When in doubt, take local advice; this page is general information, not legal advice. ## A simple review workflow Start with the deposit materials and verification, because an unusable deposit makes the rest irrelevant. Then the release triggers and procedure, then the licence on release and insolvency survival, then fees and the agent's standing. Have an engineer confirm the deposit list is genuinely enough to rebuild the software. Keep an issues list with clause reference, risk and proposed change. ## One workspace for drafting, review and tracking Everything above is work you can do by hand: read the draft, mark the risky positions, line up your redlines, remember the dates. The friction is rarely the reading. It is that the draft, the comments, the versions, the signed copy and the renewal date usually live in five different places. The simple idea behind an AI contract workspace is to keep that work together: draft from your own catalogue, see each clause flagged favourable, neutral or unfavourable to you, edit clauses in plain English and get a clean diff, keep a live activity timeline so every version is traceable, and track key dates and obligations so renewals and notices do not slip. Adira is one such workspace, built on Anthropic's Claude and tuned to how your company contracts. It is India-first today; deeper support for other jurisdictions and a single legal health pane (the Company Command Centre) are on the roadmap. None of that replaces legal advice on a specific deal. It just means the review you ran once does not have to be rebuilt from scratch next quarter.