Cloud computing en het risico van faillissement (Timelex)

Auteurs: Stefan van Camp en Liesa Boghaert (Timelex)

Het risico van stopzetting of faillissement

De verschillende vormen van cloud computing, en in het bijzonder SaaS, zijn het afgelopen decennium doorgebroken als betrouwbare diensten voor de aanlevering van bedrijfskritische software. ERP software en hooggespecialiseerde software die een stevige impact kan hebben op de bedrijfsvoering van de klant, worden zonder drempelvrees op afstand gebruikt.

Verleners van cloud diensten, en in het bijzonder SaaS providers, zijn soms start-ups of scale-ups met een onzekere toekomst. Ze zijn vaak afhankelijk van investeerders, en het kan jaren duren voor ze een gevestigde portefeuille van klanten hebben opgebouwd. Er kan dus jarenlang een risico bestaan van stopzetting van de activiteiten, vereffening of faillissement. Het is bijgevolg duidelijk dat de discontinuïteit van de dienstverlening een groot risico vormt voor hun klanten, des te meer wanneer de bedrijfsactiviteit van deze klanten sterk afhankelijk is van de aangeleverde software. In geval van stopzetting, vereffening of faillissement moet de klant hopen op een snelle overname en voortzetting van de activiteit door een derde. Indien dat niet lukt, zal de klant zelf een alternatieve software oplossing moeten vinden. Hij zal de markt moeten bevragen, een overeenkomst moeten onderhandelen, een alternatieve oplossing implementeren en de data uit de bestaande software moeten migreren. Afhankelijk van de specifieke noodwendigheden van de klant en de complexiteit van de nieuwe implementatie kan dit maanden tot zelfs jaren in beslag nemen. Ondertussen moet de klant echter een mogelijkheid vinden om voorlopig, gedurende een voldoende lange overgangsperiode, de bestaande software verder te gebruiken.

Wanneer een SaaS aanbieder zijn activiteit stopzet en overgaat tot vereffening, kan deze zelf opteren om de dienstverlening op korte of lange termijn stop te zetten. Soms wordt de beslissing tot stopzetting echter ook door een derde genomen. Een SaaS provider doet immers meestal beroep op een hosting provider om de aangeboden software te hosten. Deze host kan een van de grote spelers zijn, zoals AWS, Azure of Google, maar kan evenzeer een kleinere uitbater van een datacenter zijn. In de contracten met zulke hosting providers wordt standaard opgenomen dat de host de overeenkomst kan beëindigen in geval van faillissement, vereffening, stopzetting van activiteit, en zelfs reeds vroeger, bij symptomen van insolvabiliteit. In geval van betalingsmoeilijkheden kan de host de hosting dus opschorten of stopzetten, waardoor automatisch de SaaS dienstverlening wordt stopgezet. In geval van faillissement van een SaaS provider heeft de curator die wordt aangesteld om het faillissement af te wikkelen de macht om te beslissen over de verdere uitvoering van de contracten met het cliënteel en met de host. Wanneer het voor de afwikkeling van het faillissement noodzakelijk is, kan de curator immers beslissen om een overeenkomst stop te zetten of gewoon niet verder uit te voeren (artikel XX.139 WER). Hij kan dat bijvoorbeeld doen in het belang van de schuldeisers wanneer de dienst verlieslatend is en er geen zicht is op een spoedige overname. De klanten kunnen dan geen voortzetting van hun contract eisen. Ze hebben eventueel wel een claim tot schadevergoeding, maar meestal zal die weinig opleveren.

Hoe dan ook is het voor klanten die bedrijfskritische software afnemen absoluut belangrijk om de continuïteit van het gebruik van de software te kunnen garanderen, minstens gedurende een overgangsperiode die lang genoeg is om een ordentelijke overgang naar een alternatief systeem te kunnen organiseren en de schade aan de bedrijfsvoering te beperken. Het is verder, voor zover mogelijk, ook aangewezen om het lot van de dienstverlening niet in handen te leggen van een curator. Een curator kan immers de intentie hebben om de software, meestal het enige actief van de gefailleerde, te verkopen aan een overnemer. Het lot van de bestaande klanten is ook dan onzeker. Door gebrek aan technische kennis van de curator kan er overigens veel tijd verloren gaan vooraleer hij meent dat hij de situatie voldoende begrepen heeft om de gepaste besluiten te nemen. Ondertussen verblijven de klanten echter wel in een precaire situatie. Een klant die afhankelijk is van SaaS moet dus de mogelijke risico’s van een stopzetting of een faillissement voorzien, zeker wanneer de SaaS provider economisch kwetsbaar is.

