SaaS Escrow
Everything Escrow covers, plus what it takes to stand the application up somewhere else: deployment assets, configuration and dependency information.
Protection scope:Hosted applications
What is deposited
Everything on the Escrow list
- The program code itself, with its version history, branches and tags
- Build scripts and the build, packaging and deployment configuration, including the toolchain
- Every library and dependency needed to build and run, with the complete dependency manifests
- Build documentation good enough that nobody has to call you to use it
- Interface definitions, data model structures and database access descriptions
- Configuration files, environment variables, encryption methods, and credentials, keys and certificates listed by designation, purpose and location
- The register of third-party components with their licenses
- System documentation: architecture, data flows, network topology, operations manual
Plus, for a hosted application
- Install, deployment and migration scripts
- Architecture and API documentation, and the integrations the service depends on
- Dependency versions and license information for the hosted stack
- Operating, backup, recovery and monitoring procedures
- Instructions for recreating or rotating production secrets — the secrets themselves are never deposited
We pull read-only from your repository, so everything on that list has to live in the repository. Runbooks included. That is a planning point, not a detail.
How it comes back out
- 01
A trigger event occurs — insolvency, liquidation, the end of support, an uncured material breach.
- 02
Your customer applies, with a court or register document, or with evidence.
- 03
For register facts we release within seven business days, with no objection procedure. For contestable grounds you have fourteen days to object, and a court-certified IT expert decides.
- 04
The deposit is handed over with its checksums, and the license your contract provides takes effect at that moment.
What we owe — and what we don't
We owe
- The pull at the agreed frequency
- Encrypted storage at the agreed location, inside the EEA only
- A checksum over each package and each file
- A dated record of every pull to both parties
- The notices
- Running the release procedure to the letter
We do not owe
- That the material is complete, correct, current or authentic
- That it builds, runs or is free of defects or malware
- That it fits the purpose the beneficiary has in mind
- That third-party rights in it exist or are transferable
Every escrow agent's terms say this. Most of them say it on page nine. It is the whole reason Verification exists as a product you can buy.
About VerificationWho it is for
An application you host and your customer depends on. If their continuity plan says 'we would run it ourselves', this is what makes that sentence true.
What it is not
From €200 per month
Single, Multi and All plans, the setup fee and the add-ons are on the pricing page.
FAQ
Common questions.
Are production secrets deposited?
No, never. What is deposited is how to recreate or rotate them. The secrets themselves stay with you.
Our runbooks live in a wiki. Is that a problem?
It is a planning point. We pull read-only from your repository, so whatever is not in the repository is not in the deposit. Move the runbooks there, or export them there on a schedule.
Does a deposit prove that the material works?
No. The checksum proves that what was transferred arrived intact — nothing about completeness or whether it runs. Whether a deposit can be built and deployed is a separate test, ordered as the Certified add-on.