Your source code is in escrow. But would it actually help when you need it?

Guy Krige, Risk and Regulatory Lead at ESCROWSURE.

---

Signing a software escrow agreement can provide reassurance. The supplier has deposited source code. The escrow agent has confirmed receipt. The agreement is in place.

But there is a more important question for the organisation relying on that software:

What has actually been established?

A deposit confirms that material has been supplied into an escrow arrangement. On its own, it does not establish that the material is complete, corresponds with the software currently in use, can be built or will support the organisation's intended response if supplier support becomes unavailable.

For organisations whose important business processes depend on third-party software, that distinction deserves attention.

The useful question has moved beyond: Do we have software escrow?

Management needs to establish whether the arrangement still matches the software dependency it was created to address.

Consider an escrow arrangement put in place five years ago.

The contract may still be current. Deposits may still be arriving. Yet the application itself could have changed considerably.

New versions have been released. Libraries have changed. APIs have been added. Infrastructure may have moved to the cloud. Build processes may have evolved. New third-party components could now sit between the application and the business process that depends on it.

The organisation may still have escrow, but does the material held under that arrangement correspond with the software it relies on today?

That is where escrow testing becomes useful.

Tests must examine the relationship between the business dependency, contractual mechanism, deposited materials, verification performed and intended continuity response.

That means asking questions such as: What software are we protecting? How critical is it? What failure or loss-of-support scenario are we addressing? What has been deposited? When was it last updated? What has been technically verified? What rights arise following a valid release? What would the organisation actually need to do with the material afterwards?

Those questions reveal far more about the control than a deposit receipt ever could.

Verification is another area where organisations need precision.

Saying that source code has been "verified" can sound reassuring, but the word is only meaningful when the scope of the verification is understood.

A verification procedure might establish that specified materials are present and readable. A different procedure might examine whether the deposit corresponds with a particular software version. A further technical exercise could address defined build procedures.

These tests answer different questions.

Technical verification should therefore have a defined purpose, scope and result. The conclusion should remain within what the procedure actually established.

A deposit should not automatically be described as complete. Completeness does not establish buildability. Buildability does not establish functionality. None of those outcomes, individually, establishes recoverability or uninterrupted continuity.

For a CIO, risk executive or assurance function, this distinction matters because it determines what evidence exists behind the control being reported to management.

If a risk register says a critical application is "protected by escrow", the next questions should be: protected against which scenario, and supported by what evidence?

There is also a legal dimension.

A technically useful deposit does not answer every contractual question. Equally, carefully drafted release provisions do not establish what is contained in the deposit.

An effective review needs to consider both.

What constitutes a release event under the agreement? Who may request release? What evidence or notice is required? Is there an objection or dispute procedure? What rights does the beneficiary receive following a valid release? What restrictions continue to apply to the supplier's intellectual property?

The answers depend on the particular agreement.

This is why management should be cautious about assuming that escrow means source code simply becomes available whenever a supplier experiences difficulty.

The contract determines the applicable release mechanism. The technical evidence establishes what is known about the deposited material.

Both matter.

The move towards SaaS has made this analysis more important.

With traditionally deployed software, source code and supporting technical documentation may represent a significant part of the dependency.

A hosted application can involve considerably more.

Databases, infrastructure configuration, deployment processes, interfaces, integrations, architecture, development environments and operational information may all contribute to the service the customer depends on.

Source code alone may therefore be insufficient for the organisation's intended continuity response.

A SaaS continuity review should begin by establishing what the organisation is actually trying to preserve.

Does it require access to intellectual property? Does it need sufficient technical material to recreate an environment? Are particular data, infrastructure or integration dependencies relevant?

These are different requirements and need different evidence.

The wider regulatory direction also makes this discussion timely.

South Africa's Joint Standard 2 of 2024 requires financial institutions within its scope to identify business processes and information assets, including those managed by third-party service providers, and classify them according to criticality and sensitivity.

That does not amount to a general regulatory requirement for software escrow but regulators are wanting to see actual proof of recoverability and sometimes even ask to see the relevant escrow agreement.

The relevant principle is measured: organisations identifying material technology dependencies need to understand the risks and controls associated with them and be able to demonstrate their solutions to worst case scenarios.

Internationally, similar thinking is visible in the EU's Digital Operational Resilience Act, DORA, which addresses ICT third-party risk and requires applicable financial entities to consider documented and tested exit planning for ICT services supporting critical or important functions.

Again, that does not make software escrow compulsory.

It does place greater emphasis on whether organisations understand the dependencies behind important services and whether the controls and exit arrangements they rely on can withstand scrutiny.

There is an interesting development closer to software escrow itself.

Saudi Arabia's Communications, Space and Technology Commission has published a Software Escrow Guideline describing five principal activities: agreement, deposit, verification and storage, periodic updating, and release.

The guidance applies within its own context and should not be treated as a universal regulatory standard.

Its life cycle approach is nevertheless instructive.

Software changes. Dependencies change. Business criticality can change. The escrow arrangement therefore needs to remain connected to the technology and risk it was established to address.

An agreement signed years ago should not become something that disappears into a contract repository until a crisis occurs.

For organisations reviewing critical third-party software, I would want the control owner to be able to answer seven questions:

1. What supplier failure or loss-of-support scenario are we addressing?
2. What would we need if that scenario occurred?
3. What has actually been deposited?
4. What has actually been technically verified?
5. Does the deposit correspond with the software we use today?
6. Do the contractual release mechanisms and rights support the intended response?
7. What would we need to do after a valid release?

The seventh question is often the hardest.

Who has the required technical skills? What infrastructure would be needed? Which external dependencies remain? What documentation exists? What has actually been tested?

Those answers determine what role the escrow arrangement can realistically play.

Software escrow can provide an independent control where the underlying software dependency justifies it.

But good governance should also allow an organisation to conclude that additional verification is unnecessary, that an existing arrangement remains appropriate or that escrow itself is disproportionate to a particular risk.

The objective is evidence, not simply more control.

For management, risk, legal, technology and assurance teams, one question captures the issue:

Does the arrangement you have today still match the software dependency you are carrying today?

That is what a meaningful software escrow review should be able to answer.