Escrow van broncode is weinig geschikt

In het verleden werd software voornamelijk als on-site software geïnstalleerd op computers of servers van de klant. Dit gebeurt nog steeds, maar meer en meer wordt software aangeboden in de cloud. In geval van faillissement van de licentiegever is de on-site software fysiek aanwezig en bereikbaar voor de klant. Indien de klant er voor kan zorgen dat een derde-dienstverlener of eventueel het eigen personeel onderhoud kan blijven voorzien aan de software, zoals de uitvoering van noodzakelijke aanpassingen en de correctie van bugs, kan de software gedurende een zekere tijd blijven draaien op het systeem van de klant, in afwachting van een overgang naar een nieuw systeem. Om zulk onderhoud te kunnen uitvoeren, moet de klant wel beschikken over de broncode van de software. De broncode is de leesbare en bewerkbare vorm van het computerprogramma.

In de praktijk werd het source code escrow systeem bedacht om een tijdelijke oplossing te bieden. Dit systeem houdt in dat er een tripartite bewaargevingsovereenkomst wordt gesloten tussen de klant, de licentiegever en een derde-bewaarnemer, de escrow agent. De escrow agent bewaart een versie van de broncode van de software, en zal deze vrijgeven aan de klant wanneer de “release” (ofwel vrijgevings-) voorwaarden die vermeld staan in het contract, zich voordoen. Faillissement of stopzetting van de activiteit zijn de voornaamste release voorwaarden. Belangrijk is ook dat de verplichting om de broncode vrij te geven een eigen verplichting van de escrow agent is, die niet kan verhinderd worden door de curator. De klant krijgt bij het source code escrow systeem het recht om zelf of met behulp van derden (eventueel ex-personeel van de gefailleerde) de software aan te passen en in stand te houden gedurende een periode die volstaat om op zoek te gaan naar alternatieve software. Het feit dat de klant beschikt over de broncode geeft in theorie een bepaalde autonomie aan de klant, waardoor de gevolgen van een faillissement verzacht kunnen worden (in zoverre het in de praktijk daadwerkelijk mogelijk is om met geschikte personen de software aan te passen).

De bijzondere problematiek van SaaS en cloud computing

In het kader van cloud computing zijn de gevolgen van stopzetting en faillissement nog drastischer dan bij on-premise applicaties. De software wordt immers online aangeboden en gehost in de cloud of in een privaat datacenter. Indien de hosting omgeving een multi-tenant omgeving is, worden de resources bovendien ook gedeeld met andere klanten. De klant beschikt daarentegen niet over de fysieke software, en kan die dus niet zomaar verder gebruiken, laat staan aanpassen.

Bovendien draait de software in een specifieke SaaS of PaaS omgeving, die zeer verschillend is van een on-premise omgeving. Zelfs wanneer de klant via een escrow systeem de broncode van de relevante programma’s zou verkrijgen, is de implementatie van de software een vrijwel onmogelijke opdracht. En zelfs indien dit laatste zou lukken, is er vaak al veel tijd voorbij gegaan, waarin de onderneming geen beroep kon doen op de software. Indien het om bedrijfskritische software gaat, kan dit resulteren in onherstelbare bedrijfsschade. Voor de verschillende vormen van cloud computing (SaaS, PaaS en managed services) biedt de escrow van broncode dus geen oplossing.

Hoewel de meeste ondernemingen het belang van de recuperatie van data (een ander belangrijk risico ingeval van stopzetting van de dienst) doorgaans wel goed kennen, lijken in België zowel de afnemers als de aanbieders van cloud oplossingen én de lokale escrow agenten zich nog te weinig bewust van de risico’s van een gehele discontinuïteit van het gebruik van de software zelf. In het buitenland wordt daarentegen al meer aandacht besteed aan dit risico en worden al een aantal min of meer creatieve oplossingen aangeboden.

Op zoek naar oplossingen

Gelet op de moeilijkheden van een migratie en on-premise implementatie van de relevante applicaties en de omgeving waarin deze ingebed zijn, moet de oplossing gevonden worden in ofwel een voortzetting van de bestaande configuratie bij de hosting provider, ofwel een snelle overschakeling naar een reserve-omgeving die elders wordt gehost, en die de live hosting-omgeving spiegelt.

