[INDIA] RBI, SEBI and IRDAI · Source-code escrow and continuity obligations for critical applications[EU DORA] ICT third-party risk testing required · In force Jan 2025[PRA] SS2/21 UK · Vendor recovery evidence required[MAS] Singapore TRM · Independent vendor recoverability expected[APRA] CPS 230 Australia · Third-party continuity obligations in force[FFIEC] United States · Source-code access and software escrow addressed in third-party contracts[ENTERPRISE] Mission-critical software procurement increasingly requires continuity evidence before contract
[INDIA] RBI, SEBI and IRDAI · Source-code escrow and continuity obligations for critical applications[EU DORA] ICT third-party risk testing required · In force Jan 2025[PRA] SS2/21 UK · Vendor recovery evidence required[MAS] Singapore TRM · Independent vendor recoverability expected[APRA] CPS 230 Australia · Third-party continuity obligations in force[FFIEC] United States · Source-code access and software escrow addressed in third-party contracts[ENTERPRISE] Mission-critical software procurement increasingly requires continuity evidence before contract

CATEGORY COMPARISON

Traditional software escrow, verification, and recoverability: what the differences actually are

Four approaches, and how far each one actually goes.

STORED
COMPILED
DEPLOYED
SIGNED

ESCROW VS RECOVERABILITY

Software escrow is a legal arrangement under which source code is deposited with an independent third party. Software recoverability is the independently verified proof that the deposited code can be rebuilt and operated without the vendor. Escrow is the container. Recoverability is the test that proves the container holds what it claims. Most escrow arrangements have never been tested. Castler SRP tests every deposit and seals the result as a signed Proof of Recovery.

THE COMPARISON MATRIX

Storage is not the same as a tested recovery path

Code deposit only

What is stored

Source and named documents

Is the code ever compiled

No

Is it ever deployed

No

Is the production architecture replicated

No

Who tests it

Nobody

Is there a signed artefact

Deposit receipt

How often is it refreshed

Contract dependent

Typical coverage of the Software Estate

Selected contracts

Who bears discovery work at release

Your incident team

What your auditor receives

Agreement and deposit record

Deposit + integrity check

What is stored

Source with arrival record

Is the code ever compiled

No

Is it ever deployed

No

Is the production architecture replicated

No

Who tests it

Custodian checks arrival

Is there a signed artefact

Integrity report

How often is it refreshed

Contract dependent

Typical coverage of the Software Estate

Selected contracts

Who bears discovery work at release

Your incident team

What your auditor receives

Integrity record

Deposit + build verification

What is stored

Source, dependencies and build inputs

Is the code ever compiled

Yes

Is it ever deployed

No

Is the production architecture replicated

No

Who tests it

Build specialist

Is there a signed artefact

Build report

How often is it refreshed

Scheduled engagement

Typical coverage of the Software Estate

One or two codebases

Who bears discovery work at release

Your incident team after build

What your auditor receives

Build evidence

Castler: independent rebuild, deploy and run

What is stored

Full deposit, recovery inputs and release evidence

Is the code ever compiled

Yes, independently

Is it ever deployed

Yes

Is the production architecture replicated

Yes

Who tests it

Castler agents and a named engineer

Is there a signed artefact

Signed Proof of Recovery

How often is it refreshed

Per verified release

Typical coverage of the Software Estate

Critical-Software Estate programme

Who bears discovery work at release

Procedure already documented

What your auditor receives

Build, deploy, replication and signed evidence

DEPTH OF TESTING

Stored. Compiled. Deployed. Replicated and signed

Each arc reaches further into the real recovery problem. Only the outermost operating standard proves the application can be rebuilt and run without the vendor.

Stored
Compiled
Deployed
Replicated and signed
STORED
COMPILED
DEPLOYED
SIGNED

THE HONEST CONCESSION

Where traditional escrow is still the right choice

A simple deposit can be proportionate when the operational consequence is genuinely limited.

A non-critical application

A low impact tolerance

An internal tool with no regulatory exposure

A vendor you could replace off the shelf within days

The right control should match the criticality of the application. Recoverability earns its cost where vendor loss would interrupt an important service, breach a regulatory expectation, or force an emergency engineering programme.

The one question to put to any escrow arrangement you already hold: Has anyone outside the vendor ever compiled and run the deposited code? If the answer is no, the arrangement has never been tested, and the first test will be the day it is needed.