Een cloudescrow of niet?

M. Korpershoek, 'Een cloudescrow of niet?', eerder verschenen in Automatiseringsgids 10'12.

Regelmatig blijkt de escrow waardeloos te zijn vanwege juridische en/of technische mankementen.

Als een leverancier failliet gaat, kan een escrowregeling uitkomst bieden. Maar in veel gevallen zijn die regelingen waardeloos, zegt Marianne Korpershoek. Bij het toepassen van cloudcomputing nemen de problemen alleen maar toe. Afnemers hebben meer tijd nodig om goede keuzes te maken. Bovendien is het de vraag of een goede cloudescrow wel te betalen is.

Software is de afgelopen dertig à veertig jaar onontbeerlijk geworden voor de bedrijfsvoering. In die jaren is ook gezocht naar oplossingen om ervoor te zorgen dat een bedrijf door kan blijven werken met de bestaande systemen wanneer zijn leverancier failliet gaat of gewoon stopt. De oplossing wordt gevonden in een zogenaamde escrowovereenkomst. Wat alleen vaak wordt vergeten is dat zo’n overeenkomst bestaat in vele vormen. Regelmatig blijkt de escrow waardeloos te zijn omdat er sprake is van juridische en/of technische mankementen. Ook is vaak helemaal niet duidelijk of de gewenste continuïteit mogelijk of financieel haalbaar is. Ten slotte gaan steeds meer bedrijven over op het gebruik van applicaties in de cloud. Bij het gebruik van cloudcomputing biedt traditionele escrow niet voldoende soelaas en is het de vraag of goede cloudescrow wel te betalen is. In het schema worden de verschillende vormen van cloudescrow genoemd. Maar eerst, in het kort, iets over escrow in zijn kale vorm en een aantal handvatten om te bepalen of en welke vorm van escrow nodig is.

Handen vol geld
Zoals gezegd wil een afnemer een escrowregeling om de continuïteit van zijn applicaties te garanderen bij faillissement van zijn leverancier. Wanneer de leverancier zijn broncode en documentatie aan al zijn afnemers zou geven dan zou continuïteit geen groot issue zijn. Met broncode en documentatie kunnen ook andere bedrijven de software onderhouden. In de broncode en documentatie zit echter wel alle know-how van de leverancier. Het is dus heel begrijpelijk dat zij niet zo maar aan de afnemer worden verstrekt.

Escrow is in zijn meest basale vorm een depot van de broncode van software, meestal buiten de macht van de eigenaar van die software, vergezeld van een overeenkomst die het gebruik en de aanpassing van de software regelt mocht de eigenaar failliet gaan. Een dvd of een usb-stick met de broncode in een verzegelde envelop in de kluis van een notaris, heet al vaak een escrow. Omdat er in geen enkele wet ook maar iets geregeld is over software-escrow moet de afnemer er maar op vertrouwen dat hij ook echt iets heeft aan de escrowregeling. Iedereen mag zich escrowagent noemen. De afnemers van escrowdiensten zullen zelf moeten controleren of die agent ook de verwachte continuïteit kan garanderen. Wanneer de escrow niet goed geregeld is, ontstaan er bij het faillissement allerlei problemen. De broncode die op de drager staat blijkt niet te compileren tot een executable. De broncode is niet of slecht gedocumenteerd zodat onderhoud niet mogelijk is. Of de broncode blijkt niet up-to-date.

Bij cloudcomputing zijn de problemen nog groter. Niet alleen de escrowovereenkomst dient alle juridische problemen te tackelen, er moeten ook allerlei technische maatregelen worden genomen. Ook al is de broncode helemaal in orde, een systeem volledig inrichten met alle relevante applicaties en data is een ander verhaal. Dat kan veel tijd in beslag nemen en wanneer je volledig afhankelijk bent van de cloud, heb je die tijd vaak niet. Dat is op te lossen door met twee volledig gesynchroniseerde systemen te werken, maar dat kost vaak handen vol geld.

Daarom dienen er met het oog op de kosten, goede keuzes gemaakt te worden bij het afsluiten van een cloudescrow. Nog meer dan voor de traditionele escrow geldt, moet de afnemer goed nadenken wat de risico’s zijn voor zijn bedrijf bij het faillissement van zijn cloudleverancier. Als je gekozen hebt voor een leverancier met een SLA die maximale continuïteit eist, dan moet je je afvragen of en hoe deze SLA gegarandeerd kan worden wanneer de leverancier failliet gaat. Wanneer het noodzakelijk is voor de bedrijfscontinuïteit dan betekent dat dat het uitonderhandelen van de cloudovereenkomst net zoveel tijd in beslag zal nemen als het uitonderhandelen van de SLA.

Een andere mogelijkheid is dat de afnemer zich afvraagt of een plan B mogelijk is. Bijvoorbeeld wanneer het bedrijfsproces in de cloud redelijk snel ergens anders of op eigen systemen ondergebracht kan worden. De gebruikte data moeten dan wel redelijk makkelijk op andere applicaties verwerkt kunnen worden. Dan is het zaak om plan B goed in te richten, te testen en ervoor te zorgen dat de data die ondergebracht zijn in de cloud regelmatig teruggeleverd worden. Uiteraard is het raadzaam dat er zo nu en dan een ‘ontruimingsoefening’ wordt gedaan om te checken of het systeem werkt.

Voor een leverancier kan het een unique selling point zijn, wanneer hij niet alleen een goede SLA heeft, maar afnemers ook kunnen kiezen voor een op hun behoeften toegesneden cloudescrow.

Kiezen
Zolang er geen goede wettelijke regeling is voor de rechten van de afnemer bij het faillissement van zijn software- of cloudleverancier of er geen goede geaccepteerde standaarden zijn ontwikkeld, is het van belang om bij de keuze voor een bepaalde oplossing ook de gewenste continuïteit bij het failliet gaan van de leverancier mee te nemen. Als de belangen groot zijn, zullen er bij het maken van een keuze al snel een softwareconsultant en jurist betrokken moeten worden.

Voordat een afnemer kiest voor een bepaald systeem moet hij zich afvragen wat de risico’s zijn wanneer de leverancier van het systeem failliet gaat. Ligt het bedrijf dan volledig plat? Of is er tijd om oplossingen te vinden door bijvoorbeeld voor andere systemen en/of applicaties te kiezen of door de systemen door andere leveranciers te laten onderhouden. Wanneer de risico’s groot zijn, is het van het grootste belang dat er veel aandacht wordt besteed aan de continuïteit, zowel op technisch, organisatorisch als juridisch vlak. Een goede oplossing die continuïteit op de korte termijn garandeert zal tijd en een forse investering vergen. Wanneer de risico’s klein zijn kun je je afvragen of een escrowregeling wel nodig is. Het kan al voldoende zijn om ervoor te zorgen dat de data bijvoorbeeld in een regelmatige backup in een gemakkelijk porteerbaar formaat snel weer voor handen zijn.

Wanneer een leverancier een escrowregeling aanbiedt is het belangrijk helder te krijgen wat de escrow betekent bij faillissement. Soms zijn escrowregelingen optioneel. Het is belangrijk je af te vragen of de leverancier wel waar voor zijn geld biedt. Wanneer een escrowregeling onderdeel is van het totaalpakket, is het van belang om je af te vragen of de regeling voldoende is. Wanneer het gaat om belangrijke bedrijfsprocessen die in de cloud ondergebracht worden, is het zaak om de bestaande escrowregeling van de leverancier kritisch, zowel juridisch als technisch, tegen het licht te houden.