1. Een reserve-omgeving bij een derde die de live-omgeving repliceert
   In onze praktijk hebben we opgemerkt dat sommige SaaS providers er in slagen om aan een aanvaardbare prijs een reserve-systeem op te zetten, dat gehost wordt bij een derde. Deze reserve-omgeving bevat bovendien ook de relevante broncode. In deze oplossing, wordt de live omgeving voortdurend naar de reserve-omgeving gerepliceerd. Met de derde wordt vervolgens een tripartite overeenkomst gesloten. Ingeval van stopzetting of faillissement van de SaaS provider zal deze derde als een eigen verplichting de reserve-omgeving vrijgeven aan de klant. Ook dit kan een curator niet verhinderen. De reserve-omgeving fungeert dus als het ware als een bescherming bij stopzetting of faillissement en kan eventueel ook dienst doen als failover-systeem ingeval een disaster de live-omgeving zou aantasten. Dit is aldus een eerste mogelijke oplossing, die echter voor een aantal klanten in de praktijk soms te duur blijkt.
2. Escrowing van credentials en data die toegang geven tot de live-omgeving
   Als alternatief, hebben een aantal escrow agenten een systeem uitgewerkt waarbij de SaaS provider de credentials en andere data die nodig zijn om toegang te hebben tot de hosting omgeving, samen met de technische documentatie van de omgeving, in escrow plaatst. Op basis van de escrow overeenkomst wordt deze informatie dan door de escrow agent vrijgegeven aan de klant in geval van faillissement. De klant heeft dan toegang tot de live omgeving en zal tijdelijk met de software verder kunnen werken indien hij over de technische resources beschikt om de software gedurende een overgangsperiode te onderhouden. In dit geval zal de klant dan ook wel de hostingkosten verder moeten dragen. Deze tweede oplossing kan geschikt zijn voor single-tenant situaties, maar is moeilijker toe te passen in een multi-tenant omgeving waarin meerdere klanten, vaak concurrenten van elkaar, afhankelijk zijn van de applicaties en hun data die in die omgeving worden opgeslagen.
3. Verplichting tot doorbetaling van de hosting provider
   Andere oplossingen zijn er eerder op gericht om tenminste de hosting provider te betalen gedurende een zekere overgangsperiode. Een aantal SaaS providers richten bijvoorbeeld naast hun werkvennootschap ook een trust, een vzw of een gelijkaardige rechtspersoon op, waarin regelmatig fondsen worden gestort die verplicht moeten aangewend worden in geval van faillissement van de werkvennootschap. Deze rechtspersoon zal dan tenminste de kosten van de hosting provider doorbetalen gedurende een overgangsperiode, waarin de getroffen klanten een alternatieve oplossing kunnen zoeken.

Conclusie

Geen enkele oplossing zal in de praktijk waterdicht zijn, en hoe dan ook blijft het de vraag of men praktisch overweg kan met de software indien men geen personeel van de gefailleerde onderneming kan recupereren. Daarbij stelt zich bovendien de vraag hoelang zulke overgangssituaties stand moeten houden, in het bijzonder wanneer de klant op zoek moet naar een alternatieve oplossing die slechts na verloop van een aanzienlijke periode kan geïmplementeerd worden. In elk geval is het belangrijk dat de afnemers van bedrijfskritische software voldoende anticiperen op deze risico’s en een oplossing uitwerken die de schadelijke gevolgen zoveel mogelijk kan beperken.

Belangrijke vragen bij het kiezen van bedrijfskritische software zijn dus:

1.  Wordt de software on-premise of in de cloud geleverd?
2. Indien het gaat om een on-premise software:
   • Werd er voorzien in een escrow van de broncode ingeval de dienstverlener failliet gaat?
   • Kan men beroep doen op eigen personeel of derden om de software te onderhouden bij vrijgave van de broncode?
3. Indien het gaat om cloud software:
   • Is de dienstverlener voldoende financieel standvastig?
   • Is er een mechanisme voorzien opdat de onderneming bij faillissement van de dienstverlener nog (tijdelijk) toegang krijgt tot de live-omgeving?

In ieder geval is het belangrijk om voldoende te anticiperen op het risico van faillissement van de dienstverlener en hiervoor de nodige fall-back oplossingen in te bouwen. Dit vereist veelal een goed onderhandeld contract met de dienstverlener, dat zowel juridisch als IT-technisch steek houdt.

Bron: Timelex