Everything you need to know about provable trust

Release is governed by the escrow agreement and typically occurs on defined events such as the vendor’s insolvency, discontinuation of support, breach of contract, or acquisition by a third party. Castler verifies the deposited release before confirming it can be rebuilt and run independently.

A deposit typically includes source code, build scripts, configuration files, deployment documentation, and in some arrangements, a software bill of materials (SBOM). The exact contents are defined in the escrow agreement based on what is needed to independently rebuild the application.

Regulators such as the UK PRA, RBI, and frameworks like DORA increasingly expect financial institutions to demonstrate exit strategies and operational resilience for critical third-party technology. Verified software escrow arrangements can serve as supporting evidence during regulatory audits and vendor-risk assessments.

Traditional software escrow applies to on-premise or self-hosted applications where source code is deposited. SaaS escrow addresses cloud-hosted applications, where recoverability depends on additional elements such as data, infrastructure configuration, and deployment pipelines beyond just code.

An SBOM is a structured inventory of all components, libraries, and dependencies used to build a software application. In an escrow context, it helps verify exactly what is needed to rebuild the software and identifies any third-party or open-source dependencies that could affect recovery.

Yes. A software escrow agreement is a legally binding, typically tri-party contract between the vendor, the customer, and the escrow agent, setting out deposit obligations, release conditions, and verification terms. Enforceability depends on the agreement being properly drafted and signed by all parties.

Castler’s engineers rebuild and deploy the deposited release in a controlled environment and document the outcome through artifacts such as build reports, deployment runbooks, and replication reports. This evidence-based approach differs from traditional escrow, which typically holds code without testing whether it can be recovered.

If the release conditions in the escrow agreement are met, the customer can request release of the deposited materials. With a verified recoverability arrangement, the customer also has documented evidence that the recovered software can actually be rebuilt and run, reducing the risk of an unusable deposit.

Verification timelines depend on the complexity of the deposited software and the engagement stage. Castler’s process typically ranges from a few hours for an initial integrity check to several weeks for a full rebuild-and-replication verification, depending on the scope agreed with the customer.

Events such as the Synapse bankruptcy, the CrowdStrike outage, and the Jaguar Land Rover IT disruption showed how quickly a vendor failure or software fault can disrupt dependent businesses. These incidents are commonly cited examples of why verified recoverability, not just stored code, matters.

Verification can range from a basic integrity check (confirming the deposit is complete and readable) to a full build verification (confirming the software compiles and runs) to a complete replication test (confirming it can be deployed and operated in a production-like environment). Each level provides a different degree of assurance.

Pricing depends on factors such as the number of applications, verification level required, and deposit update frequency. Enterprises typically discuss pricing directly with Castler’s team based on their specific technology stack and compliance requirements.

Yes. Castler’s platform is designed to support both traditional on-premise software deposits and SaaS/cloud-hosted applications, with verification steps adapted to each deployment type.

Software Recoverability is the ability to independently rebuild, deploy, and run critical vendor software when the original vendor is unavailable. Castler turns that ability into a repeatable process and a signed Proof of Recovery. Learn more →

Traditional escrow primarily stores source code and documentation under a legal agreement. Castler goes further: it maps dependencies, rebuilds the release, deploys it, replicates the declared architecture, and has a named engineer sign the result. Learn more →

A Proof of Recovery is a signed, numbered artefact showing that a specific software release was independently rebuilt, re-deployed, and verified. It is evidence your board, regulator, auditor, insurer, or customer can examine. Learn more →

Castler’s model is designed around verification per release, so the evidence changes as the software changes instead of becoming stale between annual exercises. Learn more →

No. Initial access, source materials, dependencies, and technical documentation must be established correctly, but the verification itself is designed to prove recovery without relying on the vendor being available. Learn more →

Castler is designed to complete verification in hours rather than the multi-week cycles associated with traditional manual exercises. The exact cycle depends on the application and its dependencies. Learn more →

The signed record is backed by the build outcome, deployment procedure, architecture replication, test results, release details, and the named engineer’s seal. Learn more →

That is the platform’s design goal. Agentic verification turns a bespoke exercise for a few vendors into a repeatable operating model for every critical application in the Software Estate. Learn more →

The new release can be captured and re-verified so the Proof of Recovery stays aligned with the software that is actually in use. Learn more →

Verification can run in the selected cloud and region, with role-based access and an auditable record of the recovery workflow. Learn more →

Castler maps build, deployment, replication, testing, and signed recovery evidence to the operational-resilience themes in frameworks such as DORA, PRA SS2/21, APRA CPS 230, MAS TRM, RBI, SEBI, and IRDAI. These mappings are orientation, not legal advice. Learn more →

Verification can run in the cloud and region selected for the deployment. Castler’s trust-centre materials describe regional hosting, role-based access, encryption, and immutable audit trails. Learn more →

Castler’s site references ISO 27001, SOC 2 Type II, and PCI DSS. The Trust Center is the source for the current security and compliance package. Learn more →

No. Castler maps its evidence to relevant regulatory themes, but those summaries are for orientation only and do not replace official texts or professional legal and compliance advice. Learn more →