Een software escrow contract is een regeling waarbij een onafhankelijke partij broncode, build-instructies en documentatie van software in bewaring houdt, zodat je de software kunt blijven gebruiken als de leverancier wegvalt. De clausule opstellen is stap één. De verplichtingen eromheen bewaken is wat de regeling bruikbaar maakt. Gebeurt dat niet, dan heb je schijnzekerheid: een contractregel die faalt op het moment dat je hem nodig hebt.
Je hebt escrow geregeld. De clausule staat netjes in het softwarecontract: bij faillissement van de leverancier krijg je toegang tot de broncode. Zekerheid, denk je. Tot iemand vraagt wanneer dat depot voor het laatst is bijgewerkt. En dan wordt het stil.
Een escrowclausule is geen continuïteitsgarantie
De clausule staat vaak in een contract uit 2019. De software is sindsdien vier keer major geüpdatet. Het depot bevat een versie die niemand meer kan draaien. De inkoper die de escrow ooit regelde werkt er niet meer. Niemand merkt dit, tot de leverancier failliet gaat en je de broncode opvraagt die je niet meer kunt compileren.
Dat is het gat waar de meeste organisaties in vallen. De juridische bronnen behandelen uitgebreid hoe je de clausule opstelt: vrijgave-events, IE-structuur, aansluiting met de licentie. Over wat daarna gebeurt schrijft bijna niemand. En juist daar zit het risico. Een software escrow contract werkt alleen als de verplichtingen eromheen een eigenaar, een termijn en een status hebben.
Wat hoort er in een bruikbaar depot en waarom veroudert dat?
Een broncodekopie is niet genoeg. Om de software daadwerkelijk te kunnen draaien, moet het depot compleet en actueel zijn. ICTRecht noemt in zijn aandachtspunten voor escrow expliciet de actualiteit van het depot en de aansluiting tussen escrow, licentie en SLA.
Een werkend depot bevat minimaal:
- De actuele broncode, niet een versie van drie releases terug
- Build- en installatie-instructies waarmee een derde de software kan compileren
- Een overzicht van afhankelijkheden en third-party componenten
- Geldige licentiesleutels en certificaten
- Technische documentatie en configuratie
Elk van deze onderdelen veroudert. Een afhankelijkheid die uit de markt verdwijnt, een licentiesleutel die verloopt, een build-instructie die achterloopt op de huidige versie: stuk voor stuk maken ze het depot waardeloos op het moment van vrijgave. Een oude broncodekopie die niemand kan draaien is geen continuïteit.
De verplichtingen die niemand bewaakt
Escrow is geen eenmalige juridische check maar een set terugkerende acties. Dit zijn de verplichtingen die na ondertekening vrijwel altijd verdampen:
- De jaarlijkse verificatie van het depot door de escrow-agent
- Een broncode-update bij elke nieuwe release van de leverancier
- Een hertest bij elke majeure versie, zodat de build nog klopt
- Een actualiteitscheck van afhankelijkheden en licentiesleutels
- Het herbevestigen van de exit-afspraken bij elke contractverlenging
Bij een aanbesteding is escrow vaak een gunningseis. PIANOo adviseert een escrowregeling expliciet bij maatwerkprogrammatuur, voor gevallen als faillissement, overname of het niet nakomen van onderhoudsafspraken. Maar na gunning verdwijnt de opvolging. Het vinkje is gezet, de verplichting leeft nergens meer. Hij staat in een PDF op een netwerkschijf, zonder reminder, zonder eigenaar. Dat is precies het verschil tussen een clausule hebben en grip krijgen op het continuïteitsrisico.
SaaS-escrow: broncode alleen is niet genoeg
De meeste ICT-contracten zijn tegenwoordig cloud of SaaS. En daar wordt het complexer. “We hebben broncode-escrow” betekent weinig als de software draait in de cloud van de leverancier en jij geen manier hebt om hem zelf te draaien.
Bij SaaS-escrow regel je naast de broncode ook de deployment-procedure, de configuratie, een data-export in een bruikbaar formaat en exit-assistentie door de leverancier. Zonder die onderdelen heb je bij een faillissement wel de code, maar geen draaiende dienst en geen toegang tot je eigen data. Wie een SaaS-contract afsluit en denkt met klassieke broncode-escrow gedekt te zijn, zit op een verkeerd spoor. Leg bij cloudsoftware eerst de data-export en exit-assistentie vast, pas daarna de broncode.
De Cyberbeveiligingswet maakt bewaking aantoonbaar
De Cyberbeveiligingswet (Cbw), de Nederlandse invulling van NIS2, treedt op 15 augustus 2026 in werking, zonder algemene overgangstermijn. De wet is direct verplicht voor circa 8.000 tot 10.000 organisaties en vraagt aantoonbare beheersing van cyberrisico’s uit de leveranciersketen (bron: Staatsblad 2026, 189).
Escrow is precies zo’n maatregel om continuïteitsrisico’s uit de keten te beheersen. Maar de kern van de Cbw is aantoonbaarheid. Een escrowclausule zonder bewaking bewijst juist het tegenovergestelde van beheersing: je hebt een risico onderkend en er daarna niets mee gedaan. Je kunt niet laten zien dat het depot actueel is, wie de eigenaar is of wanneer de laatste verificatie plaatsvond.
GRIP maakt geen enkele organisatie Cbw-compliant en is geen cybersecurity- of compliancetool. GRIP geeft grip op de contractkant van die zorgplicht: welke leveranciers er zijn, welke continuïteitseisen in de uitbestede contracten staan en welke afspraken openstaan. GRIP werkt onder ISO 27001, met data-verwerking binnen Europa. Lees hoe NIS2 en contractmanagement samenhangen.
Escrow vastleggen als bewaakte actie
GRIP is contractmanagement-software voor leverancierscontracten van Nederlandse organisaties in zorg, onderwijs en publieke sector. De oplossing begint niet bij een strengere clausule, maar bij het omzetten van die clausule naar bewaakte acties met een eigenaar, een termijn en een status.
In het verschil tussen contractbeheer en contractmanagement zit precies dit onderscheid. Je ERP registreert dat je een escrowclausule hebt. In het Contract Dashboard van GRIP koppel je aan die clausule de jaarlijkse depot-verificatie als terugkerende actie, de broncode-update per release, de hertest bij majeure versies en de exit-check bij verlenging. Elke actie heeft een verantwoordelijke en een deadline. Gaat een leverancier failliet, dan heb je een objectief vrijgave-event en een depot waarvan je weet dat het klopt.
Veelgestelde vragen
Wat is een software escrow contract?
Een software escrow contract regelt dat een onafhankelijke partij de broncode, build-instructies en documentatie van software in bewaring houdt. Valt de leverancier weg, bijvoorbeeld door faillissement, dan krijg je toegang tot het depot zodat je de software kunt blijven gebruiken of onderhouden.
Wanneer is software-escrow verplicht?
Escrow is zelden wettelijk verplicht, maar PIANOo adviseert het expliciet bij maatwerkprogrammatuur in aanbestedingen. In de praktijk wordt het vaak als gunningseis opgenomen bij bedrijfskritische software waarvan de continuïteit essentieel is.
Waarom is een escrowclausule zonder bewaking een risico?
Een depot veroudert. Na meerdere releases bevat het een versie die niemand meer kan draaien, met verlopen licentiesleutels of ontbrekende afhankelijkheden. Zonder jaarlijkse verificatie en updates heb je schijnzekerheid: de clausule faalt precies op het moment dat je hem nodig hebt.
Wat is het verschil tussen software-escrow en SaaS-escrow?
Bij klassieke escrow bewaar je broncode en documentatie. Bij SaaS-escrow heb je daarnaast de deployment-procedure, configuratie, data-export en exit-assistentie nodig. De software draait immers in de cloud van de leverancier, dus broncode alleen levert geen draaiende dienst op.
Welke vrijgave-events horen in een escrowregeling?
Objectieve en controleerbare gebeurtenissen: faillissement of surseance van de leverancier, het staken van het onderhoud, of het niet herstellen van kritieke fouten binnen een afgesproken termijn. Objectieve events voorkomen discussie over wanneer je toegang tot het depot krijgt.
Hoe helpt de Cyberbeveiligingswet bij het aantonen van continuïteit?
De Cbw (in werking 15 augustus 2026) vraagt aantoonbare beheersing van continuïteitsrisico’s uit de leveranciersketen. Een bewaakte escrowregeling met een actueel depot en een gedocumenteerde eigenaar helpt die aantoonbaarheid. Een niet-bewaakte clausule doet het tegenovergestelde.
Hoe leg je escrow-verplichtingen vast als bewaakte actie?
Zet de terugkerende verplichtingen, zoals jaarlijkse verificatie, broncode-update per release en exit-check bij verlenging, in een contractdashboard met eigenaar, termijn en status. Zo wordt escrow een opvolgbare afspraak in plaats van een vergeten clausule in een PDF.
Wil je weten wanneer jouw escrowdepot voor het laatst is geverifieerd? Bekijk hoe GRIP dit oplost of boek een demo van het Contract Dashboard.