A Bigger Customer Wants Source Code Escrow for Your SaaS Product. What Are They Asking For?

A larger customer is close to signing. Then the security and procurement questionnaire arrives with a line you have not seen before: "Vendor will place its source code in escrow." Your team has never done that, nobody is sure what it means for a product that runs on your own servers, and the customer wants an answer before the deal moves.

This post explains what the request is, why a customer asks for it, what a SaaS vendor can sensibly put in the agreement, and what to settle before saying yes. It is written for founders and operations leads at software companies selling to larger customers. It is contract practice, not a statement of law.

The short answer

Source code escrow is an arrangement in which a neutral third party, the escrow agent, holds copies of materials that the customer might need if the vendor can no longer run or support the product. The agent releases them to the customer under the agreement's specified release conditions and procedures, including any notice and dispute process.

The customer is asking about continuity: if your company stops supporting the product or stops operating, can they keep their own business running? An escrow clause is one answer to that question. It is not the only one, and for a hosted product it may not be the most useful one.

Options for addressing the underlying worry include:

1. Agree to an escrow arrangement with a defined deposit.
2. Offer data export, with agreed formats, timing and availability, so the customer can retrieve and retain a usable copy of its data.
3. Offer a transition period and termination assistance if the relationship ends.
4. Document how the service is run, so someone else could run it.

What escrow is, in plain terms

A typical arrangement has three parties: the vendor that deposits the materials, the customer that may receive them, and the escrow agent that holds them. The agreement sets out four things:

• The deposit: what the vendor puts in, and how often it is updated.
• The release events: the specific things that must happen before the agent hands anything to the customer.
• What the customer may do after release: the license that comes with the materials.
• The mechanics: who pays the agent, how the deposit is checked, and what happens if the vendor disputes a release.

Each of these is a drafting choice, and each can be negotiated. A customer's form may ask for the broadest version of all four.

Why a SaaS customer asks

With software that a customer installs, the customer holds a local copy of the software. With a hosted product, the customer generally relies on the vendor to operate the service rather than holding a copy it can run independently. If the vendor disappears, access to the service may disappear too.

The request may come from a risk or security team's procurement process; it does not necessarily mean the customer doubts your company. Ask what the customer is worried about before you decide what to offer. The answer changes what a good response looks like: a customer worried about losing its data needs export rights, and a customer worried about losing the service needs documentation and a transition plan.

What "the code" means for a hosted product

For a product you host, a copy of the source code alone may not let anyone run the service. The deposit could include:

• the source code and the instructions to build it;
• the configuration and scripts that set up the hosting environment;
• a list of third-party and open-source components, with their licenses;
• operating documentation, such as how the service is deployed, monitored and backed up;
• in some arrangements, copies of the data or backups, which raises its own confidentiality questions.

A useful test for any proposed deposit: could a competent team that has never worked at your company use these materials to build and run the service? If the answer is no, identify what is missing and whether the deposit still serves the agreed continuity purpose. Running the service may also require third-party rights, infrastructure, funding and technical staff. Escrow providers may offer different levels of verification; agree what will actually be tested, whether to include that testing and who pays.

Release events: where most of the work is

The release events decide when the customer gets anything. A customer's draft may list broad triggers; a vendor wants narrow, objective ones. Categories that can appear in requests like this include:

• the vendor stops supporting or hosting the product;
• the vendor stops operating or ceases to do business;
• the vendor commits a serious breach of its support obligations and does not fix it after notice and a stated cure period;
• the vendor transfers the product to a successor that does not take on the obligations.

For each one, settle these drafting points:

• Is it objective? "Ceases to provide the service for a stated number of consecutive days" is easier to apply than "fails to adequately support the product."
• Is there notice and a chance to fix it? A cure period gives the vendor time to respond before anything is released.
• Who decides if there is a dispute? The agreement should say how a disagreement about whether an event occurred is resolved, and what the agent does in the meantime.
• Is the list closed? A closed list tells both sides what will and will not trigger release.

