Als inkoper of contractmanager kom je vroeg of laat bij de vraag ‘welke escrow sluit aan bij onze vraag?’. Het antwoord is niet altijd even duidelijk, want de meeste partijen bieden een formulier of een leadmagneet, maar geen inhoudelijke basis waarop je intern kunt afstemmen met je juridische, IT- en inkoopafdeling.
Op deze pagina vind je precies dat. We bundelen de beschikbare templates en de voorbeeld overeenkomst generator van Escrow4all, leggen per type escrow uit welke clausules je moet aanpassen, en geven je een keuzehulp zodat je met het juiste template begint. Houd er rekening mee dat een voorbeeldcontract altijd een startpunt is: bij bedrijfskritische systemen laat je het resultaat altijd reviewen door een jurist of contractmanager.
Welke escrow heb je nodig: Software, SaaS of Data?
Voordat je een template kiest, is het handig om te weten welk type escrow past bij jouw situatie. De drie varianten verschillen in scope, in wat er gedeponeerd wordt en in welke afgifte-triggers logisch zijn.
Software Escrow (on-premise / traditioneel) Hier wordt de broncode van een softwareapplicatie gedeponeerd bij een onafhankelijke escrow-agent. De software draait op servers van de gebruiker of in een omgeving die de gebruiker beheert. Kies Software Escrow als je een licentie hebt op een applicatie die lokaal geïnstalleerd is, of waarbij de leverancier de broncode beheert maar jij afhankelijk bent van onderhoud en updates. Meer achtergrond over de werking lees je op de pagina over Software Escrow oplossingen.
SaaS Escrow (hosted / cloud) Bij SaaS-applicaties draait de software bij de leverancier of bij een hostingprovider. Naast de broncode zijn ook de cloudomgeving, configuraties, data en migratie-instructies relevant. Escrow4all werkt voor SaaS Escrow samen met meer dan 75 hostingproviders. Kies SaaS Escrow als jouw applicatie als dienst wordt afgenomen en je geen directe toegang hebt tot de onderliggende infrastructuur. Zie ook de pagina over SaaS Escrow oplossingen voor de specifieke aanpak.
Data Escrow Data Escrow richt zich uitsluitend op de data zelf, los van de applicatiecode. Denk aan periodieke back-ups van databases, API-data of gestructureerde datasets die cruciaal zijn voor je bedrijfsvoering. Kies Data Escrow als de continuïteit van jouw processen afhangt van toegang tot specifieke datasets, ook als je de applicatie zelf zou kunnen vervangen. De Registry Data Escrow variant is daarnaast verplicht gesteld door ICANN voor domeinregistrars.
Twijfel je welke variant het beste past? De pagina welke Digital Escrow oplossing kiezen helpt je verder met een vergelijking.
Voorbeeldcontracten en templates: hoe je ze aanvraagt
De voorbeeld overeenkomst generator
De meest praktische aanpak is de voorbeeld overeenkomsten generator in het Knowledge Center. Via een korte intake genereert de tool een op maat gemaakt concept-overeenkomst op basis van jouw situatie: type escrow, partijen en de gewenste scope. Dit is een stuk sneller dan een generiek template helemaal zelf invullen, zeker als je nog niet precies weet welke clausules voor jouw context relevant zijn.
De generator is beschikbaar via:
Externe templates als aanvullende referentie
Wil je ook andere basistemplates inzien om te vergelijken, dan zijn er vrij beschikbare opties. Escrow London publiceert een “Software Escrow Agreement Template” als PDF (april 2023-versie, multi-beneficiary). Business in a Box biedt zowel een “Software Escrow Agreement Template” als een “Source Code Escrow Agreement Template” als gratis Word-bestand. Deze zijn nuttig als referentie, maar houd in gedachten dat ze niet zijn afgestemd op de Nederlandse context of op de werkwijze van een ISO 27001-gecertificeerde escrow-agent.
Belangrijke clausules: wat staat er in een software escrow overeenkomst?
Zodra je een template in handen hebt, wil je snel begrijpen welke onderdelen kritiek zijn en wat je zelf moet invullen of aanpassen. Hieronder een overzicht per clausule-categorie.
Partijen en rollen
Een software escrow overeenkomst kent drie partijen:
- Depositor / leverancier: de softwareontwikkelaar die de broncode en bijbehorend materiaal deponeert.
- Beneficiary / licentienemer: de organisatie die de software gebruikt en baat heeft bij de bescherming.
- Escrow-agent: de onafhankelijke derde partij die het depot beheert, bewaart en vrijgeeft. Meer over de rol lees je op de pagina wat is een escrow-agent.
Zorg dat alle drie partijen in het contract correct zijn benoemd, inclusief hun juridische entiteit en vestigingsadres.
Depotmateriaal
Dit is een van de meest onderschatte onderdelen. Leg zo precies mogelijk vast wat er gedeponeerd wordt:
- Volledige broncode (inclusief alle versies die in productie draaien)
- Build scripts en compilatie-instructies
- Technische documentatie en installatiehandleidingen
- Configuratiebestanden en omgevingsvariabelen
- Voor SaaS: cloudomgeving-configuraties, containerbestanden, migratie-scripts
Variatie in wat er gedeponeerd wordt is een veelvoorkomend knelpunt bij verificaties. De verificaties-pagina legt uit hoe Escrow4all de kwaliteit en compleetheid van het depot beoordeelt.
Afgifte-triggers
Expliciete afgifte-triggers zijn het hart van de overeenkomst. Vage formuleringen als “als de leverancier zijn verplichtingen niet nakomt” zijn juridisch kwetsbaar. Definieer concrete events, zoals:
- Faillissement of surseance van betaling van de leverancier
- Stopzetting van onderhoud en support zonder opvolger
- Overname waarbij de nieuwe eigenaar de overeenkomst niet overneemt
- Langdurige niet-beschikbaarheid (bijv. meer dan X aaneengesloten werkdagen)
- Contractbreuk die niet binnen een afgesproken termijn is hersteld
Voor elk event is het verstandig ook te beschrijven welk bewijs nodig is voordat de escrow-agent tot afgifte overgaat.
Verificatie en onderhoudsverplichting
Een escrow-overeenkomst zonder verificatieafspraken is een papieren tijger. Leg vast:
- Hoe vaak de leverancier het depot bijwerkt (bijv. bij elke productierelease of minimaal kwartaals)
- Welk type verificatie er plaatsvindt (formeel, functioneel of uitgebreide tests)
- Wie de kosten van verificatie draagt
Escrow4all is ISO 27001-gecertificeerde en in staat om zowel formele als diepgaande technische verificaties uit te voeren.
Gebruik na afgifte
Omschrijf helder wat de beneficiary mag doen met het materiaal nadat het is vrijgegeven:
- Intern gebruik voor herstel en continuïteit: ja, altijd
- Inschakelen van een andere partij voor onderhoud: vaak toegestaan, maar specificeer dit expliciet
- Commercieel doorontwikkelen of distribueren: vrijwel altijd uitgesloten
- Tijdsduur van het gebruik na afgifte: stel een redelijke termijn vast
Escrow-agent verplichtingen
De escrow-agent is contractueel gehouden aan:
- Veilig bewaren van het depot (bij Escrow4all conform ISO 27001)
- Afgifte uitsluitend bij een vastgesteld en getoetst trigger-event
- Vertrouwelijkheid van het gedeponeerde materiaal
- Neutrale positie: de agent oordeelt niet over de inhoud van een geschil, maar toetst of het afgifte-verzoek aan de contractuele criteria voldoet
Gebruikstips: wanneer welk template kiezen?
Voor leveranciers die willen standaardiseren Start met de overeenkomst-generator van Escrow4all en pas de voorgestelde depotfrequentie en trigger-events aan op jouw releasecyclus. Als je meerdere klanten hebt die escrow verlangen, is het efficiënter om met een standaard basisovereenkomst te werken die je per klant alleen aanvult met specifieke afgifte-voorwaarden.
Voor inkopers die bedrijfscontinuïteit willen borgen Focus bij het doornemen van het template op de secties over release events, het bewijsmechanisme en de procedure bij een geschil over het al dan niet van toepassing zijn van een trigger. Dit zijn de secties waar in de praktijk de meeste discussie over ontstaat. De escrow-regeling pagina geeft je meer context over hoe zo’n regeling in zijn geheel werkt.
Voor de publieke sector of multi-country contracten Kies de taalvariant (NL of EN) die aansluit bij de primaire juridische context van het contract. Laat jurisdictie-specifieke onderdelen, zoals toepasselijk recht en forumkeuze, altijd afstemmen met een jurist die kennis heeft van de betreffende landen. Bij aanbestedingen geldt bovendien dat escrow soms contractueel verplicht is gesteld, zoals beschreven in de GIBIT-toelichting.
Versies en actueel houden
Templates verouderen. De meest voorkomende redenen om een escrow overeenkomst te herzien zijn:
- Nieuwe technologie bij de leverancier (migratie naar cloud of microservices)
- Gewijzigde wet- en regelgeving (denk aan NIS2 of DORA)
- Aanpassing van de trigger-events op basis van opgedane ervaringen
- Nieuwe verificatiemethoden die in het contract worden vastgelegd
Escrow4all verwerkt relevante updates in de overeenkomst-generator zodra deze beschikbaar zijn. Controleer bij elk nieuw contract of je de meest recente versie van het template gebruikt. Heb je een bestaande overeenkomst die al een aantal jaar oud is? Dan is het verstandig om die eens naast een actueel concept te leggen.
Meer weten?
Over digital escrow oplossingen?
Of heb je een andere vraag?
Neem dan met ons contact op.