Om de continuïteit van de automatisering binnen bedrijven te waarborgen wordt vaak gebruik gemaakt van een escrow. De escrow is bedoeld om de gebruiker van de software te verzekeren van het ononderbroken gebruik van bedrijfskritische software, als de leverancier om welke reden dan ook, niet meer kan leveren.

In een escrowovereenkomst wordt vastgelegd dat een kopie van de broncodes en documentatie van de software door een derde partij in bewaring worden genomen. Op het moment dat de softwareleverancier onverhoopt niet aan haar verplichtingen kan voldoen (bijvoorbeeld in geval van faillissement), zorgt de escrowagent ervoor dat de broncodes en documentatie van de applicatie worden vrijgegeven aan de gebruiker. Ik bespreek hier een paar aandachtpunten waar je even bij stil moet staan voordat je een escrowovereenkomst afsluit.

Praktische uitvoering

Een escrowregeling wordt vaak als juridische methode beschouwd om de bedrijfscontinuïteit te regelen. Vergeten wordt dat een escrow ook een hele praktische kant heeft. De broncode en documentatie die in escrow ligt, moet namelijk ook worden gecontroleerd op bruikbaarheid. Klopt de documentatie bij de broncode (documentatie bij software is niet zelden een onderwerp dat meer aandacht nodig heeft)? Is de software en de documentatie bruikbaar voor het doel waarvoor het in escrow is gelegd? Deze controle moet met enige regelmaat worden uitgevoegd om ervoor te zorgen dat het ook echt bruikbaar is op het moment dat het nodig is.

Voorwaarden voor de escrow

Maak goede afspraken over de voorwaarden waaronder de escrow kan worden ingezet en de broncodes moeten worden afgegeven. Wat gebeurt er als er een conflict is op het moment dat er ook een calamiteit is op grond waarvan de organisatie de escrow wil inzetten? Zijn de afspraken in de escrow niet in conflict met de afspraken die zijn opgenomen in de licentieovereenkomst of de Service Level Agreement. Welke afspraken gelden er voor de opzegging van de escrow en hoe wordt gegarandeerd dat dat organisatie niet ineens zonder het vangnet van de escrow zit.

Intellectueel eigendomsrecht

Om gebruik te kunnen maken van de escrow in bijvoorbeeld een faillissementsituatie van de leverancier zul je ook licentierechten moeten hebben. Zonder die licentierechten mag je immers geen gebruik maken van de software. De leverancier is vaak niet de rechthebbende op het auteursrecht op de software. Meestal wordt dat ondergebracht in een holding. Een escrow aangaan met de werkmaatschappij is dan weinig zinvol. De escrowovereenkomst moet worden aangegaan met de holding, als partij die over de intellectuele eigendom kan beschikken.

Escrow voor clouddiensten is niet voldoende

Steeds meer bedrijven stappen over op clouddiensten. Een clouddienst bestaat uit meer dan alleen software. De software wordt als dienst aangeboden en draait op de servers van de leverancier of bij een externe hostingpartij. Wanneer de hostingpartij uitvalt, is de toegang tot de software verbroken. Je hebt dan niets aan alleen een broncode. Er zal dan een nieuwe hostingomgeving moeten worden ingericht. Er gaat dan heel veel tijd overheen, voordat de dienst weer operationeel is. Daarnaast zijn er ook maatregelen nodig om de beschikbaarheid van de data te organiseren. Want ook die data bevinden zich niet op de systemen van de organisatie maar op de systemen van de leverancier. Een escrowregeling waarbij uitsluitend de broncode wordt afgegeven is dus niet voldoende om continuïteit te garanderen als de organisatie gebruik maakt van clouddiensten.

Conclusie

Een escrowovereenkomst kan een goede methode zijn om de beschikbaarheid van de software te garanderen, maar kijk goed of de escrowovereenkomst voldoende is om de continuïteit te garanderen, want in het geval van clouddiensten is de escrow alleen niet voldoende.