How an escrow release interacts with a bankruptcy filing is a question for bankruptcy counsel and is outside this post.

What the customer can do after release

Release of the materials alone does not establish the customer's permission to use them. The agreements should specify the license rights available on release, whether already granted or taking effect then; rights that are too broad can harm the vendor. Points to settle:

• Purpose: use limited to keeping the customer's own operations running, not to build a competing product or to resell.
• Who may see it: the customer's employees and named contractors, under confidentiality terms at least as strict as the main agreement.
• How long: define a period that fits the agreed continuity purpose, including any agreed transition period.
• Ownership: state that depositing or releasing the materials does not transfer ownership of intellectual property, distinguish the vendor's rights from third-party rights, and specify the customer's license.
• Return or destruction: what happens to the materials when the arrangement ends.

If your source code is a trade secret, address confidentiality, security and access controls while the materials are held in escrow as well as after release. Our post on trade secrets and patents covers why.

Alternatives that address the same worry

If an escrow arrangement is more than you can offer right now, there are other ways to answer the continuity question. They can be offered instead of escrow or alongside it:

• Data export: the customer can retrieve its data in a usable format at any time, and for a stated period after termination.
• A transition period: a stated number of days of continued service and help moving off the product if either side ends the agreement.
• Support and uptime commitments: written targets and remedies. See our post on uptime and service credits.
• Longer notice before the product is retired: the customer is told well in advance if you plan to end it.
• Operating documentation: a runbook that describes how the service is deployed and recovered.

A customer may accept a combination if it answers the continuity question in writing. If your product is part of a larger deal, see our posts on enterprise SaaS contracts and security questionnaires.

Seven questions to settle before you say yes

1. What is the customer worried about? Losing data, losing the service, or checking a procurement box? Answer the real concern.
2. What would you deposit, and could someone else run it? List the materials. Test whether a team outside your company could use them.
3. What are the release events, and are they objective? Define each one and the applicable notice, cure and dispute procedures, including when a cure period is appropriate.
4. What may the customer do after release? Write the purpose, the people, the duration and the ownership down.
5. Who is a party and who pays? Decide whether the customer pays the escrow agent's fees or whether the cost is part of a larger price, and whether other customers could join the same arrangement.
6. How are updates and checks handled? Decide how often the deposit is refreshed, for example with each major release, and who verifies it.
7. Does the deposit raise problems of its own? Open-source components carry license terms. Including customer data in a backup can raise confidentiality, privacy and security obligations; define whose data may be included and how other customers' data will be excluded or segregated. If your product uses a model or a service from an upstream provider, that provider's terms may limit what you can hand over. See our posts on acceptable use policies and AI vendor terms. Check what you have already promised other customers and investors about source code.

What this post does not cover

This post does not address bankruptcy or insolvency law, whether any particular clause is enforceable, which escrow providers to use or what they charge, or what terms are standard in any market. It does not say what your agreement should contain; that depends on the product, the customer and the deal. For the wider picture, see our posts on diligence-grade contracts, the first enterprise customer's pilot and SaaS renewal terms.

How we can help

Accord & Shield Legal drafts and reviews SaaS terms and customer contract terms for technology companies in Arizona, California and Texas. To better understand the scope of your matter, you can schedule an initial consultation. The consultation is evaluation-only; no legal advice is provided. Representation begins only after an engagement agreement is signed and any required retainer is received. Please do not send confidential or sensitive documents before we confirm that we can assist.

This article is general information, not legal advice. Reading it does not create an attorney-client relationship. How any of these points applies to your company depends on your product, your contracts and your facts; consult an attorney about your situation.

Book an Initial Consultation

Schedule an initial consultation to discuss how to respond to a customer's source code escrow, continuity or procurement request. Bring a short, nonconfidential description of the situation and any deadline the customer has set.

Please do not send contracts, documents or confidential information until the firm has agreed in writing to represent you.

Schedule a consultation Call (623) 239-2682